[Pulp-dev] redmine process for katello-integration-related issues

Brian Bouterse bmbouter at redhat.com
Mon Apr 27 19:07:56 UTC 2020 

On Mon, Apr 27, 2020 at 2:52 PM Grant Gainey <ggainey at redhat.com> 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 <ggainey at redhat.com> 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 <daviddavis at 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 <ggainey at redhat.com> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Apr 22, 2020 at 6:17 PM David Davis <daviddavis at 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 <ggainey at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Hey folks,
>>>>>>
>>>>>> To close the loop on this:
>>>>>>
>>>>>> On Thu, Apr 9, 2020 at 6:26 AM Tatiana Tereshchenko <
>>>>>> ttereshc at 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 <daviddavis at 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 <
>>>>>>>> jsherril at 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 <ggainey at 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 at redhat.com
>>>>>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Pulp-dev mailing listPulp-dev at redhat.comhttps://www.redhat.com/mailman/listinfo/pulp-dev
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Pulp-dev mailing list
>>>>>>>>> Pulp-dev at redhat.com
>>>>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Pulp-dev mailing list
>>>>>>>> Pulp-dev at redhat.com
>>>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Pulp-dev mailing list
>>>>>>> Pulp-dev at 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 at 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20200427/a66cb0f2/attachment.htm>

More information about the Pulp-dev mailing list