On 05/01/2015 13:03, John Spray wrote: > 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?
I think that's the idea, indeed. QE does the merge, when and if tests are green. > > 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 >> -- Loïc Dachary, Artisan Logiciel Libre
signature.asc
Description: OpenPGP digital signature
