[Pulp-dev] Merging forward commits

[David Davis]

The first option sounds good to me. I can make a redmine issue to document
this workflow.


David

On Tue, Jan 31, 2017 at 7:30 AM, Brian Bouterse <bbouters at redhat.com> wrote:

> +1 to making Pulp3 have all PRs target master and cherry picking backwards
> when necessary. I won't recap the benefits, but there are many.
>
> If we adopt this, the only thing I think we need with this also do
> (besides documenting this) is a way to track the cherry picking. There are
> several options:
>
> * Use a second/different redmine issue to track the inclusion of the
> backport into a given release and associate the two somehow. Maybe a custom
> field called 'cherry picks' could record issue numbers as a comma separated
> list which would be clickable into a redmine query.
>
> * Use an associated commit. With this a redmine issue will show the
> original commits and any cherry picks. We could have a new commit keyword
> so a commit could contain "cherrypick #1234" which would associate the
> cherry pick commit with issue 1234. It would not modify the state of the
> issue so whatever state it's in, e.g. CLOSED - CURRENT RELEASE or MODIFIED
> would remain as-is.
>
> * Use a custom field to track the cherry picks. This is convenient for
> release engineering queries, but would not show the actual cherry pick
> commits themselves.
>
>
> +1 the first option because it allows users to request backports as they
> desire and we can track them very clearly. It also should let the existing
> release engineering processes work well as-is in terms of making release
> notes. With that, I also prefer using a custom field to track the redmine
> issue numbers of the associated cherry pick commits so that for any given
> issue you can see if cherry picks are requested and then go look at those
> issues easily for more info.
>
> Thank you so much for bringing this up. If consensus is reached we should
> make a Redmine issue to document this new process for Pulp3.
>
> On Mon, Jan 30, 2017 at 5:16 PM, Sean Myers <sean.myers at redhat.com> wrote:
>
>> On 01/30/2017 04:55 PM, David Davis wrote:
>> > I was wondering if it might be worth considering cherrypicking commits
>> to
>> > release branches instead of merging them forward from release branches.
>> I
>> > might be a bit biased coming from Katello where we have done this for a
>> > while. For one thing I noticed that the git history in Pulp is very
>> > convoluted because of all the merge commits. Here is the git history of
>> > master in katello (bottom) compared to the git history of master in pulp
>> > (top):
>> >
>> > https://i.imgur.com/PR5vNBZ.png
>> >
>> > I think cherrypicking commits from master to release branches could also
>> > simplify our workflow a bit. Right now you have to identify what branch
>> > needs a hotfix before you open the PR and then you also have to update
>> the
>> > appropriate branch(es) after merging. I think this presents a barrier to
>> > entry for community contributors by asking them to open a PR against a
>> > specific branch if they want to fix a bug instead of just master (which
>> is
>> > the common paradigm in open source). Instead, with cherrypicking
>> hotfixes,
>> > we’d only have to worry about updating branches as part of
>> merging—which we
>> > have to do anyway as part of merging forward commits.
>> >
>> > There might instances where this workflow doesn’t work as well as
>> merging
>> > forward commits—namely when there are conflicts on a rebase branch or we
>> > need to test something specifically against a release—but I think we
>> could
>> > just handle those one-off cases as they arise.
>> >
>> > Thoughts?
>>
>> We've had similar discussions in the past and, iirc, we're generally in
>> favor
>> of moving to a cherry-picking model from master to release branches. The
>> (a?)
>> problem is that the Pulp 2 build system is heavily dependent on the merge
>> forward logic, so if we did switch to cherry-picking, it would be for
>> Pulp 3.
>>
>> That said, I'm +1 for cherry-picking from master to release branches for
>> Pulp
>> 3+, and largely for the reasons you state here. As the current "guy who
>> knows
>> which branch to open PRs against", it would be great if, when asked what
>> branch
>> to open PRs against, the answer was always "master".
>>
>>
>> _______________________________________________
>> 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/20170131/b9039b5f/attachment.htm>