[Pulp-dev] redmine process for katello-integration-related issues
Grant Gainey
ggainey at redhat.com
Mon Apr 27 18:51:29 UTC 2020
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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20200427/a31e10ae/attachment.htm>
More information about the Pulp-dev
mailing list