Re: towards a stable version

From: Kent Landfield <kent_at_hypermail-project.org>
Date: Wed, 15 Sep 1999 09:30:42 -0500 (CDT)
Message-Id: <199909151430.JAA15367_at_landfield.com>


# I'm glad to see this project increasing pace. In order to make the most out
# of it, while at the same time keeping order, I have some opinions what we
# should do:
#
# 1. Feature freeze, bugfixes only. From now on.
#
# 2. Get a stable version out. 2.0stablebeta. This should occur before we
# apply patches from Peter McCluskey and John Finlay. Not that their
# contributions are less interesting, just that we have a lot of new source
# code on the door step and it can take a while to bugfix all that and I'd
# rather have a stable version before.
#
# As Kent just wrote, we're doing our best in cleaning up the current
# version, and then I hope we'll release our first 2.0stablebeta.
#
# 3. Non-beta release sometime. I prefer not setting any dates.
#
# 4. Meanwhile we're fixing bugs for the stable version, we work on the
# feature set for the next version and merge all the code we get from
# people that are decided to be part of the hypermail future. There is no
# limit to what we can include, but more religous restrictions of what
# hypermail should and shouldn't do. We need a lot more discussions around
# several of the topics opened up lately.
#
# We could make sort of a fork in the project to enable us to work on post
# 2.0 things while we're trying to get 2.0 stable.

This is a good course of action.

# I would also like to open the subject about maintaining this project. I
# don't want this head-of-the-class role I've gotten. I would like to see
# someone else shouldering the reponsibility of maintaining and leading this
# project. Kent? Jose? Paul? or why not John or Peter? I want to get back to
# my former role as a "mere" contributor. The reason for this is my lack of
# time and my amount of other projects that also require my attention. There's
# no hurry, but...

What we should do is to form a core team that makes decisions as a team and is recognized as the team.

We have seen that real work can get in the way of any one individual. There should be a release manager assigned by the core team for each new release. That should/would be a different person for each release. That way we get new blood and new ideas in and releases aren't delayed as much by real-work situations. The core group would decide on the needed fuctionality. Then the release manager would be responsible for making the specific decisions as to what goes into that specific release and the timetables to make that happen. We could focus on a specific set of features and work more efficiently towards getting that release out on a timely and projected basis.

Instead we have seen this loooooog running beta cycle of "nearly ready to release, add new features, unstable again, debugged, nearly ready to release, add new features, unstable...

This approach would require that we discuss the features we want to see get in before we start with a specific release and be much more focused and timely.

-- 
Kent Landfield                        Phone: 1-817-545-2502             
Email: kent_at_landfield.com             http://www.landfield.com/
Email: kent_at_nfr.net                   http://www.nfr.net/
Search the Usenet FAQ Archive at http://www.faqs.org/faqs/
Search the RFC/FYI/STD/BCP Archive at http://www.faqs.org/rfcs/
Received on Wed 15 Sep 1999 04:32:27 PM GMT

This archive was generated by hypermail 2.2.0 : Thu 22 Feb 2007 07:33:51 PM GMT GMT