Additional Labels for Backport Work

[Jesper Wilhelmsson]

> On 27 Aug 2020, at 18:48, Mario Torre <neugens at redhat.com> wrote:
> 
> On Thu, Aug 27, 2020 at 6:11 PM Langer, Christoph
> <christoph.langer at sap.com> wrote:
>> 
>> +1
>> 
>> I think the labels are a good way to get things sorted.
>> 
>> Regarding "Locking an item for working on it", I was encouraging people to add some comment. But a label doesn't seem bad as well.
> 
> After a brief discussion today, it occurred to me that we can create
> backport bugs manually and assign them directly, wouldn't this be a
> better approach to track who is working on a specific backport?

As I read through this thread I was thinking the same thing. Why not use the facilities already in place in JBS instead of reinventing things?

The needs-review label don't have any counterpart in JBS, so as long as it's maintained (labels are removed once the review is done) this can be a good use of labels. I would suggest to put the label on the backport issue and use the same label ("needs-review") for all releases. (Queries would then look at fixVersion as well.) Reducing the number of different labels makes it easier to write verification queries to make sure things are well in JBS. A verification query for this could for instance check that there are no closed issues with the needs-review label. That query wouldn't have to be updated as new releases come and go.

Assigning issues are done using the assignee field and the correct way to do this is as Mario writes to create the backport issue and assign it to the engineer.

Dependencies between bugs are expressed using links ("blocks" etc). The "other fixes" that an issue is blocked by should have their own JBS issues and therefore using links would be the natural way to express this relationship.

/Jesper


> Cheers,
> Mario
> 
> --
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
>