httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@ebuilt.com>
Subject Re: Release Strategy
Date Mon, 05 Feb 2001 23:08:44 GMT
The model I am talking about was used by the Apache Group throughout
the first year of development, with the exception that we were not
using CVS at the time and thus the patch and build process was slower.

I've explained what I intend to do in as many ways as I can.  It isn't
brain surgery.  It is a simple matter of adding a little laxative to
the thought process that is currently going on in the minds of the RMs.
Just tag the tree with the version number and let it be built before
deciding whether or not it is alpha/beta/gold, and don't cry over the
loss of a few build numbers as a result of overactive commits.

I have put far more thought into this than was ever placed in the
current process of calling things alpha or beta.  Go back in the
archives for the 1.2 releases and see for yourself.  I've been asking
for this change for over three years now.  Personally, I'm tired of
being prevented from improving our development process.  It is broken.
Until you propose something that is better, I will proceed with something
I believe will work better than the current process.  If it doesn't
work, then we'll change it again, and keep changing it until we get
it right.  But I am not going to do a field study and write a
dissertation on the subject just because you aren't sure it will work.
I can't even be "sure" that it will work myself -- it is an experiment.
The only question in my mind was whether or not the group felt the
current process was broken, and that was answered with a resounding
"Yes".  

> My current problem with this discussion is that I do not see how this
> model works.  I would really like to see an example of this model in
> practice in an Open Source project.

I don't know of any.  I don't know of any open source project outside
of Apache that had even remotely comparable quality of code as that
of the original Apache development process.  Not even close.

> I am personally not going to be comfortable with this model until I see
> such an example.  I would back the PHP model 100%, because I have worked
> it out in my mind, and I see how it all fits together.  I also know from
> watching PHP that it seems to work, at least it did for the last release
> (the one I was watching).

No process that produces two different code bases with the same version
number can be said to work.  PHP is doing what I proposed *except* that
they allow development to occur after the version has been tagged by
branching the tree into release candidates.  I don't like that model
because it is equivalent to having four version components (the last
one being the rc or patchlevel number, which hasn't been consistently
communicated to the user yet because that process is still being learned).
I think three version components is plenty.

> I have thought about the model that is being proposed, and I have outlined
> my problems with it.  I have not been able to reconcile the problems I
> have with what has been posted on the list.
> 
> I would appreciate one of two things.  1)  A very well thought out
> description for how this all works, assuming the tree never freezes, and
> developers intermix bug fixes with bugs.  2)  An example of an open source
> project that uses this model so that I can look at what has happened in
> the past with that project.
> 
> I believe that either one of those two options would be a very good way to
> prove this model against the real-world.  I would also be very happy to
> listen to some other method for proving how this model would work.  I am
> very reluctant to use this model without first measuring it against some
> other real-world benchmarks.

I already provided (1), well enough that two other people had no problem
interpreting what should be done even though I was off-line for the
weekend.  I'd honestly like to stop arguing about it now so that I can
get back to fixing buildconf.

....Roy

Mime
View raw message