Sorry for not responding sooner. I like just doing a review process before the release but the triage idea sounds good too.
I’m also +1 for considering commits of issues that don’t cherry-pick cleanly for 2.y releases. David On Wed, Jan 10, 2018 at 4:18 PM, Patrick Creech <pcre...@redhat.com> wrote: > 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 > _______________________________________________ > 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
