On Mon, Apr 27, 2020 at 3:08 PM Brian Bouterse <bmbou...@redhat.com> wrote:
> On Mon, Apr 27, 2020 at 2:52 PM Grant Gainey <ggai...@redhat.com> wrote: > >> >> Sooo, how about the following for YARP (Yet Another Redmine Process): >> >> - Anything with a katello-PX tag, gets a *Katello* tag >> - Open issues with a Katello-P1 tag, get set to *High* priority >> - Open issues with a Katello-P1 or Katello-P2 tag, acquire a " >> *Katello-Release-3.16*"[1] tag >> - Open issues with a Katello-P3 tag acquire a "*Katello-Release-3.17*"[1] >> tag >> - Katello-PX tags are removed >> - Milestone is used in pulpcore and plugins to describe the version *of >> that project* when an issue is expected to be delivered >> - *Katello devs *that open issues as they test are *responsible* for >> setting *Priority* and adding the *Katello tag* >> - *Pulp/Katello triage meetings* are *responsible* for adding >> *Katello-3.XX >> tags* and *validating Priority* >> - *Pulp/plugin devs* *prioritize* work for katello *by >> Katello-version and priority*. >> >> On the downside, we end up with Yet More Tags doing things this way. >> > My goal is to have fewer tags and a simpler process. Here's my > counterproposal. Can we replace the 'Katello - P1", "Katello - P2", > "Katello - P3" with a single tag called ''Katello"? I think the weekly > check-in meeting will allow us to handle everything else in terms of > prioritization. > I actually think that will be *less simple *after about the second triage-meeting. The first five bullets up there are a one-time process to get us away from Katello-PX tags (and is prob going to be me pushing the buttons, so I'm ok with it :) ) So let's leave them aside. Milestone use is up to the plugin/project teams, to use or not. It's just listed to make clear it is *not* useful in the katello-PX context. With "just use a single tag 'Katello'", triage team meets weekly-ish, decides when things need to be done and in what priority. How is that recorded? As someone looking for "what I should work on next", where do I get that info? Do I have to find meeting minutes, or a spreadsheet, or worst track someone down and interrupt them? When priorities change, how do we make sure nobody's working from last-week's minutes? The last three bullets give us three responsible parties, each with one job. Katello-devs remember to mark issues 'Katello' when they open them. Triage meeting writes "needed by" and "priority" down *in the issues themselves*, rather than in a separate document. Developers let redmine tell them what order to work on things. I think my proposal makes things *simpler* - because if we follow it, there should be way less "asking around" to figure out what priorities are. Tools like redmine/bugzilla should be able to give a developer (or a manager, or an Interested Party) a view of what's being worked on, when, and in what order, without requiring extra reporting/documentation/meetings. Thoughts? G > >> On the upside, issues no longer require updating every release, devs can >> prioritize using an issue-query, and everyone can see what everyone else's >> expectations are without needing a meeting for it. >> >> I am absolutely certain I have missed something - it was all the way back >> on Friday morning when I had the last conversation about this, which may as >> well have been in the Pleistocene as far as my neurons are concerned. >> Please comment with suggestions/corrections. >> >> G >> >> [1] I prob am off on my katello-versions - but you get the idea... >> >> >> How's that sound? >>> >>> G >>> >>> >>> On Thu, Apr 23, 2020 at 6:29 AM 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 >>>>> >>>> >>> >>> -- >>> Grant Gainey >>> Principal Software Engineer, Red Hat System Management Engineering >>> >> >> >> -- >> 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