+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