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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
