[Question]: Contributing to btrfs

[Question]: Contributing to btrfs

[Philippe Loctaux]

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
phil@philippeloctaux.com

[Question]: Contributing to btrfs

[Philippe Loctaux]

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
phil@philippeloctaux.com

Re: [Question]: Contributing to btrfs

[Duncan]

Philippe Loctaux posted on Sat, 20 Feb 2016 23:40:50 +0100 as excerpted:

> 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. =:^)

https://btrfs.wiki.kernel.org

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. =:^)

-- 
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

Re: [Question]: Contributing to btrfs

[Qu Wenruo]

Philippe Loctaux wrote on 2016/02/20 23:40 +0100:
> 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
>
> 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
> phil@philippeloctaux.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>

Re: [Question]: Contributing to btrfs

[Philippe Loctaux]

On Mon, Feb 22, 2016 at 09:18:04AM +0800, Qu Wenruo wrote:
> 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
phil@philippeloctaux.com

Re: [Question]: Contributing to btrfs

[Qu Wenruo]

Philippe Loctaux wrote on 2016/02/22 08:26 +0100:
> On Mon, Feb 22, 2016 at 09:18:04AM +0800, Qu Wenruo wrote:
>> 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?

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

>
> --
> Philippe Loctaux
> phil@philippeloctaux.com
>
>

Re: [Question]: Contributing to btrfs

[Philippe Loctaux]

On Mon, Feb 22, 2016 at 03:34:32PM +0800, Qu Wenruo wrote:
> 
> 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.


> 
> 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
phil@philippeloctaux.com

Re: [Question]: Contributing to btrfs

[Filipe Manana]

On Mon, Feb 22, 2016 at 7:26 AM, Philippe Loctaux
<phil@philippeloctaux.com> wrote:
> On Mon, Feb 22, 2016 at 09:18:04AM +0800, Qu Wenruo wrote:
>> 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?

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.


>
> --
> Philippe Loctaux
> phil@philippeloctaux.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
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."

Re: [Question]: Contributing to btrfs

[David Sterba]

Hi,

On Sat, Feb 20, 2016 at 10:09:03PM +0100, Philippe Loctaux wrote:
> 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."

Re: [Question]: Contributing to btrfs

[Simon Quigley]

[-- Attachment #1: Type: text/plain, Size: 424 bytes --]

> 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.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Question]: Contributing to btrfs

[David Sterba]

On Mon, Feb 22, 2016 at 10:47:29AM +0000, Filipe Manana wrote:
[snip]
> 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

Re: [Question]: Contributing to btrfs

[Filipe Manana]

On Mon, Feb 22, 2016 at 12:02 PM, Simon Quigley <tsimonq2@ubuntu.com> wrote:
>> 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.

> 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.




-- 
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."

Re: [Question]: Contributing to btrfs

[Simon Quigley]

On Mon, Feb 22, 2016 at 7:29 AM, Filipe Manana <fdmanana@gmail.com> wrote:
> On Mon, Feb 22, 2016 at 12:02 PM, Simon Quigley <tsimonq2@ubuntu.com> wrote:
>>> 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.
>
>> 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.

I guess you have a point, I apologize. Overall though, I am curious as
to what Chris Mason has to say about this.

Re: [Question]: Contributing to btrfs

[Philippe Loctaux]

On Mon, Feb 22, 2016 at 12:34:12PM +0100, David Sterba wrote:
> 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
phil@philippeloctaux.com

Re: [Question]: Contributing to btrfs

[Philippe Loctaux]

On Mon, Feb 22, 2016 at 01:18:05PM +0100, David Sterba wrote:
> 
> 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
phil@philippeloctaux.com

Re: [Question]: Contributing to btrfs

[Philippe Loctaux]

On Mon, Feb 22, 2016 at 01:29:31PM +0000, Filipe Manana wrote:
> 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
phil@philippeloctaux.com

Re: [Question]: Contributing to btrfs

[David Sterba]

On Mon, Feb 22, 2016 at 05:41:50PM +0100, Philippe Loctaux wrote:
> On Mon, Feb 22, 2016 at 01:18:05PM +0100, David Sterba wrote:
> > 
> > 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?

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.

Re: [Question]: Contributing to btrfs

[Qu Wenruo]

Simon Quigley wrote on 2016/02/22 08:45 -0600:
> On Mon, Feb 22, 2016 at 7:29 AM, Filipe Manana <fdmanana@gmail.com> wrote:
>> On Mon, Feb 22, 2016 at 12:02 PM, Simon Quigley <tsimonq2@ubuntu.com> wrote:
>>>> 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.
>>
>>> 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).

And, even employed, at least I also went through that phase.
(Not to mention I also started by sending small cleanups)

>> 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.

>
> 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


> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>

Re: [Question]: Contributing to btrfs

[Simon Quigley]

> 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!

> 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.

> 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?

> 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.

I agree, because the userspace tool probably uses kernel calls of some sort.

> 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
tsimonq2@ubuntu.com
tsimonq2 on Freenode

Re: [Question]: Contributing to btrfs

[Qu Wenruo]

Simon Quigley wrote on 2016/02/22 20:07 -0600:
>> 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!
>
>> 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.
>
>> 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?

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.

>
>> 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.
>
> 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

>
>> 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
> tsimonq2@ubuntu.com
> tsimonq2 on Freenode
>
>