Apologies for the delay in voting. We got in some feedback on PUP #3 that has been addressed.
Will now be aiming for Wednesday, May 24 for voting. I’ll start a new email thread with the guidelines on how to vote. David On Wed, May 3, 2017 at 1:54 PM, David Davis <davidda...@redhat.com> wrote: > 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 <davidda...@redhat.com> 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 <davidda...@redhat.com> >> 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 <bbout...@redhat.com> >>> 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 <davidda...@redhat.com> >>>> 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 <bbout...@redhat.com> >>>>> 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 <davidda...@redhat.com> >>>>>> 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 <bbout...@redhat.com >>>>>>> > 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 <sean.my...@redhat.com >>>>>>>> > 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 >>>>>>>>> Pulp-dev@redhat.com >>>>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Pulp-dev mailing list >>>>>>>> Pulp-dev@redhat.com >>>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
