From: Kent Landfield (kent@hypermail.org)
Date: Wed Sep 15 1999 - 09:30:42 CDT
# 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@landfield.com http://www.landfield.com/ Email: kent@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/