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

[Zorro Lang <zlang@redhat.com>]

On Wed, Aug 16, 2023 at 05:33:45PM -0700, Darrick J. Wong wrote:
> 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...)

OK, you or (the one you nominate to be the XFS testing lead) might want to send
a patch to fstests@, to add a "M: xxx" under "XFS" (xfstests/MAINTAINERS.),
and add this new definition of "Testing lead" part to "M:" flag in
xfstests/MAINTAINERS. We can talk about more details under that patch.

Thanks,
Zorro

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