+1 On Oct 2, 2017 9:28 AM, "Ina Panova" <ipan...@redhat.com> 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 <dal...@redhat.com> wrote: > >> +1 >> >> On Mon, Oct 2, 2017 at 7:37 AM, Michael Hrivnak <mhriv...@redhat.com> >> wrote: >> >>> +1 >>> >>> On Fri, Sep 29, 2017 at 10:08 AM, Brian Bouterse <bbout...@redhat.com> >>> 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 <dkli...@redhat.com> >>>> wrote: >>>> >>>>> +1 >>>>> >>>>> On Fri, Sep 29, 2017 at 9:17 AM, David Davis <davidda...@redhat.com> >>>>> 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 <bbout...@redhat.com >>>>>> > 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 <davidda...@redhat.com> >>>>>>> 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 <pcre...@redhat.com >>>>>>>> > 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 >>>>>>>>> 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 >>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Pulp-dev mailing list >>>> Pulp-dev@redhat.com >>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>> >>>> >>> >>> >>> -- >>> >>> Michael Hrivnak >>> >>> Principal Software Engineer, RHCE >>> >>> Red Hat >>> >>> _______________________________________________ >>> 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 > >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev