interim release strategy

["Roy T. Fielding" <fi...@ebuilt.com>]

> I am tracing a potential problem with mod_setenvif and conditional
> logging.  It may already be fixed in 1.3 HEAD, and an artifact
> of the IHS 1.3.6.4 version where the problem is being seen,
> but if not I would like to get a fix in for 1.3-STABLE.
> 
> Now is probably an excellent time for Roy to expound in
> detail on what his nomenclature would mean for this next
> release..

I was only going to apply it to the 2.0 releases, at least until
the nomenclature itself is stable.

There really isn't that much different from our current release
strategy except:

   1) the RM can tag the tree with a new version whenever they
      think it is buildable and is an improvement over the last
      released version of that tree;

   2) everyone should make a habit of noting things in STATUS
      whenever they think the tree is not buildable (or they are
      just about to do something significant that the RM should
      know about);

   3) nobody talks about releasing something until after it has
      been built and tested;

   4) nobody freezes the tree -- if it so happens that the tree is
      screwed at the point it was tagged, we just keep going;

   5) nobody gripes if we go through 52 minor versions a year.

What is the difference between stable and current?  No feature/fix
gets added to stable until after the same feature/fix has been added
and *released* in current, or (iff it cannot be tested in current)
the fix gets three +1 in RTC mode.  No architecture changes in stable.
No API changes in stable.

BTW, I would have tagged a 2.0 release last weekend, but it wasn't
buildable.  Also, I need to move Announcement out of the build tree
and move versions out of httpd.h, just to avoid some of the simple
errors that frequently ruin builds.

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.

....Roy

Re: interim release strategy

["Roy T. Fielding" <fi...@ebuilt.com>]

> > 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.

....Roy

Re: interim release strategy

["Roy T. Fielding" <fi...@ebuilt.com>]

> >    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

Re: interim release strategy

[rb...@covalent.net]

>    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.

>    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.

> 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.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------