+1 On Mon, Oct 2, 2017 at 3:42 PM, Bihan Zhang <[email protected]> wrote:
> +1 > > On Oct 2, 2017 9:28 AM, "Ina Panova" <[email protected]> wrote: > >> +1 >> >> >> >> -------- >> Regards, >> >> Ina Panova >> Software Engineer| Pulp| Red Hat Inc. >> >> "Do not go where the path may lead, >> go instead where there is no path and leave a trail." >> >> On Mon, Oct 2, 2017 at 2:45 PM, Daniel Alley <[email protected]> wrote: >> >>> +1 >>> >>> On Mon, Oct 2, 2017 at 7:37 AM, Michael Hrivnak <[email protected]> >>> wrote: >>> >>>> +1 >>>> >>>> On Fri, Sep 29, 2017 at 10:08 AM, Brian Bouterse <[email protected]> >>>> wrote: >>>> >>>>> +1 >>>>> >>>>> I believe the cherry picking approach will avoid merge-forward >>>>> problems we've experienced, allow for less friction during community >>>>> contribution, and create a more stable project overall. >>>>> >>>>> On Fri, Sep 29, 2017 at 9:53 AM, Dennis Kliban <[email protected]> >>>>> wrote: >>>>> >>>>>> +1 >>>>>> >>>>>> On Fri, Sep 29, 2017 at 9:17 AM, David Davis <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> I went back and looked at PUP-3 and it does lay out some of the >>>>>>> items @pcreech mentions although at a higher, more general level. I’ll >>>>>>> leave the document as is unless someone disagrees. >>>>>>> >>>>>>> With that in mind, let's go ahead and vote on PUP-3. We’ll end the >>>>>>> voting on October 8th which is about 10 days away. >>>>>>> >>>>>>> To refresh everyone’s memory, voting is outlined in PUP-1: >>>>>>> >>>>>>> https://github.com/pulp/pups/blob/master/pup-0001.md#voting >>>>>>> >>>>>>> And here’s the PUP in question: >>>>>>> >>>>>>> https://github.com/daviddavis/pups/blob/pup3/pup-0003.md >>>>>>> >>>>>>> Please respond to this thread with your vote or any >>>>>>> comments/questions. >>>>>>> >>>>>>> >>>>>>> David >>>>>>> >>>>>>> On Thu, Sep 28, 2017 at 12:15 PM, Brian Bouterse < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Thanks @pcreech for all the comments. I also believe that switching >>>>>>>> to a cherry-picking model will provide many benefits. >>>>>>>> >>>>>>>> As a general FYI, the way PUP-3 is written, it allows us to adopt >>>>>>>> it (assuming it passes at vote) and then figure out how to roll it out >>>>>>>> later in coordination w/ release engineering. >>>>>>>> >>>>>>>> @daviddavis, should we start casting votes or should we wait for >>>>>>>> you to declare it open after maybe pushing an update? >>>>>>>> >>>>>>>> Thanks! >>>>>>>> Brian >>>>>>>> >>>>>>>> On Mon, Sep 25, 2017 at 1:38 PM, David Davis <[email protected] >>>>>>>> > wrote: >>>>>>>> >>>>>>>>> Patrick, >>>>>>>>> >>>>>>>>> Thanks for the feedback. I’d like to update PUP-3 in the next >>>>>>>>> couple days with the pain points you mention. >>>>>>>>> >>>>>>>>> Also, I’d love the idea of having some tooling that tells us >>>>>>>>> exactly which commits to cherry pick into which release branch. I >>>>>>>>> think we >>>>>>>>> should have this in place before we switch to cherry-picking if we >>>>>>>>> decide >>>>>>>>> to go that route. >>>>>>>>> >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>> On Fri, Sep 22, 2017 at 1:56 PM, Patrick Creech < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Since I was one of the early voices against cherrypicking during >>>>>>>>>> the initial vote, I figured I'd send this e-mail along with some >>>>>>>>>> points >>>>>>>>>> that have helped me be in favor of cherry picking before voting >>>>>>>>>> starts. >>>>>>>>>> >>>>>>>>>> In taking over the release engineering process, I have gained >>>>>>>>>> some perspective on our current situation and have found >>>>>>>>>> Cherrypicking to >>>>>>>>>> be an enticing concept for pulp. Most notably, these are the >>>>>>>>>> things I ran into during the release process for 2.13.4 that >>>>>>>>>> caused some headaches and frustrations. >>>>>>>>>> >>>>>>>>>> Firstly, we had an issue come up with the Pulp Docker 2 line that >>>>>>>>>> does not exist with the new Pulp Docker 3 line. Dockerhub V2 >>>>>>>>>> Schema2 has >>>>>>>>>> some manifest issues that cause syncs in the Pulp Docker 2 >>>>>>>>>> line to fail. A change specific to this issue was created and >>>>>>>>>> merged to the 2.4-dev branch. It's only application is the 2 line, >>>>>>>>>> but to >>>>>>>>>> satisfy our current tooling and policy, this change had to be >>>>>>>>>> merged forward through 3.0-dev and to Master, where it no longer >>>>>>>>>> applies and the code no longer exists in this form. I took great >>>>>>>>>> care to >>>>>>>>>> verify that no code changes happened on 3.0-dev and master, >>>>>>>>>> but there is the window open for issues here. >>>>>>>>>> >>>>>>>>>> Another issue that happened is when issues that are merged from a >>>>>>>>>> -dev branch aren't merged forward. In this case, two issues that >>>>>>>>>> landed on >>>>>>>>>> the most recent -dev branch weren't merged forward along >>>>>>>>>> to master before a helper script was ran. When this helper >>>>>>>>>> script ran, it was ran with the merge strategy of "ours" to ensure >>>>>>>>>> it's >>>>>>>>>> changes don't persist forward. When "ours" is used, conflicting >>>>>>>>>> changes are automatically dropped from the source branch to the >>>>>>>>>> destination branch. This caused the code for these two changes to >>>>>>>>>> dissapear on the master branch, while their commit hashes were there >>>>>>>>>> in the history. I had to cherry-pick these changes forward to >>>>>>>>>> master from the branch they landed on to ensure the modified code >>>>>>>>>> exists. >>>>>>>>>> >>>>>>>>>> And lastly, since 2.13.4 was a 2.13.z release that was done after >>>>>>>>>> 2.14.0 went out, changes had to be cherry-picked back from 2.14-dev >>>>>>>>>> to >>>>>>>>>> 2.13-dev. Since the hash changed, these changes yet again had >>>>>>>>>> to be merged forward to 2.14-dev and then Master, even though >>>>>>>>>> they already existed in these branches, thus helping to pollute the >>>>>>>>>> repo >>>>>>>>>> history further with more duplication. >>>>>>>>>> >>>>>>>>>> While a large portion of these issues can be attributed to the >>>>>>>>>> merge forward everything policy, I have been in talks with other >>>>>>>>>> teams that >>>>>>>>>> follow a cherrypicking strategy about their workflow since >>>>>>>>>> I'm in the process of revamping pulp's release engineering >>>>>>>>>> process. Something that caught my attention as beneficial is a >>>>>>>>>> team's >>>>>>>>>> strategy that everything goes on master, and with some automated >>>>>>>>>> tooling and bookeeping in their issue tracker they can identify >>>>>>>>>> what cherrypicks need to be pulled back to the release branch and >>>>>>>>>> spit out >>>>>>>>>> a command for the release engineer to run to do the >>>>>>>>>> cherrypicks. The release engineer resolves any conflicts, and >>>>>>>>>> then puts up a PR to merge into the release branch so the work goes >>>>>>>>>> through >>>>>>>>>> the normal testing + review process. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> In short, at this point I have come to believe that switching to >>>>>>>>>> a cherry-pick model will allow us greater flexibility and accuracy in >>>>>>>>>> ensuring our releases contain what we want them to contain, and >>>>>>>>>> don't contain what we don't want. With tooling, it should also >>>>>>>>>> help simplify ensuring the right things get put in the right places. >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Pulp-dev mailing list >>>>> [email protected] >>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> Michael Hrivnak >>>> >>>> Principal Software Engineer, RHCE >>>> >>>> Red Hat >>>> >>>> _______________________________________________ >>>> 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 >> >> > _______________________________________________ > 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
