Regarding who and when we’ll cherry-pick, that sounds good to me. Although, we’ll probably have to sync up schedules between when we cherry-pick and when we release I imagine. Or maybe the cherry-picker can work with whoever is doing the release to make sure the proper bug fixes get cherry-picked in before the release.
Your proposals around how to track cherry-picks all sound good to me. I can update the PUP unless anyone is opposed. Regarding not cherry-picking stuff that doesn’t apply, I don’t have an opinion one way or the other. I think the best course of action would be to try it out and see if users are ok with it. One question I also wanted to bring up: when do we want to transition to this cherry-picking workflow? I think someone mentioned only cherry-picking for Pulp 3 but it seems like most of the people in the PUP PR think favor cherry-picking for both Pulp 2 and Pulp 3 once the proposal is accepted. Does anyone oppose that or have any thoughts? David On Fri, Apr 14, 2017 at 11:02 AM, Brian Bouterse <[email protected]> wrote: > Thanks for putting this together. I put several comments on the PR, but I > want to share some thoughts via the mailing list: > > Who will do the cherry pick and when? We should consider that rather than > having each developer perform the cherry picks, having one person do them > say on a weekly basis. This can be a rotating role. I think this would be > good for several reasons. (1) It's less overhead when merging fixes; once > its merged to master the developer is done. (2) Less will fall through the > cracks by having them all done at one time. (3) More consistency by having > them done in batches because when you do something a few times you get > better at it. I think this approach would address some of the items in the > Drawbacks section of the PUP. > > How will we track cherry picks? For this we want something that will work > for release engineers releasing Pulp, something that works for all of the > redmine automation we have, and something that works for QE which has > pulp-smash skip issues by version. If we could do something that would work > with the existing processes that would be ideal. To that end, when a cherry > pick from master to the previous devel branch (e.g. 2.13-dev) occurs the > 'Platform Release' field could be set to 2.13.next which is basically our > current process. In terms of tracking the cherry pick commit I think using > the `-x` option while cherry picking and adding a `cherry-pick #1234` to > the cherry picked issue number would cause the commit to be associated with > the redmine issue and make it clear that it is a cherry pick. If we do all > ^ I think the cherry picks would be adequately tracked. > > Lastly, I think if a cherry pick does not apply cleanly we should not > cherry pick it unless there is an exceptional reason that the previous > z-stream we are cherry picking into must have that bugfix. In other words, > if it picks cleanly do it, otherwise don't worry about it. Users will > receive the fix in the next y stream anyway. Generally I think releasing a > bugfix in a z-stream is not worth reimplementing or modifying the fix given > that it is available in the very next y release which releases roughly > every 12 weeks. > > Other ideas/thoughts/suggestions/questions welcome! > > Thanks @daviddavis for putting this effort together. > > -Brian > > > On Tue, Apr 11, 2017 at 4:38 PM, David Davis <[email protected]> > wrote: > >> I’ve been working on the PUP for cherry-picking changes across our >> branches and I’ve opened a PR. Feedback would be much appreciated. >> >> https://github.com/pulp/pups/pull/3 >> >> Also, I wanted to mention that it might be worth discussing how we can >> improve our merge forward process even if we don’t want to use >> cherry-picking instead. We’ve seen a couple accidental merges and I was >> wondering if there might be some way to prevent that? Two options I can >> think of. First maybe we could merge forward less often? I’m not sure how >> to time this. Secondly, perhaps we could use code reviews/PRs to confirm >> merges? >> >> Thanks. >> >> David >> >> On Tue, Mar 21, 2017 at 4:08 PM, Brian Bouterse <[email protected]> >> wrote: >> >>> I would really like to collaborate on this. First one to start it; let >>> the other know. >>> >>> On Tue, Mar 21, 2017 at 3:18 PM, David Davis <[email protected]> >>> wrote: >>> >>>> So I was planning on doing that actually. Although, if you have the >>>> spare cycles, go for it. >>>> >>>> >>>> David >>>> >>>> On Tue, Mar 21, 2017 at 2:49 PM, Brian Bouterse <[email protected]> >>>> wrote: >>>> >>>>> I plan to turn this thread into a formal RFC once that process has >>>>> been ratified. >>>>> >>>>> On Tue, Mar 21, 2017 at 11:13 AM, Sean Myers <[email protected]> >>>>> wrote: >>>>> >>>>>> On 02/06/2017 12:09 PM, Ina Panova wrote: >>>>>> > Seems like we are trying to choose/figure out what's more important >>>>>> - >>>>>> > linear commit history which is readable or confidence and ability >>>>>> to track >>>>>> > where exactly change had been applied? >>>>>> > >>>>>> > I agree with Mike and think that merging forward is so super >>>>>> simple, i must >>>>>> > admit i had issues to understand this strategy from the beginning >>>>>> but now i >>>>>> > could do that even with closed eyes. >>>>>> >>>>>> The problem, as has become very clear in the past few days, is that >>>>>> merging >>>>>> forward does not give us the confidence (or ability) to track where >>>>>> exactly >>>>>> a change has been applied. All it tells us is what commit hashes >>>>>> exist on a >>>>>> branch, which is not the same thing. You can record a commit hash as >>>>>> merged >>>>>> without bringing its changes forward, which is a necessary step in >>>>>> fixing >>>>>> merge-forward mistakes. The best way to see if a specific change >>>>>> exists on >>>>>> a given branch, whether we're cherry-picking or we're merging >>>>>> forward, as I >>>>>> understand it, is to use 'git cherry'. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pulp-dev mailing list >>>>>> [email protected] >>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Pulp-dev mailing list >>>>> [email protected] >>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>> >>>>> >>>> >>> >> >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
