Re: Threading of patch series (was: [PATCH v6 00/14] error: Do compile-time format string checking on grub>)

[Konrad Rzeszutek Wilk]

..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