From: Bjørn Roald (bjorn_at_[hidden])
Date: 2008-08-27 04:42:52
John Maddock wrote:
> David Abrahams wrote:
>>> At some point in the future we can reevaluate that. If we change over
>>> to CMake someday, perhaps testing will become so easy that a lot of
>>> resources are freed. Or maybe as we refine the quarterly release
>>> cycle, quarterly releases will become so automatic that we can divert
>>> resources to point releases occasionally. But not now.
>> That's fine with me, as long as we all understand that the new system
>> where there is a single "release" branch does not accomodate point
>> releases. Should we decide to start making point releases, we'll have
>> to change the system again.
>> Anyway, maybe being able to tell people straight out that Boost
>> doesn't do point releases will help explain things to the many people
>> who have been asking how the current system can work.
> I was wondering about this earlier today, what if we alternated point
> releases and full releases? We should as Beman says get the current
> system semi-automatic *first* of course!
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
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.
The rest of this post is some thoughts on how maintenance for former
releases could work if it is a separate responsibility from the moving
forward effort. If the current boost team are let off the hook as far
as point releases, who can then maintain the released versions?
Individuals, organizations, or commercial entities need to be offered
the needed tools and formal role needed to take responsibility for
maintenance of one or more released major versions. These entities may
be sponsored in the way they like to perform this work. I think there
is a clear interest and possible marked for this. The hope that this is
possible without making the result end under a closed license or in some
other way or form of limited distribution.
Source of fixes would be patches and suggestions for official hot-fixes
provided by anybody in a systematic way (e.g. trac tickets). Careful
merging of none-breaking fixes (trac tickets) from new major releases is
also a possible source. Direct work by maintainers of point releases
should be published so fixes is sufficiently available for maintainers
of other branches.
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.
Some centralized management role in boost community controlling what a
can go into a point release and what is worthy of a point release seems
needed. With this there is a chance of a system that can be recognized
between the major releases. I bet the next "future" discussion will be
of multiple levels of releases so this is subject is something to keep
attention to. Multiple levels may allow a 1.34 version with asio and
expressive but no (or few) breaking changes on old libraries.
Migration tools between major versions of boost is another possible need
that I think is best left to those that may benefit from making and
providing them commercially or otherwise. I do not think the boost
library developers should need to be concerned with this.
Some additional things that come to my mind is:
Users of boost are developers. They are lacy and need some help in
understanding why they should,,and how they go about, getting their
company to sponsor boost point release maintenance. A possible idea
would be web pages explaining to developers and managers that sponsoring
is optional, but how it will give their developers certain levels of
attention from maintainers and generally help provide point releases so
fragile patching or costly moves to new breaking releases can be
avoided. I think it is best to avoid open options to pricing as
developers are lacy and do not bother the extra work of trying to figure
and argue for an amount that make sense to pay. Give some fixed
options with various terms as this is much simpler to relate to. Each
maintainer of former releases releases should publish which of the
options they prefer and support either on their own web page or in some
agreed way on the boost pages. The last option sounds better to me but
will require some official boost management and may be fragile.
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.
-- Bjørn > > John. > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk