[Mesa-dev] [PATCH] docs: Clarify Fixes tag behavior for stable branches.

[Emil Velikov]

On 23 September 2018 at 15:40, Bas Nieuwenhuizen
<bas at basnieuwenhuizen.nl> wrote:
> On Sun, Sep 23, 2018 at 4:34 PM Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>
>> On 23 September 2018 at 15:28, Bas Nieuwenhuizen
>> <bas at basnieuwenhuizen.nl> wrote:
>> > This seems to be the current state of affairs. Emil has plans to
>> > get feedback about it and possibly change it, but let us put this
>> > in the documentation now in case that gets delayed or cancelled.
>> >
>> > This should clarify the misunderstanding which started
>> >
>> > https://lists.freedesktop.org/archives/mesa-dev/2018-September/205696.html
>> >
>> > Signed-off-by: Bas Nieuwenhuizen <bas at basnieuwenhuizen.nl>
>> > CC: Emil Velikov <emil.l.velikov at gmail.com>
>> > ---
>> >
>> > Seems like some release managers also consistently notify on rejected Fixes patches,
>> > but I don't think we should encode behavior of different release managers in the
>> > documentation, so this seems like the safe choice.
>> >
>> I think it's crucial that there's consistency and clarity of what we do.
>>
>> >  docs/submittingpatches.html | 4 +++-
>> >  1 file changed, 3 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/docs/submittingpatches.html b/docs/submittingpatches.html
>> > index e5350bdb2cf..144e00d677b 100644
>> > --- a/docs/submittingpatches.html
>> > +++ b/docs/submittingpatches.html
>> > @@ -284,7 +284,9 @@ Thus, drop the line <strong>only</strong> if you want to cancel the nomination.
>> >
>> >  Alternatively, if one uses the "Fixes" tag as described in the "Patch formatting"
>> >  section, it nominates a commit for all active stable branches that include the
>> > -commit that is referred to.
>> > +commit that is referred to. However, this is only an implicit nomination and the
>> > +release manager can decide to reject your patch without replying to the original
>> > +patch or asking for a backport.
>> >
>> We can have this temporary, but I'd argue that silently dropping
>> things is a bad idea.
>
> Totally agreed, the question here is whether there is value in
> documenting our current process with the listed shortcomings.  If yes,
> this patch is IMO it, if not I'll drop it.

Since this is what others have been doing - let's get this merged as-is.
But we should sit down and clarify things this week.

-Emil