Re: [boost] 1.34 Release Plan - an alternative view

From: David Abrahams (dave_at_[hidden])
Date: 2006-01-26 11:02:09

"Robert Ramey" <ramey_at_[hidden]> writes:

> I understand that as boost gets bigger it gets harder to make
> new releases.  There is more to do, more to keep in sync,
> and more ripple effect in changes.  I see this more structured
> and formal release procedure as an attempt to deal with this.
> It seems to aim for a closer coordination of developement
> and release efforts to avoid difficulties associated with
> development of software libraries which have varying
> degrees of coupling.  I sympathize with with the effort.
>
> I would summarize the general idea as getting developers
> more "in sync" through different stages of development
> and release.  I see this as getting more difficult as boost
> gets bigger and more diverse.  The development of different
> libraries can't really be "scheduled".
>
> So I think this is the wrong approach and I think it will
> make things harder rather than easier.
>
> I would propose a different way of going about this.  Here
> it is.
>
> For the moment, exclude those packages related to
> building and testing from consideration - I'll address
> those at the end.
>
> a) developers build and test their libraries on their local machine
> against the latest release.
>
> b) when they think they are ready, they open a branch on the
> main trunk and check in their "next release".  So the cvs
> system will have a branch for every developers "next release"

I'm not opposed to the general direction you're going in (in fact I'll
cautiously say I like it ;->), but there absolutely needs to be room
in the plan for developers to use the CVS/SVN repository for checkins
during the development of their "next release."  Making large changes
on a local machine without small intermediate checkins is a recipe for
disaster.  You may be comfortable with it, but it's generally not
considered to be good practice and I wouldn't want to consign the
other Boost developers to working that way.  It has to be possible to
make small changes, test, and check in repeatedly.

One way to do it is to create a branch for the next release of a
library, then create a branch of that branch for any intermediate
checkins that are not intended to result in a "releaseable state."
But then, what is the trunk for?  Instead of using a branch and a
meta-branch, why not the trunk and a branch?

> c) when checked in - the developer will queue up a test request
> on the new branch.

What happens with that test request?  You don't expect the testers to
test each branch separately against the last stable release of the
rest of Boost, do you?

This would be a lot simpler if developers would just keep the
library's "next releaseable state" on the trunk.  Of course, that's
what I try to do with my libraries, and I think most of the other
developers do, too.  The only reasons the trunk has seemed to get
destabilized in the past is that some people seemed to be allergic to
using branches (so they'd do intermediate development on the trunk),
and some others did not view failures on the trunk as something to be
avoided (see "test-driven development").

> d) when the the test results show that the "next library release"
> is "ready",  the branch is merged with the main trunk.  The
> complete regression test is then run.  There "should" be no new
> errors but there might be cases where the library developer has
> inadvertently changed some undocumented behavior which
> might show us as some error.  Also there might be cases where
> the other parts of boost detect an error which has not been
> detected in the library test suite.  These should be only a few
> cases.
>
> e) Once tests a d) above pass, the boost library version is incremented
> and a new release is emitted.
>
> f) At this point, working developers would update their local development
> copies of the CVS tree.
>
> In this system:
>
> a) Each library could be developed at its own pace an schedule.
> There would be not rush to "make the next release" with all the
> problems that that causes.

Having thought about the way you're proposing to use branches, I don't
see much difference from the situation we have today.  I certainly
don't see any difference in the (dis)incentives to "rush features to
make the next release."  IMO the greatest thing we can do to make that
less of an issue is to shorten the release cycle, so that if you miss
this release you know there will be another a couple of months.  That
was something the moderators (those who were present) discussed at
Mont Tremblant, and Thomas' upcoming release was part of that plan.

> b) The latest release of Boost would more up to date.  That is, one
> wouldn't be in the situation of needing the next ehancemet, knowing
> its already in there but not being able to use it because the next
> release isn't ready yet.

I don't see how your suggestion would make any difference in this
respect either.  The fact that, under your plan, a library author
doesn't put his work *anywhere* in the repository until he's sure it's
ready for release isn't going to keep the release any closer to the
latest state of development.  It just keeps the latest state of
development on private machines.  Of course, Boost is a community, so
this state will migrate to wikis, the vault, and personal websites as
library authors collaborate and try to get users to exercise some of
their new ideas.  If you check your latest releaseable state into the
trunk then at least it gets tested and you can find out what the
problems are.

Again, the best thing we can do to make sure that the latest release
of Boost is "more up to date" with the latest enhancements from
library authors is to shorten the release cycle.

>  c) Testing resources would be used much more efficiently.  Basically
> more testing would be focused on areas that are likely to have problems
> and less testing is focused on things that "almost for sure" should pass.
> Testing would be done only where and when changes have been made.

How so?  What about this plan would cause this effect?  I don't see
it.

> Code  for building and test are special cases and would have to be
> considered individually.  Certainly Jamfile/toolset updates could
> be work with the above system.  Movement to V2 wouldn't fit here
> and would have to be considered how to do this.  Boost.Test enhancement
> would require some consideration as well.  In general - code breaking
> changes would have to be considered specially.
>
> Basically, I don't believe the current Boost developement model is
> scalable and I think the procedure has to change to recognise this.

That has been recognized, and we are changing it.  Boost is getting to
be a big ship; changing its direction has significant cost, so there
needs to be an obvious and plausible cause-and-effect relationship
between any changes to procedure and the results we want to achieve.
I agree with all your goals here, but I don't see any way in which the
specific suggestions can improve things.

> So in my view the current proposal goes in exactly the wrong
> direction.

What proposal?

Thomas is the release manager for 1.34.  What he posted was his
release plan and schedule; it's his perogative.

The release procedure takes a sensible approach from a Boost-wide
point-of-view, by which I mean that it is specified at a level that
can be managed by a release manager -- and it is the only approach
that I know of that's been shown to work for large project releases
with many independent but related development efforts.  Before
choosing a different one, I would want to know that it had been shown
to work in large projects like Boost.

It may be that we need a library-level procedure to be developed, so
that developers understand how to use branches and the testing system
to accomplish the goals we share.

> Note that this is starting to occur by necesity.  Multi-index has a "beta"
> version compatible with 1.33 that one can download.  I've been
> testing changes to serialization on my machine against 1.33.  I haven't
> checked them into the HEAD.  So now I know what problems are
> mine and what problems are associated with changes in compiler
> versions, stlport versions etc.  My next step is to make a few more
> changes, run some more tests locally (basically later version of stlport)
> and upload a package similar to Joaquin's.  This would make the
> changes (mostly bug fixes and documentation upates) available
> to those who need them now and also give those who want to help
> me out a way to test my changes without waiting for the next release
> when it will be too late to fix anything.

You could have done this much more reliably (and, IMO, more easily) by
doing the development on a branch off latest release state and merging
each one into the head as you become satisfied with it.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com