Grant, thanks for trying to solve it thoroughly and with less bookkeeping work for others.
However, I agree with the sentiment that it's better to have no milestone than the wrong one. Setting a milestone correctly is a difficult-to-impossible task, since that can change with time. Also some projects/plugins assign milestones as a part of release process, some assign ahead of time. How about every mini-team, pulpcore and plugins, will figure out milestones themselves and set them whenever they think is necessary? And for now we just: - create a Katello tag - set this tag for all Katello items - adjust priority (P1 - High, P2 - Normal, P3 - low) - remove Katello-Px tags What do you all think? On Thu, Apr 23, 2020 at 12:30 PM David Davis <[email protected]> wrote: > pulpcore is not the only project with milestones. Each project has its own > set of milestones to represent different versions. The issue is your > proposal is trying to assign all Katello-PX issues to a pulpcore milestone. > That won't work if you have say a pulp_container or pulp_ansible issue with > a Katello-PX tag. > > You could go through all the Katello-PX issues and try to figure out which > milestone in which project to assign it to but with so many milestones and > projects, it's going to be a huge pain. My suggestion was to just worry > about the open issues and not try to retroactively assign these issues to > milestones. > > David > > > On Wed, Apr 22, 2020 at 7:12 PM Grant Gainey <[email protected]> wrote: > >> >> >> On Wed, Apr 22, 2020 at 6:17 PM David Davis <[email protected]> >> 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 <[email protected]> wrote: >>> >>>> Hey folks, >>>> >>>> To close the loop on this: >>>> >>>> On Thu, Apr 9, 2020 at 6:26 AM Tatiana Tereshchenko < >>>> [email protected]> 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 <[email protected]> >>>>> 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 <[email protected]> >>>>>> 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 <[email protected]> >>>>>>> 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 >>>>>>>> [email protected] >>>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pulp-dev mailing >>>>>>> [email protected]https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pulp-dev mailing list >>>>>>> [email protected] >>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>>> >>>>>> _______________________________________________ >>>>>> Pulp-dev mailing list >>>>>> [email protected] >>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>> >>>>> _______________________________________________ >>>>> Pulp-dev mailing list >>>>> [email protected] >>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>> >>>> >>>> >>>> -- >>>> Grant Gainey >>>> Principal Software Engineer, Red Hat System Management Engineering >>>> _______________________________________________ >>>> Pulp-dev mailing list >>>> [email protected] >>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>> >>> >> >> -- >> Grant Gainey >> Principal Software Engineer, Red Hat System Management Engineering >> > _______________________________________________ > Pulp-dev mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/pulp-dev >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
