From: "naruse (Yui NARUSE)" Date: 2012-03-28T00:07:40+09:00 Subject: [ruby-core:43746] [ruby-trunk - Feature #5590][Closed] Proposal for sustainable branch maintenance Issue #5590 has been updated by naruse (Yui NARUSE). Status changed from Open to Closed See also [ruby-dev:45183] and [ruby-core:42363] ---------------------------------------- Feature #5590: Proposal for sustainable branch maintenance https://bugs.ruby-lang.org/issues/5590#change-25255 Author: yugui (Yuki Sonoda) Status: Closed Priority: Normal Assignee: Category: Target version: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, == Background I have been maintaining ruby_1_9_1 and ruby_1_9_2 branch. Ruby 1.9 is now stable as Ruby 1.8 was, but it has not yet reached to the bugless nirvana. So Ruby 1.9 needs continuous maintenance. But actually ruby_1_9_1 is no longer well-maintained. My backports to ruby_1_9_? tend to be late. There is a bottle-neck. The bottle-neck is review process for commits in trunk. A few bug is branch-specific. Most of bugs in Ruby 1.9.x reproduce with trunk too. So I rarely need to write a branch specific patch. Just backporting from trunk fixes most of bugs in Ruby 1.9.x. But I need to read a commit carefully and run unit tests before backport the commit. This review process takes really really long. That's why patch level releases have been late. == Proposal Let's parallelize the bottle-neck. Review and tests are necessary for stability and compatibility of released branches but these processes can be parallelized. I propose the following process: * A committer who fixed a bug in trunk should also check if the bug reproduces with other active branches. If reproduces, (s)he should create a backport request on the Redmine. * Or anyone who want us to backport a commit in trunk can create a backport request. * Another committer review the request. This reviewer checks if this commit is good enough and backport it to the older branch. * Any committer who thinks the backport breaks compatiblity can revert it. * Eventually the maintainer of the branch decides to revert or not. CI and a new Redmine plugin can help this process. * Automatic request triggered by commit message? And the branch maintainer can have time to plan the next patch-level release. - -- Regards, Yuki Yugui Sonoda http://yugui.jp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk601B4ACgkQOXzH5JLb/AVbbgCfZKsBSQplRx1SvgE0zhTKIUYm QwEAn2FM660J6oo3fAiLAkNh1uB5PXRM =PGvr -----END PGP SIGNATURE----- -- http://bugs.ruby-lang.org/