--f46d0408d3c1d5fc4e04b10038d6 Content-Type: text/plain; charset=ISO-8859-1 > 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. > > What do you mean by "active branches"? Should the "Branch Statuses" chart at http://redmine.ruby-lang.org/projects/ruby/wiki/ReleaseEngineering be updated so that everyone is clear as to which branches are considered active? "Frozen" doesn't clearly convey "active". Also, what do you think non-committers can do to help you parallelize the backport bottlenecks? At the end of the day it's always going to be a commiter who has to review, approve, and backport so as to ensure stability. But perhaps those of us who regularly build MRI can help offload at least part of the work. The challenge I see is that you don't want to create additional bottleneck's by depending upon non-committers in order to commit timely backports. Non-committer contributions come and go on irregular schedules not necessarily in sync with ruby-core timelines. 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. But perhaps you have a better idea how some of us might be able to help. Jon --- http://thecodeshop.github.com | http://jonforums.github.com/ twitter: @jonforums --f46d0408d3c1d5fc4e04b10038d6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> == Proposal<br> Let's parallelize the bottle-neck.<br> Review and tests are necessary for stability and compatibility of<br> released branches but these processes can be parallelized.<br> I propose the following process:<br> <br> * A committer who fixed a bug in trunk should also check if the bug<br> ¨Âåðòïäõãå÷éôè ïôèåáãôéöå âòáîãèåóÉæ òåðòïäõãåó¨ó©èóèïõìä¼âò¾ ¨Âòåáôâáãëðïòô òåñõåóïî ôèÒåäíéî宼âò¾ Or anyone who want us to backport a commit in trunk can create a<br> ¨Âáãëðïòòåñõåóô®¼âò¾ * Another committer review the request. This reviewer checks if this<br> ¨Âïííééó çïïä åîïõçè áîâáãëðïòô éô ôï ôèïìäåâòáîã讼âò* Any committer who thinks the backport breaks compatiblity can revert<br> ¨Âô®¼âò¾ Eventually the maintainer of the branch decides to revert or not.<br> <br> CI and a new Redmine plugin can help this process.<br> * Automatic request triggered by commit message?<br> <br> And the branch maintainer can have time to plan the next patch-level<br> release.<br> <br></blockquote><div><br><br>What do you mean by "active branches"?Should the "Branch Statuses" chart at<br><br> http://redmine.ruby-lang.org/projects/ruby/wiki/ReleaseEngineering<br> <br>be updated so that everyone is clear as to which branches are considered active? "Frozen" doesn't clearly convey "active".<br><br>Also, what do you think non-committers can do to help you parallelize the backport bottlenecks?At the end of the day it's always goingo be a commiter who has to review, approve, and backport so as to ensure stability. But perhaps those of us who regularly build MRI can help offloadt least part of the work.<br> <br>The challenge I see is that you don't want to create additional bottleneck's by depending upon non-committers in order to commit timely backports.Non-committer contributions come and go on irregular schedules not necessarily in sync with ruby-core timelines. 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.<br> <br>But perhaps you have a better idea how some of us might be able to help.<br><br>Jon<br><br>---<br>http://thecodeshop.github.com | http://jonforums.github.com/<br> twitter: @jonforums<br></div></div> --f46d0408d3c1d5fc4e04b10038d6--