+1 and to the nitpick as well - tag katello-related issues as 'Katello' - use the milestone field to define the planned-pulp-release-version - use the Priority field to mark how important it is *to Katello* - remove the existing Katello P1/2/3 tags
On Wed, Apr 8, 2020 at 6:47 PM David Davis <davidda...@redhat.com> wrote: > Nitpick but I would use 'Katello' to be consistent with other tags. And > agreed that we should remove the Katello P tags. Other than that, LGTM. > > David > > > On Wed, Apr 8, 2020 at 12:42 PM Justin Sherrill <jsher...@redhat.com> > wrote: > >> +1 to all of this! >> On 4/8/20 12:35 PM, Brian Bouterse wrote: >> >> Thanks for writing this up and sending! My only addition would be to also >> remove the P1, P2, P3 tags entirely after setting all tagged issues with >> 'katello' and setting their priorities based on the previous P1/P2/P3 label. >> >> Thank you! >> >> On Wed, Apr 8, 2020 at 12:32 PM Grant Gainey <ggai...@redhat.com> wrote: >> >>> Hey folks, >>> >>> As part of working with the katello upstream, we have been using a >>> mechanism for prioritizing pulp-issues in order to help keep the Katello >>> Gang unblocked. We have been using the 'Tags' field in an issue, and >>> marking things as Katello-P1/2/3, with P1 being "blocker for the next >>> release". >>> >>> As we move through releases, this is starting to break down - last >>> release's P2 is this release's P1. This was brought up for discussion in >>> today's integration meeting. >>> >>> In order to continue being able to prioritize work, we're proposing a >>> change to the process to make it more sustainable as releases go on. I >>> *think* I have captured the proposal effectively below - if I've missed >>> something vital, I'm sure someone who was in the meeting will expand on it: >>> >>> - tag katello-related issues as 'katello' >>> - use the milestone field to define the planned-pulp-release-version >>> - use the Priority field to mark how important it is, *to katello*, >>> to fix a bug NOW, as opposed to 'the day before the release is cut' >>> (which >>> in practice is likely to be 'blockers are critical, everything else is >>> normal') >>> >>> This will make it easy to query redmine in a way that returns a >>> properly-ordered list, without some human having to go through and >>> group-change tags on multiple issues at once. >>> >>> Would appreciate more eyes on this, and especially input on what I might >>> have missed. We'd like to switch 'soon', so feedback before, say next >>> Wednesday 15-APR would be great! >>> >>> Thanks, >>> G >>> -- >>> Grant Gainey >>> Principal Software Engineer, Red Hat System Management Engineering >>> _______________________________________________ >>> Pulp-dev mailing list >>> Pulp-dev@redhat.com >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >> >> _______________________________________________ >> Pulp-dev mailing >> listPulp-dev@redhat.comhttps://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 >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
