Feature #5590: Proposal for sustainable branch maintenance

• Status: Closed
• Assignee: -
• Target version: -

[yugui (Yuki Sonoda)]

-----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 [e-mail]
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-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

(2011/11/08 0:25), Yugui wrote:

== 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:

I agree this in general.

There're some other proposals such as review before commit, but we
accept Yugui's proposal for now and start doing this, right?
According to commits to ruby_1_9_3, @arton (Akio Tajima) is doing this already. I'm
not against it. Let's find problems by doing now.

Proposals like review before commit, requires LGTM*2 by committer,
would be good for new proposal for branch maintenance. Now go write a
proposal how good/bad it is and file a ticket!

• Another committer review the request. This reviewer checks if
  this commit is good enough and backport it to the older
  branch.

Do you mean the word "backport" as committing? If so, who changes
patchlevel? The committer? You?

I think the committer who commit the patch should also change patch
level. Both Shyouhei's and my backport scripts automatically bump
patch level, so it is not so hard.

@arton (Akio Tajima), can you do this?

// NaHi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)

iQEcBAEBAgAGBQJOuKhFAAoJEC7N6P3yLbI20s4H/1nGsHqYQkouPSAd9R7deXUj
xSHWQ7kdRK056KID5wqewuqKxYkldgzAAZ0+osIeQuIpWP2HyiTdQJ+1os1y7IZa
osLvKo0FqlDAE/SZLlF9pC8aXl8VCrNF/Mmo5AAxUk4hfz4PYZNkBfBZWb38h/cb
yTcpgN/d+N/Be6by29MkhMsqxuffojoiowFX8bCK/WaETExLiLRNB+Pfy5Dnvx7j
/aomyBS9uRbA4aGUuWfujW8MATo0SikOgNez/2dhBeqVhrea5jAXsIlju6ndsInD
pQGs6xlijxi2ZDhjTcfdXBhhV0CJgiGzAJtk/PMBmn1y3+G/BgWjWTMnW7kes2E=
=FiZ8
-----END PGP SIGNATURE-----

On Sat, Nov 05, 2011 at 03:11:55PM +0900, Yuki Sonoda (Yugui) wrote:

-----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.

I would like to try the new system. :-)

I've submitted a backport request here:

http://redmine.ruby-lang.org/issues/5646

Can someone +1, and I'll merge to the bugfix branch? Thank you!

--
Aaron Patterson
http://tenderlovemaking.com/

[naruse (Yui NARUSE)]

• Status changed from Open to Closed

See also [ruby-dev:45183] and [ruby-core:42363]