Thinking out loud, it would be nice if github would support a "cherry pick" PR that would be integrated with redmine. I'm imagining the process would be to do the normal PR process against master. Then, open a 2nd PR against the release branch to back-port. The PR could automate the cherry picking and update redmine. Probably just dreaming.
On 01/31/2017 06:30 AM, Brian Bouterse 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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
