From: Beman Dawes (bdawes_at_[hidden])
Date: 2007-06-06 23:03:11
Rene Rivera wrote:
> Gennadiy Rozental wrote:
>> "Rene Rivera" <grafikrobot_at_[hidden]> wrote in message
>>> Thomas Witt wrote:
>>>> Douglas Gregor wrote:
>>>>> On Jun 4, 2007, at 10:10 AM, Beman Dawes wrote:
>>>> I was going to write this email, but Doug beat me to it.
>>> And I guess you both beat me to it... As I was busy spending all my free
>>> time trying to fix bugs for 1.34.1. Although what's below are not my
>>> only thoughts on the release procedure...
>>>> The proposal seems to assume infinite resources in testing.
>> Which particular part?
> On-demand testing, testing of breaking-stable branch, continuous testing
> of stable branch, all with high-availability and high-. Currently we can
> only manage partial testing of *1* branch, in one build variation. And
> now we are talking of testing at least three branches at once.
But under the proposal we do not have to test entire branches. Instead
of testing all rows for all columns, we only test a usually small number
of rows against some of the columns. Together with a reduction in the
number of machines running release branch tests (as others have also
suggested), the net effect may well be a drop in the total testing load.
>> Can we get strait to the point?
>> What is required to make stable release? (Complete list)
>> Why 1.34.0 is not stable?
> Complete, interesting thought :-) I can't say I have such a complete
> list. But perhaps this will give you and idea:
> * Bugs attributed 1.34.0 <http://tinyurl.com/2cn7g6>, and only a small
> number of them are targeted for 1.34.1.
> * The inspection reports 193 non-license problems, and *1059* license
> * We don't test the build and install process.
> * We don't test libraries against an installed release.
> * We don't test release versions, even though this is the most used
> variant by users.
> * We don't test, to any effective means, 64 bit architectures.
> * We don't test, to any effective means, multi-cpu architectures.
Stable doesn't mean perfect. It only means no worse than on the last
release. And in practice each release will be better, so the bar for
stability keeps getting higher. Eventually, all of the issues you
mention will be dealt with, but releases should not be held waiting for
that state of perfection.
>> I believe spliting the directory structure will our life way simple in many
>> prospectives. What complications do you see?
> It increases the number of combinations that need testing. And in
> complicates the build and testing infrastructure. Both of which increase
> the likelihood of instability.
The Boosters as a whole should only be concerned with testing for full
releases. If particular projects want to do library specific releases,
it is their responsibility to do the testing of those releases.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk