[Pulp-dev] Merging forward commits

[Daniel Alley]

+1

On Mon, Feb 6, 2017 at 12:09 PM, Ina Panova <ipanova at redhat.com> wrote:

> Seems like we are trying to choose/figure out what's more important -
> linear commit history which is readable or confidence and ability to track
> where exactly change had been applied?
>
> I agree with Mike and think that merging forward is so super simple, i
> must admit i had issues to understand this strategy from the beginning but
> now i could do that even with closed eyes.
>
> +1 of writing down the benefits of cherry-picking and clear our
> expectations.
>
>
>
> --------
> 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 Thu, Feb 2, 2017 at 6:50 PM, David Davis <daviddavis at redhat.com> wrote:
>
>> I think the merging forward seems pretty straightforward as well (with
>> some exceptions) but one of the my concerns is expecting community
>> contributors to know our process, the last release branch, etc when they
>> open a PR. Maybe this isn’t something to worry about though if we don’t
>> have enough contributions from outside the core Pulp team.
>>
>> Another one of my concerns is the git history being cluttered by merging
>> forward every time we commit a bug fix or hot fix (see my original email).
>> Thinking through this a bit though, what if we merged forward commits less
>> often? One option might be to only merge forward when we do a release.
>>
>> Also, I like the idea of creating a proposal and trying out cherrypicking
>> to see what the benefits would be and if we actually meet those benefits by
>> cherrypicking.
>>
>>
>> David
>>
>> On Thu, Feb 2, 2017 at 10:46 AM, Michael Hrivnak <mhrivnak at redhat.com>
>> wrote:
>>
>>> This comes up periodically, and we've had split opinions for a long
>>> time. I've been in the camp that likes merging, and finds it intuitive. But
>>> I'm open to trying cherry-picking since there is a lot of interest.
>>>
>>> I must admit, I am always surprised when people describe merging forward
>>> as complicated. For me, it boils down to this:
>>>
>>> - Features happen on master. No merging or cherry-picking required.
>>> - Bug fixes happen on the last release branch. Merge your bugfix branch
>>> to master and the release branch. Simple.
>>> - Hotfixes are a rare exception that require slightly more thought, but
>>> are still easy to reason about. If in doubt, "git merge-base [list all the
>>> places you want to merge your fix]" tells you where to branch from.
>>>
>>> That's the extent of my thought process when merging forward. I am
>>> generally interested to know more about how this process causes friction.
>>>
>>> But all of that said, I'm very happy to give cherry-picking a try. As
>>> Brian said, my main concern would just be tracking where a change has been
>>> applied. This is something I value a lot in the merge model.
>>>
>>> If we do switch, I think we should first write down specifically what
>>> benefits we expect to get. That would help in two ways: 1) Make sure
>>> everyone is on the same page about what we expect to gain. I suspect there
>>> are differing assumptions across the group. 2) Enable us to evaluate
>>> afterward to what extent the change was successful.
>>>
>>> Lastly, our current branching model was inspired by this classic
>>> approach:
>>>
>>> http://nvie.com/posts/a-successful-git-branching-model/
>>>
>>> If you're not familiar, it's worth a read for perspective. Their
>>> "develop" branch is our "master". And obviously we don't do things in quite
>>> the same way, but the general principles are the same.
>>>
>>> Michael
>>>
>>> On Thu, Feb 2, 2017 at 3:34 PM, Brian Bouterse <bbouters at redhat.com>
>>> wrote:
>>>
>>>> The main concern for me is how to track the cherry picks in Redmine.
>>>> Using the rebase and merge approach, or if Github had a dedicate cherry
>>>> pick feature, we still need a way in Redmine to know if any given bugfix
>>>> has been applied to older release streams, i.e. the current bugfix release
>>>> stream.
>>>>
>>>> On Wed, Feb 1, 2017 at 12:18 PM, Jeremy Audet <jaudet at redhat.com>
>>>> wrote:
>>>>
>>>>> > Thinking out loud, it would be nice if github would support a
>>>>> "cherry pick" PR
>>>>>
>>>>> I think you can. The submitter just needs to open a PR against some
>>>>> branch other than master, and the merger needs to select the rebase
>>>>> and merge
>>>>> <https://github.com/blog/2243-rebase-and-merge-pull-requests> GUI
>>>>> option.
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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/20170321/345a7abd/attachment.htm>