On 11/12/2010 5:41 AM, Jim Bell wrote:
On 1:59 PM, David Abrahams wrote:
At Sat, 06 Nov 2010 08:55:31 -0500, Jim Bell wrote:
We'll need a list of libraries whose maintainers authorize such changes, and libraries whose maintainers want to control all changes themselves.
Agreed. I envision active maintainers establishing rapport with guild members whose work they liked.
I don't agree.. We keep promoting library authors to not be part of the Boost community this way. Library authors should accept that once their library is accepted other people in the community will help to maintain *all* of Boost not some sub-Boost. Otherwise we keep having the same problem of having libraries that are not maintained to users satisfaction because the owner is too busy. Once a Boost library is accepted it should become a shared responsibility of the community!
Should we look for a person or two from the volunteers for this role? I don't think the volunteers themselves can be authorized to commit to trunk. We need more trusted people to do that.
I agree. One trusted person should sanity-check marked changes and merge. (And revert!) And a single person would be good in terms of getting to know guild members whose work needs closer scrutiny. (And they could ask other guild members to help with that scrutiny.)
But could this alone be a significant effort?
I disagree, the responsibility of getting verifying, applying, and merging should be shared. Again for the same reasons of Boost being a product of the community. I outlined some procedures for handling this, and allowing trust to build for people, including volunteers, doing this validation. But I guess no one liked my ideas, since no one responded. Oh, well.
A regular schedule (say, twice a week) to run the report and patch would be good, I think. Trunk regressions need time to bake. Sorry, which report?
A Trac ticket keyword query showing the trunk patches that guild members suggest.
In fact, we could build a sophisticated guild workflow using trac ticket keywords alone. I haven't decided if that's crazy or brilliant.
Trac supports custom workflows. So we can adapt it to handle whatever we want in the natural Trac way instead of a kludged tagged protocol.
Should there be a guild mailing list?
Probably, just like we have a testing list for people volunteering testing resources. But, as you know, there must still be some fair amount of communications on the dev list. As that's what the core community will be paying attention to. NOTE: The parts I agree with are cut ;-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail