[ruby-core:40801] Re: Proposal for sustainable branch maintenance

> Historically, the release manager and branch manager have been the
> same person (= Yugui).  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