[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230531195928.GJ4163@brightrain.aerifal.cx>
Date: Wed, 31 May 2023 15:59:28 -0400
From: Rich Felker <dalias@...c.org>
To: Jens Gustedt <Jens.Gustedt@...ia.fr>
Cc: musl@...ts.openwall.com
Subject: High-level C23 process requests
The C23 patches have gotten to be something of a sprawl of threads of
various review and revision work, disagreements from minor to major,
etc., and I'd like to make a couple requests for keeping this
managable to myself and other list participants:
1. Generally, we don't do the LKML-style thing of sending N related
patches as N replies to a thread. This is really unmanagable for
folks' inboxes, and a few people have expressed that already to me
out-of-band. Patches are best sent in MIME form, with a set of
related patches all attached to a single email. This makes it a lot
easier to discuss with context that crosses individual patch
boundaries, and for folks not interested in them to ignore them. It
also makes it possible to keep the v2, etc. in the same thread so
context is preserved (which isn't a hard rule or anything, but
might help keep things organized here).
2. Extension (or "optional") functionality that's not a C23
conformance requirement should be clearly marked as such and
proposed separately, ideally after C23 work is merged so that
there's not so much cognitive load here. This is the only way
that's fair to our community to be able to engage in any sort of
process about whether such changes move forward. Normally, when
this kind of change is proposed, it's in isolation and clearly
visible for folks to weigh in on, but that does not work when it's
bundled with changes which would be automatically acceptable in
principle as conformance requirements.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
