First things first: I want to call this program "Boost.Guild." Agreed? At Sat, 06 Nov 2010 08:55:31 -0500, Jim Bell wrote:
Say you have a team of volunteers attacking failed regressions and tickets. They're creating (hopefully) good trunk patches. They can't commit to the trunk, but can modify tickets.
If maintainers are active, they could review and incorporate them. But this increased activity may be more of a strain for them. If maintainers are MIA, it won't happen.
So we need at least one person to bring these changes back into the trunk. Changes to libraries they're not familiar with.
BoostPro is willing to commit resources to help with that if there's someone else (like you) running the program with us. We'll need a list of libraries whose maintainers authorize such changes, and libraries whose maintainers want to control all changes themselves.
What's the best way for the volunteers to signal to these trunk-authority people to pick up their change?
A Ticket keyword and corresponding report should work. Is there a better way?
I can't think of one.
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.
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? -- Dave Abrahams BoostPro Computing http://www.boostpro.com