[Pulp-dev] Pulp Cherry-Picking

[Patrick Creech]

The release engineering team has some tooling that will help automate the cherry-picking process,
but it will need some changes to the process outlined in the PUP-3.

The main thing is how would we want to associate a particular redmine item with what release it
*should* land in (as opposed to which one it *did* land in, that we do now).  We would need some way
to attach it to a release before the cherry-picking process gets ran so the code knows how to
associate it.  This could be as simple as a review of done work x days before a release and
identifying what should be picked back, or it could be labled as next z or next y during triage (to
name a couple options, open to others).

Something else I was thinking about was the automatic removal of issues that don't pick cleanly from
a release.  Given the recent statment of how our 2.y streams would be less frequent, this would mean
fixes would take longer to land for our users.  I think coming up with a process here to resolve the
(hopefully few) times this happens would be beneficial instead of defaulting to dropping them.

Questions? Comments? Suggestions?


Thanks,
Patrick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180110/4b8c7386/attachment.sig>