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