httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: cvs commit: apachen STATUS
Date Thu, 08 Jan 1998 23:27:20 GMT
Sam Robb wrote:
> Jim Jagielski wrote:
> > Unfortunately, this is the problem... We say we're in feature freeze
> > and then don't stick with it. We say, Oh we'll add this, oh we'll
> > add that and we're back to square one... Does anyone think that
> > this would be _better_ with the FreeForAllMode (tm)?  :)
> Um... just an observation from someone on the outside:
> I've been subscribed to, and reading, the new-httpd
> mailing list for about 5-6 months now, I think. Feature
> freeze?  Hardly... in fact, I've been under the impression
> that you were at the start of a new cycle (what with the
> discussions of process models, threading, logging, etc.)
> and that you were working on developing 1.3 instead of
> working on releasing it.
> Who's responsible for the release?  All of you?  Or is
> there one person in charge of keeping everyone focused
> on the release long enough to get it done in a reasonable
> amount of time?

Good questions...

There is a loose-and-fuzzy concept of a Release Manager for Apache.
Basically, this person's job is to coordinate the release of an
official version or beta. They do the grunt work of rolling the
tarball and stuff like that, but it's also their job to "limit"
the addition of new code to allow a release to actually be created.
However, this isn't a good position to be in because it ruffles
too many feathers. The main idea is that, during a "major
release", like going from 1.2 to 1.3, we have a fast a furious
Feature mode, where cool stuff and new features are added to the
code. To make this quicker, Dean suggested, and everyone adopted
what's known as Lazy Voting where a person submits a patch and,
unless they hear a veto after a few days, can commit it. The idea
being that we want to spur as much new code and features at
this stage and it's OK having the code added without any sort
of Group review because the bugs will be worked out during
beta (whew!). After a point where we think we have enough new
features added, we put a freeze on new features and start
beta cycles. When the code becomes "stable" enough to consider
a beta release, a Release Manager (RM) is picked and they try to
guide the group to a beta release.

Unfortunately, everybody in the group are dedicated hackers and love
working code, so it's incredibly hard for people to stop adding
little bits and pieces. The RM should, ideally, monitor this, but
it's a precarious position for obvious reasons... It's hard to
set goals that aren't perceived as deadlines :)

A lot of discussion about the things you mention above were concerning
Apache 2.0, which is in super-conceptual mode.
      Jim Jagielski            |       jaguNET Access Services           |
            "Look at me! I'm wearing a cardboard belt!"

View raw message