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
