Re: [PATCH 1/3] docs: add maintainer entry profile for XFS

[Luis Chamberlain <mcgrof@kernel.org>]

On Fri, Aug 18, 2023 at 07:07:36PM -0700, Darrick J. Wong wrote:
> On Wed, Aug 16, 2023 at 06:15:22PM -0700, Luis Chamberlain wrote:
> > On Wed, Aug 16, 2023 at 05:33:45PM -0700, Darrick J. Wong wrote:
> > > However, I defined the testing lead (quoting from above):
> > > 
> > > "**Testing Lead**: This person is responsible for setting the test
> > > coverage goals of the project, negotiating with developers to decide
> > > on new tests for new features, and making sure that developers and
> > > release managers execute on the testing."
> > 
> > This I thought I could do.
> 
> Well I certainly invite you to try! :)

OK I don't need a documented tag to try that, so will chug on to try to
help with that.

> > > In my mind, that means the testing lead should be reviewing changes
> > > proposed for tests/xfs/* in fstests by XFS developers to make sure that
> > > new features are adequately covered; and checking that drive-by
> > > contributions from others fit well with what's already there.
> > 
> > This should be included in the description if that's part of the role.
> > This alone is a task and I'm afraid *that* does require much more time
> > commitment and experience I don't think I have with XFS yet. And so it
> > would seem to me a more experience developer on both fstests and XFS
> > would be required for this.

<-- QA stuff -->

FWIW I never have worked with a QA team other than to ask what they do, the
work I do simply is designed to be used by kernel developers for kernel
developers. Why? Because I don't want to disrupt a QA team. If they want
to use it, then great.

> (As for testcase review: is that the job of the code reviewer?  or the
> test maintainer?  I don't know...)
> 
> At this time, our testing is so ... uneven ... that "someone who feels
> totally comfortable with calling bs on obviously inadequate testing and
> people will listen to" is probably qualification enough. :)

OK best I can do is just try, specially in light of "burnout", so to try to
help as communal effort.

I think it helps to quantify the work required, so to ensure I can also
commit and don't break my own responsibilities elsewhere, breaking it
down just for XFS specific tests:

git log --pretty=oneline --since="2023-01-01" --until="2023-02-01" tests/xfs/ | wc -l
17
git log --pretty=oneline --since="2023-02-01" --until="2023-03-01" tests/xfs/ | wc -l
26
git log --pretty=oneline --since="2023-03-01" --until="2023-04-01" tests/xfs/ | wc -l
10
git log --pretty=oneline --since="2023-04-01" --until="2023-05-01" tests/xfs/ | wc -l
1
git log --pretty=oneline --since="2023-05-01" --until="2023-06-01" tests/xfs/ | wc -l
4
git log --pretty=oneline --since="2023-06-01" --until="2023-07-01" tests/xfs/ | wc -l
5
git log --pretty=oneline --since="2023-07-01" --until="2023-08-01" tests/xfs/ | wc -l
5

Lemme just try...

> > > > And a test lead might do more testing besides fstests. So I can't imagine
> > > > that I need to check another project to learn about who's in charge of the
> > > > current project I'm changing.
> > > 
> > > ...so the testing lead would be the person who you'd talk to directly
> > > about changes that you want to make.
> > 
> > I could certainly help try to set a high bar, but to actually ensure
> > correctness of XFS test patches, I do think that should require a more
> > seasoned XFS developer and with fstests.
> 
> <shrug> Maybe we should chat more directly about this? :)
> I'll look you up in #kdevops (the irc) next week.

Sure.

  Luis