Re: [boost] Release Team?

From: Robert Ramey (ramey_at_[hidden])
Date: 2007-09-07 18:24:28

Rene Rivera wrote:

> The short form is - It will be a bigger job, on average, with each
> release as more "components" are added to Boost.
>
>> In my opinion this is 180 degrees in the wrong direction.  It will
>> make things worse rather than better.
>
> Worse how?

By trying to do more things at once rather than less.

>> The right way to think about this is:  Its a bigger job than it used
>> to be - Divide into smaller jobs.  This means just adding one tested
>> library at a time.
>
> That would only partially reduce the work. What about bug fixes to
> existing libraries? What about added platforms? What about
> improvements to release tools? What about release packaging? What
> about bug/issue monitoring? What about release documentation? ...and
> so on for all the things a release manager does.

We've been through all this. each of these things should be tested
against the latest "ready to release".   Each time a developert things
its ready, that one set of changes is rolled into the ready to release
and a tarball is made for release testing.  I that passes, its made
availble to users.

> I suspect we will never have volunteers given the specter of facing
> what Thomas went through

100% agree

>> Now someone is going to say - that's too hard - You're tripling the
>> work !!!
>
> Yes.

LOL - I  knew it.

>> Ahhhh - and why is that?  That's because the build/release system is
>> waaaaay to fragil.
>
> Do you expect the entire release system to be fixed before we do
> another release?

I don't expect a release to have a release system that needs fixing.  I
expect a release system which works advertised - even if it doesn't
have every feature that everyone wants.  Then I expect the release
system - like any other boost component - to be incrementally
improved by the addition of useful features.  I expect the release
system - like I expect of any other boost component to always
work - even though its never finished.  In fact, I expect even more
than that.  I expect every boost component to be shipped with
a way of verifying on the target machine that it does in fact
work the way its documented to work.

>> a) Move to incremental releases
>
> Yes. Which is what Beman and yourself, and everyone else AFAICT, is
> saying. Do you have some other definition of "incremental"? How are
> incremental releases different from previous releases?

Ahhhhh - maybe that's the source of some confusion.  The whole
concept of a "Boost Release" contains in its name that at a certain
point in time, every thing synced up at exactly the same moment.  I
don't that's possible.  What I want is:

a) A release ready branch which hasn't had anything checked into
it which hasn't been proved to work.
b) A simple reliable way to make tarball from the release ready
branch which an be run every time a component has been checked
in and the branch re-tested.
c) A test of the branch whenever something is checked in.
d) To make any tarball which passes the final test available to the
public.
e) I want the same steps above applied to every boost component
which is fixed/improved or enhanced.
f) I DON'T want separate bug fix releases, bug fix branches, etc.

In short - there should be no distinction between incremental release
and previous releases.

In practical terms I would expect a new tarball available to the public
every few weeks.

>> b) Formalize the developement of Boost Build to the standards
>> demanded of other boost components.
>
> Yes, and IMHO Boost Build V2 is of higher quality than some Boost
> libraries. But perhaps you mean the development of release and
> testing, tools and procedures?

Here is my example.  I didn't keep notes so I just speaking from memory.

a)I get SVN on my machine and become more or less comfortable with it.
b) I create a branch on RC_1_34_1 and check it out to my machine.
c) I merge in the changes to the serialization library which have 
accumulated
during the 1 1/2 years while 1.34.1 has been "in release"
d) I re-run the tests for the serialization library.  OK a few problems with
new bjam.v2 syntax.  Now I have a big problem with bjam syntax but
we're not going into that right now.
e) Now I have no way of seeing the results.  The original compiler_status
nor me compiler_status2 don't work anymore due to changes in bjam,
toolset jamfiles and process_jam_log.  This combination is fragil due
in large part that there is no documented interface for passing data from
one component to the other.  Well, I get the squared away - at least on
my machine.
f) Now I run all my old platforms. STLport jam files don't work - This
is from the release platform!!!.  Commeau does't work no information
on how to fix this.  The directory structure has been shuffled around
so anything I had before such as a VC IDE solution won't work anymore.
I big thing for me was to be able to use the profile build variant.  Well
this "sort of" works with gcc.  Whe I ask about this, i'm told that no one
has ever asked about it before and anyway profiling isn't considered
effect for C++ programs !!! I would be inclined to fix it - but the
whole bjam langauge/tools setup is very hard to understand so its
too risky to mess with.  I just make a shell script which walks the
directory tree and re-executest all the tests - about 20 lines of
shell script.

That's the short version - I forgot the rest.

So it takes a huge amount of work and only just now getting
to the point that I was before 1.34 came out.

To a man with a hammer in his hand, the whole world looks like
a nail.

To a group of software library/tool programmers, every problem
looks like it will be solved with a new tool.  Generals (and
politicians - and actually everyone) have the tendency to re-fight
the last war.  That's what we're currently doing here.

Robert Ramey