Hey folks, Apologies for the time-gap, but I believe we've finally closed the loop on this proposal in this weeks Pulp3/katello integration meetup. The stakeholders all agreed that we're going to:
- set all open Katello-P1-tagged issues to High prio - set all open Katello-P3-tagged issues to Low prio - add a Katello tag to all Katello-PX-tagged issues - remove Katello-PX tag and all uses thereof - inform the thread of meeting decision - triage-meeting will be looking for 'open Katello tag' and will prioritize from that set going forward This is the "inform the thread" bullet - I am going to do the pan.io housecleaning this afternoon. Thanks for all the thoughtful input folks! G On Mon, Apr 27, 2020 at 3:31 PM Grant Gainey <[email protected]> wrote: > On Mon, Apr 27, 2020 at 3:08 PM Brian Bouterse <[email protected]> > wrote: > >> On Mon, Apr 27, 2020 at 2:52 PM Grant Gainey <[email protected]> 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 <[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 >>>>>> >>>>> >>>> >>>> -- >>>> Grant Gainey >>>> Principal Software Engineer, Red Hat System Management Engineering >>>> >>> >>> >>> -- >>> 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 > -- Grant Gainey Principal Software Engineer, Red Hat System Management Engineering
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
