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

["Darrick J. Wong" <djwong@kernel.org>]

On Wed, Aug 16, 2023 at 02:04:05PM +0800, Zorro Lang wrote:
> On Tue, Aug 15, 2023 at 05:11:08PM -0700, Darrick J. Wong wrote:
> > On Tue, Aug 15, 2023 at 04:54:55PM -0700, Luis Chamberlain wrote:
> > > On Sat, Aug 12, 2023 at 12:05:33PM +0300, Amir Goldstein wrote:
> > > > On Sat, Aug 12, 2023 at 3:04 AM Darrick J. Wong <djwong@kernel.org> wrote:
> > > > >
> > > > > On Fri, Aug 11, 2023 at 12:31:18PM -0700, Luis Chamberlain wrote:
> > > > > > On Tue, Aug 01, 2023 at 12:58:21PM -0700, Darrick J. Wong wrote:
> > > > > > > +Roles
> > > > > > > +-----
> > > > > > > +There are seven key roles in the XFS project.
> > > > > > > +- **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.
> > > > > > > +
> > > > > > > +  The testing lead should identify themselves with an ``M:`` entry in
> > > > > > > +  the XFS section of the fstests MAINTAINERS file.
> > 
> >                                     ^^^^^^^^^^^^^^^^^^^
> > > > > >
> > > > > > I think breaking responsibility down is very sensible, and should hopefully
> > > > > > allow you to not burn out. Given I realize how difficult it is to do all
> > > > > > the tasks, and since I'm already doing quite a bit of testing of XFS
> > > > > > on linux-next I can volunteer to help with this task of testing lead
> > > > > > if folks also think it may be useful to the community.
> > > > > >
> > > > > > The only thing is I'd like to also ask if Amir would join me on the
> > > > > > role to avoid conflicts of interest when and if it comes down to testing
> > > > > > features I'm involved in somehow.
> > > > >
> > > > > Good question.  Amir?
> > > > >
> > > > 
> > > > I am more than happy to help, but I don't believe that I currently perform
> > > > or that I will have time to perform the official duties of **Testing
> > > > Lead** role.
> > > > 
> > > > I fully support the nomination of Luis and I think the **Release Manager**
> > > > should be able to resolve any conflict of interests of the **Testing Lead**
> > > > as feature developer should any such conflicts arise :)
> > > 
> > > Fair enough.
> > > 
> > > Darrick, I suppose just one thing then, using M for Testing Lead seems
> > > likely to implicate the 'Testing Lead' getting Cc'd on every single new
> 
> Do you hope to get CC address/list ...
> 
> > > patch. As much as I could help review, I don't think I can commit to
> > > that, and I think that's the point of the current split. To let us split
> > > roles to help scale stuff.
> > 
> > Note that we're talking about "M:" entries in the *fstests* MAINTAINERS
> > file, not the kernel...
> 
> ... from fstests project, for a patch on a linux-$FSTYP project?
> 
> That's weird to me. 

Not for the kernel, no.  Just the contributions to fstests.

For example, if I were sending a patch deluge, the online fsck testing
patches would be cc'd to you; to whomever's listed as M: under XFS in
fstests MAINTAINERS; and fstests@ and linux-xfs@.

The kernel patches would be cc'd to linux-xfs, and to whomever steps up
to review the code (who are we kidding, dchinner).

xfsprogs patches for online fsck would be cc'd to linux-xfs and Carlos.

> 
> > 
> > > So how about a separate new prefix, TL: ? Adding Linus in case he has
> > > a stronger preference to only keep us at one character fist index on
> > > MAINTAINERS.
> > 
> > ...so I'm cc'ing Zorro since he's the owner of the relevant git repo.
> > Hey Zorro, do you have any opinions about how to record who's
> > responsible for each filesystem adding tests for new code and whatnot?
> 
> I think a specific fs test lead is a contributer for that fs project more,
> not for fstests. The test lead need to report test results to that fs
> project, not necessary to report to fstests.

I disagree -- yes, /developers/ (and the release manager) should be
running tests and reporting those results to that fs project.

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

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.

(That's what I thought you wanted out from the people mentioned in the
fstests MAINTAINERS file...)

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

(Wait, who is "I" here?  You, Zorro?  Or were you paraphrasing a
developer?)

--D

> (If I understood anything wrong, please correct me:)
> 
> Thanks,
> Zorro
> 
> > 
> > --D
> > 
> > > 
> > >   Luis
> > 
>