I'm not familiar with the other tooling, but I'm glad that we'll be using it. Tools that are shared are usually better.
I wanted to check my understanding of the cherry picking approach. Is the review idea for Z releases specifically to sort out feature commits from bugfix commits to only include the bugfix commits? To contrast that against the process for Y releases, where both features and bugfixes are included and cherry picked. Is that understanding right? In terms of as automation idea, would it be possible to Z streams only cherry-pick commits associated with Issues (not Story, Task, or Refactor)? Thanks for making the Pulp builds great! -Brian On Wed, Jan 17, 2018 at 9:25 AM, David Davis <davidda...@redhat.com> wrote: > 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 > >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
