[Pulp-dev] Merging forward commits

[Brian Bouterse]

+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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170131/c52ea64a/attachment.htm>