| Message ID | 169091990172.112530.13872332887678504055.stgit@frogsfrogsfrogs (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | xfs: maintainer transition for 6.6 | expand |
Adding a few notes from a discussion I had with Chandan this morning: On Tue, Aug 01, 2023 at 12:58:21PM -0700, Darrick J. Wong wrote: > From: Darrick J. Wong <djwong@kernel.org> > > Create a new document to list what I think are (within the scope of XFS) > our shared goals and community roles. Since I will be stepping down > shortly, I feel it's important to write down somewhere all the hats that > I have been wearing for the past six years. > > Also, document important extra details about how to contribute to XFS. > > Cc: corbet@lwn.net > Signed-off-by: Darrick J. Wong <djwong@kernel.org> > --- > Documentation/filesystems/index.rst | 1 > .../filesystems/xfs-maintainer-entry-profile.rst | 192 ++++++++++++++++++++ > .../maintainer/maintainer-entry-profile.rst | 1 > MAINTAINERS | 1 > 4 files changed, 195 insertions(+) > create mode 100644 Documentation/filesystems/xfs-maintainer-entry-profile.rst > > > diff --git a/Documentation/filesystems/index.rst b/Documentation/filesystems/index.rst > index eb252fc972aa..09cade7eaefc 100644 > --- a/Documentation/filesystems/index.rst > +++ b/Documentation/filesystems/index.rst > @@ -122,6 +122,7 @@ Documentation for filesystem implementations. > virtiofs > vfat > xfs-delayed-logging-design > + xfs-maintainer-entry-profile > xfs-self-describing-metadata > xfs-online-fsck-design > zonefs > diff --git a/Documentation/filesystems/xfs-maintainer-entry-profile.rst b/Documentation/filesystems/xfs-maintainer-entry-profile.rst > new file mode 100644 > index 000000000000..55d9e1fb5cd4 > --- /dev/null > +++ b/Documentation/filesystems/xfs-maintainer-entry-profile.rst > @@ -0,0 +1,192 @@ > +XFS Maintainer Entry Profile > +============================ > + > +Overview > +-------- > +XFS is a well known high-performance filesystem in the Linux kernel. > +The aim of this project is to provide and maintain a robust and > +performant filesystem. > + > +Patches are generally merged to the for-next branch of the appropriate > +git repository. > +After a testing period, the for-next branch is merged to the master > +branch. > + > +Kernel code are merged to the xfs-linux tree[0]. > +Userspace code are merged to the xfsprogs tree[1]. > +Test cases are merged to the xfstests tree[2]. > +Ondisk format documentation are merged to the xfs-documentation tree[3]. > + > +All patchsets involving XFS *must* be cc'd in their entirety to the mailing > +list linux-xfs@vger.kernel.org. > + > +Roles > +----- > +There are seven key roles in the XFS project. Eight. > +A person can take on multiple roles, and a role can be filled by > +multiple people. > +Anyone taking on a role is advised to check in with themselves and > +others on a regular basis about burnout. > + > +- **Outside Contributor**: Anyone who sends a patch but is not involved > + in the XFS project on a regular basis. > + These folks are usually people who work on other filesystems or > + elsewhere in the kernel community. > + > +- **Developer**: Someone who is familiar with the XFS codebase enough to > + write new code, documentation, and tests. > + > + Developers can often be found in the IRC channel mentioned by the ``C:`` > + entry in the kernel MAINTAINERS file. > + > +- **Senior Developer**: A developer who is very familiar with at least > + some part of the XFS codebase and/or other subsystems in the kernel. > + These people collectively decide the long term goals of the project > + and nudge the community in that direction. > + They should help prioritize development and review work for each release > + cycle. > + > + Senior developers tend to be more active participants in the IRC channel. > + > +- **Reviewer**: Someone (most likely also a developer) who reads code > + submissions to decide: > + > + 0. Is the idea behind the contribution sound? > + 1. Does the idea fit the goals of the project? > + 2. Is the contribution designed correctly? > + 3. Is the contribution polished? > + 4. Can the contribution be tested effectively? > + > + Reviewers should identify themselves with an ``R:`` entry in the kernel > + and fstests MAINTAINERS files. > + > +- **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. > + > +- **Bug Triager**: Someone who examines incoming bug reports in just > + enough detail to identify the person to whom the report should be > + forwarded. > + > + The bug triagers should identify themselves with a ``B:`` entry in > + the kernel MAINTAINERS file. > + > +- **Release Manager**: This person merges reviewed patchsets into an > + integration branch, tests the result locally, pushes the branch to a > + public git repository, and sends pull requests further upstream. > + This person should not be an active developer to avoid conflicts of > + interest. Chandan asked if it was wise to forbid the release manager from /ever/ writing patches. I decided that it wouldn't be the end of the world if the RM produced bug fixes from time to time, or simple cleanups of grotty parts of the codebase. I also recalled that my real goal here was to break the very frustrating dynamic that I encountered wherein reviewers of the maintainer's feature patchsets refuse to sign off unless the maintainer agrees to expand the scope of the work to include yet more cleanups. I withdraw this last sentence and replace it with: "If a developer and a reviewer fail to reach a resolution on some point, the release manager must have the ability to intervene to try to drive a resolution." > + > + The release manager should identify themselves with an ``M:`` entry in > + the kernel MAINTAINERS file. > + > +- **Community Manager**: This person calls and moderates meetings of as many > + XFS participants as they can get when mailing list discussions prove > + insufficient for collective decisionmaking. > + They may also serve as liaison between managers of the organizations > + sponsoring work on any part of XFS. Note: I'll keep doing this part too, since I already have all those connections. --D > + > +- **LTS Maintainer**: Someone who backports and tests bug fixes from > + uptream to the LTS kernels. > + There tend to be six separate LTS trees at any given time. > + > + The maintainer for a given LTS release should identify themselves with an > + ``M:`` entry in the MAINTAINERS file for that LTS tree. > + Unmaintained LTS kernels should be marked with status ``S: Orphan`` in that > + same file. > + > +Submission Checklist Addendum > +----------------------------- > +Please follow these additional rules when submitting to XFS: > + > +- Patches affecting only the filesystem itself should be based against > + the latest -rc or the for-next branch. > + These patches will be merged back to the for-next branch. > + > +- Authors of patches touching other subsystems need to coordinate with > + the maintainers of XFS and the relevant subsystems to decide how to > + proceed with a merge. > + > +- Any patchset changing XFS should be cc'd in its entirety to linux-xfs. > + Do not send partial patchsets; that makes analysis of the broader > + context of the changes unnecessarily difficult. > + > +- Anyone making kernel changes that have corresponding changes to the > + userspace utilities should send the userspace changes as separate > + patchsets immediately after the kernel patchsets. > + > +- Authors of bug fix patches are expected to use fstests[2] to perform > + an A/B test of the patch to determine that there are no regressions. > + When possible, a new regression test case should be written for > + fstests. > + > +- Authors of new feature patchsets must ensure that fstests will have > + appropriate functional and input corner-case test cases for the new > + feature. > + > +- When implementing a new feature, it is strongly suggested that the > + developers write a design document to answer the following questions: > + > + * **What** problem is this trying to solve? > + > + * **Who** will benefit from this solution, and **where** will they > + access it? > + > + * **How** will this new feature work? This should touch on major data > + structures and algorithms supporting the solution at a higher level > + than code comments. > + > + * **What** userspace interfaces are necessary to build off of the new > + features? > + > + * **How** will this work be tested to ensure that it solves the > + problems laid out in the design document without causing new > + problems? > + > + The design document should be committed in the kernel documentation > + directory. > + It may be omitted if the feature is already well known to the > + community. > + > +- Patchsets for the new tests should be submitted as separate patchsets > + immediately after the kernel and userspace code patchsets. > + > +- Changes to the on-disk format of XFS must be described in the ondisk > + format document[3] and submitted as a patchset after the fstests > + patchsets. > + > +- Patchsets implementing bug fixes and further code cleanups should put > + the bug fixes at the beginning of the series to ease backporting. > + > +Key Release Cycle Dates > +----------------------- > +Bug fixes may be sent at any time, though the release manager may decide to > +defer a patch when the next merge window is close. > + > +Code submissions targeting the next merge window should be sent between > +-rc1 and -rc6. > +This gives the community time to review the changes, to suggest other changes, > +and for the author to retest those changes. > + > +Code submissions also requiring changes to fs/iomap and targeting the > +next merge window should be sent between -rc1 and -rc4. > +This allows the broader kernel community adequate time to test the > +infrastructure changes. > + > +Review Cadence > +-------------- > +In general, please wait at least one week before pinging for feedback. > +To find reviewers, either consult the MAINTAINERS file, or ask > +developers that have Reviewed-by tags for XFS changes to take a look and > +offer their opinion. > + > +References > +---------- > +| [0] https://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git/ > +| [1] https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git/ > +| [2] https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/ > +| [3] https://git.kernel.org/pub/scm/fs/xfs/xfs-documentation.git/ > diff --git a/Documentation/maintainer/maintainer-entry-profile.rst b/Documentation/maintainer/maintainer-entry-profile.rst > index cfd37f31077f..6b64072d4bf2 100644 > --- a/Documentation/maintainer/maintainer-entry-profile.rst > +++ b/Documentation/maintainer/maintainer-entry-profile.rst > @@ -105,3 +105,4 @@ to do something different in the near future. > ../driver-api/media/maintainer-entry-profile > ../driver-api/vfio-pci-device-specific-driver-acceptance > ../nvme/feature-and-quirk-policy > + ../filesystems/xfs-maintainer-entry-profile > diff --git a/MAINTAINERS b/MAINTAINERS > index d516295978a4..d232e9e36b87 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -23330,6 +23330,7 @@ S: Supported > W: http://xfs.org/ > C: irc://irc.oftc.net/xfs > T: git git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git > +P: Documentation/filesystems/xfs-maintainer-entry-profile.rst > F: Documentation/ABI/testing/sysfs-fs-xfs > F: Documentation/admin-guide/xfs.rst > F: Documentation/filesystems/xfs-delayed-logging-design.rst >
On Thu, Aug 03, 2023 at 10:09:38 PM -0700, Darrick J. Wong wrote: > Adding a few notes from a discussion I had with Chandan this morning: > The contents of the patch along with the changes mentioned look good to me. Reviewed-by: Chandan Babu R <chandan.babu@oracle.com>
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. Luis
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? (/me also notes that he's listed as R: in fstests MAINTAINERS so he can pinch hit if there are conflicts of interest, at least for xfs/iomap stuff.) --D > Luis
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 :) Thanks, Amir.
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 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. 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. Luis
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 > 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... > 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? --D > > Luis
On Tue, Aug 15, 2023 at 05:11:08PM -0700, Darrick J. Wong wrote: > Note that we're talking about "M:" entries in the *fstests* MAINTAINERS > file, not the kernel... Ah, that makes much more sense :) Luis
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 >
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 > > >
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. > 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. > > 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. Luis
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! :) > > 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. <shrug> I think someone familiar with running a QA organization would know exactly the sorts of things that need testing and how to make a reasonably thorough test plan. They wouldn't necessarily need to know all that much about the xfs codebase per se, though obviously they'd need to be familiar with C and all of its marvelous footguns. (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. :) > > > 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. --D > Luis
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 > > > > > >
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
diff --git a/Documentation/filesystems/index.rst b/Documentation/filesystems/index.rst index eb252fc972aa..09cade7eaefc 100644 --- a/Documentation/filesystems/index.rst +++ b/Documentation/filesystems/index.rst @@ -122,6 +122,7 @@ Documentation for filesystem implementations. virtiofs vfat xfs-delayed-logging-design + xfs-maintainer-entry-profile xfs-self-describing-metadata xfs-online-fsck-design zonefs diff --git a/Documentation/filesystems/xfs-maintainer-entry-profile.rst b/Documentation/filesystems/xfs-maintainer-entry-profile.rst new file mode 100644 index 000000000000..55d9e1fb5cd4 --- /dev/null +++ b/Documentation/filesystems/xfs-maintainer-entry-profile.rst @@ -0,0 +1,192 @@ +XFS Maintainer Entry Profile +============================ + +Overview +-------- +XFS is a well known high-performance filesystem in the Linux kernel. +The aim of this project is to provide and maintain a robust and +performant filesystem. + +Patches are generally merged to the for-next branch of the appropriate +git repository. +After a testing period, the for-next branch is merged to the master +branch. + +Kernel code are merged to the xfs-linux tree[0]. +Userspace code are merged to the xfsprogs tree[1]. +Test cases are merged to the xfstests tree[2]. +Ondisk format documentation are merged to the xfs-documentation tree[3]. + +All patchsets involving XFS *must* be cc'd in their entirety to the mailing +list linux-xfs@vger.kernel.org. + +Roles +----- +There are seven key roles in the XFS project. +A person can take on multiple roles, and a role can be filled by +multiple people. +Anyone taking on a role is advised to check in with themselves and +others on a regular basis about burnout. + +- **Outside Contributor**: Anyone who sends a patch but is not involved + in the XFS project on a regular basis. + These folks are usually people who work on other filesystems or + elsewhere in the kernel community. + +- **Developer**: Someone who is familiar with the XFS codebase enough to + write new code, documentation, and tests. + + Developers can often be found in the IRC channel mentioned by the ``C:`` + entry in the kernel MAINTAINERS file. + +- **Senior Developer**: A developer who is very familiar with at least + some part of the XFS codebase and/or other subsystems in the kernel. + These people collectively decide the long term goals of the project + and nudge the community in that direction. + They should help prioritize development and review work for each release + cycle. + + Senior developers tend to be more active participants in the IRC channel. + +- **Reviewer**: Someone (most likely also a developer) who reads code + submissions to decide: + + 0. Is the idea behind the contribution sound? + 1. Does the idea fit the goals of the project? + 2. Is the contribution designed correctly? + 3. Is the contribution polished? + 4. Can the contribution be tested effectively? + + Reviewers should identify themselves with an ``R:`` entry in the kernel + and fstests MAINTAINERS files. + +- **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. + +- **Bug Triager**: Someone who examines incoming bug reports in just + enough detail to identify the person to whom the report should be + forwarded. + + The bug triagers should identify themselves with a ``B:`` entry in + the kernel MAINTAINERS file. + +- **Release Manager**: This person merges reviewed patchsets into an + integration branch, tests the result locally, pushes the branch to a + public git repository, and sends pull requests further upstream. + This person should not be an active developer to avoid conflicts of + interest. + + The release manager should identify themselves with an ``M:`` entry in + the kernel MAINTAINERS file. + +- **Community Manager**: This person calls and moderates meetings of as many + XFS participants as they can get when mailing list discussions prove + insufficient for collective decisionmaking. + They may also serve as liaison between managers of the organizations + sponsoring work on any part of XFS. + +- **LTS Maintainer**: Someone who backports and tests bug fixes from + uptream to the LTS kernels. + There tend to be six separate LTS trees at any given time. + + The maintainer for a given LTS release should identify themselves with an + ``M:`` entry in the MAINTAINERS file for that LTS tree. + Unmaintained LTS kernels should be marked with status ``S: Orphan`` in that + same file. + +Submission Checklist Addendum +----------------------------- +Please follow these additional rules when submitting to XFS: + +- Patches affecting only the filesystem itself should be based against + the latest -rc or the for-next branch. + These patches will be merged back to the for-next branch. + +- Authors of patches touching other subsystems need to coordinate with + the maintainers of XFS and the relevant subsystems to decide how to + proceed with a merge. + +- Any patchset changing XFS should be cc'd in its entirety to linux-xfs. + Do not send partial patchsets; that makes analysis of the broader + context of the changes unnecessarily difficult. + +- Anyone making kernel changes that have corresponding changes to the + userspace utilities should send the userspace changes as separate + patchsets immediately after the kernel patchsets. + +- Authors of bug fix patches are expected to use fstests[2] to perform + an A/B test of the patch to determine that there are no regressions. + When possible, a new regression test case should be written for + fstests. + +- Authors of new feature patchsets must ensure that fstests will have + appropriate functional and input corner-case test cases for the new + feature. + +- When implementing a new feature, it is strongly suggested that the + developers write a design document to answer the following questions: + + * **What** problem is this trying to solve? + + * **Who** will benefit from this solution, and **where** will they + access it? + + * **How** will this new feature work? This should touch on major data + structures and algorithms supporting the solution at a higher level + than code comments. + + * **What** userspace interfaces are necessary to build off of the new + features? + + * **How** will this work be tested to ensure that it solves the + problems laid out in the design document without causing new + problems? + + The design document should be committed in the kernel documentation + directory. + It may be omitted if the feature is already well known to the + community. + +- Patchsets for the new tests should be submitted as separate patchsets + immediately after the kernel and userspace code patchsets. + +- Changes to the on-disk format of XFS must be described in the ondisk + format document[3] and submitted as a patchset after the fstests + patchsets. + +- Patchsets implementing bug fixes and further code cleanups should put + the bug fixes at the beginning of the series to ease backporting. + +Key Release Cycle Dates +----------------------- +Bug fixes may be sent at any time, though the release manager may decide to +defer a patch when the next merge window is close. + +Code submissions targeting the next merge window should be sent between +-rc1 and -rc6. +This gives the community time to review the changes, to suggest other changes, +and for the author to retest those changes. + +Code submissions also requiring changes to fs/iomap and targeting the +next merge window should be sent between -rc1 and -rc4. +This allows the broader kernel community adequate time to test the +infrastructure changes. + +Review Cadence +-------------- +In general, please wait at least one week before pinging for feedback. +To find reviewers, either consult the MAINTAINERS file, or ask +developers that have Reviewed-by tags for XFS changes to take a look and +offer their opinion. + +References +---------- +| [0] https://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git/ +| [1] https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git/ +| [2] https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/ +| [3] https://git.kernel.org/pub/scm/fs/xfs/xfs-documentation.git/ diff --git a/Documentation/maintainer/maintainer-entry-profile.rst b/Documentation/maintainer/maintainer-entry-profile.rst index cfd37f31077f..6b64072d4bf2 100644 --- a/Documentation/maintainer/maintainer-entry-profile.rst +++ b/Documentation/maintainer/maintainer-entry-profile.rst @@ -105,3 +105,4 @@ to do something different in the near future. ../driver-api/media/maintainer-entry-profile ../driver-api/vfio-pci-device-specific-driver-acceptance ../nvme/feature-and-quirk-policy + ../filesystems/xfs-maintainer-entry-profile diff --git a/MAINTAINERS b/MAINTAINERS index d516295978a4..d232e9e36b87 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -23330,6 +23330,7 @@ S: Supported W: http://xfs.org/ C: irc://irc.oftc.net/xfs T: git git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git +P: Documentation/filesystems/xfs-maintainer-entry-profile.rst F: Documentation/ABI/testing/sysfs-fs-xfs F: Documentation/admin-guide/xfs.rst F: Documentation/filesystems/xfs-delayed-logging-design.rst