apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: httpd-2.0/apr/apr-util Code Freeze
Date Fri, 09 Mar 2001 14:10:48 GMT
I don't think it has anything to do with mechanics, nor will throwing more
process at the problem fix it. (more process will simply bog down what we
can accomplish)

No... the problem is about perception. The rate of change recently has just
been quite high. It just isn't very conceivable to make a release in that
environment.

The other side of the coin is what the result of the tag/roll is. We had
some slight problems in the Windows .mak files. OtherBill went and patched
those up, and created a new zip file. Do we know the quality? No, but we
know it (at least) builds. So we ought to just toss it out there as alpha.
Believing it to be more than alpha is also a bit alarming. We *just* fixed
some serious problems in the C-L filter, and had some pretty big work in
mod_include.

Cheers,
-g

On Fri, Mar 09, 2001 at 02:28:51AM +1100, Luke Kenneth Casson Leighton wrote:
> > create a release based on an ongoing frantic development tree, all you
> > have to do is selectively tag the repository to include only those
> > revisions that you consider to be stable.  There is no rule that requires
> > the entire HEAD to be tagged at once, and there is nothing wrong with
> > moving tags from one revision to another within CVS *provided* that
> > such moves are made before a tarball based on that tag is released.
> 
> roy,
> 
> sounds like you already appreciate the need for partial /
> selective tagging.
> 
> the difference between what you propose and what i propose is that the
> _developers_ must use - on a daily basis - selective / partial tagging -
> _not_ the release manager.
> 
> then and _only_ then can this rule be applied and be more confident to
> work: "no developer shall commit code to cvs main if it don't work / ain't
> stable".
> 
> of course, you can't fix all the bugs, and you can't forsee what might
> happen if two developers do two cvs merges simultaneously from two of
> their partial-cvs-tags, but we have that already on a smaller-scale on a
> per-file basis: you can't forsee what might happen if two developers fix
> the same problem in the same file in different ways!
> 
> that's the trade-off you get with concurrent versioning.
> 
> luke
> 
>  ----- Luke Kenneth Casson Leighton <lkcl@samba-tng.org> -----
> 
> "i want a world of dreams, run by near-sighted visionaries"
> "good.  that's them sorted out.  now, on _this_ world..."

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message