On Mon, Apr 27, 2020 at 2:52 PM Grant Gainey <[email protected]> wrote:
> Once more unto the breach, dear friends, once more... > > When last we saw our process, we were at something like this: > > On Thu, Apr 23, 2020 at 8:12 AM Grant Gainey <[email protected]> wrote: > >> OK, so let's take a step back. The thing that the initial proposal >> is/was attempting to address is that with the current P1/2/3 system, issues >> that are P2 one day become P1 the next, basically tied to katello's and >> pulp's release cycles. The goal was to be able to a) mark all issues that >> are important to katelllo, b) mark them for "when katello will need them" >> to meet its promises, and then c) be able to prioritize work inside a >> release cycle. Note that we were/are trying to get away from priority >> meaning "which release" - there are things that have been discussed, that >> are nice-to-haves (and therefore not High priority), that would need to be >> available by a given release for katello to take advantage of them (ie >> slated for a milestone). We also need to separate blockers from "work as >> usual". The initial proposal would solve a) by tagging something as >> 'Katello', b) by use of the milestone field to show what release *of >> pulp* the thing needed to be available by, and let us use Priority to >> address all the aspects of c), with blockers getting the Urgent priority. >> >> Having done a bunch more digging, you're right, 'milestone' as it stands >> can't be used this way for anything other than pulpcore. >> >> I think what we can do at this point is something like this: >> >> - set milestone for pulpcore issues, P2 = 3.4, P3 = 3.5 >> - mark *all* the Katello-PX tagged issues with an >> additional 'Katello' tag >> - any open Katello-P1 issues get set to *High* priority >> - remove the Katello-PX tags from *pulpcore issues only* >> - for the plugins, leave the Katello-PX tags - plugins who want to >> follow this process can set version-milestones as appropriate and remove >> when they're done >> >> > A(nother) requirement that needs to be addressed is "marking issues that > are opened *by the katello team*" - not "need this feature for > release-X", but "found this bug/issue" kind of things. This is a(nother) > cross-plugin need. > > So, back to "what are we trying to accomplish". > > The current process has problems because it: > > - conflates "needed by" and "priority" > - conflates "opened *by* katello" and "opened *for* katello" > - requires a lot of manual work as part of the release cycle to update > as the P2s become 1s and the 3s become 2s etc > > Relying on 'milestone', as we initially proposed, is a nonstarter. > Milestones are project-specific, aimed at a *project's* release-cycle, > and Care Not for pulpcore or katello. The cross-plugin Thing we have, is > 'Tag'. We'd like to use that for both "katello found this" and "katello > needs this by X". In this context, 'X' is *katello** release*, because > that's what drives "katello needs this by..." discussions. > > 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. > 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 >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
