On 1:59 PM, Robert Ramey wrote:
David Abrahams wrote:
I don't think the volunteers themselves can be authorized to commit to trunk. We need more trusted people to do that. I would like to clarify this. It's not a question of trust, it's more a question realizing that there has to be one person who is responsable for the integrity of the whole library.
I'd say this maps to the release managers. That group being small matters, as you suggest.
In a larger library, many patches and fixes will inadvertantly break something else.
Absolutely. To that end, a diff of every test matrix with the previous one, in some form, would be very useful.
If you want someone to be responsable, he has has to have the authority to control all the changes.
But even the act of tracking down how recently libX/testY/platformZ broke and what broke it is more work than one person can sort out.
If changes go in from more than one person - then no one is responsable.
It seems to me that the real problem here is that some libraries are not being maintained well enough. I realize that this is not easy to fix, but you won't make [up] for the lack of a person willing to be responsable for a library by spreading the authority among another group of people.
I disagree. If a person signs onto a ticket, (s)he takes responsibility for that ticket for its life, so (s)he'd get pulled into working out things cascading from that ticket.
The longer term solution is for boost to be more dynamic and decoupled so that unmaintained libraries eventually can get dropped without creating another fiasco.
I disagree. Perhaps a library would be frozen--no new features--because of a lack of maintainers. But, theoretically, once a regression test works, it should keep working from now until the end of the universe. And if it quits working (for a library that "hasn't changed"), why? 1. Another bug fix for that library broke it. (The guild member for that fix gets involved.) 2. Breaking change in a dependency. (A good candidate for the guild to handle.) 2. Language construct made obsolete, (Another good candidate.) 3. ??? [Chime in here.] I suggest that the main barrier to fixing something that breaks isn't that a library expert hasn't looked at it in sufficient depth, but that NO ONE has looked at it. Thus the guild. Twenty minutes studying it, without any knowledge of the library's internals, could fix many. For some, that could grow into a few hours, but a guild member working at his own pace would knock it out.