[Pulp-dev] Merging forward commits
daviddavis at redhat.com
Tue Jan 31 14:52:11 UTC 2017
The first option sounds good to me. I can make a redmine issue to document
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
>> > release branches instead of merging them forward from release branches.
>> > 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
>> > 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
>> > the common paradigm in open source). Instead, with cherrypicking
>> > 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
>> > 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
>> > just handle those one-off cases as they arise.
>> > Thoughts?
>> We've had similar discussions in the past and, iirc, we're generally in
>> of moving to a cherry-picking model from master to release branches. The
>> 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
>> 3+, and largely for the reasons you state here. As the current "guy who
>> which branch to open PRs against", it would be great if, when asked what
>> to open PRs against, the answer was always "master".
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
> Pulp-dev mailing list
> Pulp-dev at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pulp-dev