If there’s no major feedback on the PUP #3, I am going to tentatively schedule a vote for it on Monday, May 8th.
Again, feel free to review the PUP and submit feedback before then. If it warrants a major change to the PUP, I’ll postpone the vote. Thanks again to everyone who has contributed. David On Mon, May 1, 2017 at 3:05 PM, David Davis <[email protected]> wrote: > Thinking through this a bit, I am not sure having a roll for someone to do > cherry-picks makes sense. Features aren’t cherry-picked. Hotfixes are > generally made against release branches (unless I am mistaken) so having > someone have to hunt those changes down and get them to master seems > tedious. Seems like this should be left up to the person taking care of the > hot fix. > > That leaves bug fixes and I think the person who merges the PR be > responsible to cherry-picking the commit. > > Why don’t we leave out the cherry-pick role initially at least and then > decide if we need it. I also think this is less of a jarring change from > our current process and might ease the transition. > > > David > > On Wed, Apr 19, 2017 at 11:28 AM, David Davis <[email protected]> > wrote: > >> 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
