Like ships that cross in the night... :) On Thu, Apr 23, 2020 at 8:11 AM Tatiana Tereshchenko <ttere...@redhat.com> wrote:
> 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? > See the proposal I sent like 2 seconds before I saw you had replied! I think we're in broad agreement, but I like mine better :) G > > On Thu, Apr 23, 2020 at 12:30 PM David Davis <davidda...@redhat.com> > 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 <ggai...@redhat.com> wrote: >> >>> >>> >>> 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 >> > -- 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
