[boost] Point Release Management and Development Sponsorship (WAS Re: [next release] Any new libraries ready for the nextrelease?)

From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2008-08-27 05:29:43

On Wed, Aug 27, 2008 at 4:42 PM, Bjørn Roald <bjorn_at_[hidden]> wrote:
>
> I agree in general that point releases are important.  However I get the
> nagging feeling there will always be a conflict of interest between moving
> forward in features and the maintenance of released libraries features.
> One question to address here is whether to let library authors and a main
> boost release team focus on the moving forward part and let others do the
> maintenance part as far as mechanizing the point release process.  Some
> collaboration between the two efforts would be natural and beneficial for
> both, but I think it is important that this does not become intrusive.  As I
> see it there are two great reasons for loving boost, it move C++ forward and
> it provide great production quality libraries.  I hope both these can be
> taken properly care of without getting in each others way.
>

I like this idea of having many release managers worry about the
releasing of suitably tested and properly packaged point/major
releases of the library. This way boost library authors can
concentrate on maintaining a single version of the library -- the one
in trunk for example -- which passes a test suite and performs as
expected.

What I see though is that the problem with this approach is/are the following:

* Changes to libraries can only be made by library
authors/maintainers, so if a bug is filed against a certain release
(1.35 for example) fixing it would be the responsibility of the
authors/maintainers of the library on that branch/release. If it was
possible to have bugs fixed by others in a given branch and changes
are licensed under the Boost Software License, then letting the
authors/maintainers worry about the latest and greatest version of
their libraries would be feasible -- and changes from releases are
then submitted 'upstream' to be integrated to 'trunk'.

* Currently, a release branch is cut from the previous release branch
and changes for individual libraries are cherry picked and merged "as
seen fit" by authors/maintainers. If it was possible to cut a major
release branch from trunk and let a team do the cherry picking of
changes that get into trunk back into the major release branch, then
the quarterly release can still happen -- one team maintains 1.36
(stable), another 1.37 (latest). Debian has the same process of having
a 'stable' branch which lives on its own and has a team managing it
(and bug fixes that need to go out), an 'unstable' branch which has
the greatest flux but lots of testing as well, and a 'testing' branch
which eventually comes from 'unstable' to get merged with (and
becomes) 'stable'. Changes from 'unstable' that pass the testing
criteria are then merged to 'testing', gets tested, and once it passes
gets merged into 'stable'.

* Back-porting changes from trunk to point releases as well as
'up-streaming' a patch from point releases to trunk is a tedious
process which can only be managed by people other than the library
authors/maintainers. This opens up the possibility of greater
contribution and opportunity for those who want to contribute to be
able to do so without having to contend with the authors'/maintainers'
time and bandwidth. If we let authors/maintainers of libraries
concentrate on making the libraries better -- supporting new features,
experimentation, testing, etc. -- instead of asking them to do the
merge and maintenance of released versions, maybe we can stick with
the quarterly releases branching from trunk, and letting released
versions get maintained at their own pace. We can then start retiring
older versions of the library and mark them as 'unsupported' after a
certain period of time without having to ask authors/maintainers to
keep worrying about previous releases and users of these previous
releases.

>
> Test resources are essential and hard to find.  Could testers be set up with
> some sort of master schedule managed by a boost test manager so they test
> various branches/tar-balls as required and report appropriately?  That way
> the maintainer working on a point release could as required request testing
> on wide range of platforms without having their own costly setup.  Somebody
> need to be the manager of test resources and give priority as appropriate by
> controlling the testing schedule to make this work.
>

One possibility in this regard is to encourage the use of virtual
machines in the testing of libraries. Although severely limited, for
instance testing of Sun compilers on OpenSolaris and Intel compilers
in Linux can be done inside a Virtualbox/VMWare image. Interested
testers would just have to set these virtual machines up and offer
them as downloads somewhere that people can play around with.

One thing that comes to mind is testing of specific compiler versions
-- Intel 9/10 on Linux x86, GCC 4.1/4.2/4.3 on Linux x86, etc. --
which can be done by many people at the same time. Patches can be made
from within the virtual machines and submitted to authors/maintainers
in a systematic fashion for application into release branches and/or
trunk.

>
> Some boost-users (or more likely their lawyers and managers) also would like
> licenses under more  traditional commercial terms.  Don't ask me why -- but
> it seems to be a fact of life.  Companies such as BoostPro should be free to
> be maintainer of released major versions and free to dual license as needed
> to allow all developers to use boost.

IANAL, but the current version of the license is very
commercial-software friendly. Can't this be explained to these users
instead of allowing the "corruption" of the license by allowing
dual-licensing?

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.