On 23 September 2018 at 15:40, Bas Nieuwenhuizen <b...@basnieuwenhuizen.nl> wrote: > On Sun, Sep 23, 2018 at 4:34 PM Emil Velikov <emil.l.veli...@gmail.com> wrote: >> >> On 23 September 2018 at 15:28, Bas Nieuwenhuizen >> <b...@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 <b...@basnieuwenhuizen.nl> >> > CC: Emil Velikov <emil.l.veli...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
