Gennadiy Rozental wrote:
"Rene Rivera" <grafikrobot@gmail.com> wrote in message news:46647897.5030204@gmail.com...
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.
My solution doesn't require ANY of that. Let me repeat NONE.
Gennadiy, with all due respect, I wasn't talking about your solution. I was talking about Beman's proposal. I think it is a wasted effort to consider proposals and solutions that I can read concise documentation for. It's almost impossible to comment on them otherwise. So for all those thinking that their way is better, please write it up and we can consider them individually.
Well, high-availability/quick responce would be nice. But it's optional.
According to Beman it's essentially required.
* Bugs attributed 1.34.0 <http://tinyurl.com/2cn7g6>, and only a small number of them are targeted for 1.34.1.
I see only 6 bugs assigned to 1.34.1. To be frank with you I don;t see why do we need to hurry with releasing them.
The *whole* page is 1.34.0 issues, and only 6 of the 47 are slated to be fixed. One of them in particular, the one I've been trying to fix for days now #1025, gives incomplete installs for Windows Cygwin and MinGW users. This is something we don't detect, because we don't test Boost from a users point of view.
* The inspection reports 193 non-license problems, and *1059* license problems.
This is not a showstopper IMO. 1.34.0 in the same state isn't it?
I didn't say anything about "show stopper". I said it doesn't make it "stable" according to Beman's definition in which he states that clearing the inspection results is part of making it stable.
* We don't test the build and install process.
What do you want to test? In any case it doesn't make release "unstable"
I think first part of that was already answered. Yes it makes it "unstable" from the POV of users. If you can't guarantee that users will get an install they can use, how can it be stable?
* We don't test libraries against an installed release.
What do you mean?
I think Doug answered this... We don't test the *using* of Boost libraries. We only partially test the conformance of the code to expectations of library authors.
* We don't test, to any effective means, 64 bit architectures.
* We don't test, to any effective means, multi-cpu architectures.
Would be nice ... in future releases. It doesn't make current unstable.
It makes it unstable as soon as user asks why Boost doesn't work in 64-bit mode. And it makes it unstable when users complain that their program crashes in a Boost library when they run it on a dual-core, or dual-cpu, machine both of which are common now.
Let's me clarify again: do you believe 1.34.0 can't be used as stable starting point? If not, why?
Yes, it can't be used for a stable starting point. Because it is not proven stable, with testing, under the conditions users would operate under. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo