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

Josef Bacik josef at toxicpanda.com
Fri Jun 22 14:03:17 UTC 2012


On Fri, Jun 22, 2012 at 6:43 AM, Jeff Liu <jeff.liu at oracle.com> wrote:
> On 06/22/2012 02:55 PM, Srivatsa S. Bhat wrote:
>
>> 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.
>
> Me too. somehow, I missed this proposal.
>
>> 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?)
>
> I feel Josef's opinion is if we have a sub-maintainer who could help
> merging those patch sets which are qualified and most likely to be
> accepted by the project to a xxx-next tree, so that the contributers
> don't need to re-send the patches again if they already hit xxx-tree.
> At least, it could reduce the exposure rate of [PATCH RESEND] on the
> mailing list.
>
> And also, the sub-maintainer could give response to contributers in a
> relatively fast point, like a project coordinator maybe.
> This might could also make the lead maintainer's life a bit easier,
> since the leader could pick up the desired patches from that xxx-next
> tree directly.
>

Exactly, the point is more that new contributors get a faster response
and feel like they're participating.  Hopefully eventually it evolves
into a better review process, and hey if we get that I'm asking for a
pony next.  Thanks,

Josef


More information about the Ksummit-2012-discuss mailing list