[Pulp-dev] redmine process for katello-integration-related issues
Grant Gainey
ggainey at redhat.com
Fri May 8 17:30:47 UTC 2020
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 <ggainey at redhat.com> wrote:
> 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
>
--
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/20200508/2e416c60/attachment.htm>
More information about the Pulp-dev
mailing list