On 06/01/2015 00:24, Gregory Farnum wrote: > On Mon, Jan 5, 2015 at 4:16 AM, Loic Dachary <loic@xxxxxxxxxxx> wrote: >> >> >> 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 <loic@xxxxxxxxxxx> 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 :-) > > > Okay, I've got a bunch of questions. In your first email it sounds > like you're saying this is how you're going to voluntarily handle some > backports. But in response to John's email it sounds like you want to > gate all backports through yourself and this process. Is this a > request that everybody else stops performing backports, and have you > checked with enough usual suspects to make sure they'll respect the > process? ;) :-) This process is helpful if it allows me to help a little more than I currently do with the backport process. It would be a loss if the end result is that everyone cares less about backports. My primary incentive for sending this mail is to start the conversation and avoid that kind of unintended drawback. > I am 100% on board with making QE responsible for gating backports, so > thank you for starting down that path. :) But I'm not at all sure how > this scales for you. Right now backports are nominally run through two > important checks: > 1) Is it suitable for backport (decided by author or tech lead, marked > via the Pending Backport tag) > 2) Has it been through sufficient validation in master to be safe to > backport (not marked in the system anywhere, just by somebody actually > doing the backport). > > Knowing if something has been through sufficient validation to > backport requires a fair bit of attention to the details of the ticket > and the patches involved. How do you plan to keep up on that? I can't do that all by myself. > Similarly, while point releases are largely ad-hoc, we are trying to > involve all the leads in the time-to-go decision. A lot of those > decisions rest on whether specific backports have been performed yet, > whether there are very new backports we want to run through testing > for a little longer, etc. That sounds like a lot of communications > overhead between the backport gates and the leads when making these > kinds of decisions and I'm not sure how that should happen; is there a > plan? (We can look at ticket status for things which are pending > backport, but that doesn't facilitate prioritizing their backports; > and in the opposite direction there's not a good way to say "this > relatively large backport needs to go through at least three test runs > before a release".) Could you point me to a mail thread / IRC conversation that is representative of this process ? Here is a revised process which is hopefully more realistic: 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 and focus on the ones that are left unattended for too long 1a. Under the supervision of the author of the original patch, I find the commits associated with the Redmine ticket and Cherry Pick to the backport integration branch off of the desired maintenance branch (Dumping, Firefly, etc). 1b. I resolve any merge conflicts with the cherry-picked commit 2. I merge all backports for a given branch in an integration branch 3. I ask the leads of each project to review the integration 4. Once satisfied with group of backported commits to integration branch, I notify 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) What do you think ? Cheers > -Greg > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Loïc Dachary, Artisan Logiciel Libre
Attachment:
signature.asc
Description: OpenPGP digital signature
