From: Paul Menzel <pmenzel@molgen.mpg.de>
To: Glenn Washburn <development@efficientek.com>
Cc: grub-devel@gnu.org, Daniel Kiper <daniel.kiper@oracle.com>
Subject: Threading of patch series (was: [PATCH v6 00/14] error: Do compile-time format string checking on grub>)
Date: Sat, 6 Mar 2021 07:59:18 +0100 [thread overview]
Message-ID: <aea0b571-c38a-0cbf-6773-40928117155e@molgen.mpg.de> (raw)
In-Reply-To: <20210305171558.2c485f55@crass-HP-ZBook-15-G2>
Dear Glenn,
Am 06.03.21 um 00:15 schrieb Glenn Washburn:
> On Fri, 5 Mar 2021 17:27:01 +0100 Daniel Kiper wrote:
[…]
>> By the way, my I ask you once again to send each patch series as
>> separate thread. Now you are attaching all patch sets to one cover
>> letter which is confusing. Please stop doing that.
>
> How do you pull patch series from the mailing list? I'm curious if this
> is messing with that. Also what email client do you use?
>
> You are correct that I'm attaching all new versions of the patch series
> to one cover letter, but each patch series also has its own cover
> letter. So I don't consider the cover letter that is the root of the
> thread to be the cover letter for the new patch series.
>
> I can't find our prior correspondence. I recall saying that the
> patchset series in question had been not done in a less than ideal way
> because I had start by replying to the cover letter of the prior
> patchset and then switched to replying to a particular patchset cover
> letter. This was because with experience I determined that attaching to
> the thread of the next version of a patchset to the cover letter of the
> first version of the patchset looked much nicer in my browser. I
> also recall saying that I'd do this in the future to see if it worked
> well doing it properly from the start.
>
> My goal is to keep all versions of a patchset together in a client
> with tree view of threads (eg. my mail client claws-mail). This makes
> it easy to go back to a prior patchset to look at comments. I also
> wanted to meet this goal in an aesthetically pleasing way. The first
> attempt which attached a new version of a patchset to its priors cover
> letter did not meet this because it created a deep tree for patchsets
> with lots of revisions. However, attaching each new patchset to the
> cover letter of the first patchset, keeps thread tree to a minimum. It
> also makes it to collapse only certain patchset versions (aside from
> the first). Also, since I have threads sorted by thread date, I see
> patchsets ordered from most recent to least recent, which it how I like
> to order all my emails.
>
> The current case does not strictly adhere to these rules because I'm
> taking v4 as the initial patchset, which perhaps may be the source of
> some confusion. Other than that I think its worked out nicely.
>
> So I'm curious if this is causing some issue with tooling. And I'm
> curious what exactly is causing confusion? In my browser its fairly
> obvious that the root of the thread is the cover letter for v4 of the
> patch series and that the cover letters of attached patch series are
> different, noted by a different version number.
At least here, Mozilla Thunderbird 78.8.0 is only able to collapse the
top thread and not sub threads.
The mailing list archive does not seem to care [1], though that might be
because the v4 patch set cover letter is in a different month.
Anyway, as *displaying* of threading is not defined and different
between user agents, maybe it’s better to not rely on that.
Kind regards,
Paul
[1]: https://lists.gnu.org/archive/html/grub-devel/2021-03/threads.html
next prev parent reply other threads:[~2021-03-06 6:59 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-19 2:47 [PATCH v4 00/13] error: Do compile-time format string checking on grub_error Glenn Washburn
2021-02-19 2:47 ` [PATCH v4 01/13] misc: Format string for grub_error should be a literal Glenn Washburn
2021-02-19 2:47 ` [PATCH v4 02/13] error: grub_error missing format string argument Glenn Washburn
2021-02-19 2:47 ` [PATCH v4 03/13] error: grub_error format string add missing format code Glenn Washburn
2021-02-19 2:47 ` [PATCH v4 04/13] dmraid_nvidia: Format string error in grub_error Glenn Washburn
2021-02-19 2:47 ` [PATCH v4 05/13] grub_error: Use format code PRIuGRUB_SIZE for variables of type grub_size_t Glenn Washburn
2021-02-19 2:47 ` [PATCH v4 06/13] pgp: Format code for grub_error is incorrect Glenn Washburn
2021-02-19 2:47 ` [PATCH v4 07/13] efi: Format string error in grub_error Glenn Washburn
2021-02-19 2:47 ` [PATCH v4 08/13] error: Use %p format code for pointer types Glenn Washburn
2021-02-27 11:43 ` Daniel Kiper
2021-02-28 20:02 ` Glenn Washburn
2021-03-03 18:05 ` Daniel Kiper
2021-02-19 2:47 ` [PATCH v4 09/13] error: Use format code PRIxGRUB_UINT64_T for 64-bit uint argument in grub_error Glenn Washburn
2021-02-19 2:47 ` [PATCH v4 10/13] error: Use format code PRIxGRUB_UINT64_T for 64-bit arg " Glenn Washburn
2021-02-27 11:48 ` Daniel Kiper
2021-02-28 20:13 ` Glenn Washburn
2021-03-03 18:09 ` Daniel Kiper
2021-02-19 2:47 ` [PATCH v4 11/13] error: Use format code PRIuGRUB_UINT64_T for 64-bit typed fileblock " Glenn Washburn
2021-02-19 2:47 ` [PATCH v4 12/13] error: Use format code llu for 64-bit uint bp->blk_prop " Glenn Washburn
2021-02-27 12:05 ` Daniel Kiper
2021-02-28 21:10 ` Glenn Washburn
2021-03-03 18:17 ` Daniel Kiper
2021-03-04 0:46 ` Glenn Washburn
2021-02-19 2:47 ` [PATCH v4 13/13] error: Do compile-time format string checking on grub_error Glenn Washburn
2021-02-27 12:19 ` [PATCH v4 00/13] " Daniel Kiper
2021-02-28 20:31 ` Glenn Washburn
2021-03-04 1:29 ` [PATCH v5 " Glenn Washburn
2021-03-04 1:29 ` [PATCH v5 01/13] misc: Format string for grub_error should be a literal Glenn Washburn
2021-03-04 1:29 ` [PATCH v5 02/13] error: grub_error missing format string argument Glenn Washburn
2021-03-04 1:29 ` [PATCH v5 03/13] error: grub_error format string add missing format code Glenn Washburn
2021-03-04 1:29 ` [PATCH v5 04/13] dmraid_nvidia: Format string error in grub_error Glenn Washburn
2021-03-04 1:29 ` [PATCH v5 05/13] grub_error: Use format code PRIuGRUB_SIZE for variables of type grub_size_t Glenn Washburn
2021-03-04 1:29 ` [PATCH v5 06/13] pgp: Format code for grub_error is incorrect Glenn Washburn
2021-03-04 1:29 ` [PATCH v5 07/13] efi: Format string error in grub_error Glenn Washburn
2021-03-04 1:29 ` [PATCH v5 08/13] error: Use PRI* macros to get correct format string code across architectures Glenn Washburn
2021-03-04 1:29 ` [PATCH v5 09/13] error: Use format code PRIxGRUB_UINT64_T for 64-bit uint argument in grub_error Glenn Washburn
2021-03-04 1:29 ` [PATCH v5 10/13] error: Use format code PRIxGRUB_UINT64_T for 64-bit arg " Glenn Washburn
2021-03-04 1:29 ` [PATCH v5 11/13] error: Use format code PRIuGRUB_UINT64_T for 64-bit typed fileblock " Glenn Washburn
2021-03-04 1:29 ` [PATCH v5 12/13] error: Use format code llu for 64-bit uint bp->blk_prop " Glenn Washburn
2021-03-04 17:59 ` Daniel Kiper
2021-03-04 22:50 ` Glenn Washburn
2021-03-04 1:29 ` [PATCH v5 13/13] error: Do compile-time format string checking on grub_error Glenn Washburn
2021-03-05 0:22 ` [PATCH v6 00/14] error: Do compile-time format string checking on grub> Glenn Washburn
2021-03-05 0:22 ` [PATCH v6 01/14] misc: Format string for grub_error should be a literal Glenn Washburn
2021-03-05 0:22 ` [PATCH v6 02/14] error: grub_error missing format string argument Glenn Washburn
2021-03-05 0:22 ` [PATCH v6 03/14] error: grub_error format string add missing format code Glenn Washburn
2021-03-05 0:22 ` [PATCH v6 04/14] dmraid_nvidia: Format string error in grub_error Glenn Washburn
2021-03-05 0:22 ` [PATCH v6 05/14] grub_error: Use format code PRIuGRUB_SIZE for variables of type grub_size_t Glenn Washburn
2021-03-05 0:22 ` [PATCH v6 06/14] pgp: Format code for grub_error is incorrect Glenn Washburn
2021-03-05 0:22 ` [PATCH v6 07/14] efi: Format string error in grub_error Glenn Washburn
2021-03-05 0:22 ` [PATCH v6 08/14] error: Use PRI* macros to get correct format string code across architectures Glenn Washburn
2021-03-05 0:22 ` [PATCH v6 09/14] error: Use format code PRIxGRUB_UINT64_T for 64-bit uint argument in grub_error Glenn Washburn
2021-03-05 0:22 ` [PATCH v6 10/14] error: Use format code PRIxGRUB_UINT64_T for 64-bit arg " Glenn Washburn
2021-03-05 0:22 ` [PATCH v6 11/14] error: Use format code PRIuGRUB_UINT64_T for 64-bit typed fileblock " Glenn Washburn
2021-03-05 0:22 ` [PATCH v6 12/14] error: Use format code llu for 64-bit uint bp->blk_prop " Glenn Washburn
2021-03-05 0:22 ` [PATCH v6 13/14] error: Do compile-time format string checking on grub_error Glenn Washburn
2021-03-05 0:22 ` [PATCH v6 14/14] zfs: Use grub_uint64_t instead of 1ULL in BF64_*CODE macros Glenn Washburn
2021-03-05 16:27 ` [PATCH v6 00/14] error: Do compile-time format string checking on grub> Daniel Kiper
2021-03-05 23:15 ` Glenn Washburn
2021-03-06 6:59 ` Paul Menzel [this message]
2021-03-07 21:00 ` Threading of patch series (was: [PATCH v6 00/14] error: Do compile-time format string checking on grub>) Glenn Washburn
2021-03-09 21:04 ` Konrad Rzeszutek Wilk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aea0b571-c38a-0cbf-6773-40928117155e@molgen.mpg.de \
--to=pmenzel@molgen.mpg.de \
--cc=daniel.kiper@oracle.com \
--cc=development@efficientek.com \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.