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.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
