[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 16:56:16 UTC 2012

On 06/22/2012 07:29 PM, Josef Bacik wrote:

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

Ok, now I got your point. So you are managing the btrfs-next tree
and have taken such an initiative in order to reduce the response time to
patches, to avoid patches getting lost, to encourage contributions from
newcomers and to help out the maintainer in general - that's amazing!

Two words: Hats off! :-)

Srivatsa S. Bhat

More information about the Ksummit-2012-discuss mailing list