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

Grant Gainey ggainey at redhat.com
Mon Apr 27 19:31:52 UTC 2020 

On Mon, Apr 27, 2020 at 3:08 PM Brian Bouterse <bmbouter at redhat.com> wrote:

> On Mon, Apr 27, 2020 at 2:52 PM Grant Gainey <ggainey at 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 <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
>>
>

-- 
Grant Gainey
Principal Software Engineer, Red Hat System Management Engineering
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20200427/7d805819/attachment.htm>

More information about the Pulp-dev mailing list