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
