Message ID | 20201020142146.61837-1-colomar.6.4.3@gmail.com |
---|---|
Headers |
Return-Path: <libc-alpha-bounces@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3D89E385782C; Tue, 20 Oct 2020 14:23:24 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3D89E385782C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1603203804; bh=Q1x2W8I95W3CLw/9PUByWBG73WKcy4zn1xzJz/NM4fU=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=iev7ZZSonHTNBdcnjih6lOkw4bDI2+/DGPpOMezMaedmLz7LY1jUm4GCrdSOeDT0r w7gOQvtQTpSQU2qL/7tbM9giUPd3ifVZRFwes8qI2x144GktcDj+7SzWrUcgLMjk1W qLQUtcOiED3Mvcd/gtpFbGPX51LIl5VeWA/UjJso= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) by sourceware.org (Postfix) with ESMTPS id 7D84F385782C for <libc-alpha@sourceware.org>; Tue, 20 Oct 2020 14:23:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7D84F385782C Received: by mail-wr1-x443.google.com with SMTP id x7so2406012wrl.3 for <libc-alpha@sourceware.org>; Tue, 20 Oct 2020 07:23:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=Q1x2W8I95W3CLw/9PUByWBG73WKcy4zn1xzJz/NM4fU=; b=Rlz59ciJi/XLK6GpkjbUUCB7K7ghnCOrAXOohOQK90aCDUMqogCLf/u/SRM686Dj0A 8FyLAjmDRYW3tZ36NPr7RhaWqIH0AbhS+Eg+1MaM8UuRfVgpLoP1Y/XmWoI4n3AXJeCm 8w+Nji985thmfKp6S1cGBw7mzHBQzsVI/GTNncDDLeTkw5H+DkriWTeP+WvaXmOKYJoE RKQtKmrEpvBYhvnJN1ZZcpttTnBfC6dR/B0T2rJkI6nvby8PvyQ/rRwLuFbPhdgj57h4 uh/Upg+K+9AL1r/Ub+1nHPhMmhzfiOOOB0tc8r9ZlLOC5lxoHYdYmzMXJ48Fp355UKHF l7+A== X-Gm-Message-State: AOAM531xqTAOo0TmmpKyoCQDfUE/j0wYRJn3k/TsYltVMNPtNNqSjCnh q4bjpli3EjsFTjN8k+VVL4Y= X-Google-Smtp-Source: ABdhPJyyRfvKkiNHFoIDMIQqxFgW/GNBSDBeaJTBIgVrmUS8NkYfhWCSWRb7iZLusQLULGKkdjEH6Q== X-Received: by 2002:a5d:66d2:: with SMTP id k18mr4134764wrw.229.1603203800575; Tue, 20 Oct 2020 07:23:20 -0700 (PDT) Received: from localhost.localdomain ([170.253.60.68]) by smtp.googlemail.com with ESMTPSA id s19sm3422153wmc.0.2020.10.20.07.23.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Oct 2020 07:23:20 -0700 (PDT) To: mtk.manpages@gmail.com Subject: [PATCH 00/22] list.3: New page forked from queue.3 Date: Tue, 20 Oct 2020 16:21:25 +0200 Message-Id: <20201020142146.61837-1-colomar.6.4.3@gmail.com> X-Mailer: git-send-email 2.28.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, KAM_NUMSUBJECT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> From: Alejandro Colomar via Libc-alpha <libc-alpha@sourceware.org> Reply-To: Alejandro Colomar <colomar.6.4.3@gmail.com> Cc: Alejandro Colomar <colomar.6.4.3@gmail.com>, linux-man@vger.kernel.org, libc-alpha@sourceware.org Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces@sourceware.org> |
Series |
list.3: New page forked from queue.3
|
|
Message
Alejandro Colomar
Oct. 20, 2020, 2:21 p.m. UTC
Hi Michael, I finished one of the pages: list.3 Would you maybe call the page LIST.3 instead? I didn't write the link pages yet in case we call it differently. Please comment any improvements you may find. There are too many patches, so you may prefer to pull from my repo, where I created the tag 'list_v1' for this patchset: https://github.com/alejandro-colomar/man-pages.git list_v1 As you can probably guess, if you prefer to pull from the repo, I'll create similar tags for revisions of this patchset (e.g., 'list_v2'). Cheers, Alex Alejandro Colomar (22): list.3: New page that will hold the (list) contents of queue.3 list.3, queue.3: NAME: Move code from queue.3 to list.3 list.3: NAME: ffix: Use man markup list.3: NAME: Add description list.3, queue.3: SYNOPSIS: Move code from queue.3 to list.3 list.3: SYNOPSIS: Copy include from queue.3 list.3: SYNOPSIS: ffix: Use man markup list.3: DESCRIPTION: Add short description list.3: DESCRIPTION: Copy description about naming of macros from queue.3 list.3: DESCRIPTION: Remove unrelated code to adapt to this page list.3: DESCRIPTION: ffix: Use man markup list.3, queue.3: DESCRIPTION: Move list specific code from queue.3 to list.3 list.3: DESCRIPTION: ffix: Use man markup list.3: DESCRIPTION: Remove line pointing to the EXAMPLES list.3: CONFORMING TO: Copy from queue.3 list.3: CONFORMING TO: Adapt to this page list.3: CONFORMING TO: ffix: Use man markup list.3: SEE ALSO: Add insque(3) and queue(3) list.3, queue.3: EXAMPLES: Move example program from queue.3 to list.3 list.3: EXAMPLES: ffix: Use man markup list.3: BUGS: Note LIST_FOREACH() limitations list.3: RETURN VALUE: Add details about the return value of those macros that "return" a value man3/list.3 | 347 +++++++++++++++++++++++++++++++++++++++++++++++++++ man3/queue.3 | 237 ----------------------------------- 2 files changed, 347 insertions(+), 237 deletions(-) create mode 100644 man3/list.3
Comments
Hi Alex, On 10/20/20 4:21 PM, Alejandro Colomar wrote: > Hi Michael, > > I finished one of the pages: list.3 > > Would you maybe call the page LIST.3 instead? I think list.3 is okay. > I didn't write the link pages yet in case we call it differently. > > Please comment any improvements you may find. Overall, I think the result is fine, but: > There are too many patches, so you may prefer to pull from my repo, > where I created the tag 'list_v1' for this patchset: > > https://github.com/alejandro-colomar/man-pages.git list_v1 > > As you can probably guess, if you prefer to pull from the repo, > I'll create similar tags for revisions of this patchset (e.g., 'list_v2'). I suppose if I was doing this work I would chunk it up into bigger pieces. I appreciate that you are trying to meticulously show the steps that you took to build the page, but 22 patches does really feel like too much. And I would have combined the "Use man markup" patches into one step at the end, and I'd prefer you do that for future patches (but I can live with things as they are in this patch series). In terms of fewer patches, how would you feel about squashing the patches as per the blank line separators below (and consequently having bigger commit messages): > Alejandro Colomar (22): > list.3: New page that will hold the (list) contents of queue.3 > list.3, queue.3: NAME: Move code from queue.3 to list.3 > list.3: NAME: ffix: Use man markup > list.3: NAME: Add description > list.3, queue.3: SYNOPSIS: Move code from queue.3 to list.3 > list.3: SYNOPSIS: Copy include from queue.3 > list.3: SYNOPSIS: ffix: Use man markup > list.3: DESCRIPTION: Add short description > list.3: DESCRIPTION: Copy description about naming of macros from > queue.3 > list.3: DESCRIPTION: Remove unrelated code to adapt to this page > list.3: DESCRIPTION: ffix: Use man markup > list.3, queue.3: DESCRIPTION: Move list specific code from queue.3 to > list.3 > list.3: DESCRIPTION: ffix: Use man markup > list.3: DESCRIPTION: Remove line pointing to the EXAMPLES > list.3: CONFORMING TO: Copy from queue.3 > list.3: CONFORMING TO: Adapt to this page > list.3: CONFORMING TO: ffix: Use man markup > list.3: SEE ALSO: Add insque(3) and queue(3) > list.3, queue.3: EXAMPLES: Move example program from queue.3 to list.3 > list.3: EXAMPLES: ffix: Use man markup > list.3: BUGS: Note LIST_FOREACH() limitations > list.3: RETURN VALUE: Add details about the return value of those > macros that "return" a value Squashing as above would yield 10 patches, and I'd kind of prefer that so as to avoid quite so many commits in the history. (For future patches though, I would prefer to split out the "Use man markup" into a single patch at the end of the series.) Thanks, Michael
On 2020-10-20 20:57, Michael Kerrisk (man-pages) wrote: > Hi Alex, > > On 10/20/20 4:21 PM, Alejandro Colomar wrote: >> Hi Michael, >> >> I finished one of the pages: list.3 >> >> Would you maybe call the page LIST.3 instead? > > I think list.3 is okay. > >> I didn't write the link pages yet in case we call it differently. >> >> Please comment any improvements you may find. > > Overall, I think the result is fine, but: > >> There are too many patches, so you may prefer to pull from my repo, >> where I created the tag 'list_v1' for this patchset: >> >> https://github.com/alejandro-colomar/man-pages.git list_v1 >> >> As you can probably guess, if you prefer to pull from the repo, >> I'll create similar tags for revisions of this patchset (e.g., 'list_v2'). > > I suppose if I was doing this work I would chunk it up into bigger > pieces. I appreciate that you are trying to meticulously show the > steps that you took to build the page, but 22 patches does > really feel like too much. And I would have combined the > "Use man markup" patches into one step at the end, and I'd prefer > you do that for future patches (but I can live with things as they > are in this patch series). > > In terms of fewer patches, how would you feel about squashing the > patches as per the blank line separators below (and consequently > having bigger commit messages): > >> Alejandro Colomar (22): >> list.3: New page that will hold the (list) contents of queue.3 > >> list.3, queue.3: NAME: Move code from queue.3 to list.3 >> list.3: NAME: ffix: Use man markup >> list.3: NAME: Add description > >> list.3, queue.3: SYNOPSIS: Move code from queue.3 to list.3 >> list.3: SYNOPSIS: Copy include from queue.3 >> list.3: SYNOPSIS: ffix: Use man markup > >> list.3: DESCRIPTION: Add short description >> list.3: DESCRIPTION: Copy description about naming of macros from >> queue.3 >> list.3: DESCRIPTION: Remove unrelated code to adapt to this page >> list.3: DESCRIPTION: ffix: Use man markup > >> list.3, queue.3: DESCRIPTION: Move list specific code from queue.3 to >> list.3 >> list.3: DESCRIPTION: ffix: Use man markup >> list.3: DESCRIPTION: Remove line pointing to the EXAMPLES > >> list.3: CONFORMING TO: Copy from queue.3 >> list.3: CONFORMING TO: Adapt to this page >> list.3: CONFORMING TO: ffix: Use man markup > >> list.3: SEE ALSO: Add insque(3) and queue(3) > >> list.3, queue.3: EXAMPLES: Move example program from queue.3 to list.3 >> list.3: EXAMPLES: ffix: Use man markup > >> list.3: BUGS: Note LIST_FOREACH() limitations > >> list.3: RETURN VALUE: Add details about the return value of those >> macros that "return" a value > > Squashing as above would yield 10 patches, and I'd kind of prefer > that so as to avoid quite so many commits in the history. > (For future patches though, I would prefer to split out the > "Use man markup" into a single patch at the end of the series.) I can't find the source (I think it was some kernel guide for sending patches), but I read some time ago that I should separate code movement from any other changes; otherwise git might not be able to follow that movement. So I would reorder and squash the commits as: Alejandro Colomar (22): list.3: New page that will hold the (list) contents of queue.3 list.3, queue.3: NAME: Move code from queue.3 to list.3 list.3, queue.3: SYNOPSIS: Move code from queue.3 to list.3 list.3, queue.3: DESCRIPTION: Move list specific code from queue.3 to list.3 list.3, queue.3: EXAMPLES: Move example program from queue.3 to list.3 list.3: SYNOPSIS: Copy include from queue.3 list.3: DESCRIPTION: Copy description about naming of macros from queue.3 list.3: CONFORMING TO: Copy from queue.3 list.3: DESCRIPTION: Remove unrelated code to adapt to this page list.3: DESCRIPTION: Remove line pointing to the EXAMPLES list.3: CONFORMING TO: Adapt to this page squash as list.3: Copy and adapt code from queue.3 list.3: NAME: ffix: Use man markup list.3: SYNOPSIS: ffix: Use man markup list.3: DESCRIPTION: ffix: Use man markup list.3: DESCRIPTION: ffix: Use man markup list.3: CONFORMING TO: ffix: Use man markup list.3: EXAMPLES: ffix: Use man markup squash as list.3: ffix: Use man markup list.3: NAME: Add description list.3: DESCRIPTION: Add short description list.3: SEE ALSO: Add insque(3) and queue(3) list.3: BUGS: Note LIST_FOREACH() limitations list.3: RETURN VALUE: Add details about the return value of those macros that "return" a value squash as list.3: Add details I'll keep the messages of the squashed commits inside the commit msg. This would mean 8 patches. Sounds good? Thanks, Alex > > Thanks, > > Michael >
Hi Alex, On 10/20/20 9:21 PM, Alejandro Colomar wrote: > > > On 2020-10-20 20:57, Michael Kerrisk (man-pages) wrote: >> Hi Alex, >> >> On 10/20/20 4:21 PM, Alejandro Colomar wrote: >>> Hi Michael, >>> >>> I finished one of the pages: list.3 >>> >>> Would you maybe call the page LIST.3 instead? >> >> I think list.3 is okay. >> >>> I didn't write the link pages yet in case we call it differently. >>> >>> Please comment any improvements you may find. >> >> Overall, I think the result is fine, but: >> >>> There are too many patches, so you may prefer to pull from my repo, >>> where I created the tag 'list_v1' for this patchset: >>> >>> https://github.com/alejandro-colomar/man-pages.git list_v1 >>> >>> As you can probably guess, if you prefer to pull from the repo, >>> I'll create similar tags for revisions of this patchset (e.g., 'list_v2'). >> >> I suppose if I was doing this work I would chunk it up into bigger >> pieces. I appreciate that you are trying to meticulously show the >> steps that you took to build the page, but 22 patches does >> really feel like too much. And I would have combined the >> "Use man markup" patches into one step at the end, and I'd prefer >> you do that for future patches (but I can live with things as they >> are in this patch series). >> >> In terms of fewer patches, how would you feel about squashing the >> patches as per the blank line separators below (and consequently >> having bigger commit messages): >> >>> Alejandro Colomar (22): >>> list.3: New page that will hold the (list) contents of queue.3 >> >>> list.3, queue.3: NAME: Move code from queue.3 to list.3 >>> list.3: NAME: ffix: Use man markup >>> list.3: NAME: Add description >> >>> list.3, queue.3: SYNOPSIS: Move code from queue.3 to list.3 >>> list.3: SYNOPSIS: Copy include from queue.3 >>> list.3: SYNOPSIS: ffix: Use man markup >> >>> list.3: DESCRIPTION: Add short description >>> list.3: DESCRIPTION: Copy description about naming of macros from >>> queue.3 >>> list.3: DESCRIPTION: Remove unrelated code to adapt to this page >>> list.3: DESCRIPTION: ffix: Use man markup >> >>> list.3, queue.3: DESCRIPTION: Move list specific code from queue.3 to >>> list.3 >>> list.3: DESCRIPTION: ffix: Use man markup >>> list.3: DESCRIPTION: Remove line pointing to the EXAMPLES >> >>> list.3: CONFORMING TO: Copy from queue.3 >>> list.3: CONFORMING TO: Adapt to this page >>> list.3: CONFORMING TO: ffix: Use man markup >> >>> list.3: SEE ALSO: Add insque(3) and queue(3) >> >>> list.3, queue.3: EXAMPLES: Move example program from queue.3 to list.3 >>> list.3: EXAMPLES: ffix: Use man markup >> >>> list.3: BUGS: Note LIST_FOREACH() limitations >> >>> list.3: RETURN VALUE: Add details about the return value of those >>> macros that "return" a value >> >> Squashing as above would yield 10 patches, and I'd kind of prefer >> that so as to avoid quite so many commits in the history. >> (For future patches though, I would prefer to split out the >> "Use man markup" into a single patch at the end of the series.) > > > I can't find the source > (I think it was some kernel guide for sending patches), > but I read some time ago that I should separate code movement > from any other changes; > otherwise git might not be able to follow that movement. > > So I would reorder and squash the commits as: > > > Alejandro Colomar (22): > list.3: New page that will hold the (list) contents of queue.3 > > list.3, queue.3: NAME: Move code from queue.3 to list.3 > > list.3, queue.3: SYNOPSIS: Move code from queue.3 to list.3 > > list.3, queue.3: DESCRIPTION: Move list specific code from queue.3 to > list.3 > > list.3, queue.3: EXAMPLES: Move example program from queue.3 to list.3 > > list.3: SYNOPSIS: Copy include from queue.3 > list.3: DESCRIPTION: Copy description about naming of macros from > queue.3 > list.3: CONFORMING TO: Copy from queue.3 > list.3: DESCRIPTION: Remove unrelated code to adapt to this page > list.3: DESCRIPTION: Remove line pointing to the EXAMPLES > list.3: CONFORMING TO: Adapt to this page > squash as list.3: Copy and adapt code from queue.3 > > list.3: NAME: ffix: Use man markup > list.3: SYNOPSIS: ffix: Use man markup > list.3: DESCRIPTION: ffix: Use man markup > list.3: DESCRIPTION: ffix: Use man markup > list.3: CONFORMING TO: ffix: Use man markup > list.3: EXAMPLES: ffix: Use man markup > squash as list.3: ffix: Use man markup > > list.3: NAME: Add description > list.3: DESCRIPTION: Add short description > list.3: SEE ALSO: Add insque(3) and queue(3) > list.3: BUGS: Note LIST_FOREACH() limitations > list.3: RETURN VALUE: Add details about the return value of those > macros that "return" a value > squash as list.3: Add details > > > I'll keep the messages of the squashed commits inside the commit msg. > This would mean 8 patches. > > Sounds good? I think that would be fine, but I suspect you might have to fix a lot of conflicts if you reorder the patches so much, I wanted to save you having to do that work. I could live with either way, but I'd prefer to minimize the effort you need to invest to make the change. Thanks, Michael