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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 16.04.2020 23:14, Stefano Stabellini wrote:
> On Wed, 15 Apr 2020, Jan Beulich wrote:
>> 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.
> 
> I dropped the definition of "Backport: all", and adopted George's
> suggested wording:
> 
>   The backport requester is expected to specify which currently supported
>   releases need the backport; but encouraged to specify a release as far
>   back as possible which applies.
> 
> 
>> 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.
> 
> I couldn't think of anything better than:
> 
>   Backport: 4.9+ # maybe older
> 
> We probably don't need to codify something like that in this document.

The suggestion looks fine to me, and people using slightly varying
wording wouldn't be a problem either.

> As an alternative we could perhaps reuse the "Backport: all" idea in a
> different light for this new purpose.
> 
> I expect that in these cases where we don't know the oldest affected
> tree, all the currently maintained stable trees will have to get the
> backport. So maybe we could use one of the following:
> 
>   Backport: all
>   Backport: oldest
>   Backport: oldest-unknown
> 
> To express that the fix needs to be backported to *all* the currently
> maintained stable trees, but there might be also other older
> unmaintained trees that could be affected; we don't know for sure how
> far back it should go.

My prior objection to "all" remains - it changes over time what
"currently means", rendering the tag stale quite quickly. I think
that without even providing a suggested means to create such a tag
without an explicit version specified we underline the need to
figure out a baseline from where to apply the backport.

One more thing comes to mind that may want mentioning here: If
people request a backport, I think this should take as an
implication their willingness to actually be involved in doing
the actual backporting work. Typically it's pretty simple, but
every now and then quite a bit of effort is needed. It would be
nice if the stable tree maintainers could push over some of this
burden without the requester being caught by surprise.

Jan