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