From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: The development of GNU GRUB <grub-devel@gnu.org>
Cc: Paul Menzel <pmenzel@molgen.mpg.de>,
Daniel Kiper <daniel.kiper@oracle.com>
Subject: Re: Threading of patch series (was: [PATCH v6 00/14] error: Do compile-time format string checking on grub>)
Date: Tue, 9 Mar 2021 16:04:22 -0500 [thread overview]
Message-ID: <YEfi1jTxA1fj+z8l@Konrads-MacBook-Pro.local> (raw)
In-Reply-To: <20210307150043.00fa893c@crass-HP-ZBook-15-G2>
..snip..
> I'm less concerned with the capabilities of other clients than I am for
> how this negatively impacts the current workflow of people on this
> list, which is what I'm trying to figure out. How does doing this
> making things more difficult for people here? And specifically Daniel.
Don't know what flow Daniel is using, but my email reader is mutt.
Once I am comfortable with the patches I usually save them in a mailbox
(.mbox) and do 'git am -s' on them and then kickoff a workflow.
Having multiple threads within threads makes my life as maintainer
more difficult as I have to manually split out the right version and
save it.
I suppose I can use the 'tag-save' option and save the ones
with a certain version to a mailbox which can add another step in this.
And then I am worried I missed something :-(
>
> If this causes tools to break, then that's certainly a good reason to
> avoid changing things. If it makes Daniel's workflow more burdensome
> because he has a client that can not collapse threads at all, then
> that's a valid concern too. I'm currently failing to see as valid
> concerns: "because traditionally we've never done it that way" or "I
> don't like seeing patchset revisions together".
>
> From a structuring data point of view, it makes more sense (to me) to
> link patchset revisions together. Now it might also be true that
> looking at previous patchsets is very uncommon and so its not a huge
Maintainers trust that folks add right after the ---
v6: Fixed up spaces
Fixed up XYZ
and there is no need to go back to v5 or earlier.
> benefit to link them together. But that's not a reason why it shouldn't
> be done.
So ... making the life of maintainer and as simple as possible makes
it easier and faster to get patches upstream.
That is what LKML has taught a lot of us and that is probably why
many of us are used to this workflow.
>
> Perhaps with a better understanding of the harm, I could come to a
> different opinion. And sincerely, thank you for the feedback.
>
> Glenn
>
> > Kind regards,
> >
> > Paul
> >
> >
> > [1]:
> > https://lists.gnu.org/archive/html/grub-devel/2021-03/threads.html
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
prev parent reply other threads:[~2021-03-09 21:04 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 ` Threading of patch series (was: [PATCH v6 00/14] error: Do compile-time format string checking on grub>) Paul Menzel
2021-03-07 21:00 ` Glenn Washburn
2021-03-09 21:04 ` Konrad Rzeszutek Wilk [this message]
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=YEfi1jTxA1fj+z8l@Konrads-MacBook-Pro.local \
--to=konrad.wilk@oracle.com \
--cc=daniel.kiper@oracle.com \
--cc=grub-devel@gnu.org \
--cc=pmenzel@molgen.mpg.de \
/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.