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

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Fri, 2015-07-31 at 15:09 +0200, Nicolas Ferre wrote:
> Le 16/07/2015 18:52, Steven Rostedt a écrit :
> > On Thu, 16 Jul 2015 09:24:56 -0700
> > Tim Bird <tim.bird@sonymobile.com> wrote:
> > 
> > 
> >> That's really good feedback.  I've often assumed that if you saw something
> >> that needed fixing, you had a responsibility to properly format a patch
> >> so as not to burden the maintainer.  I've labeled my own "best-effort,
> >> but-probably-not-mainlinable" patches as [RFC PATCH..].  Would it be
> >> worth having a convention for that sort of thing?
> > 
> > At a minimum, the patch should not be html, an attachment, nor have
> > broken whitespace where the patch doesn't apply. But other than that,
> 
> Le me just react on the "no attachment" statement:
> 
> As a maintainer, I accept patches as attachments, rework them and
> properly submit them.
> For a newcomer, it's sometimes very difficult to find a way to send
> patches with git or using a "patch/plain-text-friendly" SMTP server.

Just a me-too on this.  Sometime attachments are the only way to get
undamaged patches through an exchange server which a lot of companies
who submit drivers force their employees to use.  Accepting them isn't a
hardship: git-am actually processes attachments perfectly well.

Also git am --whitespace=fix manages to correct most broken whitespace
issues.  I usually remember to add it, but perhaps it should be the
default?

We've just had long discussions about using tools to help newcomers,
let's actually not cause problems over things our tools already cope
with.

James

> This mostly apply for company employees and breaking this barrier could
> allow us to have more "gifts" in Neil Brown words.
> 
> When I recall how difficult it can be to gain a properly configured SMTP
> server for my Mainline activities in a former company, I completely
> measure the barrier for contribution it can be.
> 
> > just report the bug and say "this fixes it for me". And if it is a real
> > bug, the maintainer should take it.
> 
> [..]
>