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. -Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
