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 <yugui / yugui.jp>
 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/