[Ksummit-2012-discuss] [ATTEND] Building up younger contributors and high volume trees

Josef Bacik josef at toxicpanda.com
Tue Jun 19 16:18:32 UTC 2012


Hello,

Sorry for using gmail but I'm between email addresses atm.  I've been
an active contributor to Btrfs for years now and have done lots of
random things in the file system space, mostly in the area of
creating/fixing interfaces for things like hole punching and
seek_hole/seek_data.

I'm interested in the writeback discussions of course but I'm also
relatively young in the community, both in age and experience.  I know
this topic has been beaten to death over the years and I'd like to
join in the beating.  The thing that hinders new contributors the most
is that most subsystems have very busy maintainers.  For Btrfs we have
Chris who is working just as hard developing the damn thing as well as
playing maintainer.  I've tried to step in and handle the patch monkey
side of things, that way new contributors patches don't get lost in
the fray.

Long term developers are all so busy working on their corner of the
world that they often don't look up long enough to notice or help new
contributors.  This is the same problem with patch reviews as well.  I
think that having one person who is in charge of what goes in and
doesn't works great for our quality, but it adds a lot of churn where
people have to re-send patches over and over to get them included, not
to mention sitting there for an entire release period to wait and see
if it got picked up or not.  Having something like btrfs-next where I
cram anything that hits the mailinglist in (within reason of course) I
believe has already helped us immensely with including new
contributors and making them feel like they are making progress.  Then
from there Chris can have a nice view of what he wants to take and
what he doesn't, and all of the other developers have a nice tree to
base their work on so we don't all trample on each other.

I think having something like btrfs-next for every maintainer would be
helpful to existing developers and new developers.  I would like to
have a discussion that actually comes up with a solution to the
problem that we can all go back and implement, so for example all
maintainers appoint a sub-maintainer that takes on this kind of work
or something like that.  It seems like every year the conclusion is
"yup we could do better, but we're still doing pretty great so carry
on!", and I'd like to avoid that this year and have some real tangible
thing that most of us go back and implement to try and make every ones
life easier.

Hopefully that's not too rambly.  Thanks,

Josef Bacik


More information about the Ksummit-2012-discuss mailing list