--f46d04083df386085f04b1186c93 Content-Type: text/plain; charset=ISO-8859-1 > Historically, the release manager and branch manager have been the > same person ( ugui). As Yugui said, the branch maintenance (by > one person) is very hard task; this is one of reasons why 1.9 release > tended to be late. That is a lot to ask of one person. Sadly we often pursue things for the sheer fun of it only to discover the yoke of maintenance makes it not so fun anymore. How apropos..."sustainable branch maintenance." > > From that perspective, I don't > > yet see how non-committers can really help with the backports bottleneck > > other than perhaps testing `trunk` patches against their favorite "active" > > branch and reporting status in a backport request. > > If you do such a hard contribution sustainably, you will become a > comitter :-) Unfortunately, it seems the carrot of becoming a committer hasn't attracted enough developers to sustain the backport workload. If becoming a commiter was perceived as alluring, I argue you'd already have plenty of folks working to become committers. The fact is, we all know the real secret; being a committer is hard work. I wonder if something modest and targeted to increasing backport velocity might work better than the current process. Create a GitHub 'ruby-backports' organization and populate it with an MRI clone repo. The sole purpose of the repo is to allow interested non-committers to more easily "pre backport" interesting trunk patches for final review by the appropriate branch manager. This idea has startup and maintenance (eg - `git svn rebase`, git svn dcommit`, etc) costs, but also has some potentially interesting benefits: * the backport repo has access rights distinct from the main MRI repo. * as such, a backport repo committer is not necessarily a ruby-core committer. * actual backporting becomes more accessible to non-committers. * ruby-core sees more clearly the high-priority patches as they _should_ be the ones committed more quickly to the backports repo...patch Darwinism. * ruby-core branch managers retain control over final backports to main MRI repo. * those interested in becoming a ruby-core commiter can first become a backport repo committer. * those not interested in becoming a ruby-core committer can more easily contribute to keeping MRI healthy while accelerating the pace of branch patch releases. BTW, this isn't yet another attempt to get the main svn repo switched to git. We have a git mirror repo that works great, thank you very much. If anyone is looking to exhume that old issue, this isn't your chance ;) Will it actually attract sustainable contributions? Who knows. Today anyone can clone the git mirror repo, hack on a backport, and send a pull request. So, frankly I don't see how creating another repo magically solves anything. But it's hard to predict what might catch on without actually experimenting. Potentially interesting in theory, but is it worth a try? Jon --- http://thecodeshop.github.com | http://jonforums.github.com/ twitter: @jonforums --f46d04083df386085f04b1186c93 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br>> Historically, the release manager and branch manager have been the<br>> same person (= Yugui).As Yugui said, the branch maintenance (by<br>> one person) is very hard task; this is one of reasons why 1.9 release<br> > tended to be late.<br><br><br>That is a lot to ask of one person. Sadly we often pursue things for the sheer fun of it only to discover the yoke of maintenance makes it not so fun anymore. How apropos..."sustainableranch maintenance."<br> <br><br><br>> > From that perspective, I don't<br>> > yet see how non-committers can really help with the backports bottleneck<br>>gt; other than perhaps testing `trunk` patches against their favorite "active"<br> > > branch and reporting status in a backport request.<br>> <br>> If you do such a hard contribution sustainably, you will become a<br>> comitter :-)<br><br><br>Unfortunately, it seems the carrot of becoming a committer hasn't attracted enough developers to sustain the backport workload. If becoming a commiter was perceived as alluring, I argue you'dlready have plenty of folks working to become committers. The fact is, well know the real secret; being a committer is hard work.<br> <br>I wonder if something modest and targeted to increasing backport velocity might work better than the current process.<br><br>Create a GitHub 'ruby-backports' organization and populate it with an MRI clone repo. The sole purpose of the repo is to allow interested non-committers to more easily "pre backport" interesting trunk patches for final review byhe appropriate branch manager.<br> <br>This idea has startup and maintenance (eg - `git svn rebase`, git svn dcommit`, etc) costs, but also has some potentially interesting benefits:<br><br>* the backport repo has access rights distinct from the main MRI repo.<br> * as such, a backport repo committer is not necessarily a ruby-core committer.<br>* actual backporting becomes more accessible to non-committers.<br>* ruby-core sees more clearly the high-priority patches as they _should_ be the<br> ones committed more quickly to the backports repo...patch Darwinism.<br>* ruby-core branch managers retain control over final backports to main MRI repo.<br>* those interested in becoming a ruby-core commiter can first become a backport<br> repo committer.<br>* those not interested in becoming a ruby-core committer can more easily contribute<br> to keeping MRI healthy while accelerating the pace of branch patch releases.<br><br>BTW, this isn't yet another attempt to get the main svn repo switched to git. We have a git mirror repo that works great, thank you very much. If anyone is looking to exhume that old issue, this isn't your chance ;)<br> <br>Will it actually attract sustainable contributions? Who knows. Today anyone can clone the git mirror repo, hack on a backport, and send a pull request. So, frankly I don't see how creating another repo magically solves anything. But it's hard to predict what might catch on without actually experimenting.<br> <br>Potentially interesting in theory, but is it worth a try?<br><br>Jon<br><br>---<br>http://thecodeshop.github.com | http://jonforums.github.com/<br> twitter: @jonforums<br><br> --f46d04083df386085f04b1186c93--