[Pulp-dev] Reconsidering PUP-3

[David Davis]

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 <pcreech at 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170925/ae7a5e31/attachment.htm>