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

Wed Apr 22 22:16:35 UTC 2020

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.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20200422/a1044606/attachment.htm>