[boost] Re: Re: [1.33.0] Let's start preparations...

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-03-08 13:31:34

Peter Dimov wrote:
> Victor A. Wagner Jr. wrote:
>> I'm suggesting that the work continue on the mainline towards release
>> and that anyone working on something OTHER than the release, work on
>> a branch.  That way as long as we're playing with CVS the testers
>> don't have to do ANYTHING to their already functioning scripts. The
>> only people who will need to worry about weird labels will be those
>> working on stuff unrelated to the release.
>
> FWIW, I agree with Victor. I'd go further and state that the CVS
> should _always_ be kept in a release-ready form. Any deviations from
> this ideal should be fixed as quickly as possible. I, personally,
> always use the CVS version of Boost, I never wait for an "official"
> release. This model is not well supported. Most energy is invested in
> releases, which makes them very hard to manage (because the effort is
> not amortized over time.)
>
> Scheduled releases are still a good thing because they provide a
> deadline, though.
>

FWIW - I also agree with the idea that we should strive to have the mainline
always "release ready" and that experimentation be undertaken on either
local versions or a separate branch.

There are a couple of fundamental problems with the current situation:

a) testing is not scalable - it now take so much resources that not many can
do it.  As it gets larger, the problem gets worse.

b) testing is a little "too expermental".  There are issues with incremental
build and testing that, if resolved, could make the process less resource
intensive.  This would be helpful.

c) Library developers make their ehancements and run on the compilers that
they have.  Then they have to upload to the main line to "see what
happens" - now the can address issues related to other compilers - But -
now:

i) mainline isn't "ready for release"
ii) other developer whose packages depend on the uploaded "experimental"
code are stymied if the experimental code has a bug.  Now this might cause a
ripple effect and make libraries fail that depend on the "experimental"
upload which wastes a lot of testing resources.

So to really "fix" this a couple of things would have to change:

a) mainline would always have to be considered "candidate for release"
Tarballs would be tested when and only when code where merged from a
development branch into the mainline.  I would expect this to occurr
relatively infrequently - whenever a library maintainer thinks its really
ready.  (guestimate - one or two weeks) The question to be answered by this
testing is "Is this ready for release" rather than "what is the current
state of development".  Whenever a release came up clean it would be labeled
boost 1.32.?? (beta).

b) Users who want to download it would be encouraged to do so and file bug
reports and upload test results to a new "pending issues" test matices.
This would require that the "Getting Started" section of the documentation
explain  the test as part of the installation process.  In fact, we might
even want to make the default install a "test" as a side effect of the test
is building of all the libraries anyhow.  That is - spread the testing
around to make it scalable.

c) Separate development test on the "development tree" would be similar as
it is now except.

i) incremental update, build and test would be used - this presumes some
fixes - including the detection that Jamfiles have been changed and perhaps
library authors being permitted to request a total rebuild.

d) Its time to approach some industry players for more support.  A company
that toutes "Boost Compatibility" on its packaging and or promotional
material has to expect to be hit up for some support.   Such support
could/should consist of:
i) running at least the release testing on their own platforms.
ii) perhaps providing a platform/compiler for running developmental tests.
iii) providing software to developers/maintainers of libraries accepted into
boost.

Note for the above to work - the developemental and release testing has to
be TOTALLY automatic once its setup.

I realize that this might sound ambitious - but I think that boost is on the
verge of bigger things.

Robert Ramey