[request-sponsor] Incremental improvements to the sponsor program: phase 0: handing off changes
On Tue, 5 May 2009, Mark J. Nelson wrote: > This note was blind copied to on-discuss at opensolaris.org. If you read > it there and want to follow the conversation, please subscribe to > opendev-discuss. > > > > Howdy-- > > Now that we've got 400+ contributions under our collective belt, I > imagine that everybody's got opinions about what's good, bad, and ugly > about the whole request/sponsor process. > > And we want to hear what we can do to streamline that process, making it > easier for Contributors and for Sponsors. > > Here's one idea that's been percolating for a little while now, targeted > primarily at more experienced Contributors: > > Write an optional Mercurial extension to (A) collect, through a series > of questions and answers, supplemented by changeset comments, all of the > information necessary for a sponsor to file an RTI; and (B) submit that That seems very useful to me. > information as the explanatory text for an "hg email" command [1], where > a sponsor with commit rights can pick it up and oversee the mechanics of > integration. The separation of items (A) and (B) is important--(A) is > intended as a stopgap measure until we get the resources to figure out > how OpenRTI fits, and (B) is a first step towards changing the way we > integrate changes. > > For a complex fix, and/or a relatively inexperienced Contributor, this > won't look much different from what we have today. A sponsor will still > be available via the request-sponsor alias, and can still help with any > part of the internal process. The earlier the sponsor is involved, the > less useful this extension would be. > > For more experienced submitters, however, this would have the following > benefits: > > - Allow greater autonomy: a note to request-sponsor will still be > appropriate to avoid duplicating effort, but now it becomes a > notification that "I'm working on this," instead of a request for a sponsor. With how our processes are currently set up, a sponsor (or someone internal) will still need to then update the CR internally noting that it is being worked on. Not all developers for ON are on the request-sponsor alias - in fact, just a small handful are. > - Provide a more formal means of handing off the fix: right now, fixes > may be communicated in a variety of formats. This will unify and > formalize the expected format, which is a necessary prerequisite for > automating processes such as rebase, recommit, and validation. Such > automation is explicitly not part of this phase. This would be nice. Presumably, this would put more of the onus of testing, etc, on the external contributor? > - Allow more flexibility: the more information that the Contributor > provides, the less interactive the handoff may be. The less information > provided, the more interactive. The less experienced the Contributor, > the earlier a Sponsor is assigned, and the more the Sponsor participates > in the process. > > For now, I would love to hear from Contributors and Sponsors. Does this > sound like a step in a useful direction? Would you use such a thing? yes, though I don't think it will solve all our woes, it will help. Thank you for thinking about this, Valerie -- Valerie Fenwick, http://blogs.sun.com/bubbva Solaris Security Technologies, Developer, Sun Microsystems, Inc. 17 Network Circle, Menlo Park, CA, 94025.
[request-sponsor] Incremental improvements to the sponsor program: phase 0: handing off changes
On Tue, May 5, 2009 at 7:18 PM, Mark J. Nelson wrote: > > For now, I would love to hear from Contributors and Sponsors. ?Does this > sound like a step in a useful direction? ?Would you use such a thing? > Yes, this sounds like a step in the right direction. It seems to me that the current process has the contributor doing the fun work and has the sponsor doing all of the drudge work. I get the feeling that this is a disincentive to sponsorship. And what's perverse about this disincentive is that it's likely greatest for precisely that set of bugs that get people started contributing, the oss-bite-size bugs. This proposal seems like it would reduce the drudgery of sponsorship. Chad
[request-sponsor] Incremental improvements to the sponsor program: phase 0: handing off changes
This note was blind copied to on-discuss at opensolaris.org. If you read it there and want to follow the conversation, please subscribe to opendev-discuss. Howdy-- Now that we've got 400+ contributions under our collective belt, I imagine that everybody's got opinions about what's good, bad, and ugly about the whole request/sponsor process. And we want to hear what we can do to streamline that process, making it easier for Contributors and for Sponsors. Here's one idea that's been percolating for a little while now, targeted primarily at more experienced Contributors: Write an optional Mercurial extension to (A) collect, through a series of questions and answers, supplemented by changeset comments, all of the information necessary for a sponsor to file an RTI; and (B) submit that information as the explanatory text for an "hg email" command [1], where a sponsor with commit rights can pick it up and oversee the mechanics of integration. The separation of items (A) and (B) is important--(A) is intended as a stopgap measure until we get the resources to figure out how OpenRTI fits, and (B) is a first step towards changing the way we integrate changes. For a complex fix, and/or a relatively inexperienced Contributor, this won't look much different from what we have today. A sponsor will still be available via the request-sponsor alias, and can still help with any part of the internal process. The earlier the sponsor is involved, the less useful this extension would be. For more experienced submitters, however, this would have the following benefits: - Allow greater autonomy: a note to request-sponsor will still be appropriate to avoid duplicating effort, but now it becomes a notification that "I'm working on this," instead of a request for a sponsor. - Provide a more formal means of handing off the fix: right now, fixes may be communicated in a variety of formats. This will unify and formalize the expected format, which is a necessary prerequisite for automating processes such as rebase, recommit, and validation. Such automation is explicitly not part of this phase. - Allow more flexibility: the more information that the Contributor provides, the less interactive the handoff may be. The less information provided, the more interactive. The less experienced the Contributor, the earlier a Sponsor is assigned, and the more the Sponsor participates in the process. For now, I would love to hear from Contributors and Sponsors. Does this sound like a step in a useful direction? Would you use such a thing? --Mark [1] http://www.selenic.com/mercurial/wiki/index.cgi/PatchbombExtension
