Oops, this was sent by accident. :) On Sun, Nov 03, 2024 at 12:10:18AM +0100, Alejandro Colomar wrote: > Link: <https://lwn.net/Articles/989380/> > Cc: Jiri Olsa <jolsa@xxxxxxxxxx> > Cc: Günther Noack <gnoack@xxxxxxxxxx> > Signed-off-by: Alejandro Colomar <alx@xxxxxxxxxx> > --- > > [offlist] > > Hi Günther, Jiri, > > I've prepared a draft of this contributing process that we talked about. > I won't officially post it until the other situation (sponsoring) is > resolved, but we can discuss it in private if you want. > > > Have a lovely night! > Alex > > CONTRIBUTING.d/patches | 23 +++++++++++++++++++++++ > 1 file changed, 23 insertions(+) > > diff --git a/CONTRIBUTING.d/patches b/CONTRIBUTING.d/patches > index fedb163d3..0562ded66 100644 > --- a/CONTRIBUTING.d/patches > +++ b/CONTRIBUTING.d/patches > @@ -131,6 +131,26 @@ Description > to the list. See also <CONTRIBUTING.d/git> for instructions for > configuring git-send-email(1) to use neomutt(1) as a driver. > > + New kernel/libc features > + If you write a new kernel or libc feature, you should document it > + in the same patch set that adds the feature, including any > + patches to the manual pages. The entire patch set consisting of > + both the feature and its manual page should be sent to all > + recipients for a better review process. That can be done with > + the following procedure: > + > + 1) Generate the kernel or libc patch set, with a cover letter, > + and using --thread in git-format-patch(1) (as specified in > + our ./CONTRIBUTING.d/git). This will generate a Message-ID > + header field in the cover letter. > + > + 2) Generate the man-pages patch set using > + --in-reply-to="<message-id>", where <message-id> is the value > + of the header field of the cover letter. > + > + 3) Send first the kernel/libc patch set, and then the man-pages > + one, so that they have a consistent order. > + > See also > CONTRIBUTING > CONTRIBUTING.d/* > -- > 2.39.2 > -- <https://www.alejandro-colomar.es/>
Attachment:
signature.asc
Description: PGP signature
