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

Josef Bacik josef at toxicpanda.com
Fri Jun 22 13:59:31 UTC 2012

On Fri, Jun 22, 2012 at 2:55 AM, Srivatsa S. Bhat
<srivatsa.bhat at linux.vnet.ibm.com> wrote:
> 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?)

So just using btrfs as an example, we have a couple of random
developer silos where different people work on the different areas
that are interesting to them.  So we had problems keeping up with what
each of us were doing.  Then throw in random new contributors and we
were dropping patches a lot because nobody was looking up from their
TODO list to notice the contributions.  Btrfs-next is trying to be a
solution to these problems.  Every day I look through the mailinglist
and pull out individual patches to pull into btrfs-next.  This way if
we get a crap patch the new guy knows right away with some
constructive criticism, and if we get a good patch from a new guy they
feel like they've accomplished something because their patch was
pulled into a tree relatively quickly.

We have a metric crap ton of development trees yes.  What makes
btrfs-next a little unique is that we have a seasoned developer (me)
looking through all the patches and responding to them and pulling
them into a tree that everybody uses and works on.  The thing that was
weird to me and took getting used to when I first started out was that
even obviously correct patches took forever to go anywhere.  I know
the argument is been made that "if a developer doesn't want to stick
around then we don't want him", but that is unhelpful and can turn
younger people off who just simply don't have the experience to know
that this kind of work is a process.  Thanks,


More information about the Ksummit-2012-discuss mailing list