On 15 May 2010 20:32, Daniel Walker <daniel.j.walker@gmail.com> wrote:
On Sat, May 15, 2010 at 1:07 PM, Paul A. Bristow
The main improvement should come from more eyes viewing the code - isn't that the strength of Open Source?
To achieve this we need a way to get more 'candidate code' in real-life use by more people for a much longer period of time.
Ditto. That's the heart of the issue, I think.
I'd also be interested in this. I picture three releases: 1) Boost.Candidate The goal here would be a quick way for people to grab what's out there, find something they're interested in, and, if possible, use it. I'd love to see this "released" automatically every week by a script. Getting in should be as easy as the developer adding the name of their sandbox subdirectory to a textfile in the sandbox root (which would be automatically removed if the script had any problem grabbing everything from that directory). 2) Boost.Main What we have right now. While it wouldn't need any changes, it might help the schedule to say that a library can't go to formal review until there are 3 "accept" preliminary reviews filed, which can be done at any point while the library in question is in Candidate. This would be released twice a year, say Q2 and Q4 (and people can always use it from candidate if they can't wait the extra 4 months over the current process). 3) Boost.Foundation A community vision of TR2. Essential parts that have passed some extra bar. I see this as for portability necessities and things needed to write other libraries, rather than implementations of specific things, so it would probably get Thread and MPL, but likely not GIL or CRC, for instance. I suspect less than half of the current libraries should end up in here. This would get one release a year in Q1, with a bugfix release in Q3 if needed. ~ Scott