: Contributing to btrfs
Hello!
I'm new to the mailing list and btrfs in general (I've been using it for two weeks on my new arch install) and I'd like to contribute to the code :)
I know how to work w/ git and patches, I just wanted to know which git repo I need to clone to start contributing :)
I went on the kernel wiki and I saw some git repos, that confused me, that's why I'm asking here :)
I'd like to apologize for my english, I'm not english native (french).
I'll wait for your replies, thanks and have a nice day!
--
Phil
[email protected]
Hello!
I'm new to the mailing list and btrfs in general (I've been using it for two weeks on my new arch install) and I'd like to contribute to the code :)
I know how to work w/ git and patches, I just wanted to know which git repo I need to clone to start contributing :)
I went on the kernel wiki and I saw some git repos, that confused me, that's why I'm asking here :)
I'd like to apologize for my english, I'm not english native (french).
I'll wait for your replies, thanks and have a nice day!
--
Phil
[email protected]
Philippe Loctaux posted on Sat, 20 Feb 2016 23:40:50 +0100 as excerpted:
Quoted 9 lines
I'm new to the mailing list and btrfs in general (I've been using it for two weeks on my new arch install) and I'd like to contribute to the code :)
I know how to work w/ git and patches, I just wanted to know which git repo I need to clone to start contributing :)
I went on the kernel wiki and I saw some git repos, that confused me, that's why I'm asking here :)
You mention the kernel wiki, but don't mention the btrfs wiki, which is on a kernel wiki subdomain, and which has the btrfs-specific information, both for users and for developers. Missing that is thus likely to be the source of your confusion, which makes it easy to fix. =:^)
More specifically of interest for developers:
https://btrfs.wiki.kernel.org/index.php/Main_Page#Developer_documentation
But as you're a new user as well, and missed the btrfs user docs on the wiki, spend some time looking over them as well, as they'll almost certainly contain some rather useful user information you missed, as well.
If OTOH, you meant that you read that, and were still confused, as may be the case give that I too was a bit confused as a list regular, when I was looking for actual development sources, as the kernel.org userspace repo only contains releases, the repo.or.cz repo is what I was looking for to get the actual under development userspace HEAD code. Or just do what I did and browse around a bit until you figure out which of the listed repos you're actually after. =:^)
Signature · 3 lines
Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Philippe Loctaux wrote on 2016/02/20 23:40 +0100:
Quoted 7 lines
Hello!
I'm new to the mailing list and btrfs in general (I've been using it for two weeks on my new arch install) and I'd like to contribute to the code :)
I know how to work w/ git and patches, I just wanted to know which git repo I need to clone to start contributing :)
https://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git
For branch, normally I use 'integration-X.X' as base for kernel development.
And for btrfs-progs,
https://github.com/kdave/btrfs-progs.git devel
Thanks,
Qu
Quoted 17 lines
I went on the kernel wiki and I saw some git repos, that confused me, that's why I'm asking here :)
I'd like to apologize for my english, I'm not english native (french).
I'll wait for your replies, thanks and have a nice day!
--
Phil
[email protected]
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 5 lines · Qu Wenruo
https://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git
For branch, normally I use 'integration-X.X' as base for kernel development.And for btrfs-progs,
https://github.com/kdave/btrfs-progs.git devel
Allright, I'll work from these repos!
Is it fine if I work from Linus's repo?
Will my patches get rejected if I do so?
--
Philippe Loctaux
[email protected]
Philippe Loctaux wrote on 2016/02/22 08:26 +0100:
Quoted 11 lines · Qu Wenruo
Quoted 5 lines
https://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git
For branch, normally I use 'integration-X.X' as base for kernel development.And for btrfs-progs,
https://github.com/kdave/btrfs-progs.git develAllright, I'll work from these repos!
Is it fine if I work from Linus's repo?
Will my patches get rejected if I do so?
It depends.
If it's just small fix, and can be applied on Chris' integration branch, that's OK.
In that case, just submit patches to mail list, and if it's OK, maintainers like David will pick and rebase them properly.
But for huge modifications, it's recommended to use integration branch, as the final pull request is sent to btrfs maintainer Chris, not Linus.
Although all above is just my personal experience, other developers may give better advice though.
Thanks,
Qu
Quoted 6 lines
--
Philippe Loctaux
[email protected]
Quoted 4 lines · Qu Wenruo
It depends.
If it's just small fix, and can be applied on Chris' integration branch, that's OK.
Allright, the patches I sent added/removed a couple of lines, so it should be fine.
Quoted 3 lines
But for huge modifications, it's recommended to use integration branch, as the final pull request is sent to btrfs maintainer Chris, not Linus.
For the moment I'll send small ones, I don't wanna get dirty too fast :P
Thanks for your quick reply!
--
Philippe Loctaux
[email protected]
Quoted 11 lines · Philippe Loctaux
Quoted 5 lines · Qu Wenruo
https://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git
For branch, normally I use 'integration-X.X' as base for kernel development.And for btrfs-progs,
https://github.com/kdave/btrfs-progs.git develAllright, I'll work from these repos!
Is it fine if I work from Linus's repo?
Will my patches get rejected if I do so?
If you want to contribute and do something useful for others and yourself, just don't keep sending these patches to fix whitespace/style issues reported by checkpatch.
Think about it:
1) You don't learn anything by doing them. You don't learn nothing about btrfs internals, filesystems in general, kernel programming in general, general programming in C, etc. It ends up being only a waste of time for you;
2) You're not offering any benefit to users - not fixing a bug, not adding a new feature, not doing any performance/efficiency improvement, not making the code more reliable, etc;
3) You're not offering a benefit for other developers either, like doing a cleanup that simplifies a complex algorithm for example.
If you care so much about the whitespace/style issues, just fix them while doing a useful change as mentioned above that happens to touch the same code.
It takes time to read and understand code, it can be a big investment of time, but it ends up being worth it. There's plenty of bug reports and performance issues in the mailing list or bugzilla, so there's no shortage of things to do.
Same advice applies to any other kernel subsystem or open source project in general. Also before jumping into such a storm of useless patches, observe first what a community does for at least a month, and learn from other contributors - what they do, how they do it, the flow of development and releases, etc. Don't rush into a sending patch just for the sake of sending it and having your name in the git history.
Hope it helps.
Quoted 8 lines
--
Philippe Loctaux
[email protected]
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 5 lines
Filipe David Manana, "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men."
Quoted 4 lines
1) You don't learn anything by doing them. You don't learn nothing about btrfs internals, filesystems in general, kernel programming in general, general programming in C, etc. It ends up being only a waste of time for you;
It is useful for one reason. If you would like to get used to the workflow of kernel development, this seems to be useful for a lot of people. In fact, Linus himself has encouraged this.
Quoted 6 lines · Simon Quigley
Quoted 4 lines
1) You don't learn anything by doing them. You don't learn nothing about btrfs internals, filesystems in general, kernel programming in general, general programming in C, etc. It ends up being only a waste of time for you;
It is useful for one reason. If you would like to get used to the workflow of kernel development,
No, that's silly. Generating a patch file and sending it to the mailing list is very trivial. There's not much to learn there. Certainly you don't need to send around 10 whitespace/style patches for that. 1 is enough to "test the waters". And most people learn that by observing others for a while too.
Quoted 1 line
this seems to be useful for a lot of people. In fact, Linus himself has encouraged this.
Whitespace/style patches I doubt. He probably encourages for small cleanup/optimizations as the first patch, like he did recently at
https://lkml.org/lkml/2015/9/15/919. That's something that requires some thinking and understanding. Now running checkpatch and fix its warnings, doesn't require any skill at all.
What were you planning? Sending more 100 patches, each one to fix a different style issue for each function? There's probably hundreds or thousands more style/whitespace "issues" to fix in btrfs alone.
Just think about what you want to accomplish. It's normal to not know what do initially, I think everyone goes through that phase, specially if not employed to work on btrfs (or whatever project interests you). Just read code, find issues in it, make changes for your own testing, read bug reports and performance issue reports here in the list and in kernel's bugzilla - some bugs might be easy to fix, other might require very deep knowledge of the internals or no one figured out yet how to reproduce. Or run xfstests and filesystem stress testing tools to find problems (there's plenty of races, deadlocks, etc that happen often and no one knows about them yet). Over time you'll find plenty of things to do, that make you learn a lot and do something useful for users and other developers.
Signature · 5 lines
Filipe David Manana, "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men."
Quoted 25 lines · Filipe Manana
Quoted 6 lines · Simon Quigley
Quoted 4 lines
1) You don't learn anything by doing them. You don't learn nothing about btrfs internals, filesystems in general, kernel programming in general, general programming in C, etc. It ends up being only a waste of time for you;
It is useful for one reason. If you would like to get used to the workflow of kernel development,
No, that's silly. Generating a patch file and sending it to the mailing list is very trivial. There's not much to learn there. Certainly you don't need to send around 10 whitespace/style patches for that. 1 is enough to "test the waters". And most people learn that by observing others for a while too.
Quoted 1 line
this seems to be useful for a lot of people. In fact, Linus himself has encouraged this.
Whitespace/style patches I doubt. He probably encourages for small cleanup/optimizations as the first patch, like he did recently at
https://lkml.org/lkml/2015/9/15/919. That's something that requires some thinking and understanding. Now running checkpatch and fix its warnings, doesn't require any skill at all.
What were you planning? Sending more 100 patches, each one to fix a different style issue for each function? There's probably hundreds or thousands more style/whitespace "issues" to fix in btrfs alone.
Quoted 12 lines
Just think about what you want to accomplish. It's normal to not know what do initially, I think everyone goes through that phase, specially if not employed to work on btrfs (or whatever project interests you). Just read code, find issues in it, make changes for your own testing, read bug reports and performance issue reports here in the list and in kernel's bugzilla - some bugs might be easy to fix, other might require very deep knowledge of the internals or no one figured out yet how to reproduce. Or run xfstests and filesystem stress testing tools to find problems (there's plenty of races, deadlocks, etc that happen often and no one knows about them yet). Over time you'll find plenty of things to do, that make you learn a lot and do something useful for users and other developers.
I guess you have a point, I apologize. Overall though, I am curious as to what Chris Mason has to say about this.
Simon Quigley wrote on 2016/02/22 08:45 -0600:
Quoted 26 lines · Filipe Manana
Quoted 25 lines · Simon Quigley
Quoted 6 lines
Quoted 4 lines
1) You don't learn anything by doing them. You don't learn nothing about btrfs internals, filesystems in general, kernel programming in general, general programming in C, etc. It ends up being only a waste of time for you;
It is useful for one reason. If you would like to get used to the workflow of kernel development,
No, that's silly. Generating a patch file and sending it to the mailing list is very trivial. There's not much to learn there. Certainly you don't need to send around 10 whitespace/style patches for that. 1 is enough to "test the waters". And most people learn that by observing others for a while too.
Quoted 1 line
this seems to be useful for a lot of people. In fact, Linus himself has encouraged this.
Whitespace/style patches I doubt. He probably encourages for small cleanup/optimizations as the first patch, like he did recently at
https://lkml.org/lkml/2015/9/15/919. That's something that requires some thinking and understanding. Now running checkpatch and fix its warnings, doesn't require any skill at all.
What were you planning? Sending more 100 patches, each one to fix a different style issue for each function? There's probably hundreds or thousands more style/whitespace "issues" to fix in btrfs alone.
Quoted 3 lines
Quoted 3 lines
Just think about what you want to accomplish. It's normal to not know what do initially, I think everyone goes through that phase, specially if not employed to work on btrfs (or whatever project interests you).
And, even employed, at least I also went through that phase. (Not to mention I also started by sending small cleanups)
Quoted 9 lines
Quoted 9 lines
Just read code, find issues in it, make changes for your own testing, read bug reports and performance issue reports here in the list and in kernel's bugzilla - some bugs might be easy to fix, other might require very deep knowledge of the internals or no one figured out yet how to reproduce. Or run xfstests and filesystem stress testing tools to find problems (there's plenty of races, deadlocks, etc that happen often and no one knows about them yet). Over time you'll find plenty of things to do, that make you learn a lot and do something useful for users and other developers.
Despite reading the code, which sometimes is quite boring and easy to get lost especially when you are not familiar with btrfs, personally I recommend to start from btrfs on-disk format with btrfs-dedup-tree.
And my personal quick-and-dirty skill up roadmap would be:
1) Understand btrfs on-disk format
2) btrfs-progs contributor
3) btrfs kernel contributor
On-disk data is static and you don't need to care any of the complicated implementation or details.
All you need to care is, what is on disk, what's the meaning of that on-disk data, and how on-disk data change after you did something with the btrfs filesystem, like creating a empty file/dir, or write some data into it.
Also, when you play with btrfs-debug-tree, it's quite easy to get familiar how btrfs-debug-tree works, and maybe found some easy enhancement for btrfs-debug-tree.
On-disk format also provides a super good entry point for further reading.
If you want to understand how btrfs inserts file extents, as long as you find file extents use EXTENT_DATA key type, you can easily find the direct code which inserts that key into btrfs btree.
With btrfs-debug-tree as a learning tool, you will be quite easy to begin your contribution to btrfs-progs, like adding some output which current btrfs-debug-tree lacks.
After you're familiar with btrfs-progs enough, all skills learnt will help you to start your kernel contribution, although kernel is never as easy as btrfs-progs, but I think that's your object.
Quoted 3 lines
I guess you have a point, I apologize. Overall though, I am curious as to what Chris Mason has to say about this.
I think David, one of the kernel maintainers and btrfs-progs maintainer, and Filipe, one of the core and the most active developer, their words have carries a lot of weight.
Thanks,
Qu
Quoted 6 lines
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 2 lines
And, even employed, at least I also went through that phase. (Not to mention I also started by sending small cleanups)
Thank you. I read Linus' statement somewhere, I just can't find it!
Quoted 4 lines
Despite reading the code, which sometimes is quite boring and easy to get lost especially when you are not familiar with btrfs, personally I recommend to start from btrfs on-disk format with btrfs-dedup-tree.
I'll RTFM on this one because I don't know what this is.
Quoted 4 lines
And my personal quick-and-dirty skill up roadmap would be:
1) Understand btrfs on-disk format
2) btrfs-progs contributor
3) btrfs kernel contributor
Should this be documented somewhere?
Quoted 17 lines
On-disk data is static and you don't need to care any of the complicated implementation or details.
All you need to care is, what is on disk, what's the meaning of that on-disk data, and how on-disk data change after you did something with the btrfs filesystem, like creating a empty file/dir, or write some data into it.Also, when you play with btrfs-debug-tree, it's quite easy to get familiar how btrfs-debug-tree works, and maybe found some easy enhancement for btrfs-debug-tree.
On-disk format also provides a super good entry point for further reading.
If you want to understand how btrfs inserts file extents, as long as you find file extents use
EXTENT_DATAkey type, you can easily find the direct code which inserts that key into btrfs btree.
Quoted 7 lines
With btrfs-debug-tree as a learning tool, you will be quite easy to begin your contribution to btrfs-progs, like adding some output which current btrfs-debug-tree lacks.
After you're familiar with btrfs-progs enough, all skills learnt will help you to start your kernel contribution, although kernel is never as easy as btrfs-progs, but I think that's your object.
I agree, because the userspace tool probably uses kernel calls of some sort.
Quoted 3 lines
I think David, one of the kernel maintainers and btrfs-progs maintainer, and Filipe, one of the core and the most active developer, their words have carries a lot of weight.
I apologize, I'm new around here, I thought Chris was the sole maintainer of all of btrfs. I also wanted his additional feedback, but I guess that isn't really needed. :)
For all of you, thank you for taking time to help Philippe and myself out with this. I'm new to kernel development and I'd really like to help out with btrfs because I feel it has serious potential. I'm glad I learned how to submit patches, and I'll look into the resources suggested. In my opinion this should be documented somewhere, a btrfs-specific thing, because I would much rather RTFM then have to wait and ask questions (although the latter still is valuable). If you have any other feedback for beginning kernel development that you would like to share, please, send me an email or PM me on IRC. I'm on #btrfs on Freenode.
Thanks,
Simon Quigley
[email protected]
tsimonq2 on Freenode
Simon Quigley wrote on 2016/02/22 20:07 -0600:
Quoted 10 lines
Quoted 2 lines
And, even employed, at least I also went through that phase. (Not to mention I also started by sending small cleanups)
Thank you. I read Linus' statement somewhere, I just can't find it!
Quoted 4 lines
Despite reading the code, which sometimes is quite boring and easy to get lost especially when you are not familiar with btrfs, personally I recommend to start from btrfs on-disk format with btrfs-dedup-tree.
Quoted 8 lines
I'll RTFM on this one because I don't know what this is.
Quoted 4 lines
And my personal quick-and-dirty skill up roadmap would be:
1) Understand btrfs on-disk format
2) btrfs-progs contributor
3) btrfs kernel contributorShould this be documented somewhere?
Btrfs wiki has a Developer's FAQ, which includes how to start contribution.
And my method is just a *QUICK-AND-DIRTY* hack for guys who gets lost in codes easily, like myself.
BTW, btrfs wiki also has a lot of info on on-disk format and other things to help you get started.
Quoted 22 lines
Quoted 22 lines
On-disk data is static and you don't need to care any of the complicated implementation or details.
All you need to care is, what is on disk, what's the meaning of that on-disk data, and how on-disk data change after you did something with the btrfs filesystem, like creating a empty file/dir, or write some data into it.Also, when you play with btrfs-debug-tree, it's quite easy to get familiar how btrfs-debug-tree works, and maybe found some easy enhancement for btrfs-debug-tree.
On-disk format also provides a super good entry point for further reading.
If you want to understand how btrfs inserts file extents, as long as you find file extents use
EXTENT_DATAkey type, you can easily find the direct code which inserts that key into btrfs btree.With btrfs-debug-tree as a learning tool, you will be quite easy to begin your contribution to btrfs-progs, like adding some output which current btrfs-debug-tree lacks.
Quoted 5 lines
Quoted 3 lines
After you're familiar with btrfs-progs enough, all skills learnt will help you to start your kernel contribution, although kernel is never as easy as btrfs-progs, but I think that's your object.
I agree, because the userspace tool probably uses kernel calls of some sort.
Not all(although a lot of is), btrfs offline progs, like btrfsck is pure user-space program, and uses a simplified user-space only implementation.
And that's why I recommend to start from btrfs-progs, just because a lot of things is simplified and more easy to understand.
Thanks,
Qu
Quoted 22 lines
Quoted 4 lines
I think David, one of the kernel maintainers and btrfs-progs maintainer, and Filipe, one of the core and the most active developer, their words have carries a lot of weight.
I apologize, I'm new around here, I thought Chris was the sole maintainer of all of btrfs. I also wanted his additional feedback, but I guess that isn't really needed. :)
For all of you, thank you for taking time to help Philippe and myself out with this. I'm new to kernel development and I'd really like to help out with btrfs because I feel it has serious potential. I'm glad I learned how to submit patches, and I'll look into the resources suggested. In my opinion this should be documented somewhere, a btrfs-specific thing, because I would much rather RTFM then have to wait and ask questions (although the latter still is valuable). If you have any other feedback for beginning kernel development that you would like to share, please, send me an email or PM me on IRC. I'm on #btrfs on Freenode.
Thanks,
Simon Quigley
[email protected]
tsimonq2 on Freenode
Quoted 8 lines · Filipe Manana
Whitespace/style patches I doubt. He probably encourages for small cleanup/optimizations as the first patch, like he did recently at
https://lkml.org/lkml/2015/9/15/919. That's something that requires some thinking and understanding. Now running checkpatch and fix its warnings, doesn't require any skill at all.
What were you planning? Sending more 100 patches, each one to fix a different style issue for each function? There's probably hundreds or thousands more style/whitespace "issues" to fix in btrfs alone.
I agree with you, I won't spend all my time fixing style/whitespace issues, now that I know what I can do, thanks for that :)
--
Philippe Loctaux
[email protected]
On Mon, Feb 22, 2016 at 10:47:29AM +0000, Filipe Manana wrote:
[snip]
Quoted 1 line
Hope it helps.
Thanks for the writeup. Should we ever need it again, it's now on the wiki.
https://btrfs.wiki.kernel.org/index.php/Developer's_FAQ#How_not_to_start
Quoted 5 lines · David Sterba
Thanks for the writeup. Should we ever need it again, it's now on the wiki.
https://btrfs.wiki.kernel.org/index.php/Developer's_FAQ#How_not_to_start
Thanks for putting that on the wiki, so that the new persons (hopefully) won't make the same mistakes that I did :)
Is there a way we can put this onto the main kernel wiki so that almost anyone can read that, not just the btrfs people?
--
Philippe Loctaux
[email protected]
Quoted 5 lines · Philippe Loctaux
Quoted 4 lines · David Sterba
Thanks for the writeup. Should we ever need it again, it's now on the wiki.
Quoted 7 lines
Quoted 1 line
https://btrfs.wiki.kernel.org/index.php/Developer's_FAQ#How_not_to_start
Thanks for putting that on the wiki, so that the new persons (hopefully) won't make the same mistakes that I did :)
Is there a way we can put this onto the main kernel wiki so that almost anyone can read that, not just the btrfs people?
I don't think there's one style that fits all subsystems/maintainers and can be recommended as general practice and I certainly do not want to maintain any such guide on a wiki. There are guides, posts and recommendations on how to contribute to linux kernel but they depend on the acutal maintainers and the preferences. This can change over time. IMO it's good to lurk for a while and observe the local habits.
Hi,
Quoted 2 lines · Philippe Loctaux
I'm new to the mailing list and btrfs in general (I've been using it for two weeks on my new arch install) and I'd like to contribute to the code :)
contributions to code are welcome, but please try not to spend too much time fixing style problems or checkpatch warnings. This may be a good start to get used to the patch formatting, mails and the feedback loop, which you seem to understand now.
But otherwise whitespace-only changes are not considered worth the time, and I don't want to encourage people to do that. My usual answer to that is at
https://btrfs.wiki.kernel.org/index.php/Project_ideas#Cleanup_projects
"Please note that pure whitespace and style reformatting changes are not really necessary at this phase of development. They get fixed along regular changes. Possibly once upon in a while a patch that fixes many if not all whitespace errors could work, but otherwise it's considered a noise."
Quoted 5 lines · David Sterba
But otherwise whitespace-only changes are not considered worth the time, and I don't want to encourage people to do that. My usual answer to that is at
https://btrfs.wiki.kernel.org/index.php/Project_ideas#Cleanup_projects
Thanks, I'll take a look and see what I can do!
--
Philippe Loctaux
[email protected]