httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <>
Subject Re: interim release strategy
Date Fri, 02 Feb 2001 23:37:47 GMT
> > A code freeze doesn't mean "no new features" -- it means no changes
> > aside from those applied by the RM.  And if it were a useful tool, our
> > current release process wouldn't suck.
> No, the current process sucks because it's only when there's
> a "release date" set, do we see the large influx of "could
> you hold off, I'm just working on this." I tend to believe
> that having a date, tends to spur production, as people
> think to themselves I better get off my duff and commit
> this before it goes out. It's because of *this* that
> code freeze doesn't work as well as it should. (no,
> not totally, but a large reason).

You are right, but need to back up one causal link.  The reason people
feel a need to rush things in is because we only build a release once
in a blue moon.  If the builds were done on a regular, frequent basis
then people will add their changes when they are prepared to properly
code and test those changes, and will be suitably abused if they break
the build without warning the list.  Under normal circumstances, our
CVS tree should always be buildable [the difficult part of this is the
win32 build, which gets broken far too frequently due to the proprietary
make files -- we'll need to fix that eventually].

> > The only thing that a code freeze accomplishes in the way of stability is
> > to prevent anyone but the RM from working on the code.  Yes, it is
> > somewhat more stable, but at too great a cost.  I'd rather take
> > the shotgun approach and determine stability after the fact.
> Nope, recent experiences have shown that stuff added "at the
> last minute" tends to be things that we need to fix again.

If we go with my proposal, then there is no "last minute".

> By making better use of tags, this would be *greatly*
> reduced, but there is too much mix of tag and release
> "versions" to allow us to use CVS as we should.

Yes, which is why the main change is social, not technical -- we have
to stop treating every build version as if it were a release version.
We simply cannot know that until after the build is tested.


View raw message