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 <bbout...@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.my...@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@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >> > > _______________________________________________ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev > >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
