On Wed, Apr 22, 2020 at 6:17 PM David Davis <davidda...@redhat.com> wrote:
> A couple observations: the 3.3[0] and 3.4[1] milestones already exist in > redmine. Also, you won't be able to assign any of the MODIFIED issues to > 3.3 because they're all plugin issues and the 3.3 milestone is exclusive to > pulpcore. IMHO, I probably wouldn't assign any issues to any milestones. I > think it would be worse having an issue on the wrong milestone than it > being unassigned. > If pulpcore is the only thing that has the version-milestones, then we're at a dead stop. The whole point of the initial process proposal, was that "milestone" would be able to completely replace the Katello-PX tags as a way for Katello to tell us what they needed/expected when; if that's only useful for pulpcore, then we have missed the mark, since the tags are used cross-organizationally. If you look at the list of open-issues <https://pulp.plan.io/issues?c%5B%5D=project&c%5B%5D=tracker&c%5B%5D=status&c%5B%5D=priority&c%5B%5D=subject&c%5B%5D=author&c%5B%5D=assigned_to&c%5B%5D=cf_3&c%5B%5D=cf_7&f%5B%5D=status_id&f%5B%5D=cf_7&f%5B%5D=&group_by=&op%5Bcf_7%5D=%3D&op%5Bstatus_id%5D=o&set_filter=1&sort=project%2Cstatus%2Ccf_7&t%5B%5D=&utf8=%E2%9C%93&v%5Bcf_7%5D%5B%5D=Katello-P1&v%5Bcf_7%5D%5B%5D=Katello-P2&v%5Bcf_7%5D%5B%5D=Katello-P3> currently tagged with Katello-PX tags, you'll see more than pulpcore in there. >From ttereshc's summary email: > > - 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 > > If we can't mark non-pulpcore-issues with "planned-pulp-release-version", then this proposal is DOA. Clearly, we need some more discussion! Anyone else want to join in? G > That would leave the process somewhat simpler: > > 1. Create a Katello tag and assign it to all Katello-PX issues > 2. Set the priority to high for P1 issues, medium for P2 issues, and low > for P3 issues > 3. Optionally, add open P2 issues to 3.4 milestone > 4. Remove all Katello-PX tags > > And then Katello can just add the 15 issues at NEW/ASSIGNED to a milestone > as they see fit: https://pulp.plan.io/issues?query_id=113. > > [0] https://pulp.plan.io/versions/83 > [1] https://pulp.plan.io/versions/88 > > David > > > On Wed, Apr 22, 2020 at 5:15 PM Grant Gainey <ggai...@redhat.com> wrote: > >> Hey folks, >> >> To close the loop on this: >> >> On Thu, Apr 9, 2020 at 6:26 AM Tatiana Tereshchenko <ttere...@redhat.com> >> wrote: >> >>> +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 >>> >>> I am working to actually make these changes, and need a quick check on >> specifics. >> >> Right now there are 29 open issues with a Katello-PX tag. 14 of these are >> in MODIFIED/P1, all against various plugins (ansible, certguard, and rpm) >> I propose to do the following (order matters): >> >> 1. create milestones for *pulp-3.0*, *pulp-3.4*, *pulp-3.5*, and >> *pulp-3.6* (thinking both ahead and behind a little) >> 2. create a *Katello* tag >> 3. anything in MODIFIED gets the *3.3* milestone. >> 4. Remaining open katello-P2 issues get a *3.4* milestone. >> 5. Remaining open katello-P3 issues get a *3.5* milestone >> 6. open *Katello-P1* issues get a *High* priority >> 7. all other open issues get a *Normal* priority >> 8. closed Katello-PX issues get the *3.0 *milestone >> 9. tag all Katello-PX issues, open or closed, with *Katello* >> 10. remove all Katello-PX tags on anything open or closed >> 11. This will leave us with 29 open issues using the new process, *which >> will need Priority and Milestone triage* >> >> Does that catch everything we want from this, going forward? I'd like a >> quick turnaround here so we can make sure we are working on 3.4 items in >> the right order. >> >> G >> >> >>> 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 >>> >> >> >> -- >> 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 >> > -- 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