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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 15.04.2020 11:56, George Dunlap wrote:
> 
> 
>> On Apr 15, 2020, at 10:49 AM, Julien Grall <julien@xxxxxxx> 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.
> 
> I agree that specifying the oldest revision possible would be helpful.
> 
> However, I don’t think finding the absolute oldest revision should be 
> *required* — imagine a bug that was introduced between 3.2 and 3.3.  It’s 
> also perfectly fine if you go all the way back to 4.2 and stop because you 
> get bored, not because you found out that 4.1 didn’t need it.

In which case I'd like there to be a (canonical?) way of expressing
this, like in XSAs we say "at least back to" in such a case.

Jan