|
Boost : |
From: Benjamin Kosnik (bkoz_at_[hidden])
Date: 2007-06-07 04:49:26
> > 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:
Thanks Rene. This list was very useful, as was the link to your
presentation at boostcon.
> * 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
> problems.
Why can't these be fixed up for 1.34.1?
> * 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.
Yep. IMHO, this is contrary to most SWE best practices.
> * We don't test, to any effective means, 64 bit architectures.
I'm not quite sure what you're getting at here: can you elaborate?
Certainly, targets that are native 64bit like alpha, x86-64,
ppc64, s390x are tested. Do you mean tested and reported on the boost
regression site? If so, I agree, some reports for 64bit arches
(big/little endian) would be helpful to developers without access to
this hardware.
> * We don't test, to any effective means, multi-cpu architectures.
Again, as above. This can be tested on a local basis.
Or am I confused here? Are you talking about mt testing on single,
dual, quad+ systems? Or some other kind of testing?
I think a more decentralized testing/reporting procedure would help
things greatly. Too much of the reporting is centralized.
-benjamin
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk