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

Grant Gainey ggainey at redhat.com
Thu Apr 23 12:14:30 UTC 2020


Like ships that cross in the night... :)

On Thu, Apr 23, 2020 at 8:11 AM Tatiana Tereshchenko <ttereshc at redhat.com>
wrote:

> 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?
>

See the proposal I sent like 2 seconds before I saw you had replied!  I
think we're in broad agreement, but I like mine better :)

G


>
> 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
>>
>

-- 
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/20200423/b200dc41/attachment.htm>


More information about the Pulp-dev mailing list