2021-02-11 23:33:17

by David Howells

[permalink] [raw]
Subject: Re: [GIT PULL] fscache: I/O API modernisation and netfs helper library

Linus Torvalds <[email protected]> wrote:

> Also, honestly, I really *REALLY* want your commit messages to talk
> about who has been cc'd, who has been part of development, and point
> to the PUBLIC MAILING LISTS WHERE THAT DISCUSSION WAS TAKING PLACE, so
> that I can actually see that "yes, other people were involved"

Most of the development discussion took place on IRC and waving snippets of
code about in pastebin rather than email - the latency of email is just too
high. There's not a great deal I can do about that now as I haven't kept IRC
logs. I can do that in future if you want.

> No, I don't require this in general, but exactly because of the
> history we have, I really really want to see that. I want to see a
>
> Link: https://lore.kernel.org/r/....

I can add links to where I've posted the stuff for review. Do you want this
on a per-patch basis or just in the cover for now?

Also, do you want things like these:

https://lore.kernel.org/linux-fsdevel/[email protected]/
https://lore.kernel.org/linux-fsdevel/[email protected]/

which pertain to the overall fscache rewrite, but where the relevant changes
didn't end up included in this particular patchset? Or this:

https://listman.redhat.com/archives/linux-cachefs/2020-December/msg00000.html

where someone was testing the overall patchset of which this is a subset?

> and the Cc's - or better yet, the Reviewed-by's etc - so that when I
> get a pull request, it really is very obvious to me when I look at it
> that others really have been involved.
>
> So if I continue to see just
>
> Signed-off-by: David Howells <[email protected]>
>
> at the end of the commit messages, I will not pull.
>
> Yes, in this thread a couple of people have piped up and said that
> they were part of the discussion and that they are interested, but if
> I have to start asking around just to see that, then it's too little,
> too late.
>
> No more of this "it looks like David Howells did things in private". I
> want links I can follow to see the discussion, and I really want to
> see that others really have been involved.
>
> Ok?

Sure.

I can go and edit in link pointers into the existing patches if you want and
add Jeff's Review-and-tested-by into the appropriate ones. You would be able
to compare against the existing tag, so it wouldn't entirely invalidate the
testing.

Also, do you want links inserting into all the patches of the two keyrings
pull requests I've sent you?

David


2021-02-13 01:11:29

by Linus Torvalds

[permalink] [raw]
Subject: Re: [GIT PULL] fscache: I/O API modernisation and netfs helper library

On Thu, Feb 11, 2021 at 3:21 PM David Howells <[email protected]> wrote:
>
> Most of the development discussion took place on IRC and waving snippets of
> code about in pastebin rather than email - the latency of email is just too
> high. There's not a great deal I can do about that now as I haven't kept IRC
> logs. I can do that in future if you want.

No, I really don't.

IRC is fine for discussing ideas about how to solve things.

But no, it's not a replacement for actual code review after the fact.

If you think email has too long latency for review, and can't use
public mailing lists and cc the people who are maintainers, then I
simply don't want your patches.

You need to fix your development model. This whole "I need to get
feedback from whoever still uses irc and is active RIGHT NOW" is not a
valid model. It's fine for brainstorming for possible approaches, and
getting ideas, sure.

Linus

2021-02-15 00:41:59

by David Howells

[permalink] [raw]
Subject: Re: [GIT PULL] fscache: I/O API modernisation and netfs helper library

Linus Torvalds <[email protected]> wrote:

> But no, it's not a replacement for actual code review after the fact.
>
> If you think email has too long latency for review, and can't use
> public mailing lists and cc the people who are maintainers, then I
> simply don't want your patches.

I think we were talking at cross-purposes by the term "development" here. I
was referring to the discussion of how the implementation should be done and
working closely with colleagues - both inside and outside Red Hat - to get
things working, not specifically the public review side of things. It's just
that I don't have a complete record of the how-to-implement-it, the
how-to-get-various-bits-working-together and the why-is-it-not-working?
discussions.

Anyway, I have posted my fscache modernisation patches multiple times for
public review, I have tried to involve the wider community in aspects of the
development on public mailing lists and I have been including the maintainers
in to/cc.

I've posted the more full patchset for public review a number of times:

4th May 2020:
https://lore.kernel.org/linux-fsdevel/158861203563.340223.7585359869938129395.stgit@warthog.procyon.org.uk/

13th Jul (split into three subsets):
https://lore.kernel.org/linux-fsdevel/159465766378.1376105.11619976251039287525.stgit@warthog.procyon.org.uk/
https://lore.kernel.org/linux-fsdevel/159465784033.1376674.18106463693989811037.stgit@warthog.procyon.org.uk/
https://lore.kernel.org/linux-fsdevel/159465821598.1377938.2046362270225008168.stgit@warthog.procyon.org.uk/

20th Nov:
https://lore.kernel.org/linux-fsdevel/160588455242.3465195.3214733858273019178.stgit@warthog.procyon.org.uk/

I then cut it down and posted that publically a couple of times:

20th Jan:
https://lore.kernel.org/linux-fsdevel/161118128472.1232039.11746799833066425131.stgit@warthog.procyon.org.uk/

25th Jan:
https://lore.kernel.org/linux-fsdevel/161161025063.2537118.2009249444682241405.stgit@warthog.procyon.org.uk/

I let you know what was coming here:
https://lore.kernel.org/linux-fsdevel/[email protected]/
https://lore.kernel.org/linux-fsdevel/[email protected]/

to try and find out whether you were going to have any objections to the
design in advance, rather than at the last minute.

I've apprised people of what I was up to:
https://lore.kernel.org/lkml/[email protected]/
https://lore.kernel.org/linux-fsdevel/[email protected]/
https://lore.kernel.org/linux-fsdevel/[email protected]/
https://lore.kernel.org/linux-fsdevel/[email protected]/

Asked for consultation on parts of what I wanted to do:
https://lore.kernel.org/linux-fsdevel/[email protected]/
https://lore.kernel.org/linux-fsdevel/[email protected]/
https://lore.kernel.org/linux-fsdevel/[email protected]/

Asked someone who is actually using fscache in production to test the rewrite:
https://listman.redhat.com/archives/linux-cachefs/2020-December/msg00000.html

I've posted partial patches to try and help 9p and cifs along:
https://lore.kernel.org/linux-fsdevel/[email protected]/
https://lore.kernel.org/linux-cifs/[email protected]/
https://lore.kernel.org/linux-fsdevel/[email protected]/
https://lore.kernel.org/linux-cifs/[email protected]/

(Jeff has been handling Ceph and Dave NFS).

Proposed conference topics related to this:
https://lore.kernel.org/linux-fsdevel/[email protected]/
https://lore.kernel.org/linux-fsdevel/[email protected]/
https://lore.kernel.org/linux-fsdevel/[email protected]/

though the lockdown put paid to that:-(

Willy has discussed it too:
https://lore.kernel.org/linux-fsdevel/[email protected]/

David