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

[Zorro Lang <zlang@redhat.com>]

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. 

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

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.

(If I understood anything wrong, please correct me:)

Thanks,
Zorro

> 
> --D
> 
> > 
> >   Luis
>