1XFS Maintainer Entry Profile 2============================ 3 4Overview 5-------- 6XFS is a well known high-performance filesystem in the Linux kernel. 7The aim of this project is to provide and maintain a robust and 8performant filesystem. 9 10Patches are generally merged to the for-next branch of the appropriate 11git repository. 12After a testing period, the for-next branch is merged to the master 13branch. 14 15Kernel code are merged to the xfs-linux tree[0]. 16Userspace code are merged to the xfsprogs tree[1]. 17Test cases are merged to the xfstests tree[2]. 18Ondisk format documentation are merged to the xfs-documentation tree[3]. 19 20All patchsets involving XFS *must* be cc'd in their entirety to the mailing 21list linux-xfs@vger.kernel.org. 22 23Roles 24----- 25There are eight key roles in the XFS project. 26A person can take on multiple roles, and a role can be filled by 27multiple people. 28Anyone taking on a role is advised to check in with themselves and 29others on a regular basis about burnout. 30 31- **Outside Contributor**: Anyone who sends a patch but is not involved 32 in the XFS project on a regular basis. 33 These folks are usually people who work on other filesystems or 34 elsewhere in the kernel community. 35 36- **Developer**: Someone who is familiar with the XFS codebase enough to 37 write new code, documentation, and tests. 38 39 Developers can often be found in the IRC channel mentioned by the ``C:`` 40 entry in the kernel MAINTAINERS file. 41 42- **Senior Developer**: A developer who is very familiar with at least 43 some part of the XFS codebase and/or other subsystems in the kernel. 44 These people collectively decide the long term goals of the project 45 and nudge the community in that direction. 46 They should help prioritize development and review work for each release 47 cycle. 48 49 Senior developers tend to be more active participants in the IRC channel. 50 51- **Reviewer**: Someone (most likely also a developer) who reads code 52 submissions to decide: 53 54 0. Is the idea behind the contribution sound? 55 1. Does the idea fit the goals of the project? 56 2. Is the contribution designed correctly? 57 3. Is the contribution polished? 58 4. Can the contribution be tested effectively? 59 60 Reviewers should identify themselves with an ``R:`` entry in the kernel 61 and fstests MAINTAINERS files. 62 63- **Testing Lead**: This person is responsible for setting the test 64 coverage goals of the project, negotiating with developers to decide 65 on new tests for new features, and making sure that developers and 66 release managers execute on the testing. 67 68 The testing lead should identify themselves with an ``M:`` entry in 69 the XFS section of the fstests MAINTAINERS file. 70 71- **Bug Triager**: Someone who examines incoming bug reports in just 72 enough detail to identify the person to whom the report should be 73 forwarded. 74 75 The bug triagers should identify themselves with a ``B:`` entry in 76 the kernel MAINTAINERS file. 77 78- **Release Manager**: This person merges reviewed patchsets into an 79 integration branch, tests the result locally, pushes the branch to a 80 public git repository, and sends pull requests further upstream. 81 The release manager is not expected to work on new feature patchsets. 82 If a developer and a reviewer fail to reach a resolution on some point, 83 the release manager must have the ability to intervene to try to drive a 84 resolution. 85 86 The release manager should identify themselves with an ``M:`` entry in 87 the kernel MAINTAINERS file. 88 89- **Community Manager**: This person calls and moderates meetings of as many 90 XFS participants as they can get when mailing list discussions prove 91 insufficient for collective decisionmaking. 92 They may also serve as liaison between managers of the organizations 93 sponsoring work on any part of XFS. 94 95- **LTS Maintainer**: Someone who backports and tests bug fixes from 96 uptream to the LTS kernels. 97 There tend to be six separate LTS trees at any given time. 98 99 The maintainer for a given LTS release should identify themselves with an 100 ``M:`` entry in the MAINTAINERS file for that LTS tree. 101 Unmaintained LTS kernels should be marked with status ``S: Orphan`` in that 102 same file. 103 104Submission Checklist Addendum 105----------------------------- 106Please follow these additional rules when submitting to XFS: 107 108- Patches affecting only the filesystem itself should be based against 109 the latest -rc or the for-next branch. 110 These patches will be merged back to the for-next branch. 111 112- Authors of patches touching other subsystems need to coordinate with 113 the maintainers of XFS and the relevant subsystems to decide how to 114 proceed with a merge. 115 116- Any patchset changing XFS should be cc'd in its entirety to linux-xfs. 117 Do not send partial patchsets; that makes analysis of the broader 118 context of the changes unnecessarily difficult. 119 120- Anyone making kernel changes that have corresponding changes to the 121 userspace utilities should send the userspace changes as separate 122 patchsets immediately after the kernel patchsets. 123 124- Authors of bug fix patches are expected to use fstests[2] to perform 125 an A/B test of the patch to determine that there are no regressions. 126 When possible, a new regression test case should be written for 127 fstests. 128 129- Authors of new feature patchsets must ensure that fstests will have 130 appropriate functional and input corner-case test cases for the new 131 feature. 132 133- When implementing a new feature, it is strongly suggested that the 134 developers write a design document to answer the following questions: 135 136 * **What** problem is this trying to solve? 137 138 * **Who** will benefit from this solution, and **where** will they 139 access it? 140 141 * **How** will this new feature work? This should touch on major data 142 structures and algorithms supporting the solution at a higher level 143 than code comments. 144 145 * **What** userspace interfaces are necessary to build off of the new 146 features? 147 148 * **How** will this work be tested to ensure that it solves the 149 problems laid out in the design document without causing new 150 problems? 151 152 The design document should be committed in the kernel documentation 153 directory. 154 It may be omitted if the feature is already well known to the 155 community. 156 157- Patchsets for the new tests should be submitted as separate patchsets 158 immediately after the kernel and userspace code patchsets. 159 160- Changes to the on-disk format of XFS must be described in the ondisk 161 format document[3] and submitted as a patchset after the fstests 162 patchsets. 163 164- Patchsets implementing bug fixes and further code cleanups should put 165 the bug fixes at the beginning of the series to ease backporting. 166 167Key Release Cycle Dates 168----------------------- 169Bug fixes may be sent at any time, though the release manager may decide to 170defer a patch when the next merge window is close. 171 172Code submissions targeting the next merge window should be sent between 173-rc1 and -rc6. 174This gives the community time to review the changes, to suggest other changes, 175and for the author to retest those changes. 176 177Code submissions also requiring changes to fs/iomap and targeting the 178next merge window should be sent between -rc1 and -rc4. 179This allows the broader kernel community adequate time to test the 180infrastructure changes. 181 182Review Cadence 183-------------- 184In general, please wait at least one week before pinging for feedback. 185To find reviewers, either consult the MAINTAINERS file, or ask 186developers that have Reviewed-by tags for XFS changes to take a look and 187offer their opinion. 188 189References 190---------- 191| [0] https://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git/ 192| [1] https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git/ 193| [2] https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/ 194| [3] https://git.kernel.org/pub/scm/fs/xfs/xfs-documentation.git/ 195