[Pulp-dev] Reconsidering PUP-3

Michael Hrivnak mhrivnak at redhat.com
Mon Oct 2 11:37:01 UTC 2017


+1

On Fri, Sep 29, 2017 at 10:08 AM, Brian Bouterse <bbouters at redhat.com>
wrote:

> +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 <dkliban at redhat.com> wrote:
>
>> +1
>>
>> On Fri, Sep 29, 2017 at 9:17 AM, David Davis <daviddavis at 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 <bbouters at 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 <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
>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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
>
>


-- 

Michael Hrivnak

Principal Software Engineer, RHCE

Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20171002/61114ead/attachment.htm>


More information about the Pulp-dev mailing list