Hi Pekka, A couple small ideas come to mind:
On 27 June 2018 at 14:47, Pekka Paalanen <ppaala...@gmail.com> wrote: > From: Pekka Paalanen <pekka.paala...@collabora.co.uk> > > Half of the ideas came from Daniel but most of them are reworded, the > rest are my thoughts. > > Mention compiler warnings specifically, and be more explicit on what > kind of code or bugs or bug fixes are acceptable or not. Clarify commit > scope. > > Cc: Daniel Stone <dani...@collabora.com> > Signed-off-by: Pekka Paalanen <pekka.paala...@collabora.co.uk> > --- > CONTRIBUTING.md | 19 ++++++++++++++++--- > 1 file changed, 16 insertions(+), 3 deletions(-) > > diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md > index 70d0eca..51bef89 100644 > --- a/CONTRIBUTING.md > +++ b/CONTRIBUTING.md > @@ -223,11 +223,24 @@ include tests excercising the additions in the test > suite. > - The code fits the existing software architecture, e.g. no layering > violations. > > -- The code is correct and does not ignore corner-cases. > +- The code is correct and does not introduce new failures for existing users, > +does not add new corner-case bugs, and does not introduce new compiler > +warnings. Compiler warnings vary greatly on the compiler and it's version. It does become a nuisance when committer/reviewer is using a newer version which flags dozens of warnings. That aside, worth loosening this for patches where existing code is copied or moved? > > -- In a patch series, every intermediate step produces correct code as well. > +- In a patch series, every intermediate step produces correct and > warning-free > +code as well. > It makes sense to move this as the final bullet-point and let it refer to the whole section. Namely: - In a patch series, every intermediate step adheres to the guidelines above. HTH Emil _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel