[Pulp-dev] Reconsidering PUP-3

[Brian Bouterse]

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 <daviddavis at 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 <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
>>
>>
>
> _______________________________________________
> 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/20170928/30194585/attachment.htm>