From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_LOW,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 20470 invoked from network); 31 May 2023 19:59:45 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 31 May 2023 19:59:45 -0000 Received: (qmail 7544 invoked by uid 550); 31 May 2023 19:59:41 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 7510 invoked from network); 31 May 2023 19:59:40 -0000 Date: Wed, 31 May 2023 15:59:28 -0400 From: Rich Felker To: Jens Gustedt Cc: musl@lists.openwall.com Message-ID: <20230531195928.GJ4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [musl] 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.