Sounds sane -- is the new plan to always do backports via this process? i.e. if I see a backport PR which has not been through integration testing, should I refrain from merging it?
John On Mon, Jan 5, 2015 at 11:53 AM, Loic Dachary <[email protected]> wrote: > Hi Ceph, > > I'm going to spend time to care for the Ceph backports (i.e. help reduce the > time they stay in pull requests or redmine tickets). It should roughly go as > follows: > > 0. Developer follows normal process to land PR to master. Once complete and > ticket is marked Pending Backport this process initiates. > 1. I periodically polls Redmine to look for tickets in Pending Backport state > 2. I find commit associated with Redmine ticket and Cherry Picks it to > backport integration branch off of desired maintenance branch (Dumping, > Firefly, etc). (Note - patch may require backport to multiple branches) > 3. I resolve any merge conflicts with the cherry-picked commit > 4. Once satisfied with group of backported commits to integration branch, I > notifies QE. > 5. QE tests backport integration branch against appropriate suites > 6a. If QE is satisfied with test results, they merge backport integration > branch. > 6b. If QE is NOT satisfied with the test results, they indicate backport > integration branch is NOT ready to merge and return to me to work with > original Developer to resolve issue and return to steps 2/3 > 7. Ticket is moved to Resolved once backport integration branch containing > cherry-picked backport is merged to the desired mainteance branch(es) > > I'll first try to implement this semi manually and document / script when > convenient. If anyone has ideas to improve this tentative process, now is the > time :-) > > Cheers > > -- > Loïc Dachary, Artisan Logiciel Libre > -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
