[Pulp-dev] Reconsidering PUP-3

Tue Oct 3 12:36:23 UTC 2017

+1

On Mon, Oct 2, 2017 at 3:42 PM, Bihan Zhang <bizhang at redhat.com> wrote:

> +1
>
> On Oct 2, 2017 9:28 AM, "Ina Panova" <ipanova at redhat.com> wrote:
>
>> +1
>>
>>
>>
>> --------
>> Regards,
>>
>> Ina Panova
>> Software Engineer| Pulp| Red Hat Inc.
>>
>> "Do not go where the path may lead,
>>  go instead where there is no path and leave a trail."
>>
>> On Mon, Oct 2, 2017 at 2:45 PM, Daniel Alley <dalley at redhat.com> wrote:
>>
>>> +1
>>>
>>> On Mon, Oct 2, 2017 at 7:37 AM, Michael Hrivnak <mhrivnak at redhat.com>
>>> wrote:
>>>
>>>> +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
>>>>
>>>> _______________________________________________
>>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20171003/f0276208/attachment.htm>