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

Srivatsa S. Bhat srivatsa.bhat at linux.vnet.ibm.com
Fri Jun 22 06:55:16 UTC 2012


On 06/19/2012 09:48 PM, Josef Bacik wrote:

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


Being a new contributor myself, I'd definitely be interested in discussing
what factors hinder new contributors and what roadblocks they face, so that
we can try to resolve them. However, I didn't exactly get what you meant by
having new trees for each subsystem. Don't we already have enough development
trees (atleast one for each of the major subsystems) that eventually feed
linux-next? Or maybe you meant something else and I missed your point..
(perhaps you were trying to outline how the work involved in managing these
trees could be split up for faster response times?)

Regards,

Srivatsa S. Bhat



More information about the Ksummit-2012-discuss mailing list