Getting volunteers' changes back to trunk
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. 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? Should we look for a person or two from the volunteers for this role? A regular schedule (say, twice a week) to run the report and patch would be good, I think. Trunk regressions need time to bake. Thoughts?
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
On 1:59 PM, David Abrahams wrote:
First things first: I want to call this program "Boost.Guild." Agreed?
Agreed. (I like it!)
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.
I envision it to be self-study and group-study. What do you see my role being? (Besides keeping an e-mail list of members and organizing the lavish annual appreciation banquet. ;-)
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.
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.
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?
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. Should there be a guild mailing list?
At Fri, 12 Nov 2010 05:41:23 -0600, Jim Bell wrote:
On 1:59 PM, David Abrahams wrote:
First things first: I want to call this program "Boost.Guild." Agreed?
Agreed. (I like it!)
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.
I envision it to be self-study and group-study. What do you see my role being? (Besides keeping an e-mail list of members and organizing the lavish annual appreciation banquet. ;-)
General leadership. That means deciding what you think needs to be done and convincing others to work with you in that direction.
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 think we should work hard to keep that direct interaction optional, though, or maintainers may not want to get involved. They need to know that this doesn't necessarily have to be a drain on their resources. Of course, any maintainer can eventually promote a guild member to co-maintainer if all are agreed.
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.
I agree. One trusted person should sanity-check marked changes and merge.
I don't think it has to be just one person, but as I said, we're willing to devote some resources to this.
(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?
Yes, that's why you should split it up. Maybe we have one or more guild liaisons, and have different people doing the commits. I think we may be able to offer some testing resources.
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.
Should there be a guild mailing list?
If the guild members or organizers want one. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
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
At Fri, 12 Nov 2010 10:34:33 -0600, Rene Rivera wrote:
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!
Wow. I *think* I love that idea.
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.
Agreed, but probably not solely among people considered to be (and who consider themselves) apprentices.
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.
I didn't see them. Repost?
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.
yup. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 11/12/2010 10:41 AM, David Abrahams wrote:
At Fri, 12 Nov 2010 10:34:33 -0600, Rene Rivera wrote:
On 11/12/2010 5:41 AM, Jim Bell wrote:
I disagree, the responsibility of getting verifying, applying, and merging should be shared.
Agreed, but probably not solely among people considered to be (and who consider themselves) apprentices.
Right. And that's something I mentioned in my early post...
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.
I didn't see them. Repost?
Here's the post <http://lists.boost.org/Archives/boost/2010/10/172626.php>. It was part of one of the other threads about this. In fact, it was a reply to your post ;-) -- -- 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
At Fri, 12 Nov 2010 10:56:18 -0600, Rene Rivera wrote:
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.
I didn't see them. Repost?
Here's the post <http://lists.boost.org/Archives/boost/2010/10/172626.php>. It was part of one of the other threads about this. In fact, it was a reply to your post ;-)
Ah. I think that one got caught in my "too long to deal with right now" filter. I'll try to get back to it. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 1:59 PM, Rene Rivera wrote:
I didn't see them. Repost?
Here's the post <http://lists.boost.org/Archives/boost/2010/10/172626.php>.
Thanks for reviving this. Sorry I glossed over it, too. Hope you don't mind if I respond generally. There's no way I'd lead an effort like that (without hourly compensation). Not a chance. Tracking all that criteria across all those people sounds like a huge ongoing time commitment. RE SVN access: I say the guild members never get SVN access. Work indefinitely without it. Or if they want it, they run the gauntlet the current volunteers do. (I have no desire to run that gauntlet myself.) RE: Testing requirement (two platforms): I agree. I see the guild as a large pool of volunteers who we call on (for a little help from each). All help is geared toward streamlining things for those more committed. Instead of all the criteria, I say throw it wide open. See who shows up, and what they accomplish. Let the cream rise to the top. (Again, you're not granting SVN access.) Having a big pool of volunteers you can call on to grind out the things many people can do seems very valuable. So my thinking's pretty contrary all around.
At Fri, 12 Nov 2010 13:11:00 -0600, Jim Bell wrote:
On 1:59 PM, Rene Rivera wrote:
I didn't see them. Repost?
Here's the post <http://lists.boost.org/Archives/boost/2010/10/172626.php>.
RE SVN access: I say the guild members never get SVN access. Work indefinitely without it. Or if they want it, they run the gauntlet the current volunteers do. (I have no desire to run that gauntlet myself.)
"The gauntlet" often just involves getting a maintainer to ask the moderators to grant them access. It's not a big deal. I think if a maintainer finds himself repeatedly approving a volunteer's patches, he might well decide it's in his interest. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
At Fri, 12 Nov 2010 13:11:00 -0600, Jim Bell wrote:
On 1:59 PM, Rene Rivera wrote:
I didn't see them. Repost?
Here's the post <http://lists.boost.org/Archives/boost/2010/10/172626.php>.
RE SVN access: I say the guild members never get SVN access. Work indefinitely without it. Or if they want it, they run the gauntlet the current volunteers do. (I have no desire to run that gauntlet myself.)
"The gauntlet" often just involves getting a maintainer to ask the moderators to grant them access. It's not a big deal. I think if a maintainer finds himself repeatedly approving a volunteer's patches, he might well decide it's in his interest. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 11/12/2010 1:11 PM, Jim Bell wrote:
On 1:59 PM, Rene Rivera wrote:
I didn't see them. Repost?
Here's the post <http://lists.boost.org/Archives/boost/2010/10/172626.php>.
Thanks for reviving this. Sorry I glossed over it, too. Hope you don't mind if I respond generally.
There's no way I'd lead an effort like that (without hourly compensation). Not a chance. Tracking all that criteria across all those people sounds like a huge ongoing time commitment.
I think most of the work of keeping track of those counts can be done automatically by Trac.
I see the guild as a large pool of volunteers who we call on (for a little help from each). All help is geared toward streamlining things for those more committed.
Instead of all the criteria, I say throw it wide open. See who shows up, and what they accomplish. Let the cream rise to the top. (Again, you're not granting SVN access.) Having a big pool of volunteers you can call on to grind out the things many people can do seems very valuable.
The problem I see is that funneling through a small pipeline of maintainers that do the commits doesn't solve the problem of getting patches applied. It just prolongs the current bottlenecks to a different set of people. And I would hate to be one of those people given the likely huge workload in doing the commits. The most likely outcome of such a structure would be either: patches slowing to a crawl like now as maintainers don't have the time, or all patches get accepted as maintainers are overwhelmed and avoid doing full reviews. Neither of which is a desired outcome. -- -- 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
On 1:59 PM, Rene Rivera wrote:
[...]
Instead of all the criteria, I say throw it wide open. See who shows up, and what they accomplish. Let the cream rise to the top. (Again, you're not granting SVN access.) Having a big pool of volunteers you can call on to grind out the things many people can do seems very valuable.
The problem I see is that funneling through a small pipeline of maintainers that do the commits doesn't solve the problem of getting patches applied. It just prolongs the current bottlenecks to a different set of people. And I would hate to be one of those people given the likely huge workload in doing the commits. The most likely outcome of such a structure would be either: patches slowing to a crawl like now as maintainers don't have the time, or all patches get accepted as maintainers are overwhelmed and avoid doing full reviews. Neither of which is a desired outcome.
My original topic precisely. The bottleneck now is the maintainers getting their mind around each and every patch (or bug report, and coming up with their own patch). If that switches to a quick sanity-check and commit, I'd think a maintainer could knock them out pretty fast. Would chaos and confusion reign? Or would the risk of embarrassment cause guild members to act with great care? (Guild members, not submitters, mind you: They were motivated enough to sign up, and they can simply not submit anything they're not confident will work.) There will surely be bumps along the way. But if the trunk regression matrix were much greener than it is, that would show problems faster, too. I also envision us whipping up a little script that compares a regression to its previous one, showing newly-broken tests or symptom changes. (Does this already exist?)
At Fri, 12 Nov 2010 13:52:35 -0600, Rene Rivera wrote:
The problem I see is that funneling through a small pipeline of maintainers that do the commits doesn't solve the problem of getting patches applied. It just prolongs the current bottlenecks to a different set of people.
Yep, that's an issue.
And I would hate to be one of those people given the likely huge workload in doing the commits. The most likely outcome of such a structure would be either: patches slowing to a crawl like now as maintainers don't have the time, or all patches get accepted as maintainers are overwhelmed and avoid doing full reviews. Neither of which is a desired outcome.
So what do you suggest as an alternative? I guess I'd better read that earlier message. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 1:59 PM, David Abrahams wrote:
At Fri, 12 Nov 2010 10:34:33 -0600, Rene Rivera 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
On 11/12/2010 5:41 AM, Jim Bell wrote: 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! Wow. I *think* I love that idea.
The guild's whole purpose is to (1) improve boost for the community, and (2) lighten authors' maintenance burdens. If these aren't accomplished, we scratch it. The guild's bias is heavily self-study (IMHO), so to minimally involve the authors. Establishing rapport would be completely at the authors' discretion. And, theoretically, if the guild really is lightening authors' burdens significantly, then some of their new-found abundance of free time might be spent that way. (Rene: Are you saying that library authors should be more involved, or shouldn't be more burdened?)
On 11/12/2010 12:32 PM, Jim Bell wrote:
(Rene: Are you saying that library authors should be more involved, or shouldn't be more burdened?)
I'm saying they shouldn't be more burdened. And I'm also saying they should not have the option to be fully burdened. -- -- 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
At Fri, 12 Nov 2010 12:53:34 -0600, Rene Rivera wrote:
On 11/12/2010 12:32 PM, Jim Bell wrote:
(Rene: Are you saying that library authors should be more involved, or shouldn't be more burdened?)
I'm saying they shouldn't be more burdened. And I'm also saying they should not have the option to be fully burdened.
Hmm, so we dispense with the notion of ownership? That has been a foundation of Boost from day 1. Not saying it can't be overturned, but that would be a radical change. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 11/12/2010 1:01 PM, David Abrahams wrote:
At Fri, 12 Nov 2010 12:53:34 -0600, Rene Rivera wrote:
On 11/12/2010 12:32 PM, Jim Bell wrote:
(Rene: Are you saying that library authors should be more involved, or shouldn't be more burdened?)
I'm saying they shouldn't be more burdened. And I'm also saying they should not have the option to be fully burdened.
Hmm, so we dispense with the notion of ownership? That has been a foundation of Boost from day 1. Not saying it can't be overturned, but that would be a radical change.
Mostly no. The mostly depending on what you consider is owned by an author. Most the effort we expend on libraries, as a community, is in ensuring the design, interfaces, and documentation are up to Boost quality. The implementation of the library is generally less important, and many times takes considerable time, with considerable feedback from the community, to get the best implementation. So I think that the current structure already places a more shared ownership on the implementation. And we are talking about patches here, not about making considerable changes to a library. -- -- 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
On 12/11/10 17:34, Rene Rivera wrote:
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!
I totally digg this idea.
David Abrahams wrote:
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?
modifying the ticket seems to work well - assuming there's an active maintainer.
A Ticket keyword and corresponding report should work. Is there a better way?
I can't think of one.
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. In a larger library, many patches and fixes will inadvertantly break something else. If you want someone to be responsable, he has has to have the authority to control all the changes. 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 of for the lack of a person willing to be responsable for a library by spreading the authority among another group of people. 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 also admit that this doesn't help things right now but there it is. Robert Ramey
At Fri, 12 Nov 2010 16:33:38 -0800, Robert Ramey 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. In a larger library, many patches and fixes will inadvertantly break something else. If you want someone to be responsable, he has has to have the authority to control all the changes. If changes go in from more than one person - then no one is responsable.
I think I understand what you're driving at, but if what you said were strictly true, there would be no working partnerships in the world, right? There is such a thing as shared responsibility. However, it's true that you probably can't spread it uniformly across the community. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 11/12/2010 9:33 PM, David Abrahams wrote:
At Fri, 12 Nov 2010 16:33:38 -0800, Robert Ramey 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. In a larger library, many patches and fixes will inadvertantly break something else. If you want someone to be responsable, he has has to have the authority to control all the changes. If changes go in from more than one person - then no one is responsable.
I think I understand what you're driving at, but if what you said were strictly true, there would be no working partnerships in the world, right? There is such a thing as shared responsibility. However, it's true that you probably can't spread it uniformly across the community.
I don't think either Jim or myself have suggested fully spreading it across the community. I think we both are suggesting "training" a group of volunteers, the Guild, to shared that responsibility. In exchange for healthier libraries we are trading some control. Which seems like a more than fair trade to me. What Jim and I are trying to grapple with is how much control is given up and how to temper the lost control. But what I mentioned in another response is that the goal would be to never loose control over the design. Since it's only patches to fix bugs that we are loosing some control over. And after all, it's the design that of paramount importance. -- -- 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
Rene Rivera wrote:
On 11/12/2010 9:33 PM, David Abrahams wrote:
At Fri, 12 Nov 2010 16:33:38 -0800, Robert Ramey 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. In a larger library, many patches and fixes will inadvertantly break something else. If you want someone to be responsable, he has has to have the authority to control all the changes. If changes go in from more than one person - then no one is responsable.
I think I understand what you're driving at, but if what you said were strictly true, there would be no working partnerships in the world, right? There is such a thing as shared responsibility. However, it's true that you probably can't spread it uniformly across the community.
It's sort of off topic, but in anycase ... The concept of "partnership" be it in business, politics or whatever generally fails for the reasons I've alluded to above. Those that do work (e.g. hewlet-packard, rogers and hamerstein, abott & costello, jobs & wozniak, etc.) may be partnerships in some nominal way, but in fact they are not based on shared responsability but rather divided/allocated responsability. So a look at the above examples yields respectively technical/business, lyrics/music, straightman/funnyman, technical/marketing, etc. If I had nothing else to do, I could go on on how that relates to boost, but I'm going to quit while I'm ahead. Robert Ramey
At Sun, 14 Nov 2010 12:35:35 -0800, Robert Ramey wrote:
Rene Rivera wrote:
On 11/12/2010 9:33 PM, David Abrahams wrote:
At Fri, 12 Nov 2010 16:33:38 -0800, Robert Ramey 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. In a larger library, many patches and fixes will inadvertantly break something else. If you want someone to be responsable, he has has to have the authority to control all the changes. If changes go in from more than one person - then no one is responsable.
I think I understand what you're driving at, but if what you said were strictly true, there would be no working partnerships in the world, right? There is such a thing as shared responsibility. However, it's true that you probably can't spread it uniformly across the community.
It's sort of off topic, but in anycase ...
The concept of "partnership" be it in business, politics or whatever generally fails for the reasons I've alluded to above. Those that do work (e.g. hewlet-packard, rogers and hamerstein, abott & costello, jobs & wozniak, etc.) may be partnerships in some nominal way, but in fact they are not based on shared responsability but rather divided/allocated responsability. So a look at the above examples yields respectively technical/business, lyrics/music, straightman/funnyman, technical/marketing, etc.
This isn't as black-and-white as you make it sound. You can think of your examples as role allocation by strength. It doesn't mean there's no such thing as shared responsibility. On a successful sports team, if a player is sidelined for any reason, the rest of the team takes responsibility for covering his/her duties. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
At Sun, 14 Nov 2010 11:41:27 -0600, Rene Rivera wrote:
On 11/12/2010 9:33 PM, David Abrahams wrote:
At Fri, 12 Nov 2010 16:33:38 -0800, Robert Ramey 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. In a larger library, many patches and fixes will inadvertantly break something else. If you want someone to be responsable, he has has to have the authority to control all the changes. If changes go in from more than one person - then no one is responsable.
I think I understand what you're driving at, but if what you said were strictly true, there would be no working partnerships in the world, right? There is such a thing as shared responsibility. However, it's true that you probably can't spread it uniformly across the community.
I don't think either Jim or myself have suggested fully spreading it across the community.
I didn't mean to imply that you had.
I think we both are suggesting "training" a group of volunteers, the Guild, to shared that responsibility. In exchange for healthier libraries we are trading some control. Which seems like a more than fair trade to me. What Jim and I are trying to grapple with is how much control is given up and how to temper the lost control. But what I mentioned in another response is that the goal would be to never loose control over the design. Since it's only patches to fix bugs that we are loosing some control over. And after all, it's the design that of paramount importance.
Implementation quality, documentation, maintainability, and other factors are important too. I'm reluctant to accept that there's an absolute ordering. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
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.
On 11/14/2010 8:39 AM, Jim Bell wrote:
On 1:59 PM, Robert Ramey wrote:
David Abrahams wrote:
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.
I'm working on a solution to that.. By replacing the whole test report system. But it's something that's going to take a few months to make it work :-(
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.
Right.. Also I think having such a Guild will eventually solve the problem of "some" libraries not being maintained. Eventually Guild members will become experts at maintaining particular libraries and could eventually take full ownership of abandoned libraries much better than having some random person volunteer, as we do now. Having a fluid Guild work on bugs has the most benefit as far as balancing control. If a libraries is well maintained, like yours Robert, then it's unlikely that a Guild member will ever need to get involved. After all there's no point in trying to fix bugs that will be taken care of by the owner and expert diligently. Hence, for libraries that are not well maintained will get more attention and the author will loose more control by the sheer fact that she is less diligent. -- -- 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
Rene Rivera wrote:
Having a fluid Guild work on bugs has the most benefit as far as balancing control. If a libraries is well maintained, like yours Robert, then it's unlikely that a Guild member will ever need to get involved. After all there's no point in trying to fix bugs that will be taken care of by the owner and expert diligently.
For the record, I should note that I get A LOT of help with bugs from others - including some of those active on this thread. I suspect that the fact that I do try address and incorporate bug fixes and suggestions has a lot to do with the fact that others are willing to invest the effort to help.
Hence, for libraries that are not well maintained will get more attention and the author will loose more control by the sheer fact that she is less diligent.
Sounds good to me. Just make sure that the "if you break it, you bought it" rule is enforced. Robert Ramey
On 1:59 PM, Robert Ramey wrote:
Rene Rivera wrote:
Having a fluid Guild work on bugs has the most benefit as far as balancing control. If a libraries is well maintained, like yours Robert, then it's unlikely that a Guild member will ever need to get involved. After all there's no point in trying to fix bugs that will be taken care of by the owner and expert diligently.
Yes. No open tickets and all regressions passing means nothing for the Guild to do. (Do we capitalize the Guild or not? I've not been consistent myself.)
For the record, I should note that I get A LOT of help with bugs from others - including some of those active on this thread. I suspect that the fact that I do try address and incorporate bug fixes and suggestions has a lot to do with the fact that others are willing to invest the effort to help.
I'll bet the help you get is in small amounts, each focused on a specific issue: your own Guild.
Hence, for libraries that are not well maintained will get more attention and the author will loose more control by the sheer fact that she is less diligent. Sounds good to me. Just make sure that the "if you break it, you bought it" rule is enforced.
Seeing unexpected effects from a change is a very valuable learning experience--hence, sharpening one's skills. There could be times where another guild member needs to step in where one drops out of sight (or, God forbid, steps in front of a bus). Yet another valuable learning experience, IMHO.
At Mon, 15 Nov 2010 08:37:54 -0600, Jim Bell wrote:
Do we capitalize the Guild or not? I've not been consistent myself.
I say yes. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
participants (6)
-
Dave Abrahams -
David Abrahams
-
Jim Bell -
joel falcou -
Rene Rivera -
Robert Ramey