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

[Glenn Washburn <development@efficientek.com>]

Hi Paul,

On Sat, 6 Mar 2021 07:59:18 +0100
Paul Menzel <pmenzel@molgen.mpg.de> wrote:

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

Thanks for the feedback. I don't suppose that's a big loss of
functionality with respect the way I'm sending new patchset versions.
If the thread is super long, just collapse the whole thread. Perhaps
I'm failing to see the issue.

What could be annoying is if you want to go back several patch
revisions and compare with the current one. But that would still be
easier this way than the current practice because the previous version
is likely to be between a lot of other threads.

Now it definitely would be more problematic for clients that can not
collapse threads (perhaps text-based ones?). Does anyone have this
issue?

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

Yes, I believe that the mailing list only threads on a per month basis.
I've actually been annoyed by this in the past with other list using
the same setup when trying to read multi-month threads.

> Anyway, as *displaying* of threading is not defined and different 
> between user agents, maybe it’s better to not rely on that.

I'm confused by this. I accept the premise, but I don't understand
"rely" in this context, which I interpret as "to assume". I _am_
relying on the behavior of my email client for my personal usage. I
understand your comment to be analogous to saying that I am relying on
the display capabilities of others email clients when I send a patch
with --thread in git send-email because there may be someone on the
list who chooses to use an email client that does not support a
threaded view.

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.

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
benefit to link them together. But that's not a reason why it shouldn't
be done.

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