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: interim release strategy
Date Fri, 02 Feb 2001 20:13:52 GMT
> >    3) nobody talks about releasing something until after it has
> >       been built and tested;
> 
> I dislike this.  IMHO it is a good thing for us to shoot for
> releases.  Without something to aim for, we could all be going in
> different directions.  I really want to see everybody aiming at the same
> general thing.

We are SUPPOSED to be going in different directions!

Collaborative open source only works well when each person is working
on what they believe to be most important, according to their own personal
or company goals, and according to their own personal work schedules
and available free time.  Some portion of that will also be to the group's
benefit, since nobody gets any benefit until the code is released ---
it takes at least three happy campers to produce a release.

The only time everyone aims at the same thing is when they are being
employed to do so or when they have joined a cult.

> >    4) nobody freezes the tree -- if it so happens that the tree is
> >       screwed at the point it was tagged, we just keep going;
> 
> I also dislike this.  A code freeze is a useful tool.  It allows us to
> stabilize quickly, because we are stopping adding new features.  At the
> very least, we must have feature freeze, and I would hope a thirty minute
> freeze for the actual tagging would be acceptable.

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.

We don't need a freeze, and especially not a feature freeze, because
it is extremely rare for the tree to be in a state between features.
This doesn't mean that the RM shouldn't tell people that they are
about to tag the tree, and it doesn't mean that committers shouldn't
use their own good judgement as to when something is committed
to the tree.  It simply means that we don't need to spend days upon
days arguing about when these things should happen, or spend weeks
holding our commits just because someone feels that a particular day
would be a nice day for a release.

Like I said, we can do this because, if it turns out we were unlucky
and the tag point does not correspond to a stable tree state, then
we just don't release that version.

Right now we spend far too much time managing the release process
(and yet never producing releases as good as those pre-1.1), while
at the same time telling most of the group to stop what they are doing
so that we can obey one person's arbitrary release schedule.  I think
we spent more time in 2000 being in "code freeze" mode than in
normal "just do what needs to be done" mode.  Fuck that -- we've been
doing it for three years now and it doesn't work.  The problem is that
it makes it nearly impossible for part-time volunteers to work on
the code with any degree of satisfaction.

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.

> > Right now I'm midway through replacing buildconf.  I was planning
> > to get it all done this week and tag something this weekend, but
> > a long-time friend has decided to surprise me with a visit this
> > weekend.  Ryan, feel free to tag the tree and build a tarball
> > this weekend as soon as you think it should be done (after all,
> > it only needs to be better than the last time we tagged).  We
> > can update the nomenclature later.
> 
> I may tag this weekend, or I may not.  I would really like to see more
> people comment on this approach, and make sure it is where we want to
> go.  I am also going to get home tomorrow at around 1:00, so I will most
> likely want to spend Saturday with my wife.  So if I tag, it will be
> Sunday.

I wanted to be sure that I wasn't holding you up if you were planning
to work on it.  Personally, I'd be happy to let anyone with commit
access tag the tree whenever they think it builds on all the major
platforms.  The role of RM was intended to simply coordinate testing
and pick up stray patches from non-committers, not to manage the
goals of the group.

....Roy

Mime
View raw message