From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2007-08-02 12:34:11
Robert Ramey wrote:
> Vladimir Prus wrote:
>> Beman Dawes wrote:
>>> The bottom line is that I know that code works *before* it gets
>>> merged into the stable branch. That's the critical point; the exact
>>> way the testing is done is important operationally, but those
>>> details don't matter as far as the big picture goes.
>> Ok, and what about a case we saw in 1.34.0 -- a library fails
>> on obscure compiler, obscure version. Nobody seems interested to
>> fix that. Are you expecting that tests on all compilers will
>> be run before merge to stable? Or you expect testing on
>> just gcc and msvc?
> Obviously Beman's proposal does not (and cannot) address every problem. The
> criteria for acceptance of the proposal is whether it improves things.
> At this point there shouldn't be too much doubt that it will.
<sarcasm>At this point there isn't much doubt that anything will improve
> The main problem that is addressed by this proposal is that testing
> tests "one thing" at a time to "one" person, so when something fails its
> easy to isolate without everyone looking at all the code. It also
> elminates the requirement that everyone be in sync with their
> next release simultaneously. This is obviously not scalable and
> the source of much agony in the past.
And this is still the part I'm not understanding. If there is one
'stable' branch, and if that's the only reference point, this is IMO
a scalability problem.
Contrast that to the much more radical proposition to make boost modular,
where each 'component' (or however you'd like to call those) would follow
its own release schedule, and a developer can choose which versions of
prerequisite components to depend on, as long as they are actually released.
-- ...ich hab' noch einen Koffer in Berlin...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk