Source repositories
Since 2.6.29-rc1, Btrfs has been included in the mainline kernel.
Kernel module
The kernel.org git repository is not used for development, only for pull requests that go to Linus and for linux-next integration:
https://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git -- pull request source
branch for-next gets pulled to the linux-next tree, is rebased and contains base development branches and topic branches
branch next-fixes has fixes for the next upcoming rcN and is usually turned into a pull request
The following git repository is used for group development and is updated with patches from the mailing list:
The main branch with patches is for-next . Note that it gets rebased or updated (fixed typos, added Reviewed-by tags etc). The base point for patches depend on the development phase. See development schedule. Independent changes can be based on the linus/master branch, changes that could depend on patches that have been added to one of the queues should use that as a base.
btrfs-progs git repository
Release repositories
The sources of the userspace utilities can be obtained from these repositories:
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git (http://git.kernel.org/?p=linux/kernel/git/kdave/btrfs-progs.git;a=summary) - release repository, not for development
The master branch contains the latest released version is never rebased and updated after a release.
Development repositories
git://github.com/kdave/btrfs-progs.git (https://github.com/kdave/btrfs-progs)
git://gitlab.com/kdave/btrfs-progs.git (https://gitlab.com/kdave/btrfs-progs)
For build dependencies and installation instructions please see https://github.com/kdave/btrfs-progs/blob/master/INSTALL
Development branches
The latest development branch is called devel. Contains patches that are reviewed or tested and on the way to the next release. When a patch is added to the branch, a mail notification is sent as a reply to the patch.
The git repositories on kernel.org are not used for development or integration branches.
GitHub development
Pull requests are accepted for contributions, and slightly more preferred as they get tested by the CI (Github actions). Patches to the mailing are also accepted but not mandatory. You can link to a branch in any git repository if the mails do not make it to the mailing list or for convenience.
The development model of btrfs-progs has moved from kernel model to github and is less strict about some things. Pull request review workflow.
It is still desired to write good changelogs:
proper subject line: e.g. prefix with btrfs-progs: subpart, … , descriptive yet not too long
proper changelog: the changelogs are often missing or lacking explanation why the change was made, or how is something broken, what are user-visible effects of the bug or the fix, how does an improvement help or the intended usecase
the Signed-off-by line: this document who authored the change, you can read more about the The Developer’s Certificate of Origin here (chapter 11)]
one logical change per patch: e.g. not mixing bug fixes, cleanups, features etc., sometimes it’s not clear and will be usually pointed out during reviews
references to reports, issues, pull requests
Pull requests allow to update commits, fixups are possible and recommended.
Administration and support tools
There is a separate repository of useful scripts for common administrative tasks on btrfs. This is at:
Patches sent to mailing list
A convenient interface to get an overview of patches and the related mail discussions can be found at https://patchwork.kernel.org/project/linux-btrfs/list/ .
It is possible to directly apply a patch by pasting the mbox link from the patch page to the command:
$ wget -O - 'https://patchwork.kernel.org/patch/123456/mbox' | git am -
You may want to add --reject, or decide otherwise what to do with the patch.