These days Neil Brown and I are maintaining the NFS server together, and
I'm currently (as of the last few weeks) tracking the to-be-submitted
patches.
I have limited time and am not expert on all of the relevant code, so I
depend on your help! I'm still experimenting a bit with the process
(suggestions welcomed), but most of the following should be obvious to
anyone who's been working on the kernel for a while.
I keep all the pending NFS and sunrpc server patches that I believe are
done in the "nfs-server-stable" branch here[1]:
git://linux-nfs.org/~bfields/linux.git nfs-server-stable
I also include nfs-server-stable in the "for-mm" branch, which is
normally included in Andrew's -mm kernels automatically, and which may
sometimes also contain other works-in-progress.
I'll try to submit urgent[2] patches to upstream immediately. All the
other patches in nfs-server-stable will be submitted in one batch just
after each new kernel release (that's about once every two months).
If you want patches included, email them to me, one patch per message,
in the format described in[3]
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
and also cc: [EMAIL PROTECTED], Neil Brown <[EMAIL PROTECTED]>, and
anyone you consider particularly qualified to review your work. Also,
please state clearly that you're asking me to apply your patches;
otherwise I may just assume you're asking people for early feedback on
work in progress (which is also encouraged, of course). If you get no
response and your work doesn't show up in my git tree, I may have
forgotten; please remind me. If I ignore something urgent, please try
Neil, Andrew, lkml, and/or Linus as necessary.
If you're fixing a mistake in a patch I already have, I'd usually prefer
an incremental patch as opposed to a complete replacement.
If you have large changes you'd like included in the next kernel, try to
submit them well in advance of the release of the current kernel. (For
example, with 2.6.23 about to be released, it may already be too late
for major changes to be included in 2.6.24.)
I'll follow up with a summary of the patches I currently have.
--b.
Notes:
[1] My suggestion for how to access my git tree:
1. Install git version 1.5.0 or later
2. If you haven't already, get Linus's tree with:
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
cd linux-2.6.git
3. Tell git about my tree with:
git remote add bfields git://linux-nfs.org/~bfields/linux.git
git fetch bfields
4. View current server patches with:
gitk origin..bfields/nfs-server-stable
4. Update as necessary using:
git fetch bfields
[2] A patch will be more likely to be treated as "urgent" if it is
obviously correct and if it fixes a severe problem (for example, one
that corrupts data or compromises security). As a release approaches,
and the time remaining to test new patches decreases, the standard for
such patches will become harder to meet.
[3] If you're new to the process, the contents of
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
and Documentation/SubmittingPatches are useful, but possibly also
overwhelming. The important points are:
- Each patch should make one set of logically related changes
and come with a comment that explains what the patch does and
why.
- No patch should introduce a regression: after applying the
first n patches of a series (for any n), the kernel should
still compile and run. It's not OK to introduce a bug in
one patch and then fix it in some later patch; instead, you
need to figure out how to reorder your changes.
Our goal is to improve the kernel through a long series of small,
incremental, easy to understand, and individually testable changes.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
