[Pulp-dev] Pulp Cherry-Picking

[David Davis]

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 <pcreech at 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180117/4d809111/attachment.htm>