..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
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
