Re: [Ksummit-discuss] [CORE TOPIC] Recruitment (Reviewers, Testers, Maintainers, Hobbyists)

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

On Thursday 09 July 2015 19:35:39 Julia Lawall wrote:
> On Thu, 9 Jul 2015, josh@joshtriplett.org wrote:
> > On Thu, Jul 09, 2015 at 05:24:06PM -0400, Julia Lawall wrote:
> >> On Thu, 9 Jul 2015, josh@joshtriplett.org wrote:
> >>> On Thu, Jul 09, 2015 at 10:38:30PM +0200, Luis R. Rodriguez wrote:
> >>>> On Thu, Jul 09, 2015 at 01:11:27PM -0700, josh@joshtriplett.org wrote:
> >>>>> Bonus if this is also wired into the 0day bot, so that you also
> >>>>> find out if you introduce a new warning or error.
> >>>> 
> >>>> No reason to make bots do stupid work, if we really wanted to
> >>>> consider this a bit more seriously the pipeline could be:
> >>>>   mailing-list | coccinelle coccicheck| smatch | sparse | 0-day-bot
> >>> 
> >>> That would effectively make the bot duplicate part of 0-day.  Seems
> >>> easier to have some way to tell 0-day "if you see obvious procedural
> >>> issues, don't bother with full-scale testing, just reject".
> >> 
> >> Not sure to understand.  Isn't it better to have the most feedback
> >> possible?
> > 
> > If 0-day has enough bandwidth, sure.  However, if this is going to
> > encourage a large number of new contributors to quickly iterate a pile
> > of patches, many of which are likely to have basic procedural issues in
> > the first few iterations, then that may waste quite a lot of build time
> > in 0-day.
> 
> My understanding was that there were plenty of computational resources
> available.  I would think that a new contributor would like the most
> assurance possible that his next attempt would be successful, and thus
> would prefer to have all the information at once.

I can't help feeling we're mixing two issues here.

The first topic we're trying to address is recruitment. From that point of 
view, giving as much feedback as possible to newcomers is good as long as we 
can make the automatic feedback constructive. An automated reply along the 
lines of

"You have tried to send a patch through e-mail to the foo@v.k.o mailing list. 
We have detected that your e-mail includes HTML content. This is not allowed 
for the reasons explained at [...]. Please configure your e-mail client to 
send plain text only and resend the patch. Instructions on how to do so far 
popular e-mail clients can be found at [...]"

would be useful. On the other hand, an automated reply from a build bot that 
just splits errors back without taking the newcomer by the hand will scare 
people off (at this point I can't help but quote the following C++ compiler 
error message from [1]:

Syntax error: unmatched thing in thing from std::nonstd::_ _
map<_Cyrillic, _$$$dollars>const basic_string< epic_
mystery,mongoose_traits &lt; char>, _ _default_alloc_<casual_
Fridays = maybe>>)

This could be considered as some form of a selection process, but we don't 
want to make it unnecessarily painful.

The second issue we're trying to address here is how to prevent maintainers 
overloading caused by newcomers mistakes. This is certainly a valuable effort, 
and even more so if our recruitment effort becomes successful, but I see it 
more as a necessary consequence of improved recruitment. It would be a shame 
if it raised the barrier to entry for kernel contributions.

-- 
Regards,

Laurent Pinchart