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

Tatiana Tereshchenko ttereshc at redhat.com
Thu Apr 23 12:11:33 UTC 2020 

Grant, thanks for trying to solve it thoroughly and with less bookkeeping
work for others.

However, I agree with the sentiment that it's better to have no milestone
than the wrong one.
Setting a milestone correctly is a difficult-to-impossible task, since that
can change with time. Also some projects/plugins assign milestones as a
part of release process, some assign ahead of time.

How about every mini-team, pulpcore and plugins, will figure out milestones
themselves and set them whenever they think is necessary?
And for now we just:

   - create a Katello tag
   - set this tag for all Katello items
   - adjust priority (P1 - High, P2 - Normal, P3 - low)
   - remove Katello-Px tags

What do you all think?

On Thu, Apr 23, 2020 at 12:30 PM 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
>>
> _______________________________________________
> 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/20200423/35917059/attachment.htm>

More information about the Pulp-dev mailing list