<div dir="ltr">Hey folks,<div><br></div><div>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".</div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><ul><li>tag katello-related issues as 'katello'</li><li>use the milestone field to define the planned-pulp-release-version</li><li>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')</li></ul><div>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.</div></div><div><br></div><div>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!</div><div><br></div><div>Thanks,</div><div>G</div><div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Grant Gainey</div><div>Principal Software Engineer, Red Hat System Management Engineering</div></div></div></div></div></div></div>