Given the recent "incident" about users complaining about updates to boost and the fact that we have a wounderful METHOD that gave us so much respect and popularity, I'd like to propose something that's been in my mind for quite some time. The very high quaility of boost libraries is due to the so-called BOOST METHOD (I just coined the term, but how I like it :): the managed and peer-reviewed acceptance process. But there is a "hole" in this method, once a library is accepted the mantainer can do whatever it pleases with it. Of course we all assume and expect the maintainer to keep its hight quality, but this is a deviation from the basic "peer-reviewing is a requirement" principle. If the assumtion here were grounded we could just as well accept libraries directly because we trust the good jugdment of the author; but we don't, and there lies our "credibility". I really think is time to come up with a "direct-update" vs "managed-update" policy. The policy would define which updates can be directly executed by the library mantainer and which need a "formal update rewiew". Naturally, the formal update review should follow the same rules as the formal acceptance review. At the very least, interface-breaking changes should require a formal update review IMO. What do you all think? -- Fernando Cacciola SciSoft http://fcacciola.50webs.com/
Ronald Garcia wrote:
On May 10, 2006, at 3:09 PM, Fernando Cacciola wrote:
Given the recent "incident" about users complaining about updates to boost
What "incident" are you referring to?
Sorry.. It started with one of the responses here: http://groups.google.co.uk/group/comp.lang.c++.moderated/browse_thread/threa... which David Abrahams reported in our list two days ago as: [filesystem][program_options][serialization][test] fromcomp.lang.c++.moderated Fernando
"Fernando Cacciola" <fernando_cacciola@hotmail.com> writes:
Given the recent "incident" about users complaining about updates to boost and the fact that we have a wounderful METHOD that gave us so much respect and popularity, I'd like to propose something that's been in my mind for quite some time.
The very high quaility of boost libraries is due to the so-called BOOST METHOD (I just coined the term, but how I like it :): the managed and peer-reviewed acceptance process. But there is a "hole" in this method, once a library is accepted the mantainer can do whatever it pleases with it.
That's not a hole; it's essential. If the maintainer couldn't do what he or she pleased with the library, nobody would ever submit one.
Of course we all assume and expect the maintainer to keep its hight quality, but this is a deviation from the basic "peer-reviewing is a requirement" principle.
We have that requirement for entry, but not for maintenance, and it's intentional.
If the assumtion here were grounded we could just as well accept libraries directly because we trust the good jugdment of the author; but we don't, and there lies our "credibility".
Well, there's a "Zen of Boost" that I think you fail to appreciate here. We maintain the tension between autonomy and ownership on the one hand, and oversight and review on the other. It's one of the key things that's made Boost successful, and I wouldn't want to change it. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams escreveu:
If the assumtion here were grounded we could just as well accept libraries directly because we trust the good jugdment of the author; but we don't, and there lies our "credibility".
Well, there's a "Zen of Boost" that I think you fail to appreciate here. We maintain the tension between autonomy and ownership on the one hand, and oversight and review on the other. It's one of the key things that's made Boost successful, and I wouldn't want to change it.
I suppose this conflict of interest would not be as important if the Boost library release process would separate (more frequently) bugfix releases from new features releases. Today, anyone worried about API stability is forced to upgrade to API-breaking versions for bugfix purposes. If there were more bugfix releases, like there was a 1.33.1, and in _those_ releases API did not break, then the community could just say: you want stability? Keep with the older. You want new features? Be prepared to adjust your code. This way, instead of constraining how authors can evolve their libraries in HEAD, a new responsibility of paying some attention to older branches and backporting fixes to them is added. Of course, it's easy to suggest other people should have _more_ work to make _our_ lives easier... -- Pedro Lamarão Desenvolvimento Intersix Technologies S.A. SP: (55 11 3803-9300) RJ: (55 21 3852-3240) www.intersix.com.br Your Security is our Business
Pedro Lamarão <pedro.lamarao@intersix.com.br> writes:
David Abrahams escreveu:
If the assumtion here were grounded we could just as well accept
libraries directly because we trust the good jugdment of the author;
but we don't, and there lies our "credibility".
Well, there's a "Zen of Boost" that I think you fail to appreciate
here. We maintain the tension between autonomy and ownership on the
one hand, and oversight and review on the other. It's one of the key
things that's made Boost successful, and I wouldn't want to change it.
I suppose this conflict of interest
I think "conflict of interest" is the wrong phrase here, but I know what you mean.
would not be as important if the Boost library release process would
separate (more frequently) bugfix releases from new features
releases.
I don't know what you mean by "would not be as important." -- Dave Abrahams Boost Consulting www.boost-consulting.com
"Fernando Cacciola" wrote:
The very high quaility of boost libraries is due to the so-called BOOST METHOD (I just coined the term, but how I like it :): the managed and peer-reviewed acceptance process.
The very high quality is due to people who choose to hang out here and contribute. Bigger problem that API changes are abandoned libraries. A tool or a process helping to maintain these libraries is needed. Even visible marking of these libraries is missing. Effective and visible way to collect bug reports does not exist (I much appreciate the work of Marshal Clow but tool support is necessary, IMHO). There's no way for people to contribute with small examples to amend the often insufficient documentation. Boost reviews often do not gather sufficient number of reviewers and the official short period needs to be extended almost every time. It is not easy to do review before the official period starts (no versioning of the source, schedule is often missing). Information about abandoned but potentialy handy libraries is not kept anywhere to be picked by someone else. The source code is usually lost. /Pavel
Pavel Vozenilek ha escrito:
"Fernando Cacciola" wrote:
The very high quaility of boost libraries is due to the so-called BOOST METHOD (I just coined the term, but how I like it :): the managed and peer-reviewed acceptance process.
The very high quality is due to people who choose to hang out here and contribute.
Bigger problem that API changes are abandoned libraries. A tool or a process helping to maintain these libraries is needed. Even visible marking of these libraries is missing.
I'd say library adopting should be encouraged: Maybe posting a "Maintainer wanted for Boost.XXX" message would raise some activity in this respect? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Joaquín Mª López Muñoz <joaquin@tid.es> writes:
Pavel Vozenilek ha escrito:
"Fernando Cacciola" wrote:
The very high quaility of boost libraries is due to the so-called BOOST
METHOD (I just coined the term, but how I like it :): the managed and
peer-reviewed acceptance process.
The very high quality is due to people who choose
to hang out here and contribute.
Bigger problem that API changes are abandoned
libraries. A tool or a process helping to maintain
these libraries is needed. Even visible
marking of these libraries is missing.
I'd say library adopting should be encouraged: Maybe posting
a "Maintainer wanted for Boost.XXX" message would raise some
activity in this respect?
I think it might be a good idea to actively remove stigma from abandoning libraries. If Boost.Threads, for example, had been officially marked as "abandoned" a while ago, I think people might've been quicker to consider taking it over. There's always the fear of stepping on the original author's toes. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"Pavel Vozenilek" <pavel_vozenilek@hotmail.com> writes:
"Fernando Cacciola" wrote:
The very high quaility of boost libraries is due to the so-called BOOST METHOD (I just coined the term, but how I like it :): the managed and peer-reviewed acceptance process.
The very high quality is due to people who choose to hang out here and contribute.
I agree with Fernando that our processes are special; they hit a high-quality "sweet spot" for C++ libraries. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"Pavel Vozenilek" <pavel_vozenilek@hotmail.com> writes:
Effective and visible way to collect bug reports does not exist (I much appreciate the work of Marshal Clow but tool support is necessary, IMHO).
The SF tracker works, IMO, even if it's ugly. I'd be happy to run a Trac server for Boost, if that's preferred, but I don't know of a _really_ compelling reason to switch.
There's no way for people to contribute with small examples to amend the often insufficient documentation.
We're fixing that. Rene's incipient site design allows that kind of comment. But anyway, what is this, a random list of complaints? ...snip more of the same... -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (6)
-
David Abrahams -
Fernando Cacciola -
Joaquín Mª López Muñoz -
Pavel Vozenilek -
Pedro Lamarão -
Ronald Garcia