Re: [PATCH v2] Introduce a description of a new optional tag for Backports

[Jan Beulich <jbeulich@xxxxxxxx>]

On 15.04.2020 11:49, Julien Grall wrote:
> 
> 
> On 15/04/2020 10:43, George Dunlap wrote:
>>
>>
>>> On Apr 15, 2020, at 7:23 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>
>>> On 14.04.2020 18:54, Stefano Stabellini wrote:
>>>> On Tue, 14 Apr 2020, Jan Beulich wrote:
>>>>> On 10.04.2020 18:49, Stefano Stabellini wrote:
>>>>
>> [snip]
>>>>>> +    Backport: all
>>>>>> +
>>>>>> +It marks a commit for being a candidate for backports to all relevant
>>>>>> +trees.
>>>>>
>>>>> I'm unconvinced of the utility of this form - what "all" resolves to
>>>>> changes over time. There's almost always a first version where a
>>>>> particular issue was introduced. If we want this to be generally
>>>>> useful, imo we shouldn't limit the scope of the tag to the upstream
>>>>> maintained stable trees.
>>>>
>>>> The reason why I suggested also to have a "wildcard" version of this
>>>> tag, is that the person adding the tag (could be the contributor trying
>>>> to be helpful) might not know exactly to which stable trees the patch
>>>> should be backported to.
>>>>
>>>> Writing this sentence, I realize that I really meant "any" rather than
>>>> "all". Would you prefer if I used "any"? Or we could even suggest to leave
>>>> it black like this:
>>>>
>>>>   Backport:
>>>>
>>>> But it looks a bit weird.
>>>
>>> Indeed. Instead of "all" or "any", how about "yes", "unspecified", or
>>> "unknown"? Nevertheless, I still think people asking for a backport
>>> should be nudged towards determining the applicable range; them not
>>> doing so effectively pushes the burden to the general maintainers or
>>> the stable tree ones, both of which scales less well. Omitting the
>>> tag if they don't want to invest the time would to me then seem to
>>> be the cleanest alternative. Albeit I'm sure views here will vary.
>>
>> FWIW asking people adding the tag to do the work of figuring out which 
>> versions to backport to makes sense to me.
> 
> If you ask the contributor to do the work then you need to give guidance on 
> the "older" version you can specify in Backport.
> 
> For instance, let say the bug was introduced in Xen 4.2. Are we allowing the 
> user to specify Backport: 4.2+ or should it be 4.11+?
> 
> I would favor the former as this helps for downstream user which haven't yet 
> moved to the supported stable tree.

In an earlier reply I did suggest the same, for the same reason.

Jan