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

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

[Peter Huewe]

Hi,

In order to continue our traditions I would like to propose again the topic of 
recruitment, but this time not only limiting to the hobbyists market.

We are definitely short on reviewers and thus have mostly overloaded 
maintainers.
For testers it's usually even worse - how many patches are actually tested?
Judging from what I read on LKML not that many.

So we should definitely discuss:
- how can we encourage hobbyists to become regular contributors
-- how to keep people interested, the drop-out rates are huge.
- encourage regular contributors to become reviewers and testers
- reviewers to become co-maintainers and finally maintainers (once the 
original maintainer is used up or moves up/on)


e.g. I think in the TPM subsystem we finally reached a good status, coming 
from having no active maintainer to a having at least a part-time maintainer 
with a two steady and excellent reviewers which also test manually most of the 
stuff!



From the 4.1 kernel report by jon corbet:
"over 60% of the changes going into this kernel passed through the hands of 
developers working for just five companies. This concentration reflects a 
simple fact: while many companies are willing to support developers working on 
specific tasks, the number of companies supporting subsystem maintainers is 
far smaller. Subsystem maintainership is also, increasingly, not a job for 
volunteer developers.."


-> How do we get companies to actively sponsor subsystem maintainership - if 
only at driver or subsubsystem level.
e.g.: I unfortunately failed at that with my company :/

-> Or how can we raise more funds to sponsor subsystem maintainer ship e.g. 
via Linux Foundation. 
(so that the maintainer atleast can buy some test-hardware)



Also I would be interested in:
- What are the effects of the Eudyptula Challenge? how many people are still 
actively contributing (more than whitespace changes)
- What are the effects of the OutReachforWomen Program? how many people are 
still actively contributing (more than whitespace changes)




Nominations:
Jason Cooper           (auto-nominated), last years 'speaker'
Greg KH				please... ;-)
Little Penguin		Eudyptula
Sarah Sharp 			OPW
Peter Huewe			Caught between hobbyist maintainer and sponsored dev.
					Wants to attend a KS :)

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

[Laurent Pinchart]

Hi Peter,

On Wednesday 08 July 2015 01:21:40 Peter Huewe wrote:
> Hi,
> 
> In order to continue our traditions I would like to propose again the topic
> of recruitment, but this time not only limiting to the hobbyists market.
> 
> We are definitely short on reviewers and thus have mostly overloaded
> maintainers.

I was about to propose a related core topic.

The reviewing and maintainership process seems to have a hard time scaling to 
the amount of contributions we receive, to the point where even well known and 
respected kernel developers get discourages.

Quoting http://www.spinics.net/lists/cpufreq/msg10609.html,

--------------------------------
> I'm trying to convince management that one of the advantages
> of mainlining the port is that it is easier to switch to newer
> kernels. Do you agree with this assertion?

Yes and no.  If you can get stuff upstream, it should make things
easier.

The difficult bit - and time consuming bit - is getting code upstream.
Even in my position, I'd suggest allowing about five years for that
activity, and even then don't have expectations of getting everything
upstream.

Frankly now, my advice to people would be to just not bother, it's
*way* too much effort to get everything to an acceptable state,
especially if the SoC has no support what so ever.
--------------------------------

That's a very serious red warning in my opinion.

Throwing more maintainers, co-maintainers or sub-maintainers at the kernel 
won't magically solve this, as the more core developers a subsystem has the 
more difficult it will be for them to synchronize. I would like share 
experience about good practice rules that have proved to be effective.

> For testers it's usually even worse - how many patches are actually tested?
> Judging from what I read on LKML not that many.
> 
> So we should definitely discuss:
> - how can we encourage hobbyists to become regular contributors
> -- how to keep people interested, the drop-out rates are huge.

We can't keep people interested if even maintainers get discouraged. Solving 
(or at least relieving) that problem won't be enough to keep people 
interested, but it's a prerequisite in my opinion.

> - encourage regular contributors to become reviewers and testers
> - reviewers to become co-maintainers and finally maintainers (once the
> original maintainer is used up or moves up/on)
> 
> 
> e.g. I think in the TPM subsystem we finally reached a good status, coming
> from having no active maintainer to a having at least a part-time maintainer
> with a two steady and excellent reviewers which also test manually most of
> the stuff!
> 
> 
> 
> From the 4.1 kernel report by jon corbet:
> "over 60% of the changes going into this kernel passed through the hands of
> developers working for just five companies. This concentration reflects a
> simple fact: while many companies are willing to support developers working
> on specific tasks, the number of companies supporting subsystem maintainers
> is far smaller. Subsystem maintainership is also, increasingly, not a job
> for volunteer developers.."
> 
> 
> -> How do we get companies to actively sponsor subsystem maintainership - if
> only at driver or subsubsystem level.
> e.g.: I unfortunately failed at that with my company :/
> 
> -> Or how can we raise more funds to sponsor subsystem maintainer ship e.g.
> via Linux Foundation.
> (so that the maintainer atleast can buy some test-hardware)
> 
> 
> 
> Also I would be interested in:
> - What are the effects of the Eudyptula Challenge? how many people are still
> actively contributing (more than whitespace changes)
> - What are the effects of the OutReachforWomen Program? how many people are
> still actively contributing (more than whitespace changes)
> 
> 
> 
> 
> Nominations:
> Jason Cooper           (auto-nominated), last years 'speaker'
> Greg KH				please... ;-)
> Little Penguin		Eudyptula
> Sarah Sharp 			OPW
> Peter Huewe			Caught between hobbyist maintainer and sponsored dev.
> 					Wants to attend a KS :)

-- 
Regards,

Laurent Pinchart

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

[Guenter Roeck]

On 07/07/2015 04:49 PM, Laurent Pinchart wrote:
> Hi Peter,
>
> On Wednesday 08 July 2015 01:21:40 Peter Huewe wrote:
>> Hi,
>>
>> In order to continue our traditions I would like to propose again the topic
>> of recruitment, but this time not only limiting to the hobbyists market.
>>
>> We are definitely short on reviewers and thus have mostly overloaded
>> maintainers.
>
> I was about to propose a related core topic.
>
> The reviewing and maintainership process seems to have a hard time scaling to
> the amount of contributions we receive, to the point where even well known and
> respected kernel developers get discourages.
>
> Quoting http://www.spinics.net/lists/cpufreq/msg10609.html,
>
> --------------------------------
>> I'm trying to convince management that one of the advantages
>> of mainlining the port is that it is easier to switch to newer
>> kernels. Do you agree with this assertion?
>
> Yes and no.  If you can get stuff upstream, it should make things
> easier.
>
> The difficult bit - and time consuming bit - is getting code upstream.
> Even in my position, I'd suggest allowing about five years for that
> activity, and even then don't have expectations of getting everything
> upstream.
>
> Frankly now, my advice to people would be to just not bother, it's
> *way* too much effort to get everything to an acceptable state,
> especially if the SoC has no support what so ever.
> --------------------------------
>
> That's a very serious red warning in my opinion.
>
> Throwing more maintainers, co-maintainers or sub-maintainers at the kernel
> won't magically solve this, as the more core developers a subsystem has the
> more difficult it will be for them to synchronize. I would like share
> experience about good practice rules that have proved to be effective.
>
>> For testers it's usually even worse - how many patches are actually tested?
>> Judging from what I read on LKML not that many.
>>
>> So we should definitely discuss:
>> - how can we encourage hobbyists to become regular contributors
>> -- how to keep people interested, the drop-out rates are huge.
>
> We can't keep people interested if even maintainers get discouraged. Solving
> (or at least relieving) that problem won't be enough to keep people
> interested, but it's a prerequisite in my opinion.
>
Problem is multi-dimensional.

Every maintainer has a different style and different preferences.
Even after being a maintainer for multiple years, I find it all but
impossible to get it right for every maintainer if I submit a patch for
some random subsystem. There may be minor coding style differences,
subject line differences, or something else that is really cosmetic.
Just finding the preferences for a specific subsystem can be challenging
and time consuming.

For my part, if I get such a patch, I try to remain friendly and either
fix up whatever I dislike myself (if I have the time and it is truly cosmetic),
or I ask for a respin. Some maintainers less than friendly in such
situations, assume that everyone who doesn't know the perfect style
for a given subsystem are clueless, and respond accordingly.
Not really encouraging.

It happened several times to me that a maintainer rejected one of my patches
for less than obvious reasons. Sure, I could spend the time and try to
convince the maintainer to accept it. Unfortunately, I don't always have
the time to do that. In once recent case, where I did spend the time,
and I thought the maintainer had agreed to accept the patch, I ended up
getting an automated patchwork email telling me that the patch was
deferred indefinitely. Not really encouraging either.

Essentially it takes a lot of time by submitters to gain the trust
of maintainers - and that may even be the case if the submitter is
also a maintainer. Not everyone has that much time (and/or patience).

Is there anything we can do about that ? I honestly don't know.
I know I can be quite stubborn myself, after all, so I can't really
complain and try to take away the right of others to be just as
stubborn as I might be. After all, I don't want to be forced to
accept a patch from some other maintainer either if I think it is
wrong. But am open to suggestions.

Guenter

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

[NeilBrown]

On Tue, 07 Jul 2015 17:50:39 -0700 Guenter Roeck <linux@roeck-us.net>
wrote:

> On 07/07/2015 04:49 PM, Laurent Pinchart wrote:
> > Hi Peter,
> >
> > On Wednesday 08 July 2015 01:21:40 Peter Huewe wrote:
> >> Hi,
> >>
> >> In order to continue our traditions I would like to propose again the topic
> >> of recruitment, but this time not only limiting to the hobbyists market.
> >>
> >> We are definitely short on reviewers and thus have mostly overloaded
> >> maintainers.
> >
> > I was about to propose a related core topic.
> >
> > The reviewing and maintainership process seems to have a hard time scaling to
> > the amount of contributions we receive, to the point where even well known and
> > respected kernel developers get discourages.
> >
> > Quoting http://www.spinics.net/lists/cpufreq/msg10609.html,
> >
> > --------------------------------
> >> I'm trying to convince management that one of the advantages
> >> of mainlining the port is that it is easier to switch to newer
> >> kernels. Do you agree with this assertion?
> >
> > Yes and no.  If you can get stuff upstream, it should make things
> > easier.
> >
> > The difficult bit - and time consuming bit - is getting code upstream.
> > Even in my position, I'd suggest allowing about five years for that
> > activity, and even then don't have expectations of getting everything
> > upstream.
> >
> > Frankly now, my advice to people would be to just not bother, it's
> > *way* too much effort to get everything to an acceptable state,
> > especially if the SoC has no support what so ever.
> > --------------------------------
> >
> > That's a very serious red warning in my opinion.
> >
> > Throwing more maintainers, co-maintainers or sub-maintainers at the kernel
> > won't magically solve this, as the more core developers a subsystem has the
> > more difficult it will be for them to synchronize. I would like share
> > experience about good practice rules that have proved to be effective.
> >
> >> For testers it's usually even worse - how many patches are actually tested?
> >> Judging from what I read on LKML not that many.
> >>
> >> So we should definitely discuss:
> >> - how can we encourage hobbyists to become regular contributors
> >> -- how to keep people interested, the drop-out rates are huge.
> >
> > We can't keep people interested if even maintainers get discouraged. Solving
> > (or at least relieving) that problem won't be enough to keep people
> > interested, but it's a prerequisite in my opinion.
> >
> Problem is multi-dimensional.

Indeed!  I wonder if we can list the dimensions.

Variability: as you say, different people want different things, and
   care to different degrees about them.  'checkpatch' and
   'CodingStyle' help with some of that (though different people care
   differently about checkpatch).  Maybe the MAINTAINERS file could
   list the preferred Subject: line and checkpatch flags for each
   maintainer.  Then we just need to herd all those wild-cats towards
   updating their maintainers entry.

   I feel there is a related issue that might be called "Policy",
   though maybe it is a separate issue. There are a lot of areas where
   the "right" thing to do from a design perspective isn't really clear.
   "devicetree" "driver model" "sysfs attributes" "system call or
   virtual filesystem" "socket or char-device" all come to mind as
   being areas where different intelligent people differ.  To a large
   extent they don't really matter as long as there is consistency.
   In areas where Linus cares, he can force consistency (if he
   notices).  But I think there are a lot of areas where he doesn't
   care and so it is very hard to find something that is "right".
   If the maintainer can say "this is wrong, do it this way" then that
   is useful.  But when all they can say is "uhm. this doesn't seem
   right but I'm not really sure" it is hard to make progress.  I've
   had a couple of those recently, and could imagine myself saying that
   in some circumstances.  So: a technical committee to resolves
   unclear questions of design.  They are right, be definition, even
   when they are wrong.

Busy-ness:  maintainers are busy people.  Some tools can help with that,
   some tools can hinder it.  There is no way to find if your
   maintainer is annoyed at you or just busy (I respond much the same
   way in both conditions).  A social network tools that tells everyone
   "Neil's current state is: grumpy".

Competence:  I don't mean "in-" here.  But maintainers tend to get to
   be maintainers because they were good at something else, and not
   good enough at hiding from the "maintainer" role.  There is a
   paradox here as a maintainer must be good at saying "No", but if
   they were they might never have agreed to become a maintainer.
   Is the kernel community big enough that we need "professional
   maintainers" (other than GregKH and akpm)?  People who can sift the
   wheat for that chaff, know enough about most subsystems that they
   can make sensible comments and recommendations, and have the
   patience to shepherd things along.
   People who have the authority to bypass the technical maintainer if
   said maintainer isn't being responsive.

Other dimensions?

NeilBrown

> 
> Every maintainer has a different style and different preferences.
> Even after being a maintainer for multiple years, I find it all but
> impossible to get it right for every maintainer if I submit a patch for
> some random subsystem. There may be minor coding style differences,
> subject line differences, or something else that is really cosmetic.
> Just finding the preferences for a specific subsystem can be challenging
> and time consuming.
> 
> For my part, if I get such a patch, I try to remain friendly and either
> fix up whatever I dislike myself (if I have the time and it is truly cosmetic),
> or I ask for a respin. Some maintainers less than friendly in such
> situations, assume that everyone who doesn't know the perfect style
> for a given subsystem are clueless, and respond accordingly.
> Not really encouraging.
> 
> It happened several times to me that a maintainer rejected one of my patches
> for less than obvious reasons. Sure, I could spend the time and try to
> convince the maintainer to accept it. Unfortunately, I don't always have
> the time to do that. In once recent case, where I did spend the time,
> and I thought the maintainer had agreed to accept the patch, I ended up
> getting an automated patchwork email telling me that the patch was
> deferred indefinitely. Not really encouraging either.
> 
> Essentially it takes a lot of time by submitters to gain the trust
> of maintainers - and that may even be the case if the submitter is
> also a maintainer. Not everyone has that much time (and/or patience).
> 
> Is there anything we can do about that ? I honestly don't know.
> I know I can be quite stubborn myself, after all, so I can't really
> complain and try to take away the right of others to be just as
> stubborn as I might be. After all, I don't want to be forced to
> accept a patch from some other maintainer either if I think it is
> wrong. But am open to suggestions.
> 
> Guenter
> 
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

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

[Laurent Pinchart]

On Wednesday 08 July 2015 11:40:11 NeilBrown wrote:
> On Tue, 07 Jul 2015 17:50:39 -0700 Guenter Roeck wrote:
> > On 07/07/2015 04:49 PM, Laurent Pinchart wrote:
> >> On Wednesday 08 July 2015 01:21:40 Peter Huewe wrote:
> >>> Hi,
> >>> 
> >>> In order to continue our traditions I would like to propose again the
> >>> topic of recruitment, but this time not only limiting to the hobbyists
> >>> market.
> >>> 
> >>> We are definitely short on reviewers and thus have mostly overloaded
> >>> maintainers.
> >> 
> >> I was about to propose a related core topic.
> >> 
> >> The reviewing and maintainership process seems to have a hard time
> >> scaling to the amount of contributions we receive, to the point where
> >> even well known and respected kernel developers get discourages.
> >> 
> >> Quoting http://www.spinics.net/lists/cpufreq/msg10609.html,
> >> 
> >> --------------------------------
> >> 
> >>> I'm trying to convince management that one of the advantages
> >>> of mainlining the port is that it is easier to switch to newer
> >>> kernels. Do you agree with this assertion?
> >> 
> >> Yes and no.  If you can get stuff upstream, it should make things
> >> easier.
> >> 
> >> The difficult bit - and time consuming bit - is getting code upstream.
> >> Even in my position, I'd suggest allowing about five years for that
> >> activity, and even then don't have expectations of getting everything
> >> upstream.
> >> 
> >> Frankly now, my advice to people would be to just not bother, it's
> >> *way* too much effort to get everything to an acceptable state,
> >> especially if the SoC has no support what so ever.
> >> --------------------------------
> >> 
> >> That's a very serious red warning in my opinion.
> >> 
> >> Throwing more maintainers, co-maintainers or sub-maintainers at the
> >> kernel won't magically solve this, as the more core developers a
> >> subsystem has the more difficult it will be for them to synchronize. I
> >> would like share experience about good practice rules that have proved to
> >> be effective.
> >> 
> >>> For testers it's usually even worse - how many patches are actually
> >>> tested? Judging from what I read on LKML not that many.
> >>> 
> >>> So we should definitely discuss:
> >>> - how can we encourage hobbyists to become regular contributors
> >>> -- how to keep people interested, the drop-out rates are huge.
> >> 
> >> We can't keep people interested if even maintainers get discouraged.
> >> Solving (or at least relieving) that problem won't be enough to keep
> >> people interested, but it's a prerequisite in my opinion.
> > 
> > Problem is multi-dimensional.
> 
> Indeed!  I wonder if we can list the dimensions.
> 
> Variability: as you say, different people want different things, and
>    care to different degrees about them.  'checkpatch' and
>    'CodingStyle' help with some of that (though different people care
>    differently about checkpatch).  Maybe the MAINTAINERS file could
>    list the preferred Subject: line and checkpatch flags for each
>    maintainer.  Then we just need to herd all those wild-cats towards
>    updating their maintainers entry.

I've seen maintainers who want to be CC'ed on every patch touching their 
subsystem, and others who prefer patches being sent to the mailing list only. 
That would be easy to express in MAINTAINERS and would already help in two 
fronts. It would lower the amount of noise for maintainers who base their work 
flow on mailing lists. It would also remove the need for submitters to decide 
whether to CC maintainers and prevent patches from falling through cracks when 
the decision is incorrect.

>    I feel there is a related issue that might be called "Policy",
>    though maybe it is a separate issue. There are a lot of areas where
>    the "right" thing to do from a design perspective isn't really clear.
>    "devicetree" "driver model" "sysfs attributes" "system call or
>    virtual filesystem" "socket or char-device" all come to mind as
>    being areas where different intelligent people differ.  To a large
>    extent they don't really matter as long as there is consistency.
>    In areas where Linus cares, he can force consistency (if he
>    notices).  But I think there are a lot of areas where he doesn't
>    care and so it is very hard to find something that is "right".
>    If the maintainer can say "this is wrong, do it this way" then that
>    is useful.  But when all they can say is "uhm. this doesn't seem
>    right but I'm not really sure" it is hard to make progress.  I've
>    had a couple of those recently, and could imagine myself saying that
>    in some circumstances.  So: a technical committee to resolves
>    unclear questions of design.  They are right, be definition, even
>    when they are wrong.

Maintainers are already busy as it is, I can't imagine how a technical 
committee could scale. We tried it for device tree bindings by appointing DT 
maintainers, and we can't really say it was a success.

I don't see anything seriously wrong with maintainers being honest and telling 
they don't know. Sometimes a task requires getting off the beaten tracks, 
that's just the way it is. Maintainers are not supposed to have answers for 
every question.

What bothers me more is the situation where patches get submitted, reviewed 
and updated several times, and then another developer notices the activity and 
requests a completely different approach. If that approach is bogus it's easy 
to dismiss it, but if it isn't the submitter will quite often get discouraged, 
and time will be wasted. I wonder if we could improve that situation, maybe 
with mechanisms that would make it easier for developers/reviewers to notice 
development activities they care about. I doubt I'm the only one who can't 
find time to follow all the mailing lists relevant to the subsystems I work 
with.

> Busy-ness:  maintainers are busy people.  Some tools can help with that,
>    some tools can hinder it.  There is no way to find if your
>    maintainer is annoyed at you or just busy (I respond much the same
>    way in both conditions).  A social network tools that tells everyone
>    "Neil's current state is: grumpy".

Would you really update that status when you get grumpy ? Maybe we need a 
brain reading device to automate the process ;-)

> Competence:  I don't mean "in-" here.  But maintainers tend to get to
>    be maintainers because they were good at something else, and not
>    good enough at hiding from the "maintainer" role.  There is a
>    paradox here as a maintainer must be good at saying "No", but if
>    they were they might never have agreed to become a maintainer.
>    Is the kernel community big enough that we need "professional
>    maintainers" (other than GregKH and akpm)?  People who can sift the
>    wheat for that chaff, know enough about most subsystems that they
>    can make sensible comments and recommendations, and have the
>    patience to shepherd things along.
>    People who have the authority to bypass the technical maintainer if
>    said maintainer isn't being responsive.
> 
> Other dimensions?
> 
> NeilBrown
> 
> > Every maintainer has a different style and different preferences.
> > Even after being a maintainer for multiple years, I find it all but
> > impossible to get it right for every maintainer if I submit a patch for
> > some random subsystem. There may be minor coding style differences,
> > subject line differences, or something else that is really cosmetic.
> > Just finding the preferences for a specific subsystem can be challenging
> > and time consuming.
> > 
> > For my part, if I get such a patch, I try to remain friendly and either
> > fix up whatever I dislike myself (if I have the time and it is truly
> > cosmetic), or I ask for a respin. Some maintainers less than friendly in
> > such situations, assume that everyone who doesn't know the perfect style
> > for a given subsystem are clueless, and respond accordingly.
> > Not really encouraging.
> > 
> > It happened several times to me that a maintainer rejected one of my
> > patches for less than obvious reasons. Sure, I could spend the time and
> > try to convince the maintainer to accept it. Unfortunately, I don't
> > always have the time to do that. In once recent case, where I did spend
> > the time, and I thought the maintainer had agreed to accept the patch, I
> > ended up getting an automated patchwork email telling me that the patch
> > was deferred indefinitely. Not really encouraging either.
> > 
> > Essentially it takes a lot of time by submitters to gain the trust
> > of maintainers - and that may even be the case if the submitter is
> > also a maintainer. Not everyone has that much time (and/or patience).
> > 
> > Is there anything we can do about that ? I honestly don't know.
> > I know I can be quite stubborn myself, after all, so I can't really
> > complain and try to take away the right of others to be just as
> > stubborn as I might be. After all, I don't want to be forced to
> > accept a patch from some other maintainer either if I think it is
> > wrong. But am open to suggestions.

-- 
Regards,

Laurent Pinchart

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

[Darren Hart]

On Wed, Jul 08, 2015 at 10:45:28PM +0300, Laurent Pinchart wrote:
> On Wednesday 08 July 2015 11:40:11 NeilBrown wrote:
> > On Tue, 07 Jul 2015 17:50:39 -0700 Guenter Roeck wrote:
> > > On 07/07/2015 04:49 PM, Laurent Pinchart wrote:
> > >> On Wednesday 08 July 2015 01:21:40 Peter Huewe wrote:
> > >>> Hi,
> > >>> 
> > >>> In order to continue our traditions I would like to propose again the
> > >>> topic of recruitment, but this time not only limiting to the hobbyists
> > >>> market.
> > >>> 
> > >>> We are definitely short on reviewers and thus have mostly overloaded
> > >>> maintainers.
> > >> 
> > >> I was about to propose a related core topic.
> > >> 
> > >> The reviewing and maintainership process seems to have a hard time
> > >> scaling to the amount of contributions we receive, to the point where
> > >> even well known and respected kernel developers get discourages.
> > >> 
> > >> Quoting http://www.spinics.net/lists/cpufreq/msg10609.html,
> > >> 
> > >> --------------------------------
> > >> 
> > >>> I'm trying to convince management that one of the advantages
> > >>> of mainlining the port is that it is easier to switch to newer
> > >>> kernels. Do you agree with this assertion?
> > >> 
> > >> Yes and no.  If you can get stuff upstream, it should make things
> > >> easier.
> > >> 
> > >> The difficult bit - and time consuming bit - is getting code upstream.
> > >> Even in my position, I'd suggest allowing about five years for that
> > >> activity, and even then don't have expectations of getting everything
> > >> upstream.
> > >> 
> > >> Frankly now, my advice to people would be to just not bother, it's
> > >> *way* too much effort to get everything to an acceptable state,
> > >> especially if the SoC has no support what so ever.
> > >> --------------------------------
> > >> 
> > >> That's a very serious red warning in my opinion.
> > >> 
> > >> Throwing more maintainers, co-maintainers or sub-maintainers at the
> > >> kernel won't magically solve this, as the more core developers a
> > >> subsystem has the more difficult it will be for them to synchronize. I
> > >> would like share experience about good practice rules that have proved to
> > >> be effective.
> > >> 
> > >>> For testers it's usually even worse - how many patches are actually
> > >>> tested? Judging from what I read on LKML not that many.
> > >>> 
> > >>> So we should definitely discuss:
> > >>> - how can we encourage hobbyists to become regular contributors
> > >>> -- how to keep people interested, the drop-out rates are huge.
> > >> 
> > >> We can't keep people interested if even maintainers get discouraged.
> > >> Solving (or at least relieving) that problem won't be enough to keep
> > >> people interested, but it's a prerequisite in my opinion.
> > > 
> > > Problem is multi-dimensional.
> > 
> > Indeed!  I wonder if we can list the dimensions.
> > 
> > Variability: as you say, different people want different things, and
> >    care to different degrees about them.  'checkpatch' and
> >    'CodingStyle' help with some of that (though different people care
> >    differently about checkpatch).  Maybe the MAINTAINERS file could
> >    list the preferred Subject: line and checkpatch flags for each
> >    maintainer.  Then we just need to herd all those wild-cats towards
> >    updating their maintainers entry.
> 
> I've seen maintainers who want to be CC'ed on every patch touching their 
> subsystem, and others who prefer patches being sent to the mailing list only. 
> That would be easy to express in MAINTAINERS and would already help in two 
> fronts. It would lower the amount of noise for maintainers who base their work 
> flow on mailing lists. It would also remove the need for submitters to decide 
> whether to CC maintainers and prevent patches from falling through cracks when 
> the decision is incorrect.

I've come to believe that this is one of many side effects of our dependency on
a completely free form mechanism for the management of our patches, a mechanism
which is becoming harder and harder to setup "correctly" with modern tooling
(since the industry is killing "real email").

I spend a highly disproportionate amount of my time, relative to measurable
quality impact to the kernel, going over the nuances of submitting patches.

1) Must have a complete commit message
2) DCO goes above the ---
3) Include a patch changelog, do so below ---
4) Cc maintainers :-)
5) Checkpatch... checkpatch... checkpatch...
6) Compiler warnings
7) CodingStyle :-)
8) Use ascii or utf8 character encodings

All of these are distractions from reviewing the code. I'm often on version 3 of
a series before I'm actually reviewing content.

I raised this in Dusseldorf with the PREEMPT_RT crowd, and I'll do so here too,
although I suspect it will be met with quite a bit of opposition. I believe our
tooling and processes are good at helping our top level maintainers scale -
which is absolutely critical to the success of Linux - but they inhibit scaling
out and attracting new developers, reviewers, etc.

Our most productive maintainers and contributors, in my understanding, often are
able to spend most of their time on their upstream Linux kernel work. They have
been doing it for a decade or more and have a lot of custom written tools to
help make the processes scale for their particular needs. This is great!

However, we have a lot of tribal knowledge regarding how to interact
successfully with the development model. So much so that many of our lesser
maintainers (like myself) spend a lot of our time as a bridge or proxy to
upstream development, which is too opaque and even enigmatic for them to get
into.

To be a successful contributor, a developer can't just be a capable C developer
with a deep knowledge of their particular product and the surrounding
subsystems, they also have to setup all kinds of email tooling which is harder
and harder to do every year. These tools are typically special-purpose for Linux
development because their corporate solution is incompatible. I just spent a day
writing perl scripts to test my email against vger's silent drop policies and
bisecting the delta between mutt and my git request-pull based automatically
generated email to discover the missing header required for vger to deliver my
pull requests to the list. Developers need to be RFC 2822 savvy and have a
rather deep understanding of SMTP, procmail. Combine that with an infinite
number of ways to accidentally annoy people on the list, from character
encoding, content-type, line length, etc. and the new developer who likely has
many other responsibilities beyond upstreaming their code or reviewing
someone else's code, has a lot of obstacles to overcome that have nothing to do
with the code in question.

While I once found our process to be a measure of the exacting quality of the
Linux kernel development process, I am coming to view it as an obstacle to
scaling out.

I am looking to make some changes in my subsystem. I've requested patchwork to
be enabled, and I'll create a for-review branch and solicit help there. I
already leverage 0-day, but I think it would be great to have something which
parses patches submitted to LKML and tests the 8 items above and more and
automatically responds to the submitter. Nobody should have to spend their time
on those things.

Looking forward a bit, I would love to see some tooling in place for people to
submit patches either via a web form (which eliminates all the email tooling for
submitting patches - which is where the formatting is especially critical) or
through one of the more managed git systems, like gerrit, etc.

I suspect this won't be a particularly popular view, but I spend enough time as
a proxy for competant developers for whom the existing processes are a major
obstacle to getting fully involved, that I think it's worth raising them.

Sorry Laurant, perhaps this should have been a new topic - but I think it fits
with the recruitment subject.

-- 
Darren Hart
Intel Open Source Technology Center

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

[josh]

On Thu, Jul 09, 2015 at 12:37:18PM -0700, Darren Hart wrote:
> On Wed, Jul 08, 2015 at 10:45:28PM +0300, Laurent Pinchart wrote:
> > On Wednesday 08 July 2015 11:40:11 NeilBrown wrote:
> > > Indeed!  I wonder if we can list the dimensions.
> > > 
> > > Variability: as you say, different people want different things, and
> > >    care to different degrees about them.  'checkpatch' and
> > >    'CodingStyle' help with some of that (though different people care
> > >    differently about checkpatch).  Maybe the MAINTAINERS file could
> > >    list the preferred Subject: line and checkpatch flags for each
> > >    maintainer.  Then we just need to herd all those wild-cats towards
> > >    updating their maintainers entry.
> > 
> > I've seen maintainers who want to be CC'ed on every patch touching their 
> > subsystem, and others who prefer patches being sent to the mailing list only. 
> > That would be easy to express in MAINTAINERS and would already help in two 
> > fronts. It would lower the amount of noise for maintainers who base their work 
> > flow on mailing lists. It would also remove the need for submitters to decide 
> > whether to CC maintainers and prevent patches from falling through cracks when 
> > the decision is incorrect.
> 
> I've come to believe that this is one of many side effects of our dependency on
> a completely free form mechanism for the management of our patches, a mechanism
> which is becoming harder and harder to setup "correctly" with modern tooling
> (since the industry is killing "real email").
> 
> I spend a highly disproportionate amount of my time, relative to measurable
> quality impact to the kernel, going over the nuances of submitting patches.
> 
> 1) Must have a complete commit message
> 2) DCO goes above the ---
> 3) Include a patch changelog, do so below ---
> 4) Cc maintainers :-)
> 5) Checkpatch... checkpatch... checkpatch...
> 6) Compiler warnings
> 7) CodingStyle :-)
> 8) Use ascii or utf8 character encodings
> 
> All of these are distractions from reviewing the code. I'm often on version 3 of
> a series before I'm actually reviewing content.
> 
> I raised this in Dusseldorf with the PREEMPT_RT crowd, and I'll do so here too,
> although I suspect it will be met with quite a bit of opposition. I believe our
> tooling and processes are good at helping our top level maintainers scale -
> which is absolutely critical to the success of Linux - but they inhibit scaling
> out and attracting new developers, reviewers, etc.
> 
> Our most productive maintainers and contributors, in my understanding, often are
> able to spend most of their time on their upstream Linux kernel work. They have
> been doing it for a decade or more and have a lot of custom written tools to
> help make the processes scale for their particular needs. This is great!
> 
> However, we have a lot of tribal knowledge regarding how to interact
> successfully with the development model. So much so that many of our lesser
> maintainers (like myself) spend a lot of our time as a bridge or proxy to
> upstream development, which is too opaque and even enigmatic for them to get
> into.
[...]
> I am looking to make some changes in my subsystem. I've requested patchwork to
> be enabled, and I'll create a for-review branch and solicit help there. I
> already leverage 0-day, but I think it would be great to have something which
> parses patches submitted to LKML and tests the 8 items above and more and
> automatically responds to the submitter. Nobody should have to spend their time
> on those things.
> 
> Looking forward a bit, I would love to see some tooling in place for people to
> submit patches either via a web form (which eliminates all the email tooling for
> submitting patches - which is where the formatting is especially critical) or
> through one of the more managed git systems, like gerrit, etc.

I would love to see this.  I don't think it makes sense for the flow
from subsystem maintainers to Linus or similar to use these tools;
anyone capable of saying "please pull" *probably* doesn't need most of
this.  However, for people who primarily interact with maintainers via
patch mails, some kind of automated CI bot, integrated with Gerrit or
github or similar, would filter out a substantial number of painful bits
before they show up.

Consider a set of scripts or services that could easily be wired into
either a Gerrit install or a GitHub hook, so that rather than spending
time sorting out SMTP and basic patch formatting, people could git push
to a repository branch they control, get automated feedback on what
needs fixing, and when all of the mechanical issues are sorted out that
same service can help them send a properly formatted mail series (with
cover letter) to the right set of people.

It would take some work to initially set up, but the result should
actually save maintainer time by avoiding the need to comment on
mechanical correctness issues.

That same bot could fairly easily be wired to a "test" mailing list,
capturing mailed patch series and running them through the same tests,
so that people comfortable with the email part of the workflow could
mail patches to that list to have them automatically checked *before*
mailing LKML.  And unlike mailing LKML, there would be no stigma
attached to iterating and sending multiple mails to that list while
trying to get the details right.

Bonus if this is also wired into the 0day bot, so that you also find out
if you introduce a new warning or error.

- Josh Triplett

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

[Luis R. Rodriguez]

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 make the 0-day-bot chain only do sensible things. My undestanding
is that the 0-day bot now has Coccinelle integration though, not so sure
of the rest, if the pipline is already set up then the auto-patch-merging
is the only next step needed, can patchwork do that for some subsystem
already set up ? It should just be a matter of adding a git repo and
adding it to the list of 0-day bot git repos.

 Luis

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

[josh]

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".

- Josh Triplett

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

[Luis R. Rodriguez]

On Thu, Jul 09, 2015 at 02:00:59PM -0700, 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".

Yeah true, Fengguang, is that an option?

  Luis

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

[Luck, Tony]

>> 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".
>
> Yeah true, Fengguang, is that an option?

But you save some compute cycles on Fengguang's farm for serializing the
process for developers.  Letting the robots try some compilations may find
some more issues with the patch series.

-Tony

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

[Fengguang Wu]

On Thu, Jul 09, 2015 at 11:03:00PM +0200, Luis R. Rodriguez wrote:
> On Thu, Jul 09, 2015 at 02:00:59PM -0700, 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".
> 
> Yeah true, Fengguang, is that an option?

Never mind, 0-day is powerful enough to do full-scale testing for
early stage branches and expose as much errors as possible in one
iteration.

Thanks,
Fengguang

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

[Julia Lawall]

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?

julia

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

[David Woodhouse]

On Thu, 2015-07-09 at 17:24 -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 w
> > > rote:
> > > > 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 we're talking about encouraging new contributors, then probably not.

You don't necessarily want a lot of negative feedback from different
places, all at once.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

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

[josh]

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.

- Josh Triplett

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

[Luis R. Rodriguez]

On Thu, Jul 9, 2015 at 4:11 PM,  <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.

I'm not being empathetic towards machines as they are not [yet]
sentient, but has anyone estimated the average cost of a full 0-day
test cycle on a full kernel tree? I'm all for using machines when
available to due our bidding, but I was simply trying to consider how
we can be more efficient about it. That's all.

 Luis

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

[Julia Lawall]

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.

julia

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

[josh]

On Thu, Jul 09, 2015 at 07:35:39PM -0400, 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.

Fair enough.  Might as well go ahead with the full battery unless it
becomes a problem.

- Josh Triplett

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

[Laurent Pinchart]

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

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

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 991 bytes --]

On Mon, 2015-07-13 at 00:44 +0300, Laurent Pinchart wrote:
> 
> 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 [...]"

Yeah, at the moment I believe 'unacceptable' mail to vger lists just
gets black-holed. Leaving users wondering WTF they did wrong. Or just
wondering why they didn't get any responses.

It would be much nicer to do the same tests at SMTP time, giving the
rejection immediately.

-- 
dwmw2


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

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

[James Bottomley]

[-- Attachment #1: Type: text/plain, Size: 1460 bytes --]

On Thu, 2015-07-16 at 10:21 +0100, David Woodhouse wrote:
> On Mon, 2015-07-13 at 00:44 +0300, Laurent Pinchart wrote:
> > 
> > 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 [...]"
> 
> Yeah, at the moment I believe 'unacceptable' mail to vger lists just
> gets black-holed. Leaving users wondering WTF they did wrong. Or just
> wondering why they didn't get any responses.
> 
> It would be much nicer to do the same tests at SMTP time, giving the
> rejection immediately.

I'll let DaveM speak for himself on vger, but the reason I don't do this
type of thing at SMTP time is that it holds the connections open and you
can easily swamp the system.  If you queue the scans, you have a much
tighter control on your machine load (admittedly my "cloud" system is
still a single processor i586 so I might be slightly behind the
technology curve).

James


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5819 bytes --]

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

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1555 bytes --]

On Thu, 2015-07-16 at 12:26 +0300, James Bottomley wrote:
> > Yeah, at the moment I believe 'unacceptable' mail to vger lists just
> > gets black-holed. Leaving users wondering WTF they did wrong. Or just
> > wondering why they didn't get any responses.
> > 
> > It would be much nicer to do the same tests at SMTP time, giving the
> > rejection immediately.
> 
> I'll let DaveM speak for himself on vger, but the reason I don't do this
> type of thing at SMTP time is that it holds the connections open and you
> can easily swamp the system.  If you queue the scans, you have a much
> tighter control on your machine load (admittedly my "cloud" system is
> still a single processor i586 so I might be slightly behind the
> technology curve).

It's no *additional* work; the scanning was being done anyway. Yes, it
means you keep a TCP socket open while you do the scan. But that really
shouldn't be a big resource issue.

If the machine is overloaded, it can stop taking incoming connections
or it can slow them down. Both of which will happen naturally. The
overall result will be that there's a slight delay, and it accepts the
mail later instead. Which is basically the same as if the message is
queued and processed later.

Besides, I believe most of the scans we're talking about¹ are simple
regex stuff and just shouldn't take that long anyway. Although many
people *do* run things like CRM114/ClamAV/SpamAssassin a SMTP time,
even on i586-class machines.


-- 
dwmw2
¹ http://vger.kernel.org/majordomo-taboos.txt

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

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

[Peter Huewe]

Am 16. Juli 2015 11:21:37 MESZ, schrieb David Woodhouse <dwmw2@infradead.org>:
>On Mon, 2015-07-13 at 00:44 +0300, Laurent Pinchart wrote:
>> 
>> 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 [...]"
>
>Yeah, at the moment I believe 'unacceptable' mail to vger lists just
>gets black-holed. Leaving users wondering WTF they did wrong. Or just
>wondering why they didn't get any responses.
>
I don't think so, at least when I got my new phone and was replying to some mails I did get some "you are sending HTML spam" message back.
( as HTML used to be the default setting :/ )

Peter

-- 
Sent from my mobile

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

[Fengguang Wu]

On Thu, Jul 09, 2015 at 04:11:31PM -0700, 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.

0-day has good enough bandwidth, now and future. :)

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

0-day can reasonably handle that kind of load. Feel free to push code
10 times per day. It'll run all build/boot tests on the latest branch
HEAD until test completion or new HEAD arrives.

Thanks,
Fengguang

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

[Peter Huewe]

Am 9. Juli 2015 23:00:59 MESZ, schrieb josh@joshtriplett.org:
>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".


0-day already includes sparse, coccinelle and smatch ;) (and others)

I have a dedicated for-review and testing branch which is 0-day monitored and only if I don't hear negative from 0-day stuff moves to my -next branch.

Thanks
Peter
-- 
Sent from my mobile

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

[Luck, Tony]

> I have a dedicated for-review and testing branch which is 0-day monitored and only if I don't hear negative from 0-day stuff moves to my -next branch.

If you ask Fengguang nicely he can mark that branch so the robots will send a successful
completion e-mail ... that way you don't have to guess how long to wait for the robots
to get around to your branch.

-Tony

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

[James Bottomley]

On Thu, 2015-07-09 at 14:00 -0700, 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".

We already have this with the 0 day project.  The only difference being
the patch has to be in a tree for it to get tested.  It's not impossible
to imagine a bot that would pick up a patch, apply it (giving automated
rejects as email replies), and leave it in for the 0 day tests to
assess ... sort of like patchwork but with an automated tree build.   We
could periodically throw away the tree (say weekly) because the job of
the bot would be to find initial rejects rather than build a workable
tree.

James

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

[Fengguang Wu]

On Fri, Jul 10, 2015 at 09:54:42AM +0100, James Bottomley wrote:
> On Thu, 2015-07-09 at 14:00 -0700, 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".
> 
> We already have this with the 0 day project.  The only difference being
> the patch has to be in a tree for it to get tested.  It's not impossible
> to imagine a bot that would pick up a patch, apply it (giving automated
> rejects as email replies), and leave it in for the 0 day tests to
> assess ... sort of like patchwork but with an automated tree build.   We
> could periodically throw away the tree (say weekly) because the job of
> the bot would be to find initial rejects rather than build a workable
> tree.

That's a good point. Up to now 0-day only takes care of code in git trees.
We've collected 500+ developers' git trees so far, however their coverage
looks not enough -- there are 3000+ kernel developers in last year's git log.

To achieve 100% code coverage, we'll also need to watch emails in the
kernel mailing lists, auto convert patch series there to git branches
for 0-day and other testers, and auto reply results to the original
mailing list's email thread.

That would be a natural fit for the email based patch submission path
and review process.

The potential problem, however, is "git-am to which base branch?"
That's where it may go messy.

Thanks,
Fengguang

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

[Josh Triplett]

On Sun, Jul 12, 2015 at 10:02:35AM +0800, Fengguang Wu wrote:
> On Fri, Jul 10, 2015 at 09:54:42AM +0100, James Bottomley wrote:
> > On Thu, 2015-07-09 at 14:00 -0700, 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".
> > 
> > We already have this with the 0 day project.  The only difference being
> > the patch has to be in a tree for it to get tested.  It's not impossible
> > to imagine a bot that would pick up a patch, apply it (giving automated
> > rejects as email replies), and leave it in for the 0 day tests to
> > assess ... sort of like patchwork but with an automated tree build.   We
> > could periodically throw away the tree (say weekly) because the job of
> > the bot would be to find initial rejects rather than build a workable
> > tree.
> 
> That's a good point. Up to now 0-day only takes care of code in git trees.
> We've collected 500+ developers' git trees so far, however their coverage
> looks not enough -- there are 3000+ kernel developers in last year's git log.
> 
> To achieve 100% code coverage, we'll also need to watch emails in the
> kernel mailing lists, auto convert patch series there to git branches
> for 0-day and other testers, and auto reply results to the original
> mailing list's email thread.
> 
> That would be a natural fit for the email based patch submission path
> and review process.
> 
> The potential problem, however, is "git-am to which base branch?"
> That's where it may go messy.

Patch submitters should be making it clear to what tree their patch
applies, preferably using an unambiguous tag in the mail subject.  In
the absence of such a tag, try it against torvalds/linux.git and
linux-next.git, and then give up and tell the submitter to specify what
their patch applies to.

- Josh Triplett

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

[James Bottomley]

On Sat, 2015-07-11 at 22:19 -0700, Josh Triplett wrote:
> On Sun, Jul 12, 2015 at 10:02:35AM +0800, Fengguang Wu wrote:
> > On Fri, Jul 10, 2015 at 09:54:42AM +0100, James Bottomley wrote:
> > > On Thu, 2015-07-09 at 14:00 -0700, 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".
> > > 
> > > We already have this with the 0 day project.  The only difference being
> > > the patch has to be in a tree for it to get tested.  It's not impossible
> > > to imagine a bot that would pick up a patch, apply it (giving automated
> > > rejects as email replies), and leave it in for the 0 day tests to
> > > assess ... sort of like patchwork but with an automated tree build.   We
> > > could periodically throw away the tree (say weekly) because the job of
> > > the bot would be to find initial rejects rather than build a workable
> > > tree.
> > 
> > That's a good point. Up to now 0-day only takes care of code in git trees.
> > We've collected 500+ developers' git trees so far, however their coverage
> > looks not enough -- there are 3000+ kernel developers in last year's git log.
> > 
> > To achieve 100% code coverage, we'll also need to watch emails in the
> > kernel mailing lists, auto convert patch series there to git branches
> > for 0-day and other testers, and auto reply results to the original
> > mailing list's email thread.
> > 
> > That would be a natural fit for the email based patch submission path
> > and review process.
> > 
> > The potential problem, however, is "git-am to which base branch?"
> > That's where it may go messy.
> 
> Patch submitters should be making it clear to what tree their patch
> applies, preferably using an unambiguous tag in the mail subject.  In
> the absence of such a tag, try it against torvalds/linux.git and
> linux-next.git, and then give up and tell the submitter to specify what
> their patch applies to.

To be honest, the mailing list it's sent to mostly identifies which tree
it should be going in.  There's difficulty over whether the for next or
for current branches ... but we have that today as well.

James

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

[Fengguang Wu]

On Sun, Jul 12, 2015 at 09:19:53AM +0100, James Bottomley wrote:
> On Sat, 2015-07-11 at 22:19 -0700, Josh Triplett wrote:
> > On Sun, Jul 12, 2015 at 10:02:35AM +0800, Fengguang Wu wrote:
> > > On Fri, Jul 10, 2015 at 09:54:42AM +0100, James Bottomley wrote:
> > > > On Thu, 2015-07-09 at 14:00 -0700, 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".
> > > > 
> > > > We already have this with the 0 day project.  The only difference being
> > > > the patch has to be in a tree for it to get tested.  It's not impossible
> > > > to imagine a bot that would pick up a patch, apply it (giving automated
> > > > rejects as email replies), and leave it in for the 0 day tests to
> > > > assess ... sort of like patchwork but with an automated tree build.   We
> > > > could periodically throw away the tree (say weekly) because the job of
> > > > the bot would be to find initial rejects rather than build a workable
> > > > tree.
> > > 
> > > That's a good point. Up to now 0-day only takes care of code in git trees.
> > > We've collected 500+ developers' git trees so far, however their coverage
> > > looks not enough -- there are 3000+ kernel developers in last year's git log.
> > > 
> > > To achieve 100% code coverage, we'll also need to watch emails in the
> > > kernel mailing lists, auto convert patch series there to git branches
> > > for 0-day and other testers, and auto reply results to the original
> > > mailing list's email thread.
> > > 
> > > That would be a natural fit for the email based patch submission path
> > > and review process.
> > > 
> > > The potential problem, however, is "git-am to which base branch?"
> > > That's where it may go messy.
> > 
> > Patch submitters should be making it clear to what tree their patch
> > applies, preferably using an unambiguous tag in the mail subject.  In
> > the absence of such a tag, try it against torvalds/linux.git and
> > linux-next.git, and then give up and tell the submitter to specify what
> > their patch applies to.
> 
> To be honest, the mailing list it's sent to mostly identifies which tree
> it should be going in.  There's difficulty over whether the for next or
> for current branches ... but we have that today as well.

Yes, mailing list would be a very good hint.

Another clue can be the index part of all git emails

        diff --git a/Makefile b/Makefile
==>     index 3ba5044..f5c8983 100644
        --- a/Makefile
        +++ b/Makefile

That object id may help identify the possible BASE branches for the
email patch. Due to my limited knowledge of git, I can only think
about a brutal force (but still affordable) way to iterate all the
well known branches to find the possible BASE branches.

Thanks,
Fengguang

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

[Josh Triplett]

On Sun, Jul 12, 2015 at 06:48:07PM +0800, Fengguang Wu wrote:
> On Sun, Jul 12, 2015 at 09:19:53AM +0100, James Bottomley wrote:
> > On Sat, 2015-07-11 at 22:19 -0700, Josh Triplett wrote:
> > > On Sun, Jul 12, 2015 at 10:02:35AM +0800, Fengguang Wu wrote:
> > > > On Fri, Jul 10, 2015 at 09:54:42AM +0100, James Bottomley wrote:
> > > > > On Thu, 2015-07-09 at 14:00 -0700, 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".
> > > > > 
> > > > > We already have this with the 0 day project.  The only difference being
> > > > > the patch has to be in a tree for it to get tested.  It's not impossible
> > > > > to imagine a bot that would pick up a patch, apply it (giving automated
> > > > > rejects as email replies), and leave it in for the 0 day tests to
> > > > > assess ... sort of like patchwork but with an automated tree build.   We
> > > > > could periodically throw away the tree (say weekly) because the job of
> > > > > the bot would be to find initial rejects rather than build a workable
> > > > > tree.
> > > > 
> > > > That's a good point. Up to now 0-day only takes care of code in git trees.
> > > > We've collected 500+ developers' git trees so far, however their coverage
> > > > looks not enough -- there are 3000+ kernel developers in last year's git log.
> > > > 
> > > > To achieve 100% code coverage, we'll also need to watch emails in the
> > > > kernel mailing lists, auto convert patch series there to git branches
> > > > for 0-day and other testers, and auto reply results to the original
> > > > mailing list's email thread.
> > > > 
> > > > That would be a natural fit for the email based patch submission path
> > > > and review process.
> > > > 
> > > > The potential problem, however, is "git-am to which base branch?"
> > > > That's where it may go messy.
> > > 
> > > Patch submitters should be making it clear to what tree their patch
> > > applies, preferably using an unambiguous tag in the mail subject.  In
> > > the absence of such a tag, try it against torvalds/linux.git and
> > > linux-next.git, and then give up and tell the submitter to specify what
> > > their patch applies to.
> > 
> > To be honest, the mailing list it's sent to mostly identifies which tree
> > it should be going in.  There's difficulty over whether the for next or
> > for current branches ... but we have that today as well.
> 
> Yes, mailing list would be a very good hint.
> 
> Another clue can be the index part of all git emails
> 
>         diff --git a/Makefile b/Makefile
> ==>     index 3ba5044..f5c8983 100644
>         --- a/Makefile
>         +++ b/Makefile
> 
> That object id may help identify the possible BASE branches for the
> email patch. Due to my limited knowledge of git, I can only think
> about a brutal force (but still affordable) way to iterate all the
> well known branches to find the possible BASE branches.

That's a good idea.

- Josh Triplett

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 602 bytes --]

On Sat, Jul 11, 2015 at 10:19:58PM -0700, Josh Triplett wrote:

> Patch submitters should be making it clear to what tree their patch
> applies, preferably using an unambiguous tag in the mail subject.  In
> the absence of such a tag, try it against torvalds/linux.git and
> linux-next.git, and then give up and tell the submitter to specify what
> their patch applies to.

This does get complicated rapidly when people have trees with multiple
branches, or when people start basing work on other pending serieses.
It's easy to indicate, but doing so in a way that a machine can cope
with gets harder.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Steven Rostedt]

On Thu, 9 Jul 2015 14:00:59 -0700
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".
> 

Please don't! I use the 0day bot for testing various patches that I'm
experimenting with. These patches are very much not in complete form.
When they pass all my tests (and the 0day bot tests), I then start the
formal process of turning them into submittable patches.

-- Steve

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

[Josh Triplett]

On Fri, Jul 10, 2015 at 11:32:47AM -0400, Steven Rostedt wrote:
> On Thu, 9 Jul 2015 14:00:59 -0700
> 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".
> > 
> 
> Please don't! I use the 0day bot for testing various patches that I'm
> experimenting with. These patches are very much not in complete form.
> When they pass all my tests (and the 0day bot tests), I then start the
> formal process of turning them into submittable patches.

To clarify, I wasn't suggesting that 0-day do that in general; I was
suggesting that it *might* make sense for an automatic testing bot for
potentially malformed submissions to an automated test address might not
want to waste time running dozens of builds on something that doesn't
meet basic sanity checks.

Along the same lines, there's little point testing if something builds
on a dozen architectures if it doesn't even build on x86.

But perhaps the latter filter makes more sense than the former, and it'd
be more helpful to give people all the feedback at once, for the same
reason GCC doesn't stop at the first error.

- Josh Triplett

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

[Darren Hart]

On Thu, Jul 09, 2015 at 01:11:27PM -0700, Josh Triplett wrote:
> On Thu, Jul 09, 2015 at 12:37:18PM -0700, Darren Hart wrote:
> > On Wed, Jul 08, 2015 at 10:45:28PM +0300, Laurent Pinchart wrote:
> > > On Wednesday 08 July 2015 11:40:11 NeilBrown wrote:
> > > > Indeed!  I wonder if we can list the dimensions.
> > > > 
> > > > Variability: as you say, different people want different things, and
> > > >    care to different degrees about them.  'checkpatch' and
> > > >    'CodingStyle' help with some of that (though different people care
> > > >    differently about checkpatch).  Maybe the MAINTAINERS file could
> > > >    list the preferred Subject: line and checkpatch flags for each
> > > >    maintainer.  Then we just need to herd all those wild-cats towards
> > > >    updating their maintainers entry.
> > > 
> > > I've seen maintainers who want to be CC'ed on every patch touching their 
> > > subsystem, and others who prefer patches being sent to the mailing list only. 
> > > That would be easy to express in MAINTAINERS and would already help in two 
> > > fronts. It would lower the amount of noise for maintainers who base their work 
> > > flow on mailing lists. It would also remove the need for submitters to decide 
> > > whether to CC maintainers and prevent patches from falling through cracks when 
> > > the decision is incorrect.
> > 
> > I've come to believe that this is one of many side effects of our dependency on
> > a completely free form mechanism for the management of our patches, a mechanism
> > which is becoming harder and harder to setup "correctly" with modern tooling
> > (since the industry is killing "real email").
> > 
> > I spend a highly disproportionate amount of my time, relative to measurable
> > quality impact to the kernel, going over the nuances of submitting patches.
> > 
> > 1) Must have a complete commit message
> > 2) DCO goes above the ---
> > 3) Include a patch changelog, do so below ---
> > 4) Cc maintainers :-)
> > 5) Checkpatch... checkpatch... checkpatch...
> > 6) Compiler warnings
> > 7) CodingStyle :-)
> > 8) Use ascii or utf8 character encodings
> > 
> > All of these are distractions from reviewing the code. I'm often on version 3 of
> > a series before I'm actually reviewing content.
> > 
> > I raised this in Dusseldorf with the PREEMPT_RT crowd, and I'll do so here too,
> > although I suspect it will be met with quite a bit of opposition. I believe our
> > tooling and processes are good at helping our top level maintainers scale -
> > which is absolutely critical to the success of Linux - but they inhibit scaling
> > out and attracting new developers, reviewers, etc.
> > 
> > Our most productive maintainers and contributors, in my understanding, often are
> > able to spend most of their time on their upstream Linux kernel work. They have
> > been doing it for a decade or more and have a lot of custom written tools to
> > help make the processes scale for their particular needs. This is great!
> > 
> > However, we have a lot of tribal knowledge regarding how to interact
> > successfully with the development model. So much so that many of our lesser
> > maintainers (like myself) spend a lot of our time as a bridge or proxy to
> > upstream development, which is too opaque and even enigmatic for them to get
> > into.
> [...]
> > I am looking to make some changes in my subsystem. I've requested patchwork to
> > be enabled, and I'll create a for-review branch and solicit help there. I
> > already leverage 0-day, but I think it would be great to have something which
> > parses patches submitted to LKML and tests the 8 items above and more and
> > automatically responds to the submitter. Nobody should have to spend their time
> > on those things.
> > 
> > Looking forward a bit, I would love to see some tooling in place for people to
> > submit patches either via a web form (which eliminates all the email tooling for
> > submitting patches - which is where the formatting is especially critical) or
> > through one of the more managed git systems, like gerrit, etc.
> 
> I would love to see this.  I don't think it makes sense for the flow
> from subsystem maintainers to Linus or similar to use these tools;
> anyone capable of saying "please pull" *probably* doesn't need most of
> this.  However, for people who primarily interact with maintainers via
> patch mails, some kind of automated CI bot, integrated with Gerrit or
> github or similar, would filter out a substantial number of painful bits
> before they show up.
> 
> Consider a set of scripts or services that could easily be wired into
> either a Gerrit install or a GitHub hook, so that rather than spending
> time sorting out SMTP and basic patch formatting, people could git push
> to a repository branch they control, get automated feedback on what
> needs fixing, and when all of the mechanical issues are sorted out that
> same service can help them send a properly formatted mail series (with
> cover letter) to the right set of people.
> 
> It would take some work to initially set up, but the result should
> actually save maintainer time by avoiding the need to comment on
> mechanical correctness issues.
> 
> That same bot could fairly easily be wired to a "test" mailing list,
> capturing mailed patch series and running them through the same tests,
> so that people comfortable with the email part of the workflow could
> mail patches to that list to have them automatically checked *before*
> mailing LKML.  And unlike mailing LKML, there would be no stigma
> attached to iterating and sending multiple mails to that list while
> trying to get the details right.
> 
> Bonus if this is also wired into the 0day bot, so that you also find out
> if you introduce a new warning or error.
> 

Pretty sure you said that better than I did :-)

The git submission mechanism makes a lot of sense (that's a bare minimum to
working with Linux) and +1000 on avoiding the stigma of a "mechanical" failure
on LKML.

-- 
Darren Hart
Intel Open Source Technology Center

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

[Fengguang Wu]

On Thu, Jul 09, 2015 at 01:11:27PM -0700, josh@joshtriplett.org wrote:
> On Thu, Jul 09, 2015 at 12:37:18PM -0700, Darren Hart wrote:
> > On Wed, Jul 08, 2015 at 10:45:28PM +0300, Laurent Pinchart wrote:
> > > On Wednesday 08 July 2015 11:40:11 NeilBrown wrote:
> > > > Indeed!  I wonder if we can list the dimensions.
> > > > 
> > > > Variability: as you say, different people want different things, and
> > > >    care to different degrees about them.  'checkpatch' and
> > > >    'CodingStyle' help with some of that (though different people care
> > > >    differently about checkpatch).  Maybe the MAINTAINERS file could
> > > >    list the preferred Subject: line and checkpatch flags for each
> > > >    maintainer.  Then we just need to herd all those wild-cats towards
> > > >    updating their maintainers entry.
> > > 
> > > I've seen maintainers who want to be CC'ed on every patch touching their 
> > > subsystem, and others who prefer patches being sent to the mailing list only. 
> > > That would be easy to express in MAINTAINERS and would already help in two 
> > > fronts. It would lower the amount of noise for maintainers who base their work 
> > > flow on mailing lists. It would also remove the need for submitters to decide 
> > > whether to CC maintainers and prevent patches from falling through cracks when 
> > > the decision is incorrect.
> > 
> > I've come to believe that this is one of many side effects of our dependency on
> > a completely free form mechanism for the management of our patches, a mechanism
> > which is becoming harder and harder to setup "correctly" with modern tooling
> > (since the industry is killing "real email").
> > 
> > I spend a highly disproportionate amount of my time, relative to measurable
> > quality impact to the kernel, going over the nuances of submitting patches.
> > 
> > 1) Must have a complete commit message
> > 2) DCO goes above the ---
> > 3) Include a patch changelog, do so below ---
> > 4) Cc maintainers :-)
> > 5) Checkpatch... checkpatch... checkpatch...
> > 6) Compiler warnings
> > 7) CodingStyle :-)
> > 8) Use ascii or utf8 character encodings
> > 
> > All of these are distractions from reviewing the code. I'm often on version 3 of
> > a series before I'm actually reviewing content.
> > 
> > I raised this in Dusseldorf with the PREEMPT_RT crowd, and I'll do so here too,
> > although I suspect it will be met with quite a bit of opposition. I believe our
> > tooling and processes are good at helping our top level maintainers scale -
> > which is absolutely critical to the success of Linux - but they inhibit scaling
> > out and attracting new developers, reviewers, etc.
> > 
> > Our most productive maintainers and contributors, in my understanding, often are
> > able to spend most of their time on their upstream Linux kernel work. They have
> > been doing it for a decade or more and have a lot of custom written tools to
> > help make the processes scale for their particular needs. This is great!
> > 
> > However, we have a lot of tribal knowledge regarding how to interact
> > successfully with the development model. So much so that many of our lesser
> > maintainers (like myself) spend a lot of our time as a bridge or proxy to
> > upstream development, which is too opaque and even enigmatic for them to get
> > into.
> [...]
> > I am looking to make some changes in my subsystem. I've requested patchwork to
> > be enabled, and I'll create a for-review branch and solicit help there. I
> > already leverage 0-day, but I think it would be great to have something which
> > parses patches submitted to LKML and tests the 8 items above and more and
> > automatically responds to the submitter. Nobody should have to spend their time
> > on those things.
> > 
> > Looking forward a bit, I would love to see some tooling in place for people to
> > submit patches either via a web form (which eliminates all the email tooling for
> > submitting patches - which is where the formatting is especially critical) or
> > through one of the more managed git systems, like gerrit, etc.
> 
> I would love to see this.  I don't think it makes sense for the flow
> from subsystem maintainers to Linus or similar to use these tools;
> anyone capable of saying "please pull" *probably* doesn't need most of
> this.  However, for people who primarily interact with maintainers via
> patch mails, some kind of automated CI bot, integrated with Gerrit or
> github or similar, would filter out a substantial number of painful bits
> before they show up.
> 
> Consider a set of scripts or services that could easily be wired into
> either a Gerrit install or a GitHub hook, so that rather than spending
> time sorting out SMTP and basic patch formatting, people could git push
> to a repository branch they control, get automated feedback on what
> needs fixing, and when all of the mechanical issues are sorted out that
> same service can help them send a properly formatted mail series (with
> cover letter) to the right set of people.
> 
> It would take some work to initially set up, but the result should
> actually save maintainer time by avoiding the need to comment on
> mechanical correctness issues.
> 
> That same bot could fairly easily be wired to a "test" mailing list,
> capturing mailed patch series and running them through the same tests,
> so that people comfortable with the email part of the workflow could
> mail patches to that list to have them automatically checked *before*
> mailing LKML.  And unlike mailing LKML, there would be no stigma
> attached to iterating and sending multiple mails to that list while
> trying to get the details right.
> 
> Bonus if this is also wired into the 0day bot, so that you also find out
> if you introduce a new warning or error.

Sure, if someone is to setup the web form or test mailing list or
both, 0day can happily run all supported tests on them, including
checkpatch.pl etc. that we normally don't run for the regular git
pushes.

Thanks,
Fengguang

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

[Darren Hart]

On Mon, Aug 03, 2015 at 08:38:05PM +0800, Fengguang Wu wrote:
> On Thu, Jul 09, 2015 at 01:11:27PM -0700, josh@joshtriplett.org wrote:
> > On Thu, Jul 09, 2015 at 12:37:18PM -0700, Darren Hart wrote:
> > > On Wed, Jul 08, 2015 at 10:45:28PM +0300, Laurent Pinchart wrote:
> > > > On Wednesday 08 July 2015 11:40:11 NeilBrown wrote:
> > > > > Indeed!  I wonder if we can list the dimensions.
> > > > > 
> > > > > Variability: as you say, different people want different things, and
> > > > >    care to different degrees about them.  'checkpatch' and
> > > > >    'CodingStyle' help with some of that (though different people care
> > > > >    differently about checkpatch).  Maybe the MAINTAINERS file could
> > > > >    list the preferred Subject: line and checkpatch flags for each
> > > > >    maintainer.  Then we just need to herd all those wild-cats towards
> > > > >    updating their maintainers entry.
> > > > 
> > > > I've seen maintainers who want to be CC'ed on every patch touching their 
> > > > subsystem, and others who prefer patches being sent to the mailing list only. 
> > > > That would be easy to express in MAINTAINERS and would already help in two 
> > > > fronts. It would lower the amount of noise for maintainers who base their work 
> > > > flow on mailing lists. It would also remove the need for submitters to decide 
> > > > whether to CC maintainers and prevent patches from falling through cracks when 
> > > > the decision is incorrect.
> > > 
> > > I've come to believe that this is one of many side effects of our dependency on
> > > a completely free form mechanism for the management of our patches, a mechanism
> > > which is becoming harder and harder to setup "correctly" with modern tooling
> > > (since the industry is killing "real email").
> > > 
> > > I spend a highly disproportionate amount of my time, relative to measurable
> > > quality impact to the kernel, going over the nuances of submitting patches.
> > > 
> > > 1) Must have a complete commit message
> > > 2) DCO goes above the ---
> > > 3) Include a patch changelog, do so below ---
> > > 4) Cc maintainers :-)
> > > 5) Checkpatch... checkpatch... checkpatch...
> > > 6) Compiler warnings
> > > 7) CodingStyle :-)
> > > 8) Use ascii or utf8 character encodings
> > > 
> > > All of these are distractions from reviewing the code. I'm often on version 3 of
> > > a series before I'm actually reviewing content.
> > > 
> > > I raised this in Dusseldorf with the PREEMPT_RT crowd, and I'll do so here too,
> > > although I suspect it will be met with quite a bit of opposition. I believe our
> > > tooling and processes are good at helping our top level maintainers scale -
> > > which is absolutely critical to the success of Linux - but they inhibit scaling
> > > out and attracting new developers, reviewers, etc.
> > > 
> > > Our most productive maintainers and contributors, in my understanding, often are
> > > able to spend most of their time on their upstream Linux kernel work. They have
> > > been doing it for a decade or more and have a lot of custom written tools to
> > > help make the processes scale for their particular needs. This is great!
> > > 
> > > However, we have a lot of tribal knowledge regarding how to interact
> > > successfully with the development model. So much so that many of our lesser
> > > maintainers (like myself) spend a lot of our time as a bridge or proxy to
> > > upstream development, which is too opaque and even enigmatic for them to get
> > > into.
> > [...]
> > > I am looking to make some changes in my subsystem. I've requested patchwork to
> > > be enabled, and I'll create a for-review branch and solicit help there. I
> > > already leverage 0-day, but I think it would be great to have something which
> > > parses patches submitted to LKML and tests the 8 items above and more and
> > > automatically responds to the submitter. Nobody should have to spend their time
> > > on those things.
> > > 
> > > Looking forward a bit, I would love to see some tooling in place for people to
> > > submit patches either via a web form (which eliminates all the email tooling for
> > > submitting patches - which is where the formatting is especially critical) or
> > > through one of the more managed git systems, like gerrit, etc.
> > 
> > I would love to see this.  I don't think it makes sense for the flow
> > from subsystem maintainers to Linus or similar to use these tools;
> > anyone capable of saying "please pull" *probably* doesn't need most of
> > this.  However, for people who primarily interact with maintainers via
> > patch mails, some kind of automated CI bot, integrated with Gerrit or
> > github or similar, would filter out a substantial number of painful bits
> > before they show up.
> > 
> > Consider a set of scripts or services that could easily be wired into
> > either a Gerrit install or a GitHub hook, so that rather than spending
> > time sorting out SMTP and basic patch formatting, people could git push
> > to a repository branch they control, get automated feedback on what
> > needs fixing, and when all of the mechanical issues are sorted out that
> > same service can help them send a properly formatted mail series (with
> > cover letter) to the right set of people.
> > 
> > It would take some work to initially set up, but the result should
> > actually save maintainer time by avoiding the need to comment on
> > mechanical correctness issues.
> > 
> > That same bot could fairly easily be wired to a "test" mailing list,
> > capturing mailed patch series and running them through the same tests,
> > so that people comfortable with the email part of the workflow could
> > mail patches to that list to have them automatically checked *before*
> > mailing LKML.  And unlike mailing LKML, there would be no stigma
> > attached to iterating and sending multiple mails to that list while
> > trying to get the details right.
> > 
> > Bonus if this is also wired into the 0day bot, so that you also find out
> > if you introduce a new warning or error.
> 
> Sure, if someone is to setup the web form or test mailing list or
> both, 0day can happily run all supported tests on them, including
> checkpatch.pl etc. that we normally don't run for the regular git
> pushes.

Fengguang,

Do we have sufficient isolation/security in place to test any patch from anyone
on a mailing list? I believe someone else raised this concern previously, but
it's been a while and I don't remember who it was.

-- 
Darren Hart
Intel Open Source Technology Center

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

[Fengguang Wu]

On Wed, Aug 05, 2015 at 12:48:58AM -0700, Darren Hart wrote:
> On Mon, Aug 03, 2015 at 08:38:05PM +0800, Fengguang Wu wrote:
> > On Thu, Jul 09, 2015 at 01:11:27PM -0700, josh@joshtriplett.org wrote:
> > > On Thu, Jul 09, 2015 at 12:37:18PM -0700, Darren Hart wrote:
> > > > On Wed, Jul 08, 2015 at 10:45:28PM +0300, Laurent Pinchart wrote:
> > > > > On Wednesday 08 July 2015 11:40:11 NeilBrown wrote:
> > > > > > Indeed!  I wonder if we can list the dimensions.
> > > > > > 
> > > > > > Variability: as you say, different people want different things, and
> > > > > >    care to different degrees about them.  'checkpatch' and
> > > > > >    'CodingStyle' help with some of that (though different people care
> > > > > >    differently about checkpatch).  Maybe the MAINTAINERS file could
> > > > > >    list the preferred Subject: line and checkpatch flags for each
> > > > > >    maintainer.  Then we just need to herd all those wild-cats towards
> > > > > >    updating their maintainers entry.
> > > > > 
> > > > > I've seen maintainers who want to be CC'ed on every patch touching their 
> > > > > subsystem, and others who prefer patches being sent to the mailing list only. 
> > > > > That would be easy to express in MAINTAINERS and would already help in two 
> > > > > fronts. It would lower the amount of noise for maintainers who base their work 
> > > > > flow on mailing lists. It would also remove the need for submitters to decide 
> > > > > whether to CC maintainers and prevent patches from falling through cracks when 
> > > > > the decision is incorrect.
> > > > 
> > > > I've come to believe that this is one of many side effects of our dependency on
> > > > a completely free form mechanism for the management of our patches, a mechanism
> > > > which is becoming harder and harder to setup "correctly" with modern tooling
> > > > (since the industry is killing "real email").
> > > > 
> > > > I spend a highly disproportionate amount of my time, relative to measurable
> > > > quality impact to the kernel, going over the nuances of submitting patches.
> > > > 
> > > > 1) Must have a complete commit message
> > > > 2) DCO goes above the ---
> > > > 3) Include a patch changelog, do so below ---
> > > > 4) Cc maintainers :-)
> > > > 5) Checkpatch... checkpatch... checkpatch...
> > > > 6) Compiler warnings
> > > > 7) CodingStyle :-)
> > > > 8) Use ascii or utf8 character encodings
> > > > 
> > > > All of these are distractions from reviewing the code. I'm often on version 3 of
> > > > a series before I'm actually reviewing content.
> > > > 
> > > > I raised this in Dusseldorf with the PREEMPT_RT crowd, and I'll do so here too,
> > > > although I suspect it will be met with quite a bit of opposition. I believe our
> > > > tooling and processes are good at helping our top level maintainers scale -
> > > > which is absolutely critical to the success of Linux - but they inhibit scaling
> > > > out and attracting new developers, reviewers, etc.
> > > > 
> > > > Our most productive maintainers and contributors, in my understanding, often are
> > > > able to spend most of their time on their upstream Linux kernel work. They have
> > > > been doing it for a decade or more and have a lot of custom written tools to
> > > > help make the processes scale for their particular needs. This is great!
> > > > 
> > > > However, we have a lot of tribal knowledge regarding how to interact
> > > > successfully with the development model. So much so that many of our lesser
> > > > maintainers (like myself) spend a lot of our time as a bridge or proxy to
> > > > upstream development, which is too opaque and even enigmatic for them to get
> > > > into.
> > > [...]
> > > > I am looking to make some changes in my subsystem. I've requested patchwork to
> > > > be enabled, and I'll create a for-review branch and solicit help there. I
> > > > already leverage 0-day, but I think it would be great to have something which
> > > > parses patches submitted to LKML and tests the 8 items above and more and
> > > > automatically responds to the submitter. Nobody should have to spend their time
> > > > on those things.
> > > > 
> > > > Looking forward a bit, I would love to see some tooling in place for people to
> > > > submit patches either via a web form (which eliminates all the email tooling for
> > > > submitting patches - which is where the formatting is especially critical) or
> > > > through one of the more managed git systems, like gerrit, etc.
> > > 
> > > I would love to see this.  I don't think it makes sense for the flow
> > > from subsystem maintainers to Linus or similar to use these tools;
> > > anyone capable of saying "please pull" *probably* doesn't need most of
> > > this.  However, for people who primarily interact with maintainers via
> > > patch mails, some kind of automated CI bot, integrated with Gerrit or
> > > github or similar, would filter out a substantial number of painful bits
> > > before they show up.
> > > 
> > > Consider a set of scripts or services that could easily be wired into
> > > either a Gerrit install or a GitHub hook, so that rather than spending
> > > time sorting out SMTP and basic patch formatting, people could git push
> > > to a repository branch they control, get automated feedback on what
> > > needs fixing, and when all of the mechanical issues are sorted out that
> > > same service can help them send a properly formatted mail series (with
> > > cover letter) to the right set of people.
> > > 
> > > It would take some work to initially set up, but the result should
> > > actually save maintainer time by avoiding the need to comment on
> > > mechanical correctness issues.
> > > 
> > > That same bot could fairly easily be wired to a "test" mailing list,
> > > capturing mailed patch series and running them through the same tests,
> > > so that people comfortable with the email part of the workflow could
> > > mail patches to that list to have them automatically checked *before*
> > > mailing LKML.  And unlike mailing LKML, there would be no stigma
> > > attached to iterating and sending multiple mails to that list while
> > > trying to get the details right.
> > > 
> > > Bonus if this is also wired into the 0day bot, so that you also find out
> > > if you introduce a new warning or error.
> > 
> > Sure, if someone is to setup the web form or test mailing list or
> > both, 0day can happily run all supported tests on them, including
> > checkpatch.pl etc. that we normally don't run for the regular git
> > pushes.
> 
> Fengguang,
> 
> Do we have sufficient isolation/security in place to test any patch from anyone
> on a mailing list? I believe someone else raised this concern previously, but
> it's been a while and I don't remember who it was.

Yes because we test so many git trees, there are isolations since
very early time.  The kbuild scripts run inside chroot and behind
firewall. There is dedicated git mirror server to fetch code from
outside which does not actually run the code.

Thanks,
Fengguang

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

[David Woodhouse]

On Thu, 2015-07-09 at 12:37 -0700, Darren Hart wrote:
> I spend a highly disproportionate amount of my time, relative to measurable
> quality impact to the kernel, going over the nuances of submitting patches.
> 
> 1) Must have a complete commit message
> 2) DCO goes above the ---
> 3) Include a patch changelog, do so below ---
> 4) Cc maintainers :-)
> 5) Checkpatch... checkpatch... checkpatch...
> 6) Compiler warnings
> 7) CodingStyle :-)
> 8) Use ascii or utf8 character encodings
> 
> All of these are distractions from reviewing the code. I'm often on 
> version 3 of a series before I'm actually reviewing content.

I don't think it's entirely appropriate to call all of those
'distractions'.

The "content" in question is a proposed change to the code base. Such a
change requires a coherent commit message which will make sense when we
look back at this commit in the future. We will need to understand what
was happening and why, in order to fix it or tweak it for new
circumstances.

Doing that is *not* a peculiarity of the Linux 'process'. It is basic
engineering discipline, and it is *part* of the work. Just like the
task of breaking a change down into incremental, bisectable commits —
which I'm surprised wasn't in your list.

Yes, there are a lot of people who *lack* that basic engineering
discipline, to the point where it *can* start to look like it's a Linux
-only requirement. But it's not. And there's not a lot we can do if an
"engineer" lacks it, short of educating them. That part isn't a process
issue.

Likewise, compiler warnings. If your developers are actually
*submitting* code with unresolved compiler warnings, again there's not
a lot we can do to help them or you. Apart from confiscating their
keyboard.

Coding style, again, isn't a Linux-specific thing. All large code bases
attempt to have some kind of consistency to make the code readable, and
anyone attempting to work on *any* code base should expect to become
familiar with the idioms and conventions (and charset choice) of the
code they're working on.

These *aren't* process issues, in my view. What you're saying with some
of these is that you're having to do *basic* (non-Linux-specific)
education of people who want to contribute code, and that *that*
doesn't scale. Which is true, but it's hard to know how to address
that, except with programs like GSoC etc.

Josh suggests that we should provide a service that people could push
code to and 'get automated feedback on what needs fixing'... but isn't
that what checkpatch was for? OK, a local tool can't cross-compile it
for you on every platform we support, but it can do a lot of stuff
short of that.

I do like the idea of a 'test' mailing list which receives patches and
checks them for corruption though.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

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

[Julia Lawall]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3162 bytes --]



On Thu, 9 Jul 2015, David Woodhouse wrote:

> On Thu, 2015-07-09 at 12:37 -0700, Darren Hart wrote:
> > I spend a highly disproportionate amount of my time, relative to measurable
> > quality impact to the kernel, going over the nuances of submitting patches.
> >
> > 1) Must have a complete commit message
> > 2) DCO goes above the ---
> > 3) Include a patch changelog, do so below ---
> > 4) Cc maintainers :-)
> > 5) Checkpatch... checkpatch... checkpatch...
> > 6) Compiler warnings
> > 7) CodingStyle :-)
> > 8) Use ascii or utf8 character encodings
> >
> > All of these are distractions from reviewing the code. I'm often on
> > version 3 of a series before I'm actually reviewing content.
>
> I don't think it's entirely appropriate to call all of those
> 'distractions'.
>
> The "content" in question is a proposed change to the code base. Such a
> change requires a coherent commit message which will make sense when we
> look back at this commit in the future. We will need to understand what
> was happening and why, in order to fix it or tweak it for new
> circumstances.
>
> Doing that is *not* a peculiarity of the Linux 'process'. It is basic
> engineering discipline, and it is *part* of the work. Just like the
> task of breaking a change down into incremental, bisectable commits —
> which I'm surprised wasn't in your list.
>
> Yes, there are a lot of people who *lack* that basic engineering
> discipline, to the point where it *can* start to look like it's a Linux
> -only requirement. But it's not. And there's not a lot we can do if an
> "engineer" lacks it, short of educating them. That part isn't a process
> issue.
>
> Likewise, compiler warnings. If your developers are actually
> *submitting* code with unresolved compiler warnings, again there's not
> a lot we can do to help them or you. Apart from confiscating their
> keyboard.
>
> Coding style, again, isn't a Linux-specific thing. All large code bases
> attempt to have some kind of consistency to make the code readable, and
> anyone attempting to work on *any* code base should expect to become
> familiar with the idioms and conventions (and charset choice) of the
> code they're working on.
>
> These *aren't* process issues, in my view. What you're saying with some
> of these is that you're having to do *basic* (non-Linux-specific)
> education of people who want to contribute code, and that *that*
> doesn't scale. Which is true, but it's hard to know how to address
> that, except with programs like GSoC etc.
>
> Josh suggests that we should provide a service that people could push
> code to and 'get automated feedback on what needs fixing'... but isn't
> that what checkpatch was for? OK, a local tool can't cross-compile it
> for you on every platform we support, but it can do a lot of stuff
> short of that.
>
> I do like the idea of a 'test' mailing list which receives patches and
> checks them for corruption though.

Experience with interns suggests that most people can get it right, but
that most people reequire a few tries to figure it out (mailer problems,
proper subject line, meaning of ---, etc).  So a test mailing list could
be helpful.

julia

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

[Darren Hart]

On Thu, Jul 09, 2015 at 11:31:49PM +0100, David Woodhouse wrote:
> On Thu, 2015-07-09 at 12:37 -0700, Darren Hart wrote:
> > I spend a highly disproportionate amount of my time, relative to measurable
> > quality impact to the kernel, going over the nuances of submitting patches.
> > 
> > 1) Must have a complete commit message
> > 2) DCO goes above the ---
> > 3) Include a patch changelog, do so below ---
> > 4) Cc maintainers :-)
> > 5) Checkpatch... checkpatch... checkpatch...
> > 6) Compiler warnings
> > 7) CodingStyle :-)
> > 8) Use ascii or utf8 character encodings
> > 
> > All of these are distractions from reviewing the code. I'm often on 
> > version 3 of a series before I'm actually reviewing content.
> 
> I don't think it's entirely appropriate to call all of those
> 'distractions'.
> 
> The "content" in question is a proposed change to the code base. Such a
> change requires a coherent commit message which will make sense when we
> look back at this commit in the future. We will need to understand what
> was happening and why, in order to fix it or tweak it for new
> circumstances.
> 
> Doing that is *not* a peculiarity of the Linux 'process'. It is basic
> engineering discipline, and it is *part* of the work. Just like the
> task of breaking a change down into incremental, bisectable commits —
> which I'm surprised wasn't in your list.
> 
> Yes, there are a lot of people who *lack* that basic engineering
> discipline, to the point where it *can* start to look like it's a Linux
> -only requirement. But it's not. And there's not a lot we can do if an
> "engineer" lacks it, short of educating them. That part isn't a process
> issue.

Fair enough. Agreed.

Small functional changes isn't something that is readily automated, and it's the
kind of feedback I do expect to give as a maintainer. That's why it isn't on the
list. I understand your point that some things that are on the list are just
good SW Eng 101 material - in practice, it still wastes my time :-) as it can
be automated.

> 
> Likewise, compiler warnings. If your developers are actually
> *submitting* code with unresolved compiler warnings, again there's not
> a lot we can do to help them or you. Apart from confiscating their
> keyboard.

In the simplest case, sure. However, it isn't uncommon for config fuzz testing
or different compiler versions to result in compiler warnings that the original
submitter could legitimately not seen. Right now my choice is to ignore their
code or spend the time to educate - but either way I have to build it and find
the error. That step could be automated.

> 
> Coding style, again, isn't a Linux-specific thing. All large code bases
> attempt to have some kind of consistency to make the code readable, and
> anyone attempting to work on *any* code base should expect to become
> familiar with the idioms and conventions (and charset choice) of the
> code they're working on.
> 
> These *aren't* process issues, in my view. What you're saying with some
> of these is that you're having to do *basic* (non-Linux-specific)
> education of people who want to contribute code, and that *that*
> doesn't scale. Which is true, but it's hard to know how to address
> that, except with programs like GSoC etc.
> 
> Josh suggests that we should provide a service that people could push
> code to and 'get automated feedback on what needs fixing'... but isn't
> that what checkpatch was for? OK, a local tool can't cross-compile it
> for you on every platform we support, but it can do a lot of stuff
> short of that.
> 
> I do like the idea of a 'test' mailing list which receives patches and
> checks them for corruption though.

I believe we're in agreement on some additional automation being available to
a broader audience would catch more errors with less maintainer/reviewer time.

As to what should be expected from contributors... I don't know. I wish everyone
was as meticulous as you and so many other kernel developers (it's one of the
things I really appreciate about Linux kernel development), and something I
personally strive for. The reality is, they aren't, and since we're talking
about recruiting, my point was by implementing some of these things we can
maintain our standards while reducing maintainer/reviewer overhead.

-- 
Darren Hart
Intel Open Source Technology Center

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

[David Woodhouse]

On Thu, 2015-07-09 at 16:38 -0700, Darren Hart wrote:
> since we're talking about recruiting, my point was by implementing 
> some of these things we can maintain our standards while reducing 
> maintainer/reviewer overhead.

Hopefully, yes. But people actually have to *use* the tools and
services we provide. Like checkpatch.

Rather than seeing them as part of the problem.

-- 
dwmw2

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

[Theodore Ts'o]

On Fri, Jul 10, 2015 at 12:41:13AM +0100, David Woodhouse wrote:
> On Thu, 2015-07-09 at 16:38 -0700, Darren Hart wrote:
> > since we're talking about recruiting, my point was by implementing 
> > some of these things we can maintain our standards while reducing 
> > maintainer/reviewer overhead.
> 
> Hopefully, yes. But people actually have to *use* the tools and
> services we provide. Like checkpatch.
> 
> Rather than seeing them as part of the problem.

Using checkpatch on patches before they are submitted are definitely
part of the solution.  Using "checkpatch --file" or coccinelle on
files where you are not the maintainer or one of the core subsystem
developers to inflate your patch count is (IMHO) part of the problem.

	      	      	   	       	  - Ted

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

[Rafael J. Wysocki]

On Thursday, July 09, 2015 04:38:54 PM Darren Hart wrote:
> On Thu, Jul 09, 2015 at 11:31:49PM +0100, David Woodhouse wrote:
> > On Thu, 2015-07-09 at 12:37 -0700, Darren Hart wrote:
> > > I spend a highly disproportionate amount of my time, relative to measurable
> > > quality impact to the kernel, going over the nuances of submitting patches.
> > > 
> > > 1) Must have a complete commit message
> > > 2) DCO goes above the ---
> > > 3) Include a patch changelog, do so below ---
> > > 4) Cc maintainers :-)
> > > 5) Checkpatch... checkpatch... checkpatch...
> > > 6) Compiler warnings
> > > 7) CodingStyle :-)
> > > 8) Use ascii or utf8 character encodings
> > > 
> > > All of these are distractions from reviewing the code. I'm often on 
> > > version 3 of a series before I'm actually reviewing content.
> > 
> > I don't think it's entirely appropriate to call all of those
> > 'distractions'.
> > 
> > The "content" in question is a proposed change to the code base. Such a
> > change requires a coherent commit message which will make sense when we
> > look back at this commit in the future. We will need to understand what
> > was happening and why, in order to fix it or tweak it for new
> > circumstances.
> > 
> > Doing that is *not* a peculiarity of the Linux 'process'. It is basic
> > engineering discipline, and it is *part* of the work. Just like the
> > task of breaking a change down into incremental, bisectable commits —
> > which I'm surprised wasn't in your list.
> > 
> > Yes, there are a lot of people who *lack* that basic engineering
> > discipline, to the point where it *can* start to look like it's a Linux
> > -only requirement. But it's not. And there's not a lot we can do if an
> > "engineer" lacks it, short of educating them. That part isn't a process
> > issue.
> 
> Fair enough. Agreed.
> 
> Small functional changes isn't something that is readily automated, and it's the
> kind of feedback I do expect to give as a maintainer. That's why it isn't on the
> list. I understand your point that some things that are on the list are just
> good SW Eng 101 material - in practice, it still wastes my time :-) as it can
> be automated.
> 
> > 
> > Likewise, compiler warnings. If your developers are actually
> > *submitting* code with unresolved compiler warnings, again there's not
> > a lot we can do to help them or you. Apart from confiscating their
> > keyboard.
> 
> In the simplest case, sure. However, it isn't uncommon for config fuzz testing
> or different compiler versions to result in compiler warnings that the original
> submitter could legitimately not seen. Right now my choice is to ignore their
> code or spend the time to educate - but either way I have to build it and find
> the error. That step could be automated.

Yeah.  That's why I have the bleeding-edge branch. :-)

> > Coding style, again, isn't a Linux-specific thing. All large code bases
> > attempt to have some kind of consistency to make the code readable, and
> > anyone attempting to work on *any* code base should expect to become
> > familiar with the idioms and conventions (and charset choice) of the
> > code they're working on.
> > 
> > These *aren't* process issues, in my view. What you're saying with some
> > of these is that you're having to do *basic* (non-Linux-specific)
> > education of people who want to contribute code, and that *that*
> > doesn't scale. Which is true, but it's hard to know how to address
> > that, except with programs like GSoC etc.
> > 
> > Josh suggests that we should provide a service that people could push
> > code to and 'get automated feedback on what needs fixing'... but isn't
> > that what checkpatch was for? OK, a local tool can't cross-compile it
> > for you on every platform we support, but it can do a lot of stuff
> > short of that.
> > 
> > I do like the idea of a 'test' mailing list which receives patches and
> > checks them for corruption though.
> 
> I believe we're in agreement on some additional automation being available to
> a broader audience would catch more errors with less maintainer/reviewer time.

That service only requires somebody with a kernel.org account and enough time
to apply *all* patches they get (except for the ones that don't apply, of course)
and push the result out into a public git branch on a regular basis.

That might be a robot, but arguably not running on kernel.org for safety
reasons.

> As to what should be expected from contributors... I don't know. I wish everyone
> was as meticulous as you and so many other kernel developers (it's one of the
> things I really appreciate about Linux kernel development), and something I
> personally strive for. The reality is, they aren't, and since we're talking
> about recruiting, my point was by implementing some of these things we can
> maintain our standards while reducing maintainer/reviewer overhead.

With all tools/scripts/0-days/whatever in place there always is the time when
*you* (the maintainer) have to decide whether or not to apply the patch (and
sometimes when to apply it too), so you have to look at it and understand
what it is doing.

Fortunately or not, no kind of software is able to understand things as of
today, so you need a human for that job.  And *that* really should be the
job for reviewers (including maintainers in a reviewer role).  All of the
coding style/build errors/white space/etc is secondary in principle.
However, people often request things to be cleaned up to start with, because
those small details prevent them from being able to understand the general
idea in the first place.

So the automation is only useful here as long as it helps patch submitters to
get their work to the point at which it can be understood by a reviewer in
a relatively short time.  Otherwise, it is just not helpful in that respect.

For example, if someone sends me a patch that doesn't apply, but that I can
easily understand and I think "Yeah, that's a good idea!", I may fix it up
and make it build and so on just fine.  But without understanding, I pretty
much can't do anything with it even if it got all of the details perfect.

Thanks,
Rafael

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

[Darren Hart]

On Fri, Jul 10, 2015 at 02:55:32AM +0200, Rafael Wysocki wrote:
> On Thursday, July 09, 2015 04:38:54 PM Darren Hart wrote:

> So the automation is only useful here as long as it helps patch submitters to
> get their work to the point at which it can be understood by a reviewer in
> a relatively short time.  Otherwise, it is just not helpful in that respect.

And that's the gist of what I'm getting at. Automation could help get things to
a reviewable state so maintainers/reviewers spend less time on what Josh called
"mechanical" errors, on things the submitter should have caught themselves, etc.

> For example, if someone sends me a patch that doesn't apply, but that I can
> easily understand and I think "Yeah, that's a good idea!", I may fix it up
> and make it build and so on just fine.  But without understanding, I pretty
> much can't do anything with it even if it got all of the details perfect.

Yes, of course.

-- 
Darren Hart
Intel Open Source Technology Center

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 3476 bytes --]

On Thu, Jul 09, 2015 at 11:31:49PM +0100, David Woodhouse wrote:
> On Thu, 2015-07-09 at 12:37 -0700, Darren Hart wrote:

> > I spend a highly disproportionate amount of my time, relative to measurable
> > quality impact to the kernel, going over the nuances of submitting patches.

> > 1) Must have a complete commit message
> > 2) DCO goes above the ---
> > 3) Include a patch changelog, do so below ---
> > 4) Cc maintainers :-)
> > 5) Checkpatch... checkpatch... checkpatch...
> > 6) Compiler warnings
> > 7) CodingStyle :-)
> > 8) Use ascii or utf8 character encodings

As far as I can tell for most of the bits of this that are tooling and
create practical problems git send-email will avoid most of the issue
and people do seem to have mostly adopted that, but perhaps that's a
result of me seeing a different submitter base to you.  I very rarely
see anything that's serious enough to cause a practical problem except
for CC issues that doesn't also come along with other substantial code
quality problems.

Patch changelogs are the biggest thing I can see there that feels like a
tooling problem to me since git send-email doesn't do anything at all,
though it's not an issue I'm personally that concerned about (I do
appreciate having them but I can often barely remember what issues I
raised in the first place).

> The "content" in question is a proposed change to the code base. Such a
> change requires a coherent commit message which will make sense when we
> look back at this commit in the future. We will need to understand what
> was happening and why, in order to fix it or tweak it for new
> circumstances.

> Doing that is *not* a peculiarity of the Linux 'process'. It is basic
> engineering discipline, and it is *part* of the work. Just like the
> task of breaking a change down into incremental, bisectable commits —
> which I'm surprised wasn't in your list.

Judging by the history of many of the proprietary codebases I've had
cause to look at the fact that these things are good engineering
practice does not mean they're not unusual.  :/

I have to say that I'm willing to cut people quite a large amount of
slack on changelogs if I can understand the code and they obviously
don't speak English that well, though in cases where I do that if I feel
it's needed I will tend to fix up the changelog myself.  It's not that
common that it's needed but I do feel it's an effort worth making.

> Likewise, compiler warnings. If your developers are actually
> *submitting* code with unresolved compiler warnings, again there's not
> a lot we can do to help them or you. Apart from confiscating their
> keyboard.

There's some that this is the case for but there's enough things that
depend on configs or compiler versions that it's perfectly plausible
that things build fine for the submitter in reasonable testing.

> Josh suggests that we should provide a service that people could push
> code to and 'get automated feedback on what needs fixing'... but isn't
> that what checkpatch was for? OK, a local tool can't cross-compile it
> for you on every platform we support, but it can do a lot of stuff
> short of that.

aiaiai is pretty reasonable for going a step beyond here, I really do
wish it played nicely with ccache though.

> I do like the idea of a 'test' mailing list which receives patches and
> checks them for corruption though.

That would help a lot of people.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Darren Hart]

On Fri, Jul 10, 2015 at 01:35:59AM +0100, Mark Brown wrote:
> On Thu, Jul 09, 2015 at 11:31:49PM +0100, David Woodhouse wrote:
> > On Thu, 2015-07-09 at 12:37 -0700, Darren Hart wrote:
> 
> > > I spend a highly disproportionate amount of my time, relative to measurable
> > > quality impact to the kernel, going over the nuances of submitting patches.
> 
> > > 1) Must have a complete commit message
> > > 2) DCO goes above the ---
> > > 3) Include a patch changelog, do so below ---
> > > 4) Cc maintainers :-)
> > > 5) Checkpatch... checkpatch... checkpatch...
> > > 6) Compiler warnings
> > > 7) CodingStyle :-)
> > > 8) Use ascii or utf8 character encodings
> 
> As far as I can tell for most of the bits of this that are tooling and
> create practical problems git send-email will avoid most of the issue
> and people do seem to have mostly adopted that, but perhaps that's a
> result of me seeing a different submitter base to you.  I very rarely

I was going to make the same comment - we all deal with a different group. I
admittedly see a number of first time contributors looking to improve their
particular laptop, rather than veteran sub-system developers (I also get people
picking up major platform drivers and doing a great job).

> see anything that's serious enough to cause a practical problem except
> for CC issues that doesn't also come along with other substantial code
> quality problems.
> 
> Patch changelogs are the biggest thing I can see there that feels like a
> tooling problem to me since git send-email doesn't do anything at all,
> though it's not an issue I'm personally that concerned about (I do
> appreciate having them but I can often barely remember what issues I
> raised in the first place).

As far as recruitment goes, I think we're talking about barriers to first-timers
and such - and git-send-email is one of those things. Eventually, a developer
spends enough time to make setting that all up worthwhile, but honestly, there
are A LOT of ways to embarass yourself with git-send-email. So much so that I've
written wrappers to it to protect people from it for the yocto project - and
even myself for my kernel work.

Is that a good assumption? Are we talking about first-timers - or are we talking
about getting current participants to do more review?

-- 
Darren Hart
Intel Open Source Technology Center

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

[Jason Cooper]

On Thu, Jul 09, 2015 at 07:07:06PM -0700, Darren Hart wrote:
> On Fri, Jul 10, 2015 at 01:35:59AM +0100, Mark Brown wrote:
> > On Thu, Jul 09, 2015 at 11:31:49PM +0100, David Woodhouse wrote:
> > > On Thu, 2015-07-09 at 12:37 -0700, Darren Hart wrote:
> > 
> > > > I spend a highly disproportionate amount of my time, relative to measurable
> > > > quality impact to the kernel, going over the nuances of submitting patches.
> > 
> > > > 1) Must have a complete commit message
> > > > 2) DCO goes above the ---
> > > > 3) Include a patch changelog, do so below ---
> > > > 4) Cc maintainers :-)
> > > > 5) Checkpatch... checkpatch... checkpatch...
> > > > 6) Compiler warnings
> > > > 7) CodingStyle :-)
> > > > 8) Use ascii or utf8 character encodings
> > 
> > As far as I can tell for most of the bits of this that are tooling and
> > create practical problems git send-email will avoid most of the issue
> > and people do seem to have mostly adopted that, but perhaps that's a
> > result of me seeing a different submitter base to you.  I very rarely
> 
> I was going to make the same comment - we all deal with a different group. I
> admittedly see a number of first time contributors looking to improve their
> particular laptop, rather than veteran sub-system developers (I also get people
> picking up major platform drivers and doing a great job).
> 
> > see anything that's serious enough to cause a practical problem except
> > for CC issues that doesn't also come along with other substantial code
> > quality problems.
> > 
> > Patch changelogs are the biggest thing I can see there that feels like a
> > tooling problem to me since git send-email doesn't do anything at all,
> > though it's not an issue I'm personally that concerned about (I do
> > appreciate having them but I can often barely remember what issues I
> > raised in the first place).
> 
> As far as recruitment goes, I think we're talking about barriers to first-timers
> and such - and git-send-email is one of those things. Eventually, a developer
> spends enough time to make setting that all up worthwhile, but honestly, there
> are A LOT of ways to embarass yourself with git-send-email. So much so that I've
> written wrappers to it to protect people from it for the yocto project - and
> even myself for my kernel work.

git send-email --kernel *.patch ?

--kernel would go through each patch and auto-fills Cc based on MAINTAINERS.
Amongst a few other things.  Shallow threading, check/edit cover letter
and so forth.

Or, we put a wrapper in ./scripts to accomplish the same.

> Is that a good assumption? Are we talking about first-timers - or are we talking
> about getting current participants to do more review?

Yes, this is about recruitment, so focused on first-timers.  Reviewers
start out as first timers.

Getting current devs to do more review falls on co-maintainer/reviewer
rotation to avoid burn-out.  I think folks would be more likely to
increase their role if they knew it wasn't a full-time commitment until
you burn out.

thx,

Jason.

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 718 bytes --]

On Fri, Jul 10, 2015 at 12:44:16PM +0000, Jason Cooper wrote:

> --kernel would go through each patch and auto-fills Cc based on MAINTAINERS.
> Amongst a few other things.  Shallow threading, check/edit cover letter
> and so forth.

People blindly CCing everyone get_maintainers finds can be a bit of a
problem, either they use --git and the false positive rate is quite high
or they don't and they miss out relevant people because MAINTAINERS
isn't 100% filled in or the reasons for CCing aren't entirely file
based.

The false positives are a bit of an issue since it discourages people
doing smaller cleanups over wide areas, you can end up getting CCed on
lots of things you touched which can be a bit offputting.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[josh]

On Fri, Jul 10, 2015 at 07:24:29PM +0100, Mark Brown wrote:
> On Fri, Jul 10, 2015 at 12:44:16PM +0000, Jason Cooper wrote:
> 
> > --kernel would go through each patch and auto-fills Cc based on MAINTAINERS.
> > Amongst a few other things.  Shallow threading, check/edit cover letter
> > and so forth.
> 
> People blindly CCing everyone get_maintainers finds can be a bit of a
> problem, either they use --git and the false positive rate is quite high
> or they don't and they miss out relevant people because MAINTAINERS
> isn't 100% filled in or the reasons for CCing aren't entirely file
> based.
> 
> The false positives are a bit of an issue since it discourages people
> doing smaller cleanups over wide areas, you can end up getting CCed on
> lots of things you touched which can be a bit offputting.

--git-fallback seems to work pretty well.  It nicely embodies the
approach of "if it doesn't have a maintainer, talk to the last poor
sucker who touched it".

- Josh Triplett

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 752 bytes --]

On Fri, Jul 10, 2015 at 01:40:05PM -0700, josh@joshtriplett.org wrote:
> On Fri, Jul 10, 2015 at 07:24:29PM +0100, Mark Brown wrote:

> > The false positives are a bit of an issue since it discourages people
> > doing smaller cleanups over wide areas, you can end up getting CCed on
> > lots of things you touched which can be a bit offputting.

> --git-fallback seems to work pretty well.  It nicely embodies the
> approach of "if it doesn't have a maintainer, talk to the last poor
> sucker who touched it".

That seems to have the same problems as just plain old git, and given
the way it uses wildcards it will use git more often than it should for
common patterns like companies supporting all their devices.  It'll just
trigger a bit less often.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Steven Rostedt]

On Thu, 9 Jul 2015 19:07:06 -0700
Darren Hart <dvhart@infradead.org> wrote:

 
> As far as recruitment goes, I think we're talking about barriers to first-timers
> and such - and git-send-email is one of those things. Eventually, a developer

+1000

I still don't use git-send-email, as I afraid that I'll blow it and end
up sending a thousand patches to every developer that ever touched the
kernel ;-)

I still use quilt to send my patch series. Just because I know how it
works and I trust it. And I get to see exactly what it is about to send
(the only thing it can send is what's in the patches/ directory,
nothing else).

I have a script that takes my git tree and creates the patches in a
format that quilt will send them nicely.

-- Steve


> spends enough time to make setting that all up worthwhile, but honestly, there
> are A LOT of ways to embarass yourself with git-send-email. So much so that I've
> written wrappers to it to protect people from it for the yocto project - and
> even myself for my kernel work.
> 

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

[David Woodhouse]

On Fri, 2015-07-10 at 15:51 -0400, Steven Rostedt wrote:
> On Thu, 9 Jul 2015 19:07:06 -0700
> Darren Hart <dvhart@infradead.org> wrote:
> 
>  
> > As far as recruitment goes, I think we're talking about barriers to first-timers
> > and such - and git-send-email is one of those things. Eventually, a developer
> 
> +1000
> 
> I still don't use git-send-email, as I afraid that I'll blow it and end
> up sending a thousand patches to every developer that ever touched the
> kernel ;-)

Rather than sending messages, it's actually better to put them as
*drafts*, ready to be sent by the user's normal mailer. It's not hard
to do this — I usually dump the mails into
~/.local/share/evolution/mail/local/.Drafts/new/ for example.

And then I can *read* them before sending them, which is good practice
anyway. Am I the only person who often finds a final minor nit with
their own patch, in that final read-through just before hitting 'send'
on an email?

Perhaps we should provide tools which make it trivial to do the same
for various different mail clients, without users having to know where,
and in what form, their drafts folders are?

-- 
dwmw2

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

[Steven Rostedt]

On Fri, 10 Jul 2015 21:00:12 +0100
David Woodhouse <dwmw2@infradead.org> wrote:
 
> Rather than sending messages, it's actually better to put them as
> *drafts*, ready to be sent by the user's normal mailer. It's not hard
> to do this — I usually dump the mails into
> ~/.local/share/evolution/mail/local/.Drafts/new/ for example.

That's also a good idea. Although I use claws-mail. But it should work.

> 
> And then I can *read* them before sending them, which is good practice
> anyway. Am I the only person who often finds a final minor nit with
> their own patch, in that final read-through just before hitting 'send'
> on an email?

This is exactly what I do before sending. But I just do:

 vim patches/*.patch

> 
> Perhaps we should provide tools which make it trivial to do the same
> for various different mail clients, without users having to know where,
> and in what form, their drafts folders are?
> 

Sounds like a plan ;-)

-- Steve

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

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1260 bytes --]

On Fri, 2015-07-10 at 16:31 -0400, Steven Rostedt wrote:
> 
> > And then I can *read* them before sending them, which is good practice
> > anyway. Am I the only person who often finds a final minor nit with
> > their own patch, in that final read-through just before hitting 'send'
> > on an email?
> 
> This is exactly what I do before sending. But I just do:
> 
>  vim patches/*.patch

That works too. Perhaps that would be the easier option for people who
aren't sure of their normal mailer.

It's mostly the *client* that screws formatting up, rather than the
transport. So maybe the best thing to advise new people to do is put
the messages into files, vet them as you describe above (except using
emacs instead of vim, of course), and then provide a simple tool which
will *send* the messages from those files, via whatever transport the
user needs.

I think we can cope with the SMTP case already but I'm not sure if we
can do it from pre-vetted files, or only directly from git-send-email?
It's not hard to add support for also sending via ActiveSync and EWS,
for the Exchange-afflicted.

Can one still send "from" GMail via SMTP these days? How does the 2
-factor authentication work? Do we cope with that?

-- 
dwmw2


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

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

[Josh Boyer]

On Fri, Jul 10, 2015 at 4:40 PM, David Woodhouse <dwmw2@infradead.org> wrote:
> On Fri, 2015-07-10 at 16:31 -0400, Steven Rostedt wrote:
>>
>> > And then I can *read* them before sending them, which is good practice
>> > anyway. Am I the only person who often finds a final minor nit with
>> > their own patch, in that final read-through just before hitting 'send'
>> > on an email?
>>
>> This is exactly what I do before sending. But I just do:
>>
>>  vim patches/*.patch
>
> That works too. Perhaps that would be the easier option for people who
> aren't sure of their normal mailer.
>
> It's mostly the *client* that screws formatting up, rather than the
> transport. So maybe the best thing to advise new people to do is put
> the messages into files, vet them as you describe above (except using
> emacs instead of vim, of course), and then provide a simple tool which
> will *send* the messages from those files, via whatever transport the
> user needs.
>
> I think we can cope with the SMTP case already but I'm not sure if we
> can do it from pre-vetted files, or only directly from git-send-email?
> It's not hard to add support for also sending via ActiveSync and EWS,
> for the Exchange-afflicted.
>
> Can one still send "from" GMail via SMTP these days? How does the 2
> -factor authentication work? Do we cope with that?

You can, but it doesn't support 2FA.  You have to generate one of
those "device" or "application" passwords and use that instead.
Things might have changed since I last set it up, but that is what I
had to do to use google SMTP via mutt.

josh

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

[Geert Uytterhoeven]

On Fri, Jul 10, 2015 at 10:43 PM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>> Can one still send "from" GMail via SMTP these days? How does the 2
>> -factor authentication work? Do we cope with that?
>
> You can, but it doesn't support 2FA.  You have to generate one of
> those "device" or "application" passwords and use that instead.
> Things might have changed since I last set it up, but that is what I
> had to do to use google SMTP via mutt.

Yes, works fine. I use that on my laptop (at home I have local SMTP).

Add to .gitconfig:

[sendemail]
        smtpencryption = tls
        smtpserver = smtp.gmail.com
        smtpuser = who-am-i@gmail.com
        smtppass = secret-app-password
        smtpserverport = 587

I'd actually encourage newcomers to use that, is it teaches them how to
set up device or app-specific passwords, too ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Darren Hart]

On Fri, Jul 10, 2015 at 09:40:38PM +0100, David Woodhouse wrote:
> On Fri, 2015-07-10 at 16:31 -0400, Steven Rostedt wrote:
> > 
> > > And then I can *read* them before sending them, which is good practice
> > > anyway. Am I the only person who often finds a final minor nit with
> > > their own patch, in that final read-through just before hitting 'send'
> > > on an email?
> > 
> > This is exactly what I do before sending. But I just do:
> > 
> >  vim patches/*.patch
> 
> That works too. Perhaps that would be the easier option for people who
> aren't sure of their normal mailer.
> 
> It's mostly the *client* that screws formatting up, rather than the
> transport. So maybe the best thing to advise new people to do is put
> the messages into files, vet them as you describe above (except using
> emacs instead of vim, of course), and then provide a simple tool which
> will *send* the messages from those files, via whatever transport the
> user needs.
> 
> I think we can cope with the SMTP case already but I'm not sure if we
> can do it from pre-vetted files, or only directly from git-send-email?
> It's not hard to add support for also sending via ActiveSync and EWS,
> for the Exchange-afflicted.
> 
> Can one still send "from" GMail via SMTP these days? How does the 2
> -factor authentication work? Do we cope with that?

This simple tool should not run on the client IMO. Or should be *required* to
run on the client. The kernel.org patch submission web form would be usable by
anyone with a browser ... OK, go ahead... "anyone with a browser" is too low a
bar for a kernel developer.... :-)

But seriously, we're talking about recruitment, and this is the kind of tooling
I routinely here non-Linux developers shake their heads at when considering our
development process. So while you and I are fine using vi (*jab*) and mutt
(*evolution) and arcane bash (*posix shell*) scripts and local MTAs... others
would very much like to focus on the code they are changing, and let the
computers handle schlepping the changesets around. Especially when they only
have a couple of patches to send, the setup is significant barrier.

-- 
Darren Hart
Intel Open Source Technology Center

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

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1180 bytes --]

On Fri, 2015-07-10 at 16:09 -0700, Darren Hart wrote:
> This simple tool should not run on the client IMO. Or should be *required* to
> run on the client. The kernel.org patch submission web form would be usable by
> anyone with a browser ... OK, go ahead... "anyone with a browser" is too low a
> bar for a kernel developer.... :-)
> 
> But seriously, we're talking about recruitment, and this is the kind of tooling
> I routinely here non-Linux developers shake their heads at when considering our
> development process. So while you and I are fine using vi (*jab*) and mutt
> (*evolution) and arcane bash (*posix shell*) scripts and local MTAs... others
> would very much like to focus on the code they are changing, and let the
> computers handle schlepping the changesets around. Especially when they only
> have a couple of patches to send, the setup is significant barrier.

Can you really do kernel development without touching a command line?

Perhaps we need a graphical tool based on gitk in which you can select
a set of commits, edit a cover letter and (initially autogenerated) set
of recipients, and then it'll send them for you?

-- 
dwmw2


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

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

[Darren Hart]

On Sat, Jul 11, 2015 at 12:37:28AM +0100, David Woodhouse wrote:
> On Fri, 2015-07-10 at 16:09 -0700, Darren Hart wrote:
> > This simple tool should not run on the client IMO. Or should be *required* to
> > run on the client. The kernel.org patch submission web form would be usable by
> > anyone with a browser ... OK, go ahead... "anyone with a browser" is too low a
> > bar for a kernel developer.... :-)
> > 
> > But seriously, we're talking about recruitment, and this is the kind of tooling
> > I routinely here non-Linux developers shake their heads at when considering our
> > development process. So while you and I are fine using vi (*jab*) and mutt
> > (*evolution) and arcane bash (*posix shell*) scripts and local MTAs... others
> > would very much like to focus on the code they are changing, and let the
> > computers handle schlepping the changesets around. Especially when they only
> > have a couple of patches to send, the setup is significant barrier.
> 
> Can you really do kernel development without touching a command line?

Of course not :-) But that's not the same thing as having to setup up a lot of
very custom special purpose tooling that you don't need for anything else just
to share a patch.

> 
> Perhaps we need a graphical tool based on gitk in which you can select
> a set of commits, edit a cover letter and (initially autogenerated) set
> of recipients, and then it'll send them for you?

That's not a bad idea, basic git usage is a requirement for kernel development.
It still depends on a successful gitk client installation, a local SMTP
configuration, possible firewall setup, etc. And I confess to be selfish in this
regard, I'm tired of helping people set that all up! That's why I like the web
submission form. Web connectivity is ubiquitous, no additonal setup is required
beyond an initial email verification through the same web service. A lot of
people outside the core developers do development through ssh to a managed Linux
machine, and are not running a Linux Desktop environment.

After some successful submissions through this, people will migrate to something
more advanced if they are to continue with kernel development, and something
like gitk integration isn't a bad idea as it can easily be preconfigured to do
all the right things with email mechanics that are becoming increasingly
difficult to configure modern GUI clients for (and most people are using a
modern GUI client for everything except Linux development these days).

-- 
Darren Hart
Intel Open Source Technology Center

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

[josh]

On Fri, Jul 10, 2015 at 09:00:12PM +0100, David Woodhouse wrote:
> On Fri, 2015-07-10 at 15:51 -0400, Steven Rostedt wrote:
> > On Thu, 9 Jul 2015 19:07:06 -0700
> > Darren Hart <dvhart@infradead.org> wrote:
> > 
> >  
> > > As far as recruitment goes, I think we're talking about barriers to first-timers
> > > and such - and git-send-email is one of those things. Eventually, a developer
> > 
> > +1000
> > 
> > I still don't use git-send-email, as I afraid that I'll blow it and end
> > up sending a thousand patches to every developer that ever touched the
> > kernel ;-)
> 
> Rather than sending messages, it's actually better to put them as
> *drafts*, ready to be sent by the user's normal mailer. It's not hard
> to do this — I usually dump the mails into
> ~/.local/share/evolution/mail/local/.Drafts/new/ for example.
> 
> And then I can *read* them before sending them, which is good practice
> anyway. Am I the only person who often finds a final minor nit with
> their own patch, in that final read-through just before hitting 'send'
> on an email?

Nope, I do that too.  (Though then I have to resist the temptation to
just fix it in the mailer rather than fixing the original and
regenerating.)

> Perhaps we should provide tools which make it trivial to do the same
> for various different mail clients, without users having to know where,
> and in what form, their drafts folders are?

git-imap-send does exactly that.  The one issue I've observed with
git-imap-send: many mailers, including mutt, will ignore the generated
Message-Id, In-Reply-To, and References headers in the drafts, and
generate new ones that break threading.  That's why I stopped using it
and started using mutt -H.

- Josh Triplett

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

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 663 bytes --]

On Fri, 2015-07-10 at 13:56 -0700, josh@joshtriplett.org wrote:
> On Fri, Jul 10, 2015 at 09:00:12PM +0100, David Woodhouse wrote:
> > And then I can *read* them before sending them, which is good practice
> > anyway. Am I the only person who often finds a final minor nit with
> > their own patch, in that final read-through just before hitting 'send'
> > on an email?
> 
> Nope, I do that too.  (Though then I have to resist the temptation to
> just fix it in the mailer rather than fixing the original and
> regenerating.)

Oh, I *always* just fix it in the mailer, even when the numbers in the
hunk headers need to be fixed up :)

-- 
dwmw2


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

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

[josh]

On Fri, Jul 10, 2015 at 10:03:43PM +0100, David Woodhouse wrote:
> On Fri, 2015-07-10 at 13:56 -0700, josh@joshtriplett.org wrote:
> > On Fri, Jul 10, 2015 at 09:00:12PM +0100, David Woodhouse wrote:
> > > And then I can *read* them before sending them, which is good practice
> > > anyway. Am I the only person who often finds a final minor nit with
> > > their own patch, in that final read-through just before hitting 'send'
> > > on an email?
> > 
> > Nope, I do that too.  (Though then I have to resist the temptation to
> > just fix it in the mailer rather than fixing the original and
> > regenerating.)
> 
> Oh, I *always* just fix it in the mailer, even when the numbers in the
> hunk headers need to be fixed up :)

I've occasionally fixed up actual typos in the patch content, though
never changing the number of lines.  The danger there is what happens
when you need to prepare v(N+1).  If you're going to need to change it
in git anyway, you might as well go ahead and do so and regenerate the
series.

I just wish I had a more satisfactory method of associating a cover
letter with a series *in git*, such that format-patch could emit a
non-placeholder cover letter.

- Josh Triplett

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

[Darren Hart]

On Fri, Jul 10, 2015 at 02:07:50PM -0700, Josh Triplett wrote:
> On Fri, Jul 10, 2015 at 10:03:43PM +0100, David Woodhouse wrote:
> > On Fri, 2015-07-10 at 13:56 -0700, josh@joshtriplett.org wrote:
> > > On Fri, Jul 10, 2015 at 09:00:12PM +0100, David Woodhouse wrote:
> > > > And then I can *read* them before sending them, which is good practice
> > > > anyway. Am I the only person who often finds a final minor nit with
> > > > their own patch, in that final read-through just before hitting 'send'
> > > > on an email?
> > > 
> > > Nope, I do that too.  (Though then I have to resist the temptation to
> > > just fix it in the mailer rather than fixing the original and
> > > regenerating.)
> > 
> > Oh, I *always* just fix it in the mailer, even when the numbers in the
> > hunk headers need to be fixed up :)
> 
> I've occasionally fixed up actual typos in the patch content, though
> never changing the number of lines.  The danger there is what happens
> when you need to prepare v(N+1).  If you're going to need to change it
> in git anyway, you might as well go ahead and do so and regenerate the
> series.
> 
> I just wish I had a more satisfactory method of associating a cover
> letter with a series *in git*, such that format-patch could emit a
> non-placeholder cover letter.

I use my tags for a similar purpose, combined with a git-pdx-pull-request.sh
script which generates the cover letter. And now that I bisected the missing
header, vger will actually deliver it to the list! \o/

-- 
Darren Hart
Intel Open Source Technology Center

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

[Geert Uytterhoeven]

On Fri, Jul 10, 2015 at 11:07 PM,  <josh@joshtriplett.org> wrote:
> I just wish I had a more satisfactory method of associating a cover
> letter with a series *in git*, such that format-patch could emit a
> non-placeholder cover letter.

You can use "git commit --allow-empty" to write cover letters.
Make sure they don't get lost during rebasing.

Still, if you include them in --format-patch, they will be "PATCH 1/n",
not "PATCH 0/n".

[...]

Oh cool, there's a "--start-number" option, will try...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Josh Triplett]

On Sun, Jul 12, 2015 at 12:28:07PM +0200, Geert Uytterhoeven wrote:
> On Fri, Jul 10, 2015 at 11:07 PM,  <josh@joshtriplett.org> wrote:
> > I just wish I had a more satisfactory method of associating a cover
> > letter with a series *in git*, such that format-patch could emit a
> > non-placeholder cover letter.
> 
> You can use "git commit --allow-empty" to write cover letters.
> Make sure they don't get lost during rebasing.
> 
> Still, if you include them in --format-patch, they will be "PATCH 1/n",
> not "PATCH 0/n".
> 
> [...]
> 
> Oh cool, there's a "--start-number" option, will try...

That's an amusing idea, though as you said, rebase will tend to throw
them away.  I've also seen cover letters done via git notes, but never
in a very satisfactory way.  Ideally, I'd love to see a message
associated with a given branch, such that that message can become the
cover letter, and if the branch gets merged that's the default merge
message.

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

[Darren Hart]

On Fri, Jul 10, 2015 at 09:00:12PM +0100, David Woodhouse wrote:
> On Fri, 2015-07-10 at 15:51 -0400, Steven Rostedt wrote:
> > On Thu, 9 Jul 2015 19:07:06 -0700
> > Darren Hart <dvhart@infradead.org> wrote:
> > 
> >  
> > > As far as recruitment goes, I think we're talking about barriers to first-timers
> > > and such - and git-send-email is one of those things. Eventually, a developer
> > 
> > +1000
> > 
> > I still don't use git-send-email, as I afraid that I'll blow it and end
> > up sending a thousand patches to every developer that ever touched the
> > kernel ;-)
> 
> Rather than sending messages, it's actually better to put them as
> *drafts*, ready to be sent by the user's normal mailer. It's not hard
> to do this — I usually dump the mails into
> ~/.local/share/evolution/mail/local/.Drafts/new/ for example.
> 
> And then I can *read* them before sending them, which is good practice
> anyway. Am I the only person who often finds a final minor nit with
> their own patch, in that final read-through just before hitting 'send'
> on an email?

I thought it was just me :)

I use git format-patch for this same purpose.

> 
> Perhaps we should provide tools which make it trivial to do the same
> for various different mail clients, without users having to know where,
> and in what form, their drafts folders are?
> 

An update to the documentation on mail clients would be welcome - although it's
looking pretty bleak out there for usable mail clients these days.

The fact that we're having this discussion among the folks that ostensibly know
what we're doing is very telling, in my opinion, of just how daunting a task
this can be for a new-comer.

-- 
Darren Hart
Intel Open Source Technology Center

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

[Geert Uytterhoeven]

On Fri, Jul 10, 2015 at 10:00 PM, David Woodhouse <dwmw2@infradead.org> wrote:
> On Fri, 2015-07-10 at 15:51 -0400, Steven Rostedt wrote:
>> On Thu, 9 Jul 2015 19:07:06 -0700
>> Darren Hart <dvhart@infradead.org> wrote:
>> > As far as recruitment goes, I think we're talking about barriers to first-timers
>> > and such - and git-send-email is one of those things. Eventually, a developer
>>
>> +1000
>>
>> I still don't use git-send-email, as I afraid that I'll blow it and end
>> up sending a thousand patches to every developer that ever touched the
>> kernel ;-)
>
> Rather than sending messages, it's actually better to put them as
> *drafts*, ready to be sent by the user's normal mailer. It's not hard
> to do this — I usually dump the mails into
> ~/.local/share/evolution/mail/local/.Drafts/new/ for example.

"Importing" patches in emails is one of the major reasons why they become
corrupted.

> And then I can *read* them before sending them, which is good practice
> anyway. Am I the only person who often finds a final minor nit with
> their own patch, in that final read-through just before hitting 'send'
> on an email?

"vi 0*patch"?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Laurent Pinchart]

On Friday 10 July 2015 21:00:12 David Woodhouse wrote:
> On Fri, 2015-07-10 at 15:51 -0400, Steven Rostedt wrote:
> > On Thu, 9 Jul 2015 19:07:06 -0700 Darren Hart wrote:
> > > As far as recruitment goes, I think we're talking about barriers to
> > > first-timers and such - and git-send-email is one of those things.
> > > Eventually, a developer> 
> > +1000
> > 
> > I still don't use git-send-email, as I afraid that I'll blow it and end
> > up sending a thousand patches to every developer that ever touched the
> > kernel ;-)
> 
> Rather than sending messages, it's actually better to put them as
> *drafts*, ready to be sent by the user's normal mailer. It's not hard
> to do this — I usually dump the mails into
> ~/.local/share/evolution/mail/local/.Drafts/new/ for example.
> 
> And then I can *read* them before sending them, which is good practice
> anyway. Am I the only person who often finds a final minor nit with
> their own patch, in that final read-through just before hitting 'send'
> on an email?

Certainly not, but what prevents you from doing that with git-send-email ? In 
my workflow I always format patches with git-format-patch, proof-read them 
with my favourite $EDITOR and then use git-send-email to send them.

> Perhaps we should provide tools which make it trivial to do the same
> for various different mail clients, without users having to know where,
> and in what form, their drafts folders are?

-- 
Regards,

Laurent Pinchart

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

[Geert Uytterhoeven]

On Mon, Jul 13, 2015 at 12:00 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Friday 10 July 2015 21:00:12 David Woodhouse wrote:
>> On Fri, 2015-07-10 at 15:51 -0400, Steven Rostedt wrote:
>> > On Thu, 9 Jul 2015 19:07:06 -0700 Darren Hart wrote:
>> > > As far as recruitment goes, I think we're talking about barriers to
>> > > first-timers and such - and git-send-email is one of those things.
>> > > Eventually, a developer>
>> > +1000
>> >
>> > I still don't use git-send-email, as I afraid that I'll blow it and end
>> > up sending a thousand patches to every developer that ever touched the
>> > kernel ;-)
>>
>> Rather than sending messages, it's actually better to put them as
>> *drafts*, ready to be sent by the user's normal mailer. It's not hard
>> to do this — I usually dump the mails into
>> ~/.local/share/evolution/mail/local/.Drafts/new/ for example.
>>
>> And then I can *read* them before sending them, which is good practice
>> anyway. Am I the only person who often finds a final minor nit with
>> their own patch, in that final read-through just before hitting 'send'
>> on an email?
>
> Certainly not, but what prevents you from doing that with git-send-email ? In
> my workflow I always format patches with git-format-patch, proof-read them
> with my favourite $EDITOR and then use git-send-email to send them.

Apparently some people think you should feed a rev-list to git-send-email
(a feature I learned about only recently), instead of patches created by
git-format-patch. As you need the patches for checkpatch.pl anyway...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Laurent Pinchart]

On Monday 13 July 2015 12:11:42 Geert Uytterhoeven wrote:
> On Mon, Jul 13, 2015 at 12:00 AM, Laurent Pinchart wrote:
> > On Friday 10 July 2015 21:00:12 David Woodhouse wrote:
> >> On Fri, 2015-07-10 at 15:51 -0400, Steven Rostedt wrote:
> >> > On Thu, 9 Jul 2015 19:07:06 -0700 Darren Hart wrote:
> >> > > As far as recruitment goes, I think we're talking about barriers to
> >> > > first-timers and such - and git-send-email is one of those things.
> >> > > Eventually, a developer>
> >> > 
> >> > +1000
> >> > 
> >> > I still don't use git-send-email, as I afraid that I'll blow it and end
> >> > up sending a thousand patches to every developer that ever touched the
> >> > kernel ;-)
> >> 
> >> Rather than sending messages, it's actually better to put them as
> >> *drafts*, ready to be sent by the user's normal mailer. It's not hard
> >> to do this — I usually dump the mails into
> >> ~/.local/share/evolution/mail/local/.Drafts/new/ for example.
> >> 
> >> And then I can *read* them before sending them, which is good practice
> >> anyway. Am I the only person who often finds a final minor nit with
> >> their own patch, in that final read-through just before hitting 'send'
> >> on an email?
> > 
> > Certainly not, but what prevents you from doing that with git-send-email ?
> > In my workflow I always format patches with git-format-patch, proof-read
> > them with my favourite $EDITOR and then use git-send-email to send them.
>
> Apparently some people think you should feed a rev-list to git-send-email
> (a feature I learned about only recently), instead of patches created by
> git-format-patch. As you need the patches for checkpatch.pl anyway...

Passing a revlist to git-send-email seems like asking for trouble, I certainly 
wouldn't recommend that. I use git-send-email as a glorified sendmail, I've 
even used it recently to send a party invitation to a large number of friends 
:-)

-- 
Regards,

Laurent Pinchart

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

[Guenter Roeck]

On Mon, Jul 13, 2015 at 01:00:14AM +0300, Laurent Pinchart wrote:
> On Friday 10 July 2015 21:00:12 David Woodhouse wrote:
> > On Fri, 2015-07-10 at 15:51 -0400, Steven Rostedt wrote:
> > > On Thu, 9 Jul 2015 19:07:06 -0700 Darren Hart wrote:
> > > > As far as recruitment goes, I think we're talking about barriers to
> > > > first-timers and such - and git-send-email is one of those things.
> > > > Eventually, a developer> 
> > > +1000
> > > 
> > > I still don't use git-send-email, as I afraid that I'll blow it and end
> > > up sending a thousand patches to every developer that ever touched the
> > > kernel ;-)
> > 
> > Rather than sending messages, it's actually better to put them as
> > *drafts*, ready to be sent by the user's normal mailer. It's not hard
> > to do this — I usually dump the mails into
> > ~/.local/share/evolution/mail/local/.Drafts/new/ for example.
> > 
> > And then I can *read* them before sending them, which is good practice
> > anyway. Am I the only person who often finds a final minor nit with
> > their own patch, in that final read-through just before hitting 'send'
> > on an email?
> 
> Certainly not, but what prevents you from doing that with git-send-email ? In 
> my workflow I always format patches with git-format-patch, proof-read them 
> with my favourite $EDITOR and then use git-send-email to send them.
> 
This exactly mateches my workflow (with an added 0000-Summary for patch
series where needed).

Guenter

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

[Jonathan Cameron]

On 13 July 2015 17:18:22 BST, Guenter Roeck <linux@roeck-us.net> wrote:
>On Mon, Jul 13, 2015 at 01:00:14AM +0300, Laurent Pinchart wrote:
>> On Friday 10 July 2015 21:00:12 David Woodhouse wrote:
>> > On Fri, 2015-07-10 at 15:51 -0400, Steven Rostedt wrote:
>> > > On Thu, 9 Jul 2015 19:07:06 -0700 Darren Hart wrote:
>> > > > As far as recruitment goes, I think we're talking about
>barriers to
>> > > > first-timers and such - and git-send-email is one of those
>things.
>> > > > Eventually, a developer> 
>> > > +1000
>> > > 
>> > > I still don't use git-send-email, as I afraid that I'll blow it
>and end
>> > > up sending a thousand patches to every developer that ever
>touched the
>> > > kernel ;-)
>> > 
>> > Rather than sending messages, it's actually better to put them as
>> > *drafts*, ready to be sent by the user's normal mailer. It's not
>hard
>> > to do this — I usually dump the mails into
>> > ~/.local/share/evolution/mail/local/.Drafts/new/ for example.
>> > 
>> > And then I can *read* them before sending them, which is good
>practice
>> > anyway. Am I the only person who often finds a final minor nit with
>> > their own patch, in that final read-through just before hitting
>'send'
>> > on an email?
>> 
>> Certainly not, but what prevents you from doing that with
>git-send-email ? In 
>> my workflow I always format patches with git-format-patch, proof-read
>them 
>> with my favourite $EDITOR and then use git-send-email to send them.
>> 
>This exactly mateches my workflow (with an added 0000-Summary for patch
>series where needed).
Likewise though often with a prestep of a sanity check in gitk.
>Guenter
>_______________________________________________
>Ksummit-discuss mailing list
>Ksummit-discuss@lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 862 bytes --]

On Mon, 2015-07-13 at 01:00 +0300, Laurent Pinchart wrote:
> 
> > And then I can *read* them before sending them, which is good practice
> > anyway. Am I the only person who often finds a final minor nit with
> > their own patch, in that final read-through just before hitting 'send'
> > on an email?
> 
> Certainly not, but what prevents you from doing that with git-send-email ? 

I don't know. It's not that I *can't* do that with git-send-email.

But I seem to see things differently when it's in a mail compose
window, and I *do* spot trivial issues there, that I've missed when
actually editing the code and even reviewing patches in gitk/etc.

Perhaps it's just the additional mental stimulus of physically
preparing to hit the 'send' button and send it out to the world with my
name on it.

Perhaps I'm just a bit weird.

-- dwmw2

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

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

[Jason Cooper]

On Tue, Jul 14, 2015 at 04:31:28PM +0100, David Woodhouse wrote:
> On Mon, 2015-07-13 at 01:00 +0300, Laurent Pinchart wrote:
> > 
> > > And then I can *read* them before sending them, which is good practice
> > > anyway. Am I the only person who often finds a final minor nit with
> > > their own patch, in that final read-through just before hitting 'send'
> > > on an email?
> > 
> > Certainly not, but what prevents you from doing that with git-send-email ? 
> 
> I don't know. It's not that I *can't* do that with git-send-email.
> 
> But I seem to see things differently when it's in a mail compose
> window, and I *do* spot trivial issues there, that I've missed when
> actually editing the code and even reviewing patches in gitk/etc.

I agree.  There's something different about viewing a patch in the mail
client vs in an editor or pager.

> Perhaps it's just the additional mental stimulus of physically
> preparing to hit the 'send' button and send it out to the world with my
> name on it.

It could also be that we're conditioned to reviewing patches in the mail
client.  So seeing the patch there triggers review-mode vice write-mode.

But I also think there's something about the review process prior to
'send' that catches mistakes as well.

thx,

Jason.

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

[Tim Bird]

On 07/10/2015 12:51 PM, Steven Rostedt wrote:
> On Thu, 9 Jul 2015 19:07:06 -0700
> Darren Hart <dvhart@infradead.org> wrote:
> 
>  
>> As far as recruitment goes, I think we're talking about barriers to first-timers
>> and such - and git-send-email is one of those things. Eventually, a developer
> 
> +1000
> 
> I still don't use git-send-email, as I afraid that I'll blow it and end
> up sending a thousand patches to every developer that ever touched the
> kernel ;-)

I'm in exactly the same boat.  I don't submit patches frequently enough
that I trust a git-send-email workflow.  It's too automated for me.
I'd rather take the extra time to manually format my patch e-mails and my
CC: lists, than be embarrassed.  Of course then I make manual mistakes
and end up getting embarrassed sometimes anyway, but I can usually
avoid a patch embarrassment armageddon.

But my manual steps and self-verification are a lot of work each time, so
some automation would be very much appreciated.
 
> I still use quilt to send my patch series. Just because I know how it
> works and I trust it. And I get to see exactly what it is about to send
> (the only thing it can send is what's in the patches/ directory,
> nothing else).
> 
> I have a script that takes my git tree and creates the patches in a
> format that quilt will send them nicely.

Maybe it would be good for a patch submission tool be able to single-step
through the submission preparation, both so that developers can learn
from it and not just use it as a crutch, and also to allow
developers to intervene if it's about to do something stupid.
 -- Tim

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

[Guenter]

On Fri, Jul 10, 2015 at 01:03:16PM -0700, Tim Bird wrote:
> On 07/10/2015 12:51 PM, Steven Rostedt wrote:
> > On Thu, 9 Jul 2015 19:07:06 -0700
> > Darren Hart <dvhart@infradead.org> wrote:
> > 
> >  
> >> As far as recruitment goes, I think we're talking about barriers to first-timers
> >> and such - and git-send-email is one of those things. Eventually, a developer
> > 
> > +1000
> > 
> > I still don't use git-send-email, as I afraid that I'll blow it and end
> > up sending a thousand patches to every developer that ever touched the
> > kernel ;-)
> 
> I'm in exactly the same boat.  I don't submit patches frequently enough
> that I trust a git-send-email workflow.  It's too automated for me.
> I'd rather take the extra time to manually format my patch e-mails and my
> CC: lists, than be embarrassed.  Of course then I make manual mistakes
> and end up getting embarrassed sometimes anyway, but I can usually
> avoid a patch embarrassment armageddon.
> 
I use git send-email, but I don't use it blindly. If I use it directly,
I give it a trial first with --dry-run. For patch series I use a directory
to collect the patches and then use a script to actually send them.
Sometimes I also use --cc-cmd with a script I have written to automatically
add Cc's, but never without dry-run.

Guenter

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

[josh]

On Fri, Jul 10, 2015 at 03:51:44PM -0400, Steven Rostedt wrote:
> On Thu, 9 Jul 2015 19:07:06 -0700
> Darren Hart <dvhart@infradead.org> wrote:
> > As far as recruitment goes, I think we're talking about barriers to first-timers
> > and such - and git-send-email is one of those things. Eventually, a developer
> 
> +1000
> 
> I still don't use git-send-email, as I afraid that I'll blow it and end
> up sending a thousand patches to every developer that ever touched the
> kernel ;-)

I don't use git-send-email either.  I use git-format-patch
--cover-letter --thread, and then mutt -H to individually send each
mail.  (I originally added the --thread and --in-reply-to options to
git-format-patch, so that you don't need to use git-send-email for
that.)

The one thing I *do* find annoying is that the combination of
format-patch and get_maintainers.pl can't easily say "I want to send all
the patches and the cover letter to the same set of people, based on
every patch".  (Or, at the very least, the cover letter to everyone.)
Otherwise, maintainers get one patch out of the series, which may be
confusing without context, and the cover letter doesn't go to anyone.
Unfortunately, fixing that then tends to hit LKML's limit on number of
recipients.

- Josh Triplett

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

[Darren Hart]

On Fri, Jul 10, 2015 at 01:54:18PM -0700, Josh Triplett wrote:
> On Fri, Jul 10, 2015 at 03:51:44PM -0400, Steven Rostedt wrote:
> > On Thu, 9 Jul 2015 19:07:06 -0700
> > Darren Hart <dvhart@infradead.org> wrote:
> > > As far as recruitment goes, I think we're talking about barriers to first-timers
> > > and such - and git-send-email is one of those things. Eventually, a developer
> > 
> > +1000
> > 
> > I still don't use git-send-email, as I afraid that I'll blow it and end
> > up sending a thousand patches to every developer that ever touched the
> > kernel ;-)
> 
> I don't use git-send-email either.  I use git-format-patch
> --cover-letter --thread, and then mutt -H to individually send each
> mail.  (I originally added the --thread and --in-reply-to options to
> git-format-patch, so that you don't need to use git-send-email for
> that.)
> 
> The one thing I *do* find annoying is that the combination of
> format-patch and get_maintainers.pl can't easily say "I want to send all
> the patches and the cover letter to the same set of people, based on
> every patch".  (Or, at the very least, the cover letter to everyone.)

A bit off topic, but:

+1000 (thanks for that Steven)

This is partly why I wrote create-pull-request and submit-pull-request for the
Yocto Project.

http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/scripts/create-pull-request
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/scripts/send-pull-request

They build the recipient list for each patch and the aggregate for the cover
letter, set confirm always, and disable git-send-email CC policy to avoid
spamming the planet.

> Otherwise, maintainers get one patch out of the series, which may be
> confusing without context, and the cover letter doesn't go to anyone.
> Unfortunately, fixing that then tends to hit LKML's limit on number of
> recipients.
> 
> - Josh Triplett
> 

-- 
Darren Hart
Intel Open Source Technology Center

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

[Dan Williams]

On Fri, Jul 10, 2015 at 1:54 PM,  <josh@joshtriplett.org> wrote:
> On Fri, Jul 10, 2015 at 03:51:44PM -0400, Steven Rostedt wrote:
>> On Thu, 9 Jul 2015 19:07:06 -0700
>> Darren Hart <dvhart@infradead.org> wrote:
>> > As far as recruitment goes, I think we're talking about barriers to first-timers
>> > and such - and git-send-email is one of those things. Eventually, a developer
>>
>> +1000
>>
>> I still don't use git-send-email, as I afraid that I'll blow it and end
>> up sending a thousand patches to every developer that ever touched the
>> kernel ;-)
>
> I don't use git-send-email either.  I use git-format-patch
> --cover-letter --thread, and then mutt -H to individually send each
> mail.  (I originally added the --thread and --in-reply-to options to
> git-format-patch, so that you don't need to use git-send-email for
> that.)
>
> The one thing I *do* find annoying is that the combination of
> format-patch and get_maintainers.pl can't easily say "I want to send all
> the patches and the cover letter to the same set of people, based on
> every patch".  (Or, at the very least, the cover letter to everyone.)
> Otherwise, maintainers get one patch out of the series, which may be
> confusing without context, and the cover letter doesn't go to anyone.
> Unfortunately, fixing that then tends to hit LKML's limit on number of
> recipients.
>

I carry this patch on top of StGit for exactly this purpose.

commit 562aca51a303e841a76defc3148db5c69b688994
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Thu Feb 27 11:54:32 2014 -0800

    mail: auto cc cover letter to union of all attribution tags in a series

    If a receiver is only copied on the a single patch out of a larger
series she
    may not have the necessary context to judge the patch.  Auto cc her on the
    cover letter.

    Signed-off-by: Dan Williams <dan.j.williams@intel.com>

diff --git a/stgit/commands/mail.py b/stgit/commands/mail.py
index e641634981d6..d986b805dbc4 100644
--- a/stgit/commands/mail.py
+++ b/stgit/commands/mail.py
@@ -534,8 +534,18 @@ def __build_cover(tmpl, msg_id, options, patches):
     except Exception, ex:
         raise CmdException, 'template parsing error: %s' % str(ex)

+    extra_cc = []
+    if options.auto:
+        for patch in patches:
+            p = crt_series.get_patch(patch)
+            if p.get_description():
+                descr = p.get_description().strip()
+                extra_cc.extend(__get_signers_list(descr))
+        extra_cc = list(set(extra_cc))
+
+
     if not options.git:
-        __build_address_headers(msg, options)
+        __build_address_headers(msg, options, extra_cc)
     __build_extra_headers(msg, msg_id, options.in_reply_to)
     __encode_message(msg)

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

[Jason Cooper]

On Thu, Jul 09, 2015 at 11:31:49PM +0100, David Woodhouse wrote:
> On Thu, 2015-07-09 at 12:37 -0700, Darren Hart wrote:
> > I spend a highly disproportionate amount of my time, relative to measurable
> > quality impact to the kernel, going over the nuances of submitting patches.
> > 
> > 1) Must have a complete commit message
> > 2) DCO goes above the ---
> > 3) Include a patch changelog, do so below ---
> > 4) Cc maintainers :-)
> > 5) Checkpatch... checkpatch... checkpatch...
> > 6) Compiler warnings
> > 7) CodingStyle :-)
> > 8) Use ascii or utf8 character encodings
> > 
> > All of these are distractions from reviewing the code. I'm often on 
> > version 3 of a series before I'm actually reviewing content.
> 
> I don't think it's entirely appropriate to call all of those
> 'distractions'.

Thank you for writing this a lot more clearly than I had in my head.

> The "content" in question is a proposed change to the code base. Such a
> change requires a coherent commit message which will make sense when we
> look back at this commit in the future. We will need to understand what
> was happening and why, in order to fix it or tweak it for new
> circumstances.
> 
> Doing that is *not* a peculiarity of the Linux 'process'. It is basic
> engineering discipline, and it is *part* of the work. Just like the
> task of breaking a change down into incremental, bisectable commits —
> which I'm surprised wasn't in your list.
> 
> Yes, there are a lot of people who *lack* that basic engineering
> discipline, to the point where it *can* start to look like it's a Linux
> -only requirement. But it's not. And there's not a lot we can do if an
> "engineer" lacks it, short of educating them. That part isn't a process
> issue.
> 
> Likewise, compiler warnings. If your developers are actually
> *submitting* code with unresolved compiler warnings, again there's not
> a lot we can do to help them or you. Apart from confiscating their
> keyboard.
> 
> Coding style, again, isn't a Linux-specific thing. All large code bases
> attempt to have some kind of consistency to make the code readable, and
> anyone attempting to work on *any* code base should expect to become
> familiar with the idioms and conventions (and charset choice) of the
> code they're working on.
> 
> These *aren't* process issues, in my view. What you're saying with some
> of these is that you're having to do *basic* (non-Linux-specific)
> education of people who want to contribute code, and that *that*
> doesn't scale. Which is true, but it's hard to know how to address
> that, except with programs like GSoC etc.

What we're also looking at here is adjusting the wetware / software
boundary.  The goal of checkpatch is the same: offload maintainer brain
time onto automated software.  But it's a double-edged sword.  Now we
see checkpatch-only patches.  Was it a net-gain for maintainer relief?
Or simply a shift in the type of annoyances?

I don't know.  The lesson learned from checkpatch and other tools
shouldn't be lost on any effort we try today.  That's not to say we
shouldn't try.  Rather, we should try new processes and tooling, *and*
establish sane goals for the same.  "After 1 year of autotest@vger,
we'll poll the maintainers and ask if they noticed a difference."  This
implies some sort of tag system so maintainers can trivially tell when a
patch has cleared autotest@vger.  Maybe:

Autotest-passed: https://autotest.kernel.org/2015/07/10/<cookie>

Depending on the proposed system, the goal can be more quantifiable, if
needed.

> Josh suggests that we should provide a service that people could push
> code to and 'get automated feedback on what needs fixing'... but isn't
> that what checkpatch was for? OK, a local tool can't cross-compile it
> for you on every platform we support, but it can do a lot of stuff
> short of that.
> 
> I do like the idea of a 'test' mailing list which receives patches and
> checks them for corruption though.

Agree.  And in sensible cases, it can suggest a fix.  e.g. "Missing
S-o-b, please read the DCO [link]. If you agree, add your S-o-b to the
end of the commit message.  'git commit -s ...' will add this for you."

wrt recruitment, It would be advisable for a few maintainers who are
interested to be subscribed to autotest@vger to keep an eye on things
and intervene if necessary.

thx,

Jason.

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

[Darren Hart]

On Fri, Jul 10, 2015 at 12:32:34PM +0000, Jason Cooper wrote:
> What we're also looking at here is adjusting the wetware / software
> boundary.  The goal of checkpatch is the same: offload maintainer brain
> time onto automated software.  But it's a double-edged sword.  Now we
> see checkpatch-only patches.  Was it a net-gain for maintainer relief?
> Or simply a shift in the type of annoyances?
> 
> I don't know.  The lesson learned from checkpatch and other tools
> shouldn't be lost on any effort we try today.  That's not to say we
> shouldn't try.  Rather, we should try new processes and tooling, *and*
> establish sane goals for the same.  "After 1 year of autotest@vger,
> we'll poll the maintainers and ask if they noticed a difference."  This
> implies some sort of tag system so maintainers can trivially tell when a
> patch has cleared autotest@vger.  Maybe:
> 
> Autotest-passed: https://autotest.kernel.org/2015/07/10/<cookie>
> 
> Depending on the proposed system, the goal can be more quantifiable, if
> needed.

I was going to suggest pretty much the same thing.

> 
> > Josh suggests that we should provide a service that people could push
> > code to and 'get automated feedback on what needs fixing'... but isn't
> > that what checkpatch was for? OK, a local tool can't cross-compile it
> > for you on every platform we support, but it can do a lot of stuff
> > short of that.
> > 
> > I do like the idea of a 'test' mailing list which receives patches and
> > checks them for corruption though.
> 
> Agree.  And in sensible cases, it can suggest a fix.  e.g. "Missing
> S-o-b, please read the DCO [link]. If you agree, add your S-o-b to the
> end of the commit message.  'git commit -s ...' will add this for you."
> 

I presume this would go back to the list and the submitter. I can see arguments
for and against including anyone else on Cc from the original patch. What did
you have in mind?

> wrt recruitment, It would be advisable for a few maintainers who are
> interested to be subscribed to autotest@vger to keep an eye on things
> and intervene if necessary.
> 
> thx,
> 
> Jason.
> 

-- 
Darren Hart
Intel Open Source Technology Center

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

[Jason Cooper]

On Fri, Jul 10, 2015 at 08:54:03AM -0700, Darren Hart wrote:
> On Fri, Jul 10, 2015 at 12:32:34PM +0000, Jason Cooper wrote:
> > What we're also looking at here is adjusting the wetware / software
> > boundary.  The goal of checkpatch is the same: offload maintainer brain
> > time onto automated software.  But it's a double-edged sword.  Now we
> > see checkpatch-only patches.  Was it a net-gain for maintainer relief?
> > Or simply a shift in the type of annoyances?
> > 
> > I don't know.  The lesson learned from checkpatch and other tools
> > shouldn't be lost on any effort we try today.  That's not to say we
> > shouldn't try.  Rather, we should try new processes and tooling, *and*
> > establish sane goals for the same.  "After 1 year of autotest@vger,
> > we'll poll the maintainers and ask if they noticed a difference."  This
> > implies some sort of tag system so maintainers can trivially tell when a
> > patch has cleared autotest@vger.  Maybe:
> > 
> > Autotest-passed: https://autotest.kernel.org/2015/07/10/<cookie>
> > 
> > Depending on the proposed system, the goal can be more quantifiable, if
> > needed.
> 
> I was going to suggest pretty much the same thing.
> 
> > 
> > > Josh suggests that we should provide a service that people could push
> > > code to and 'get automated feedback on what needs fixing'... but isn't
> > > that what checkpatch was for? OK, a local tool can't cross-compile it
> > > for you on every platform we support, but it can do a lot of stuff
> > > short of that.
> > > 
> > > I do like the idea of a 'test' mailing list which receives patches and
> > > checks them for corruption though.
> > 
> > Agree.  And in sensible cases, it can suggest a fix.  e.g. "Missing
> > S-o-b, please read the DCO [link]. If you agree, add your S-o-b to the
> > end of the commit message.  'git commit -s ...' will add this for you."
> > 
> 
> I presume this would go back to the list and the submitter. I can see arguments
> for and against including anyone else on Cc from the original patch. What did
> you have in mind?

List and submitter.  That way, receiving parties are all opted-in to the
noise.

thx,

Jason.

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

[Dan Carpenter]

On Thu, Jul 09, 2015 at 12:37:18PM -0700, Darren Hart wrote:
> I spend a highly disproportionate amount of my time, relative to measurable
> quality impact to the kernel, going over the nuances of submitting patches.
> 
> 1) Must have a complete commit message
> 2) DCO goes above the ---
> 3) Include a patch changelog, do so below ---
> 4) Cc maintainers :-)
> 5) Checkpatch... checkpatch... checkpatch...
> 6) Compiler warnings
> 7) CodingStyle :-)
> 8) Use ascii or utf8 character encodings
> 

The same people who don't run checkpatch.pl will also not opt in to your
QC system.

You should create a procmail filter to processes patches.  If the patch
fails then it changes the subject from [patch] to [fail] and stores a
response (compile warnings etc) in a directory.  Then you trigger a
macro in mutt and it mails the response.

Or you could just create a generic form letter like Greg does.

regards,
dan carpenter

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

[Darren Hart]

On Fri, Jul 10, 2015 at 05:36:41PM +0300, Dan Carpenter wrote:
> On Thu, Jul 09, 2015 at 12:37:18PM -0700, Darren Hart wrote:
> > I spend a highly disproportionate amount of my time, relative to measurable
> > quality impact to the kernel, going over the nuances of submitting patches.
> > 
> > 1) Must have a complete commit message
> > 2) DCO goes above the ---
> > 3) Include a patch changelog, do so below ---
> > 4) Cc maintainers :-)
> > 5) Checkpatch... checkpatch... checkpatch...
> > 6) Compiler warnings
> > 7) CodingStyle :-)
> > 8) Use ascii or utf8 character encodings
> > 
> 
> The same people who don't run checkpatch.pl will also not opt in to your
> QC system.

I think they would if it the barrier to use it was lower than LKML. Between our
very stringent email formatting requirements and the stigma associated with
screwing it up, I think a prominent "Kernel Patch Submitter" web form would be
readily used by a lot of first timers.

Once they are used to using that and want to move on to a patch series, we can
have instructions on how to do that, which might include a web form which
accepts a publicly visible git repository url and branch or tag, along with all
the other required cover letter stuff as part of a form.

(See Steve Rostedts response on web forms)

> You should create a procmail filter to processes patches.  If the patch
> fails then it changes the subject from [patch] to [fail] and stores a
> response (compile warnings etc) in a directory.  Then you trigger a
> macro in mutt and it mails the response.
> 
> Or you could just create a generic form letter like Greg does.
> 

OK, so this is precisely the kind of individually developed special purpose
wizardry that I think hinders recruitment. Rather than having every maintainer
reinvent this wheel in a subtly different a personal way (which gets back to the
issues raised about subtly different expectations per maintainer), it makes a
lot of sense to me to create a common infrastructure that we can all use.

Thanks,

-- 
Darren Hart
Intel Open Source Technology Center

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

[Greg KH]

On Fri, Jul 10, 2015 at 09:07:14AM -0700, Darren Hart wrote:
> On Fri, Jul 10, 2015 at 05:36:41PM +0300, Dan Carpenter wrote:
> > Or you could just create a generic form letter like Greg does.
> > 
> 
> OK, so this is precisely the kind of individually developed special purpose
> wizardry that I think hinders recruitment. Rather than having every maintainer
> reinvent this wheel in a subtly different a personal way (which gets back to the
> issues raised about subtly different expectations per maintainer), it makes a
> lot of sense to me to create a common infrastructure that we can all use.

Ok, feel free to use my "form letter" that I've created over the years
and expand on it for more common problems if I've missed anything.  I
just dump it into a response to the patch (3 keystrokes), and cut away
anything that isn't relevant to this specific patch.  Seems to work
pretty well in cutting down on me having to type the same thing all the
time.

--------------------------


Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- Your patch breaks the build.

- Your patch contains warnings and/or errors noticed by the
  scripts/checkpatch.pl tool.

- Your patch is malformed (tabs converted to spaces, linewrapped, etc.)
  and can not be applied.  Please read the file,
  Documentation/email-clients.txt in order to fix this.

- Your patch does not have a Signed-off-by: line.  Please read the
  kernel file, Documentation/SubmittingPatches and resend it after
  adding that line.  Note, the line needs to be in the body of the
  email, before the patch, not at the bottom of the patch or in the
  email signature.

- Your patch was sent privately to Greg.  Kernel development is done in
  public, please always cc: a public mailing list with a patch
  submission.  Using the tool, scripts/get_maintainer.pl on the patch
  will tell you what mailing list to cc.

- Your patch did many different things all at once, making it difficult
  to review.  All Linux kernel patches need to only do one thing at a
  time.  If you need to do multiple things (such as clean up all coding
  style issues in a file/driver), do it in a sequence of patches, each
  one doing only one thing.  This will make it easier to review the
  patches to ensure that they are correct, and to help alleviate any
  merge issues that larger patches can cause.

- Your patch did not apply to any known trees that Greg is in control
  of.  Possibly this is because you made it against Linus's tree, not
  the linux-next tree, which is where all of the development for the
  next version of the kernel is at.  Please refresh your patch against
  the linux-next tree, or even better yet, the development tree
  specified in the MAINTAINERS file for the subsystem you are submitting
  a patch for, and resend it.

- You sent multiple patches, yet no indication of which ones should be
  applied in which order.  Greg could just guess, but if you are
  receiving this email, he guessed wrong and the patches didn't apply.
  Please read the section entitled "The canonical patch format" in the
  kernel file, Documentation/SubmittingPatches for a description of how
  to do this so that Greg has a chance to apply these correctly.

- You did not specify a description of why the patch is needed, or
  possibly, any description at all, in the email body.  Please read the
  section entitled "The canonical patch format" in the kernel file,
  Documentation/SubmittingPatches for what is needed in order to
  properly describe the change.

- You did not write a descriptive Subject: for the patch, allowing Greg,
  and everyone else, to know what this patch is all about.  Please read
  the section entitled "The canonical patch format" in the kernel file,
  Documentation/SubmittingPatches for what a proper Subject: line should
  look like.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot

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

[Darren Hart]

On Fri, Jul 10, 2015 at 03:23:51PM -0700, Greg KH wrote:
> On Fri, Jul 10, 2015 at 09:07:14AM -0700, Darren Hart wrote:
> > On Fri, Jul 10, 2015 at 05:36:41PM +0300, Dan Carpenter wrote:
> > > Or you could just create a generic form letter like Greg does.
> > > 
> > 
> > OK, so this is precisely the kind of individually developed special purpose
> > wizardry that I think hinders recruitment. Rather than having every maintainer
> > reinvent this wheel in a subtly different a personal way (which gets back to the
> > issues raised about subtly different expectations per maintainer), it makes a
> > lot of sense to me to create a common infrastructure that we can all use.
> 
> Ok, feel free to use my "form letter" that I've created over the years
> and expand on it for more common problems if I've missed anything.  I
> just dump it into a response to the patch (3 keystrokes), and cut away
> anything that isn't relevant to this specific patch.  Seems to work
> pretty well in cutting down on me having to type the same thing all the
> time.

Do you have something that automates the scanning for basic errors and builds
and reports to you - or do you manually pull every patch out of your email
client and run those tests yourself to find that the patch-bot needs to be
deployed? That's the kind of thing that it seems like could be automated and
improve the quality level of patches that make it to the maintainers.

-- 
Darren Hart
Intel Open Source Technology Center

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

[Greg KH]

On Fri, Jul 10, 2015 at 05:00:34PM -0700, Darren Hart wrote:
> On Fri, Jul 10, 2015 at 03:23:51PM -0700, Greg KH wrote:
> > On Fri, Jul 10, 2015 at 09:07:14AM -0700, Darren Hart wrote:
> > > On Fri, Jul 10, 2015 at 05:36:41PM +0300, Dan Carpenter wrote:
> > > > Or you could just create a generic form letter like Greg does.
> > > > 
> > > 
> > > OK, so this is precisely the kind of individually developed special purpose
> > > wizardry that I think hinders recruitment. Rather than having every maintainer
> > > reinvent this wheel in a subtly different a personal way (which gets back to the
> > > issues raised about subtly different expectations per maintainer), it makes a
> > > lot of sense to me to create a common infrastructure that we can all use.
> > 
> > Ok, feel free to use my "form letter" that I've created over the years
> > and expand on it for more common problems if I've missed anything.  I
> > just dump it into a response to the patch (3 keystrokes), and cut away
> > anything that isn't relevant to this specific patch.  Seems to work
> > pretty well in cutting down on me having to type the same thing all the
> > time.
> 
> Do you have something that automates the scanning for basic errors and builds
> and reports to you - or do you manually pull every patch out of your email
> client and run those tests yourself to find that the patch-bot needs to be
> deployed?

Almost all of the issues I list in that response I find just by looking
at the patch, they jump out instantly.  The ones for when the build is
broken or the patch doesn't apply get found when I do my "apply this
mbox of patches" work, which I usually do in chunks of 5 patches at a
time.

So no, I don't have anything automated, so yes almost all of these could
be found by a tool.  Oh look, we have that tool, which no one uses,
checkpatch.pl.

Ok, checkpatch will not catch the issue where your email client is
messed up, or when you send a series of patches with no numbering on
them, but that's way down the list of errors that I see by quantity.
And I think I review more "first timer" patches than anyone else in the
community.  If people actually ran checkpatch it would resolve almost
all of the issues I see.

> That's the kind of thing that it seems like could be automated and
> improve the quality level of patches that make it to the maintainers.

All of these are the "simple" issues that really don't take long to
resolve.  We have it documented in great detail on how to set up an
email client, how to format the patch, and how to get everything right
on the kernelnewbies.org site.  I also teach a class on this, one hour
max is all it takes, unless you are at a company with a broken email
system.  And then all bets are off, you better just install a Linux
email server in the corner to resolve your email issues, just like all
the major companies did (IBM, Intel, Microsoft, etc.)

I applaud your attempt here, and don't want to stop you from working on
it, but I think the real issue is having people actually look for the
documentation and tools we already have created to do this.  If you make
yet-another-tool, how are you going to advertise it any better than the
existing tools/documentation are?

good luck,

greg k-h

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

[Darren Hart]

On Fri, Jul 10, 2015 at 05:13:48PM -0700, Greg KH wrote:
> On Fri, Jul 10, 2015 at 05:00:34PM -0700, Darren Hart wrote:
> > On Fri, Jul 10, 2015 at 03:23:51PM -0700, Greg KH wrote:
> > > On Fri, Jul 10, 2015 at 09:07:14AM -0700, Darren Hart wrote:
> > > > On Fri, Jul 10, 2015 at 05:36:41PM +0300, Dan Carpenter wrote:
> > > > > Or you could just create a generic form letter like Greg does.
> > > > > 
> > > > 
> > > > OK, so this is precisely the kind of individually developed special purpose
> > > > wizardry that I think hinders recruitment. Rather than having every maintainer
> > > > reinvent this wheel in a subtly different a personal way (which gets back to the
> > > > issues raised about subtly different expectations per maintainer), it makes a
> > > > lot of sense to me to create a common infrastructure that we can all use.
> > > 
> > > Ok, feel free to use my "form letter" that I've created over the years
> > > and expand on it for more common problems if I've missed anything.  I
> > > just dump it into a response to the patch (3 keystrokes), and cut away
> > > anything that isn't relevant to this specific patch.  Seems to work
> > > pretty well in cutting down on me having to type the same thing all the
> > > time.
> > 
> > Do you have something that automates the scanning for basic errors and builds
> > and reports to you - or do you manually pull every patch out of your email
> > client and run those tests yourself to find that the patch-bot needs to be
> > deployed?
> 
> Almost all of the issues I list in that response I find just by looking
> at the patch, they jump out instantly.  The ones for when the build is
> broken or the patch doesn't apply get found when I do my "apply this
> mbox of patches" work, which I usually do in chunks of 5 patches at a
> time.
> 
> So no, I don't have anything automated, so yes almost all of these could
> be found by a tool.  Oh look, we have that tool, which no one uses,
> checkpatch.pl.
> 
> Ok, checkpatch will not catch the issue where your email client is
> messed up, or when you send a series of patches with no numbering on
> them, but that's way down the list of errors that I see by quantity.
> And I think I review more "first timer" patches than anyone else in the
> community.  If people actually ran checkpatch it would resolve almost
> all of the issues I see.
> 
> > That's the kind of thing that it seems like could be automated and
> > improve the quality level of patches that make it to the maintainers.
> 
> All of these are the "simple" issues that really don't take long to
> resolve.  We have it documented in great detail on how to set up an
> email client, how to format the patch, and how to get everything right
> on the kernelnewbies.org site.  I also teach a class on this, one hour
> max is all it takes, unless you are at a company with a broken email
> system.  And then all bets are off, you better just install a Linux
> email server in the corner to resolve your email issues, just like all
> the major companies did (IBM, Intel, Microsoft, etc.)

OK, all good points. It looks as though I can step up my own tooling some to
make the email-to-compilation step faster so I don't spend as much time on
patches with compiler warnings, that don't apply, etc. Dan C. said something
similar.

The "one hour class" thing makes it sound like it takes "one hour" - but I find
I have to revisit this stuff fairly regularly, and those hours add up.

> I applaud your attempt here, and don't want to stop you from working on
> it, but I think the real issue is having people actually look for the
> documentation and tools we already have created to do this.  If you make
> yet-another-tool, how are you going to advertise it any better than the
> existing tools/documentation are?

That's definitely the key. Right now, people go through *some* process to
discover how to send their first patch to LKML - somehow they often manage to do
that without discovering (or choosing to use) checkpatch.pl or run some
reasonable set of build tests. In order for something like what is being
proposed here, the new tool would have to have to be:

1) Easier to find
2) Easier to use
3) Presented as a path to patch submission
   (not an extra tool to run beforehand)

The idea being that the patch submission process would include some automated
vetting, which catches trivial stuff for first-timers, but which also catches
more complex things by integrating with 0-day or similar. I wouldn't mind not
seeing a patch until after 0-day automatically provided feedback from all the
static analyzers and config fuzz build testing if that could be seemlessly
injected into the patch submission process.

I have people ask me about web based revision control tooling for Linux and
other projects fairly regularly. I do believe that if we made it available,
many first-timers would find it to be a much lower barrier to entry.

Of course, the output has to adhere to the current process such that it
doesn't impact the scalability of our top maintainers like you and Linus.

-- 
Darren Hart
Intel Open Source Technology Center

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

[Greg KH]

On Fri, Jul 10, 2015 at 07:39:46PM -0700, Darren Hart wrote:
> OK, all good points. It looks as though I can step up my own tooling some to
> make the email-to-compilation step faster so I don't spend as much time on
> patches with compiler warnings, that don't apply, etc. Dan C. said something
> similar.

I think I mentioned it before, but Wolfram has a set of scripts that
does this really well.  I don't know if they are published anywhere, but
that would be a good place to start with.  I think Sara Sharp also had a
bunch that she used to make life easier, you might want to ask her the
next time you see her in the office.

> The "one hour class" thing makes it sound like it takes "one hour" - but I find
> I have to revisit this stuff fairly regularly, and those hours add up.

Really?  Why?  Once you learn the workflow, what keeps changing that
breaks things?  External stuff (like corporate email servers), or things
in our workflow/tools?

thanks,

greg k-h

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

[Peter Hüwe]

Am Samstag, 11. Juli 2015, 17:04:37 schrieb Greg KH:
> On Fri, Jul 10, 2015 at 07:39:46PM -0700, Darren Hart wrote:
> > OK, all good points. It looks as though I can step up my own tooling some
> > to make the email-to-compilation step faster so I don't spend as much
> > time on patches with compiler warnings, that don't apply, etc. Dan C.
> > said something similar.
> 
> I think I mentioned it before, but Wolfram has a set of scripts that
> does this really well.  I don't know if they are published anywhere, but
> that would be a good place to start with.  I think Sara Sharp also had a
> bunch that she used to make life easier, you might want to ask her the
> next time you see her in the office.


They are called ninja-check and published here
https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2014-May/000554.html

Ksummit Thread about all these tools can be found here:
ftp://kernel.mirrors.pair.com/pub/linux/kernel/people/paulmck/LKS/LKS2014Topic/000291.html


Thanks,
Peter

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

[Darren Hart]

On Sun, Jul 12, 2015 at 11:27:08PM +0200, Peter Hüwe wrote:
> Am Samstag, 11. Juli 2015, 17:04:37 schrieb Greg KH:
> > On Fri, Jul 10, 2015 at 07:39:46PM -0700, Darren Hart wrote:
> > > OK, all good points. It looks as though I can step up my own tooling some
> > > to make the email-to-compilation step faster so I don't spend as much
> > > time on patches with compiler warnings, that don't apply, etc. Dan C.
> > > said something similar.
> > 
> > I think I mentioned it before, but Wolfram has a set of scripts that
> > does this really well.  I don't know if they are published anywhere, but
> > that would be a good place to start with.  I think Sara Sharp also had a
> > bunch that she used to make life easier, you might want to ask her the
> > next time you see her in the office.
> 
> 
> They are called ninja-check and published here
> https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2014-May/000554.html
> 
> Ksummit Thread about all these tools can be found here:
> ftp://kernel.mirrors.pair.com/pub/linux/kernel/people/paulmck/LKS/LKS2014Topic/000291.html

Thank you all very much for these pointers. I have ninja-check up and running
all the checkers now. Between these and:

http://www.do-not-panic.com/2014/07/applying-patches-from-mutt-onto-git.html
(view source for actual .muttrc as his blog hides <pipe-entry> and <tag-prefix>)

And Ben's original:
http://flavioleitner.blogspot.com/2011/03/patch-workflow-with-mutt-and-git.html

I added a checkpatch binding as well.

I now have a much more capable mutt-to-git interface which should help a ton. It
took me a day while dodging everything else I could, and I'll continue to tweak
it forever of course. Well worth the effort.

-- 
Darren Hart
Intel Open Source Technology Center

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

[Darren Hart]

On Sat, Jul 11, 2015 at 08:04:37AM -0700, Greg KH wrote:
> On Fri, Jul 10, 2015 at 07:39:46PM -0700, Darren Hart wrote:
> > OK, all good points. It looks as though I can step up my own tooling some to
> > make the email-to-compilation step faster so I don't spend as much time on
> > patches with compiler warnings, that don't apply, etc. Dan C. said something
> > similar.
> 
> I think I mentioned it before, but Wolfram has a set of scripts that
> does this really well.  I don't know if they are published anywhere, but
> that would be a good place to start with.  I think Sara Sharp also had a
> bunch that she used to make life easier, you might want to ask her the
> next time you see her in the office.

Will do. I think Jani sent me a set of scripts I need to review too.

Actually, in this sense, I'm the newbie maintainer who's spending time writing
up scripts, tools, and mutt macros to handle a process that 970 other people
have probably already written. I'll do so in a subtly different way of course,
and this will add ever so slightly to the variation in expectations and
behaviors of the Linux maintainers.

Maybe patchwork will be an improvement for tracking. Maybe not. While I do enjoy
writing up these scripts and tools to automate my job as a maintainer.... my
ability - or maybe willingness - to do so, shouldn't be what qualifies me for
the job. More tooling that standardized the process and makes the code review
more accessible to people less interested in writing mutt macros, might expand
our pool of candidates.

> > The "one hour class" thing makes it sound like it takes "one hour" - but I find
> > I have to revisit this stuff fairly regularly, and those hours add up.
> 
> Really?  Why?  Once you learn the workflow, what keeps changing that
> breaks things?  External stuff (like corporate email servers), or things
> in our workflow/tools?

In my experience it's just more new people with the same questions. Once they're
up and running, it's minimal effort to keep going. It's the initial ramp up that
gets repeated. So it's not the "one hour" adding up for the newbie, it's that
"one hour" adding up for me as the instructor :-) I'd love to help reduce the
effort it takes to bring new people up (yup - totally selfish motivation here).

This is especially true when the new people don't stick around. I really don't
want to invest an hour in someone that has 3 patches to send and will never
return.

It can be more trying when someone is doing this for a job and not because they
are interested in becoming a regular contributor. Each step is another barrier
they'd just assume avoid. If they're new, they also don't understand the
workflow or how maintainers scale, so they push against things that don't make
sense for sending 1 patch - but are necessary for processing 1000. Many of these
training sessions involve a certain amount of "why can't we just ..." or "you
don't have gerrit setup?" or ... etc. Ultimately, it's just another barrier to
recruitment.

We can say we don't want people like that contributing anyway, but the end
result of that is less hardware supported, or even more burnt out senior Linux
kernel developers who pick up the load because it's easier than training new
people.

-- 
Darren Hart
Intel Open Source Technology Center

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

[Sudip Mukherjee]

>On Sat, Jul 11, 2015 at 5:43 AM, Greg KH <greg@kroah.com> wrote:
>
> I applaud your attempt here, and don't want to stop you from working on
> it, but I think the real issue is having people actually look for the
> documentation and tools we already have created to do this.  If you make
> yet-another-tool, how are you going to advertise it any better than the
> existing tools/documentation are?
I don't know if i should give my opinion here. I am here for almost one
year and am coming from Eudyptula. I think this thread was regarding
recruitment and high dropout rates.
So from a newbie's point of view, setting up git or mutt was never a
problem. Ok, maybe everyone needs to send his/her first patch two or
three itmes until he gets it right in the formating or commit message
or subject. But sending it using git send-email never had been a problem.
In my opinion the main problem is lack of direction or guidance. As a
newbie I send my first patch, it gets accepted, I have a party to
celebrate and do more style correction and few more patches are accepted.
But by that time I am getting bored with just style correction and want
to do something more.
Now the problem starts. No one is there to guide me and I as a newbie
will not be that much capable enough to find things to do on my own. And
I start loosing the interest. Newbies who are coming from Eudyptula or
starting on their own will face this. But on the otherhand participants
of Outreachy will get a Mentor to guide them and gets a stipend to keep
them motivated. Stipend may not matter to the right candidate who has
interest but having a mentor is the big difference.

Another problem, when a newbie tries to move out of staging to some other
subsystem he likes, the maintainer may not be that much responsive. Just
for example, i submitted a patch on November, 2014 and I am yet to receive
a reply or review to that and the patch was not a style correction patch.

And using git send-email and mutt with gmail is very easy, you do not
need to do any change in gmail. If you want I can give my .gitconfig
and .muttrc for your reference.

regards
sudip

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

[Julia Lawall]

On Sat, 11 Jul 2015, Sudip Mukherjee wrote:

> >On Sat, Jul 11, 2015 at 5:43 AM, Greg KH <greg@kroah.com> wrote:
> >
> > I applaud your attempt here, and don't want to stop you from working on
> > it, but I think the real issue is having people actually look for the
> > documentation and tools we already have created to do this.  If you make
> > yet-another-tool, how are you going to advertise it any better than the
> > existing tools/documentation are?
> I don't know if i should give my opinion here. I am here for almost one
> year and am coming from Eudyptula. I think this thread was regarding
> recruitment and high dropout rates.
> So from a newbie's point of view, setting up git or mutt was never a
> problem. Ok, maybe everyone needs to send his/her first patch two or
> three itmes until he gets it right in the formating or commit message
> or subject. But sending it using git send-email never had been a problem.
> In my opinion the main problem is lack of direction or guidance. As a
> newbie I send my first patch, it gets accepted, I have a party to
> celebrate and do more style correction and few more patches are accepted.
> But by that time I am getting bored with just style correction and want
> to do something more.
> Now the problem starts. No one is there to guide me and I as a newbie
> will not be that much capable enough to find things to do on my own. And
> I start loosing the interest. Newbies who are coming from Eudyptula or
> starting on their own will face this. But on the otherhand participants
> of Outreachy will get a Mentor to guide them and gets a stipend to keep
> them motivated. Stipend may not matter to the right candidate who has
> interest but having a mentor is the big difference.

This is a good point.  I keep thinking of making a "Stuff I don't like"
blog, which would contain things that I see that look unpleasant, but that
I don't have time to deal with immediately.  This would contain things
that are probably too complicated for checkpatch.  A typical entry might
be a list of functions that could be using devm functions.  Such a thing
could get newbies looking around in the code, seeing how things fit
together, etc.

> Another problem, when a newbie tries to move out of staging to some other
> subsystem he likes, the maintainer may not be that much responsive. Just
> for example, i submitted a patch on November, 2014 and I am yet to receive
> a reply or review to that and the patch was not a style correction patch.

This seems like the sort of problem that has existed since the beginning
of time, and will exist unti the end of time.  One has to just find
something else to do, if the maintainer is completely unresponsive.

julia

> And using git send-email and mutt with gmail is very easy, you do not
> need to do any change in gmail. If you want I can give my .gitconfig
> and .muttrc for your reference.
>
> regards
> sudip
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>

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

[Jason Cooper]

On Sat, Jul 11, 2015 at 09:29:47AM -0400, Julia Lawall wrote:
> On Sat, 11 Jul 2015, Sudip Mukherjee wrote:
> > >On Sat, Jul 11, 2015 at 5:43 AM, Greg KH <greg@kroah.com> wrote:
> > >
> > > I applaud your attempt here, and don't want to stop you from working on
> > > it, but I think the real issue is having people actually look for the
> > > documentation and tools we already have created to do this.  If you make
> > > yet-another-tool, how are you going to advertise it any better than the
> > > existing tools/documentation are?
> > > 
> > I don't know if i should give my opinion here. I am here for almost one
> > year and am coming from Eudyptula. I think this thread was regarding
> > recruitment and high dropout rates.
> > So from a newbie's point of view, setting up git or mutt was never a
> > problem. Ok, maybe everyone needs to send his/her first patch two or
> > three itmes until he gets it right in the formating or commit message
> > or subject. But sending it using git send-email never had been a problem.
> > In my opinion the main problem is lack of direction or guidance. As a
> > newbie I send my first patch, it gets accepted, I have a party to
> > celebrate and do more style correction and few more patches are accepted.
> > But by that time I am getting bored with just style correction and want
> > to do something more.
> > Now the problem starts. No one is there to guide me and I as a newbie
> > will not be that much capable enough to find things to do on my own. And
> > I start loosing the interest. Newbies who are coming from Eudyptula or
> > starting on their own will face this. But on the otherhand participants
> > of Outreachy will get a Mentor to guide them and gets a stipend to keep
> > them motivated. Stipend may not matter to the right candidate who has
> > interest but having a mentor is the big difference.

Thanks Sudip for sharing your experience.

> This is a good point.  I keep thinking of making a "Stuff I don't like"
> blog, which would contain things that I see that look unpleasant, but that
> I don't have time to deal with immediately.  This would contain things
> that are probably too complicated for checkpatch.  A typical entry might
> be a list of functions that could be using devm functions.  Such a thing
> could get newbies looking around in the code, seeing how things fit
> together, etc.
> 
> > Another problem, when a newbie tries to move out of staging to some other
> > subsystem he likes, the maintainer may not be that much responsive. Just
> > for example, i submitted a patch on November, 2014 and I am yet to receive
> > a reply or review to that and the patch was not a style correction patch.
> 
> This seems like the sort of problem that has existed since the beginning
> of time, and will exist unti the end of time.  

:(  I'll admit it's been a problem, but I strongly disagree that it will
always be that way.

afaict, there's two scenarios here:  1/ A dev wanting to help, but
doesn't have a personal itch to scratch.  2/ A dev with an itch to
scratch but an unresponsive maintainer.

wrt 1, there's always a lot of potential solutions for TODO lists and
the like.  The problem with them is they quickly become out of date, or
overcome by other changes.  Thus, they need to be maintained.  Typically
by the person knowledgeable in the subsystem.  Who has little time for
such activities.

We could say "Ask the maintainer" since that person usually has a list
of itches a mile long.  But that adds a coaching / mentoring burden to
the maintainer.

Perhaps that burden could be reduced by a 'kernel-mentor@v.k.o' ML?  The
idea is that a new contributor would Cc that in addition to the usual
Cc's.  Folks like me who enjoy mentoring would be subscribed and would
do most of the coaching, leaving the subsystem-specific critique to the
subsystem maintainers.

As for 2, I think the kernel-mentor@ could help here as well.  Those of
us subscribed to it know the flow of the kernel cycle, as well as the
bursty nature of some of the maintainers.  So we could advise "Go ahead
and resend" or "Maintainer X usually applies everything around -rc7, so
let's be patient."

If it works, we may even find maintainers kicking tasks they don't have
time for to kernel-mentor@ ...

thx,

Jason.

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

[Greg KH]

On Sat, Jul 11, 2015 at 03:18:44PM +0000, Jason Cooper wrote:
> Perhaps that burden could be reduced by a 'kernel-mentor@v.k.o' ML?

We already have such a mailing list, it's quite empty and quiet :(

In other words, this idea has been tried, maybe consider something else?

greg k-h

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

[Jason Cooper]

On Sat, Jul 11, 2015 at 09:45:35AM -0700, Greg KH wrote:
> On Sat, Jul 11, 2015 at 03:18:44PM +0000, Jason Cooper wrote:
> > Perhaps that burden could be reduced by a 'kernel-mentor@v.k.o' ML?
> 
> We already have such a mailing list, it's quite empty and quiet :(

Are you referring to linux-newbie?

  http://vger.kernel.org/vger-lists.html#linux-newbie

If so, yes.  It's empty and quiet.

> In other words, this idea has been tried, maybe consider something else?

Well, the key piece is having a few experienced maintainers active on
the list.  That doesn't seem to be the case on linux-newbie.  Also,
linux-newbie doesn't seem to be kernel-specific.

We could address new users not knowing about it with a script.  Any
[PATCH] posts to a mailing list where the sender is a miss in the git
history bounces the email to the kernel-mentor list.

In case it wasn't obvious, I'd be willing to be one of those mentors if
I had a few others to rotate lead with.

thx,

Jason.

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

[Greg KH]

On Sat, Jul 11, 2015 at 07:35:39PM +0000, Jason Cooper wrote:
> On Sat, Jul 11, 2015 at 09:45:35AM -0700, Greg KH wrote:
> > On Sat, Jul 11, 2015 at 03:18:44PM +0000, Jason Cooper wrote:
> > > Perhaps that burden could be reduced by a 'kernel-mentor@v.k.o' ML?
> > 
> > We already have such a mailing list, it's quite empty and quiet :(
> 
> Are you referring to linux-newbie?
> 
>   http://vger.kernel.org/vger-lists.html#linux-newbie
> 
> If so, yes.  It's empty and quiet.

Nope, kernel-mentors:
	http://kernelnewbies.org/KernelMentors

> > In other words, this idea has been tried, maybe consider something else?
> 
> Well, the key piece is having a few experienced maintainers active on
> the list.

We have that.

> That doesn't seem to be the case on linux-newbie.  Also,
> linux-newbie doesn't seem to be kernel-specific.

I don't know anything about linux-newbie, sorry.

> We could address new users not knowing about it with a script.  Any
> [PATCH] posts to a mailing list where the sender is a miss in the git
> history bounces the email to the kernel-mentor list.
> 
> In case it wasn't obvious, I'd be willing to be one of those mentors if
> I had a few others to rotate lead with.

Great, feel free to join the kernel-mentors list and be amazed at the
silence :)

The fact that it's not well known might be one of the problems, but it
has been tried, just pointing out that this isn't a new idea, not that
it is an invalid one.

good luck!

greg k-h

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

[Jason Cooper]

On Sat, Jul 11, 2015 at 03:45:08PM -0700, Greg KH wrote:
> On Sat, Jul 11, 2015 at 07:35:39PM +0000, Jason Cooper wrote:
> > We could address new users not knowing about it with a script.  Any
> > [PATCH] posts to a mailing list where the sender is a miss in the git
> > history bounces the email to the kernel-mentor list.
> > 
> > In case it wasn't obvious, I'd be willing to be one of those mentors if
> > I had a few others to rotate lead with.
> 
> Great, feel free to join the kernel-mentors list and be amazed at the
> silence :)

Subscribed.

> The fact that it's not well known might be one of the problems, but it
> has been tried, just pointing out that this isn't a new idea, not that
> it is an invalid one.

Ack, I'll hack together a script to spot first-time patch submitters and
flag them for Cc/Fwd to kernel-mentors.

thx,

Jason.

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

[Steven Rostedt]

On Sat, 11 Jul 2015 11:24:41 +0530
Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:

> Another problem, when a newbie tries to move out of staging to some other
> subsystem he likes, the maintainer may not be that much responsive. Just
> for example, i submitted a patch on November, 2014 and I am yet to receive
> a reply or review to that and the patch was not a style correction patch.

BTW, it should always be OK to ping the maintainer if they ignore a
patch. I believe one week is a good time to wait. And again in another
week if they still do not reply. I know a few maintainers that think if
they get to a patch that is old and the author never pinged them, they
think the author doesn't think that patch is too important and they
just delete it.

I know I've been bad when patches are sent to me, especially if I'm
traveling and I don't have access to a real computer (read the patch on
my phone). I'll mark it with 'todo' and go on. By the time I get home,
I have 10 or 20 emails marked 'todo' and I could spend days on a few of
them before continuing. Finally, they just get buried, and lost in the
abyss of my INBOX. I never delete them, and after my inbox gets too
big, I'll actually try to purge it from oldest to newest, and I have
replied to patches that were over a year old, and even applied them!

I tell everyone, that if they do not hear from me within a week, please
send me a 'ping'. It will put that patch higher in the 'todo' stack.

I'm sure all maintainers are fine with a friendly ping after a week.
Don't send a ping before then, because maintainers are busy, and may
get annoyed by being too pushy.

-- Steve

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1834 bytes --]

On Wed, Jul 15, 2015 at 09:20:43PM -0400, Steven Rostedt wrote:
> Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:

> > Another problem, when a newbie tries to move out of staging to some other
> > subsystem he likes, the maintainer may not be that much responsive. Just
> > for example, i submitted a patch on November, 2014 and I am yet to receive
> > a reply or review to that and the patch was not a style correction patch.

> BTW, it should always be OK to ping the maintainer if they ignore a
> patch. I believe one week is a good time to wait. And again in another
> week if they still do not reply. I know a few maintainers that think if
> they get to a patch that is old and the author never pinged them, they
> think the author doesn't think that patch is too important and they
> just delete it.

Please don't encourage people to send content free pings bit instead
resend it - a content free ping mostly just adds to mail volume which is
pretty much the original problem.  If the patch has actually been lost
then a resend is going to be needed anyway and if not then it's mostly
just adding to mail volume.  With a lot of mail clients (including mutt
which I use) the nag will get threaded in with the original patch buried
back in the mailbox and not even be seen if that's still sitting waiting
for handling.

> I'm sure all maintainers are fine with a friendly ping after a week.
> Don't send a ping before then, because maintainers are busy, and may
> get annoyed by being too pushy.

Not me, they tend to just annoy me for the reasons above.  Resends are
useful but just straight up pings not so much.

I'd say a couple of weeks is a better lower limit than a single week
unless it's a very serious bugfix, a week could easily be a holiday or
whatever and larger patches or patch serieses do take time to review.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Steven Rostedt]

On Thu, 16 Jul 2015 14:25:51 +0100
Mark Brown <broonie@kernel.org> wrote:

> On Wed, Jul 15, 2015 at 09:20:43PM -0400, Steven Rostedt wrote:
> > Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
> 
> > > Another problem, when a newbie tries to move out of staging to some other
> > > subsystem he likes, the maintainer may not be that much responsive. Just
> > > for example, i submitted a patch on November, 2014 and I am yet to receive
> > > a reply or review to that and the patch was not a style correction patch.
> 
> > BTW, it should always be OK to ping the maintainer if they ignore a
> > patch. I believe one week is a good time to wait. And again in another
> > week if they still do not reply. I know a few maintainers that think if
> > they get to a patch that is old and the author never pinged them, they
> > think the author doesn't think that patch is too important and they
> > just delete it.
> 
> Please don't encourage people to send content free pings bit instead
> resend it - a content free ping mostly just adds to mail volume which is
> pretty much the original problem.  If the patch has actually been lost
> then a resend is going to be needed anyway and if not then it's mostly
> just adding to mail volume.  With a lot of mail clients (including mutt
> which I use) the nag will get threaded in with the original patch buried
> back in the mailbox and not even be seen if that's still sitting waiting
> for handling.

Well, then to each their own. I prefer the content free ping, because in
my mail client (claws), it brings the original patch up to the front
(my threading is to sort by latest email in the thread). A simple ping
will move their patch ahead of other patches that may have been sent
later, but are still in the abyss.

A resend will just be a duplicate in my inbox and it will confuse me
about why I have more than one of the same patch.

> 
> > I'm sure all maintainers are fine with a friendly ping after a week.
> > Don't send a ping before then, because maintainers are busy, and may
> > get annoyed by being too pushy.
> 
> Not me, they tend to just annoy me for the reasons above.  Resends are
> useful but just straight up pings not so much.

Then a simple reply to that content-free ping to tell the author what
you prefer. In fact, that's what I do when they ask me about it. I
sometimes even try to send a reply when I get the original patch
(privately to the author from my phone) that tells them to ping me in a
week if they don't hear back from me.

> 
> I'd say a couple of weeks is a better lower limit than a single week
> unless it's a very serious bugfix, a week could easily be a holiday or
> whatever and larger patches or patch serieses do take time to review.

The time length varies from person to person. Just let the author
know what you prefer. From developers I've talked to (including
myself), a week seems to be the norm to wait. Anything less is an
annoyance.

One of the issues with newcomers coming to development of the Linux
kernel, is that every maintainer is different. We should be trying
harder to let people know what we prefer. Every maintainer expects
something different, but it's up to the maintainer to explicitly let
others know what they want. You can't expect everyone to read your mind.

-- Steve

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

[Sudip Mukherjee]

On Thu, Jul 16, 2015 at 09:47:20AM -0400, Steven Rostedt wrote:
> On Thu, 16 Jul 2015 14:25:51 +0100
> Mark Brown <broonie@kernel.org> wrote:
> 
> > On Wed, Jul 15, 2015 at 09:20:43PM -0400, Steven Rostedt wrote:
> > > Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
> > 
> 
> One of the issues with newcomers coming to development of the Linux
> kernel, is that every maintainer is different. We should be trying
> harder to let people know what we prefer. Every maintainer expects
> something different, but it's up to the maintainer to explicitly let
> others know what they want. You can't expect everyone to read your mind.
Then in my opinion, it will be better if every maintainer has a script
which will reply automatically on receiving a patch that if the patch is
not applied within xxx days then please send a ping / resend the patch.

regards
sudip

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1164 bytes --]

On Thu, Jul 16, 2015 at 07:26:23PM +0530, Sudip Mukherjee wrote:

> Then in my opinion, it will be better if every maintainer has a script
> which will reply automatically on receiving a patch that if the patch is
> not applied within xxx days then please send a ping / resend the patch.

That then sets the expectation that you're going to do something with
the patch which is fine if it's relevant but there's lots of moderately
common cases with things like changes that touch multiple subsystems
(eg, for mfds or for adding a device driver and the DT using it
simultaneously) which result in things like resends of patches that
you've already reviewed due to a change earlier in the series and which
could get awfully noisy and/or confusing for submitters as a result.

To be reliable you'd off the top of my head need to start doing things
like parsing the patch to make sure it was for a relevant subsystem and
that it hadn't already got a reviewed/acked/whatever tag, sending a
different message if it wasn't something you'd expect to handle
yourself.  Personally I don't know that I trust my skills in appropriate
scripting languages to write that safely.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 3345 bytes --]

On Thu, Jul 16, 2015 at 09:47:20AM -0400, Steven Rostedt wrote:

> Well, then to each their own. I prefer the content free ping, because in
> my mail client (claws), it brings the original patch up to the front
> (my threading is to sort by latest email in the thread). A simple ping
> will move their patch ahead of other patches that may have been sent
> later, but are still in the abyss.

Interesting, not noticed a mail client with that sorting scheme before.

> A resend will just be a duplicate in my inbox and it will confuse me
> about why I have more than one of the same patch.

That happens often enough anyway due to people sending new versions in
response to other review comments or similar so I find I need to cope
with discarding old copies of things anyway.

> > Not me, they tend to just annoy me for the reasons above.  Resends are
> > useful but just straight up pings not so much.

> Then a simple reply to that content-free ping to tell the author what
> you prefer. In fact, that's what I do when they ask me about it. I
> sometimes even try to send a reply when I get the original patch
> (privately to the author from my phone) that tells them to ping me in a
> week if they don't hear back from me.

That's what I do (or just ignore them if I already have the patch) but
it does get rather repetitive and adds to the mail volume which is part
of the problem.

The basic reason I advise people to resend is that if a maintainer has a
resend in their inbox they should have everything they need to handle
the patch then and there, there are fewer things that can go wrong with
that than with a content free ping.

> > I'd say a couple of weeks is a better lower limit than a single week
> > unless it's a very serious bugfix, a week could easily be a holiday or
> > whatever and larger patches or patch serieses do take time to review.

> The time length varies from person to person. Just let the author
> know what you prefer. From developers I've talked to (including
> myself), a week seems to be the norm to wait. Anything less is an
> annoyance.

Less than a week is of course far too fast, it's a good way to get
ignored.  On the other hand a week definitely does seem to too fast to
be telling people to use as a starting point, my own experience
submitting patches and watching other people submitting patches is that
a week is definitely not an unusual time to have to wait for non-urgent
things to get handled, I only tend to start worrying that things
might've been missed after a couple of weeks.

> One of the issues with newcomers coming to development of the Linux
> kernel, is that every maintainer is different. We should be trying
> harder to let people know what we prefer. Every maintainer expects
> something different, but it's up to the maintainer to explicitly let
> others know what they want. You can't expect everyone to read your
> mind.

I basically agree with that, what I'm saying on the response time is
that I don't think you're setting realistic baselines for people.  A
week is just not what's actually happening in large parts of the kernel.
There are some people I'd expect to respond within a week in the normal
course of affairs but there are more where I wouldn't worry about it and
even the more responsive people are often slower on larger changes like
new driver submissions.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[James Bottomley]

[-- Attachment #1: Type: text/plain, Size: 1137 bytes --]

On Thu, 2015-07-16 at 15:41 +0100, Mark Brown wrote:
> On Thu, Jul 16, 2015 at 09:47:20AM -0400, Steven Rostedt wrote:
> 
> > Well, then to each their own. I prefer the content free ping, because in
> > my mail client (claws), it brings the original patch up to the front
> > (my threading is to sort by latest email in the thread). A simple ping
> > will move their patch ahead of other patches that may have been sent
> > later, but are still in the abyss.
> 
> Interesting, not noticed a mail client with that sorting scheme before.

I thought all mail clients can do this ... evolution certainly does and
I use it and imap labels to create lists of patches ready for applying.

However, there is an unintended consequence: If I'm working from this
list and applying patches in the order the mail client is presenting
them, any patch which receives a reply gets dragged to the bottom of my
list.  Usually this is correct because it means there's still debate
about the patch, but if you're going to send me pings as replies, they
have the same effect and delay the testing and application of the patch.

James


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1466 bytes --]

On Thu, Jul 16, 2015 at 05:46:39PM +0300, James Bottomley wrote:
> On Thu, 2015-07-16 at 15:41 +0100, Mark Brown wrote:
> > On Thu, Jul 16, 2015 at 09:47:20AM -0400, Steven Rostedt wrote:

> > > Well, then to each their own. I prefer the content free ping, because in
> > > my mail client (claws), it brings the original patch up to the front
> > > (my threading is to sort by latest email in the thread). A simple ping
> > > will move their patch ahead of other patches that may have been sent
> > > later, but are still in the abyss.

> > Interesting, not noticed a mail client with that sorting scheme before.

> I thought all mail clients can do this ... evolution certainly does and
> I use it and imap labels to create lists of patches ready for applying.

Hrm, perhaps it's more common in graphical clients than text mode ones -
I have to confess I've never really got on with graphical clients for
kernel workflow and everything else I'm much more inbox 0.  I mostly use
mutt but I do try others from time to time.

> However, there is an unintended consequence: If I'm working from this
> list and applying patches in the order the mail client is presenting
> them, any patch which receives a reply gets dragged to the bottom of my
> list.  Usually this is correct because it means there's still debate
> about the patch, but if you're going to send me pings as replies, they
> have the same effect and delay the testing and application of the patch.

Heh.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Jiri Kosina]

On Thu, 16 Jul 2015, Mark Brown wrote:

> Hrm, perhaps it's more common in graphical clients than text mode ones -
> I have to confess I've never really got on with graphical clients for
> kernel workflow and everything else I'm much more inbox 0.  I mostly use
> mutt but I do try others from time to time.

You can achieve the same by setting "sort_aux" properly in mutt. pine can 
do that as well (thread-sorts-by-arrival setting).

-- 
Jiri Kosina
SUSE Labs

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 760 bytes --]

On Thu, Jul 16, 2015 at 05:27:05PM +0200, Jiri Kosina wrote:
> On Thu, 16 Jul 2015, Mark Brown wrote:

> > Hrm, perhaps it's more common in graphical clients than text mode ones -
> > I have to confess I've never really got on with graphical clients for
> > kernel workflow and everything else I'm much more inbox 0.  I mostly use
> > mutt but I do try others from time to time.

> You can achieve the same by setting "sort_aux" properly in mutt. pine can 
> do that as well (thread-sorts-by-arrival setting).

Ah, thanks - I'd not seen that (it's burief in the config file).  Not
sure I actually find it helpful though since I'm most interested in
finding the most recently sent codde, it'd be useful as a sort I could
flip at runtime I guess.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Steven Rostedt]

On Thu, 16 Jul 2015 15:41:55 +0100
Mark Brown <broonie@kernel.org> wrote:

> On Thu, Jul 16, 2015 at 09:47:20AM -0400, Steven Rostedt wrote:
> 
> > Well, then to each their own. I prefer the content free ping, because in
> > my mail client (claws), it brings the original patch up to the front
> > (my threading is to sort by latest email in the thread). A simple ping
> > will move their patch ahead of other patches that may have been sent
> > later, but are still in the abyss.
> 
> Interesting, not noticed a mail client with that sorting scheme before.
> 

Both claws and evolution do this. I believe it's default for evolution,
and I kind of remember having to select this sorting style with claws.

> > A resend will just be a duplicate in my inbox and it will confuse me
> > about why I have more than one of the same patch.
> 
> That happens often enough anyway due to people sending new versions in
> response to other review comments or similar so I find I need to cope
> with discarding old copies of things anyway.

Oh, I expect a new version. Usually they are marked with v2, and that
lets me know to ignore the old one.

> > One of the issues with newcomers coming to development of the Linux
> > kernel, is that every maintainer is different. We should be trying
> > harder to let people know what we prefer. Every maintainer expects
> > something different, but it's up to the maintainer to explicitly let
> > others know what they want. You can't expect everyone to read your
> > mind.
> 
> I basically agree with that, what I'm saying on the response time is
> that I don't think you're setting realistic baselines for people.  A
> week is just not what's actually happening in large parts of the kernel.
> There are some people I'd expect to respond within a week in the normal
> course of affairs but there are more where I wouldn't worry about it and
> even the more responsive people are often slower on larger changes like
> new driver submissions.

And a lot of what maintainers prefer has to deal with the types of
changes they handle. I don't handle new devices. I usually handle new
features for tracing or bug fixes. Sometimes its updates for different
archs.

I especially prefer the ping if its for a patch series, as sending out
a new patch series that didn't change anything will definitely waste my
time, as I usually compare the old with the new to see what changed.

-- Steve

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1464 bytes --]

On Thu, Jul 16, 2015 at 10:57:51AM -0400, Steven Rostedt wrote:
> Mark Brown <broonie@kernel.org> wrote:

> > I basically agree with that, what I'm saying on the response time is
> > that I don't think you're setting realistic baselines for people.  A
> > week is just not what's actually happening in large parts of the kernel.
> > There are some people I'd expect to respond within a week in the normal
> > course of affairs but there are more where I wouldn't worry about it and
> > even the more responsive people are often slower on larger changes like
> > new driver submissions.

> And a lot of what maintainers prefer has to deal with the types of
> changes they handle. I don't handle new devices. I usually handle new
> features for tracing or bug fixes. Sometimes its updates for different
> archs.

Sure, though there's also a large amount of people's work patterns as
well - a lot of maintainers seem to batch up their work, sit down and
blast through a lot of changes at once.

> I especially prefer the ping if its for a patch series, as sending out
> a new patch series that didn't change anything will definitely waste my
> time, as I usually compare the old with the new to see what changed.

Oh, I tend to do the same thing but I basically just discard anything I
didn't review yet and compare against the baseline - if it's a resend
then I'm not discarding anything, if it's been improved then I get to
skip reviewing the intermediate version.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Steven Rostedt]

On Thu, 16 Jul 2015 16:18:40 +0100
Mark Brown <broonie@kernel.org> wrote:

 
> > I especially prefer the ping if its for a patch series, as sending out
> > a new patch series that didn't change anything will definitely waste my
> > time, as I usually compare the old with the new to see what changed.
> 
> Oh, I tend to do the same thing but I basically just discard anything I
> didn't review yet and compare against the baseline - if it's a resend
> then I'm not discarding anything, if it's been improved then I get to
> skip reviewing the intermediate version.

The problem with me is that I'll start a review but wont actually
reply. Especially if there's nothing to say about a patch. But if
something else comes up, I'll mark where I left off and continue the
other work. If I then get another patch series, I do the diff to see if
anything changed since I looked over the previous version.

-- Steve

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

[Tim Bird]

On 07/16/2015 06:47 AM, Steven Rostedt wrote:
> One of the issues with newcomers coming to development of the Linux
> kernel, is that every maintainer is different. We should be trying
> harder to let people know what we prefer. Every maintainer expects
> something different, but it's up to the maintainer to explicitly let
> others know what they want. You can't expect everyone to read your mind.

I agree with this completely.  When you switch systems (which I've done
something like 5 times in the last 2 years), you are essentially a newbie
in that new system.

How about putting some notes in the MAINTAINER file for things like
this, that some get_maintainer.pl option could show? 
We could use a I: prefix, for "Instructions:"  (only because 'N:'
is already used.)

I'm not sure the what types of per-maintainer differences would be good to
list, but at least the two described here would be good:
 - ping delay preference
 - ping style (whole patch or just an alert) preference

I think there may be some other things that we could recommend, but maybe
it would be good to use free-form instructions for a while and see what
patterns emerge.

A side benefit of this would be that maintainers could see what their
colleagues are doing, which might help spread knowledge of useful
practices.
  -- Tim

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

[Ralf Baechle]

On Thu, Jul 16, 2015 at 08:04:30AM -0700, Tim Bird wrote:

> On 07/16/2015 06:47 AM, Steven Rostedt wrote:
> > One of the issues with newcomers coming to development of the Linux
> > kernel, is that every maintainer is different. We should be trying
> > harder to let people know what we prefer. Every maintainer expects
> > something different, but it's up to the maintainer to explicitly let
> > others know what they want. You can't expect everyone to read your mind.
> 
> I agree with this completely.  When you switch systems (which I've done
> something like 5 times in the last 2 years), you are essentially a newbie
> in that new system.
> 
> How about putting some notes in the MAINTAINER file for things like
> this, that some get_maintainer.pl option could show? 
> We could use a I: prefix, for "Instructions:"  (only because 'N:'
> is already used.)
> 
> I'm not sure the what types of per-maintainer differences would be good to
> list, but at least the two described here would be good:
>  - ping delay preference
>  - ping style (whole patch or just an alert) preference
> 
> I think there may be some other things that we could recommend, but maybe
> it would be good to use free-form instructions for a while and see what
> patterns emerge.
> 
> A side benefit of this would be that maintainers could see what their
> colleagues are doing, which might help spread knowledge of useful
> practices.

Haven't systems like patchwork mostly obsoleted ping emails?

  Ralf

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

[Steven Rostedt]

On Thu, 16 Jul 2015 17:12:51 +0200
Ralf Baechle <ralf@linux-mips.org> wrote:
 
> Haven't systems like patchwork mostly obsoleted ping emails?

Not for small subsystems that don't use patchwork (like tracing).

-- Steve

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

[Tim Bird]

On 07/16/2015 08:12 AM, Ralf Baechle wrote:
> On Thu, Jul 16, 2015 at 08:04:30AM -0700, Tim Bird wrote:
> 
>> On 07/16/2015 06:47 AM, Steven Rostedt wrote:
>>> One of the issues with newcomers coming to development of the Linux
>>> kernel, is that every maintainer is different. We should be trying
>>> harder to let people know what we prefer. Every maintainer expects
>>> something different, but it's up to the maintainer to explicitly let
>>> others know what they want. You can't expect everyone to read your mind.
>>
>> I agree with this completely.  When you switch systems (which I've done
>> something like 5 times in the last 2 years), you are essentially a newbie
>> in that new system.
>>
>> How about putting some notes in the MAINTAINER file for things like
>> this, that some get_maintainer.pl option could show? 
>> We could use a I: prefix, for "Instructions:"  (only because 'N:'
>> is already used.)
>>
>> I'm not sure the what types of per-maintainer differences would be good to
>> list, but at least the two described here would be good:
>>  - ping delay preference
>>  - ping style (whole patch or just an alert) preference
>>
>> I think there may be some other things that we could recommend, but maybe
>> it would be good to use free-form instructions for a while and see what
>> patterns emerge.
>>
>> A side benefit of this would be that maintainers could see what their
>> colleagues are doing, which might help spread knowledge of useful
>> practices.
> 
> Haven't systems like patchwork mostly obsoleted ping emails?

$ grep ^[A-Z][^:] MAINTAINERS | wc -l
1389
$ grep ^Q: MAINTAINERS | wc -l
102

I think it's safe to say that less than 10% of sub-systems use
patchwork (or at least are documented to use patchwork).
 -- Tim

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 330 bytes --]

On Thu, Jul 16, 2015 at 05:12:51PM +0200, Ralf Baechle wrote:

> Haven't systems like patchwork mostly obsoleted ping emails?

With patchwork it's only possible to use it if you have a dedicated
mailing list for whatever it is you're maintaining which is relatively
rare.  I'm not really aware of anything else in the same space?

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Guenter Roeck]

On 07/16/2015 08:12 AM, Ralf Baechle wrote:
> On Thu, Jul 16, 2015 at 08:04:30AM -0700, Tim Bird wrote:
>
>> On 07/16/2015 06:47 AM, Steven Rostedt wrote:
>>> One of the issues with newcomers coming to development of the Linux
>>> kernel, is that every maintainer is different. We should be trying
>>> harder to let people know what we prefer. Every maintainer expects
>>> something different, but it's up to the maintainer to explicitly let
>>> others know what they want. You can't expect everyone to read your mind.
>>
>> I agree with this completely.  When you switch systems (which I've done
>> something like 5 times in the last 2 years), you are essentially a newbie
>> in that new system.
>>
>> How about putting some notes in the MAINTAINER file for things like
>> this, that some get_maintainer.pl option could show?
>> We could use a I: prefix, for "Instructions:"  (only because 'N:'
>> is already used.)
>>
>> I'm not sure the what types of per-maintainer differences would be good to
>> list, but at least the two described here would be good:
>>   - ping delay preference
>>   - ping style (whole patch or just an alert) preference
>>
>> I think there may be some other things that we could recommend, but maybe
>> it would be good to use free-form instructions for a while and see what
>> patterns emerge.
>>
>> A side benefit of this would be that maintainers could see what their
>> colleagues are doing, which might help spread knowledge of useful
>> practices.
>
> Haven't systems like patchwork mostly obsoleted ping emails?
>
Except that not all maintainers use patchwork.

Guenter

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

[Jonathan Corbet]

On Thu, 16 Jul 2015 08:04:30 -0700
Tim Bird <tim.bird@sonymobile.com> wrote:

> On 07/16/2015 06:47 AM, Steven Rostedt wrote:
> > One of the issues with newcomers coming to development of the Linux
> > kernel, is that every maintainer is different. We should be trying
> > harder to let people know what we prefer. Every maintainer expects
> > something different, but it's up to the maintainer to explicitly let
> > others know what they want. You can't expect everyone to read your mind.  
> 
> I agree with this completely.  When you switch systems (which I've done
> something like 5 times in the last 2 years), you are essentially a newbie
> in that new system.
> 
> How about putting some notes in the MAINTAINER file for things like
> this, that some get_maintainer.pl option could show? 
> We could use a I: prefix, for "Instructions:"  (only because 'N:'
> is already used.)

So somebody has to play the devil's advocate and ask this question...
Are we really better off documenting the fact that what looks like a
single project is actually a collection of a hundred or so idiosyncratic
fiefdoms with their own contact protocols, coding styles, beer
preferences, and more? Or perhaps we might think about gravitating toward
a more uniform set of conventions?  Preferably the ones I use? :)

Seriously, this area is a minefield for new developers; it can be
discouraging to put together your first patch, carefully follow
everything found in SubmittingPatches, CodingStyle, SubmitChecklist, and
HOWTO, appease the checkpatch.pl beast, carefully run get_maintainer.pl
with the correct command-line options, and follow all the suggestions
provided by reddit, Phoronix and 4chan, only to be told that the patch
came in during the wrong phase of the moon and they really should have
known better.

Not sure what the real answer is, but something tells me that adding a
new domain-specific language to MAINTAINERS isn't quite it :)

jon

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

[Steven Rostedt]

On Thu, 16 Jul 2015 09:41:25 -0600
Jonathan Corbet <corbet@lwn.net> wrote:


> Not sure what the real answer is, but something tells me that adding a
> new domain-specific language to MAINTAINERS isn't quite it :)
>

I agree. I believe it really comes down to the maintainers, when they
receive a patch, to express things NICELY to the new developer on any
changes they may need to make. And even say, that it's the maintainer's
preference and may not be something everyone else does.

It all comes down to the delivery of that notice. If you are nice and
polite, and say "thank you for your patch", it may not be such a burden
for the new developer. But if you come across as "Don't do it that way,
you need to do it this way", it may be a big time turn off.

-- Steve

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

[Tim Bird]

On 07/16/2015 08:41 AM, Jonathan Corbet wrote:
> On Thu, 16 Jul 2015 08:04:30 -0700
> Tim Bird <tim.bird@sonymobile.com> wrote:
> 
>> On 07/16/2015 06:47 AM, Steven Rostedt wrote:
>>> One of the issues with newcomers coming to development of the Linux
>>> kernel, is that every maintainer is different. We should be trying
>>> harder to let people know what we prefer. Every maintainer expects
>>> something different, but it's up to the maintainer to explicitly let
>>> others know what they want. You can't expect everyone to read your mind.  
>>
>> I agree with this completely.  When you switch systems (which I've done
>> something like 5 times in the last 2 years), you are essentially a newbie
>> in that new system.
>>
>> How about putting some notes in the MAINTAINER file for things like
>> this, that some get_maintainer.pl option could show? 
>> We could use a I: prefix, for "Instructions:"  (only because 'N:'
>> is already used.)
> 
> So somebody has to play the devil's advocate and ask this question...
> Are we really better off documenting the fact that what looks like a
> single project is actually a collection of a hundred or so idiosyncratic
> fiefdoms with their own contact protocols, coding styles, beer
> preferences, and more? Or perhaps we might think about gravitating toward
> a more uniform set of conventions?  Preferably the ones I use? :)
> 
> Seriously, this area is a minefield for new developers; it can be
> discouraging to put together your first patch, carefully follow
> everything found in SubmittingPatches, CodingStyle, SubmitChecklist, and
> HOWTO, appease the checkpatch.pl beast, carefully run get_maintainer.pl
> with the correct command-line options, and follow all the suggestions
> provided by reddit, Phoronix and 4chan, only to be told that the patch
> came in during the wrong phase of the moon and they really should have
> known better.
Indeed.

> Not sure what the real answer is, but something tells me that adding a
> new domain-specific language to MAINTAINERS isn't quite it :)
Not to rain on my own idea, but I strenuously agree.  I think one of
the reasons the SubmittingPatches files is not exhaustive is that
there are too many differences between maintainers for some things,
and some things change, even for a single maintainer, given the
type of patch and current maintainer circumstances.  Adding
to MAINTAINERS doesn't address this last variability at all.

We've been loathe to try to enforce consistency of process for
maintainers, thinking it would harm maintainer productivity (and
it well might).  But it makes automation hard, and you do end
up with newbies facing these daunting 110-step processes, which
still omit important steps, and might be contradictory for 
cross-system submissions.
 -- Tim

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

[Steven Rostedt]

On Thu, 16 Jul 2015 08:52:56 -0700
Tim Bird <tim.bird@sonymobile.com> wrote:

> > Not sure what the real answer is, but something tells me that adding a
> > new domain-specific language to MAINTAINERS isn't quite it :)
> Not to rain on my own idea, but I strenuously agree.  I think one of
> the reasons the SubmittingPatches files is not exhaustive is that

Right. Perhaps the solution is to inform maintainers that when they get
a patch from a newbie that isn't to their methods, to have them send
the author of the patch a nice email that explains to them what they
need.

Perhaps we should come up with a boiler plate of what should be
written, because not all of the maintainers have a proper tact
filter ;-)


> there are too many differences between maintainers for some things,
> and some things change, even for a single maintainer, given the
> type of patch and current maintainer circumstances.  Adding
> to MAINTAINERS doesn't address this last variability at all.
> 
> We've been loathe to try to enforce consistency of process for
> maintainers, thinking it would harm maintainer productivity (and
> it well might).  But it makes automation hard, and you do end
> up with newbies facing these daunting 110-step processes, which
> still omit important steps, and might be contradictory for 
> cross-system submissions.

I'm surprised that the Linux kernel, as big as it is, is as uniformed as
it is. When you herd a 1000 cats, you can't make them all follow the
same path, but you can at least have them all going in the same
direction.

-- Steve

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

[Josh Triplett]

On Thu, Jul 16, 2015 at 09:41:25AM -0600, Jonathan Corbet wrote:
> On Thu, 16 Jul 2015 08:04:30 -0700
> Tim Bird <tim.bird@sonymobile.com> wrote:
> 
> > On 07/16/2015 06:47 AM, Steven Rostedt wrote:
> > > One of the issues with newcomers coming to development of the Linux
> > > kernel, is that every maintainer is different. We should be trying
> > > harder to let people know what we prefer. Every maintainer expects
> > > something different, but it's up to the maintainer to explicitly let
> > > others know what they want. You can't expect everyone to read your mind.  
> > 
> > I agree with this completely.  When you switch systems (which I've done
> > something like 5 times in the last 2 years), you are essentially a newbie
> > in that new system.
> > 
> > How about putting some notes in the MAINTAINER file for things like
> > this, that some get_maintainer.pl option could show? 
> > We could use a I: prefix, for "Instructions:"  (only because 'N:'
> > is already used.)
> 
> So somebody has to play the devil's advocate and ask this question...
> Are we really better off documenting the fact that what looks like a
> single project is actually a collection of a hundred or so idiosyncratic
> fiefdoms with their own contact protocols, coding styles, beer
> preferences, and more? Or perhaps we might think about gravitating toward
> a more uniform set of conventions?  Preferably the ones I use? :)

Agreed completely.  We already maintain a uniform set of coding style
conventions (with only one notable exception in net/) and one uniform
set of patch guidelines ("the perfect patch", as implemented by git
format-patch).  It's not unreasonable to maintain a uniform set of
maintenance procedures as well.

- Josh Triplett

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

[Olof Johansson]

On Thu, Jul 16, 2015 at 8:41 AM, Jonathan Corbet <corbet@lwn.net> wrote:
> On Thu, 16 Jul 2015 08:04:30 -0700
> Tim Bird <tim.bird@sonymobile.com> wrote:
>
>> On 07/16/2015 06:47 AM, Steven Rostedt wrote:
>> > One of the issues with newcomers coming to development of the Linux
>> > kernel, is that every maintainer is different. We should be trying
>> > harder to let people know what we prefer. Every maintainer expects
>> > something different, but it's up to the maintainer to explicitly let
>> > others know what they want. You can't expect everyone to read your mind.
>>
>> I agree with this completely.  When you switch systems (which I've done
>> something like 5 times in the last 2 years), you are essentially a newbie
>> in that new system.
>>
>> How about putting some notes in the MAINTAINER file for things like
>> this, that some get_maintainer.pl option could show?
>> We could use a I: prefix, for "Instructions:"  (only because 'N:'
>> is already used.)
>
> So somebody has to play the devil's advocate and ask this question...
> Are we really better off documenting the fact that what looks like a
> single project is actually a collection of a hundred or so idiosyncratic
> fiefdoms with their own contact protocols, coding styles, beer
> preferences, and more? Or perhaps we might think about gravitating toward
> a more uniform set of conventions?  Preferably the ones I use? :)
>
> Seriously, this area is a minefield for new developers; it can be
> discouraging to put together your first patch, carefully follow
> everything found in SubmittingPatches, CodingStyle, SubmitChecklist, and
> HOWTO, appease the checkpatch.pl beast, carefully run get_maintainer.pl
> with the correct command-line options, and follow all the suggestions
> provided by reddit, Phoronix and 4chan, only to be told that the patch
> came in during the wrong phase of the moon and they really should have
> known better.
>
> Not sure what the real answer is, but something tells me that adding a
> new domain-specific language to MAINTAINERS isn't quite it :)

Hmm. How about something such as an initial (friendly) gatekeeper that
fronts the submissions and helps steer them in the right direction and
in the right format (with follow-up) for those who are unsure?

I'm not sure it'll be possible to achieve at the scale it's needed,
but it could be worth a try. Or, just as with some other suggestions,
maybe it has already been tried and didn't go anywhere.


-Olof

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

[Guenter Roeck]

On 07/16/2015 08:57 AM, Olof Johansson wrote:
> On Thu, Jul 16, 2015 at 8:41 AM, Jonathan Corbet <corbet@lwn.net> wrote:
>> On Thu, 16 Jul 2015 08:04:30 -0700
>> Tim Bird <tim.bird@sonymobile.com> wrote:
>>
>>> On 07/16/2015 06:47 AM, Steven Rostedt wrote:
>>>> One of the issues with newcomers coming to development of the Linux
>>>> kernel, is that every maintainer is different. We should be trying
>>>> harder to let people know what we prefer. Every maintainer expects
>>>> something different, but it's up to the maintainer to explicitly let
>>>> others know what they want. You can't expect everyone to read your mind.
>>>
>>> I agree with this completely.  When you switch systems (which I've done
>>> something like 5 times in the last 2 years), you are essentially a newbie
>>> in that new system.
>>>
>>> How about putting some notes in the MAINTAINER file for things like
>>> this, that some get_maintainer.pl option could show?
>>> We could use a I: prefix, for "Instructions:"  (only because 'N:'
>>> is already used.)
>>
>> So somebody has to play the devil's advocate and ask this question...
>> Are we really better off documenting the fact that what looks like a
>> single project is actually a collection of a hundred or so idiosyncratic
>> fiefdoms with their own contact protocols, coding styles, beer
>> preferences, and more? Or perhaps we might think about gravitating toward
>> a more uniform set of conventions?  Preferably the ones I use? :)
>>
>> Seriously, this area is a minefield for new developers; it can be
>> discouraging to put together your first patch, carefully follow
>> everything found in SubmittingPatches, CodingStyle, SubmitChecklist, and
>> HOWTO, appease the checkpatch.pl beast, carefully run get_maintainer.pl
>> with the correct command-line options, and follow all the suggestions
>> provided by reddit, Phoronix and 4chan, only to be told that the patch
>> came in during the wrong phase of the moon and they really should have
>> known better.
>>
>> Not sure what the real answer is, but something tells me that adding a
>> new domain-specific language to MAINTAINERS isn't quite it :)
>
> Hmm. How about something such as an initial (friendly) gatekeeper that
> fronts the submissions and helps steer them in the right direction and
> in the right format (with follow-up) for those who are unsure?
>
> I'm not sure it'll be possible to achieve at the scale it's needed,
> but it could be worth a try. Or, just as with some other suggestions,
> maybe it has already been tried and didn't go anywhere.
>
That only works is a newbie only submits patches into a single subsystem.
Anyone (including 'oldtimers') submitting a patch into different
subsystems will still hit the minefield, or would have to utilize the
gatekeeper again.

Overall, I don't think this would scale if the gatekeeper is a human.
Besides, that gatekeeper would have to be a genius to remember the
different per-subsystem submit procedures.

Guenter

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

[Tim Bird]

On 07/16/2015 08:41 AM, Jonathan Corbet wrote:
> Seriously, this area is a minefield for new developers; it can be
> discouraging to put together your first patch, carefully follow
> everything found in SubmittingPatches, CodingStyle, SubmitChecklist, and
> HOWTO, appease the checkpatch.pl beast, carefully run get_maintainer.pl
> with the correct command-line options, and follow all the suggestions
> provided by reddit, Phoronix and 4chan, only to be told that the patch
> came in during the wrong phase of the moon and they really should have
> known better.

Here's just an anecdote to support this.  There's a highly qualified 
developer at Sony I was talking to this week, who said that when he
sees a bug in the mainline kernel, he usually just ignores it because
the hassle-factor of submitting a patch is too high.
 -- Tim

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

[Steven Rostedt]

On Thu, 16 Jul 2015 09:09:35 -0700
Tim Bird <tim.bird@sonymobile.com> wrote:

> Here's just an anecdote to support this.  There's a highly qualified 
> developer at Sony I was talking to this week, who said that when he
> sees a bug in the mainline kernel, he usually just ignores it because
> the hassle-factor of submitting a patch is too high.

Ouch! But that's still no excuse to ignore it. There should be no
hassle factor in reporting a bug. Sending a patch along with it is a
plus. It at least demonstrates what is wrong. Now it may be a different
matter if you want your patch to make it into the kernel.

I've sent hundreds of patches to different subsystem maintainers (and
even Linus), where the patch was mostly used to show where the bug was,
and my version of the fix, but the final fix was authored by someone
else with just a Reported-by contributed to me. I'm fine with that, but
others may not be.

I heard that IBM once had a method where if you submitted a change, and
that change made it into kernel, even if the final change was not
authored by you, you still got credit for it. That's a fabulous way of
looking at contributions and giving credit to your employees.

-- Steve

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

[Tim Bird]

On 07/16/2015 09:16 AM, Steven Rostedt wrote:
> On Thu, 16 Jul 2015 09:09:35 -0700
> Tim Bird <tim.bird@sonymobile.com> wrote:
> 
>> Here's just an anecdote to support this.  There's a highly qualified 
>> developer at Sony I was talking to this week, who said that when he
>> sees a bug in the mainline kernel, he usually just ignores it because
>> the hassle-factor of submitting a patch is too high.
> 
> Ouch! But that's still no excuse to ignore it. There should be no
> hassle factor in reporting a bug. Sending a patch along with it is a
> plus. It at least demonstrates what is wrong. Now it may be a different
> matter if you want your patch to make it into the kernel.
> 
> I've sent hundreds of patches to different subsystem maintainers (and
> even Linus), where the patch was mostly used to show where the bug was,
> and my version of the fix, but the final fix was authored by someone
> else with just a Reported-by contributed to me. I'm fine with that, but
> others may not be.
> 
> I heard that IBM once had a method where if you submitted a change, and
> that change made it into kernel, even if the final change was not
> authored by you, you still got credit for it. That's a fabulous way of
> looking at contributions and giving credit to your employees.

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?

In other contexts, there have been suggestions that even known-to-be-unnacceptable
patches be submitted to lkml, just so there's a public record of some driver,
feature extension or workaround, that people can evaluate or fix up later.
What do people think of this (if they were marked as such)?
 -- Tim

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

[Steven Rostedt]

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,
just report the bug and say "this fixes it for me". And if it is a real
bug, the maintainer should take it.

Now, some maintainers will want to let the author have credit for the
patch, and may ask the author to format it differently such that they
can submit the patch with the original author as credited. I'll do that
as not to make the fix just with my name on it. So, if you really just
want the fix upstream, and don't want to bother with the hassle and get
the author credit for the change, simply state that. Something like: 

---
Note, this patch fixes the bug for me. If there's a better solution, or
it needs tweaking feel free to make the change. I don't need to be
author of the patch, a Reported-by is fine with me.

The '---' is to have that not be part of the change log in case they
do take the patch as is.

If it's not much tweaking, I'll take the patch, make the modifications
I want, and just add a comment to the change log about my updates,
leaving the original author as the author of the patch.

-- Steve

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

[NeilBrown]

On Thu, 16 Jul 2015 12:52:16 -0400 Steven Rostedt <rostedt@goodmis.org>
wrote:

> 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,
> just report the bug and say "this fixes it for me". And if it is a real
> bug, the maintainer should take it.
> 
> Now, some maintainers will want to let the author have credit for the
> patch, and may ask the author to format it differently such that they
> can submit the patch with the original author as credited. I'll do that
> as not to make the fix just with my name on it. So, if you really just
> want the fix upstream, and don't want to bother with the hassle and get
> the author credit for the change, simply state that. Something like: 
> 
> ---
> Note, this patch fixes the bug for me. If there's a better solution, or
> it needs tweaking feel free to make the change. I don't need to be
> author of the patch, a Reported-by is fine with me.
> 
> The '---' is to have that not be part of the change log in case they
> do take the patch as is.
> 
> If it's not much tweaking, I'll take the patch, make the modifications
> I want, and just add a comment to the change log about my updates,
> leaving the original author as the author of the patch.
> 

Yes.  Absolutely.  A patch is a gift - some unwrapping may be required.

We talk a lot about creating tooling to help newbies submit perfect
patches.  Maybe we need to spend more time creating tooling to help old
timers accept imperfect patches.

How hard would it be to get "patch" or "git apply" to apply
white-space-damaged patches?  Wiggle does a good job of a certain
class.  I came this --><--- close to getting wiggle to strip trailing
'\r', but I never received that third patch to push me over the edge.

How hard would it be to create a pre-commit hook that strips trailing
spaces, NormalizesCamelCase, and imposes Reverse Christmas Notation (or
whatever it is).  It could even add "FOO:" to the start of the
patch summary for any patch which modifies the "FOO" subsystem.

How hard would it be to have an SMTP server on submit.kernel.org which
only accepts properly formatted patches addressed to
"linux@kernel.org", performs basic compile tests, runs get_maintainer
and sends it off to the appropriate places.  Then Eager Developer could
just "./scripts/config-email", answer two questions, and "git
submit" (or whatever) would submit their pride and joy to the correct
place.  ./scripts/config-email would probably install the pre-commit
hooks so that bad white space would never even get to git.

NeilBrown

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

[Steven Rostedt]

On Sat, 18 Jul 2015 11:42:28 +1000
NeilBrown <neilb@suse.com> wrote:

> We talk a lot about creating tooling to help newbies submit perfect
> patches.  Maybe we need to spend more time creating tooling to help old
> timers accept imperfect patches.

+1

-- Steve

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

[Nicolas Ferre]

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.

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.

[..]

-- 
Nicolas Ferre

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

[James Bottomley]

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.
> 
> [..]
> 

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

[Geert Uytterhoeven]

On Fri, Jul 31, 2015 at 4:22 PM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> 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.

Applying attached patches is one thing.
Adding inline review comments is something different.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[James Bottomley]

On Sat, 2015-08-01 at 20:16 +0200, Geert Uytterhoeven wrote:
> On Fri, Jul 31, 2015 at 4:22 PM, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > 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.
> 
> Applying attached patches is one thing.
> Adding inline review comments is something different.

Every mail tool I know can quote from attachments.  One of the side
benefits is that reply-all doesn't, so you actually have to quote the
section you're commenting on instead of, say, doing reply-all to a 1,000
line patch with a single comment on line 745, which is a real pain for a
maintainer ...

James

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

[Geert Uytterhoeven]

On Sat, Aug 1, 2015 at 8:19 PM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Sat, 2015-08-01 at 20:16 +0200, Geert Uytterhoeven wrote:
>> On Fri, Jul 31, 2015 at 4:22 PM, James Bottomley
>> <James.Bottomley@hansenpartnership.com> wrote:
>> > On Fri, 2015-07-31 at 15:09 +0200, Nicolas Ferre wrote:
>> >> Le me just react on the "no attachment" statement:

>> Adding inline review comments is something different.
>
> Every mail tool I know can quote from attachments.  One of the side
> benefits is that reply-all doesn't, so you actually have to quote the
> section you're commenting on instead of, say, doing reply-all to a 1,000
> line patch with a single comment on line 745, which is a real pain for a
> maintainer ...

So I have to manually _add_ all sections I want to comment on (and add "> "
markers), instead of _deleting_ all sections I don't want to comment on?

Looks suitable for patches which require a single comment only...
(Which is usually not the case for patches sent as attachments ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[NeilBrown]

On Sat, 1 Aug 2015 20:42:29 +0200 Geert Uytterhoeven
<geert@linux-m68k.org> wrote:

> On Sat, Aug 1, 2015 at 8:19 PM, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > On Sat, 2015-08-01 at 20:16 +0200, Geert Uytterhoeven wrote:
> >> On Fri, Jul 31, 2015 at 4:22 PM, James Bottomley
> >> <James.Bottomley@hansenpartnership.com> wrote:
> >> > On Fri, 2015-07-31 at 15:09 +0200, Nicolas Ferre wrote:
> >> >> Le me just react on the "no attachment" statement:
> 
> >> Adding inline review comments is something different.
> >
> > Every mail tool I know can quote from attachments.  One of the side
> > benefits is that reply-all doesn't, so you actually have to quote the
> > section you're commenting on instead of, say, doing reply-all to a 1,000
> > line patch with a single comment on line 745, which is a real pain for a
> > maintainer ...
> 
> So I have to manually _add_ all sections I want to comment on (and add "> "
> markers), instead of _deleting_ all sections I don't want to comment on?
> 
> Looks suitable for patches which require a single comment only...
> (Which is usually not the case for patches sent as attachments ;-)
> 

Claws-mail doesn't make it easy to reply to attachments - you have to
use the clumsy "copy/paste/add '>'" that you describe.
However asserting that other people should follow a particular work
flow because my tools aren't very good does not sound like a convincing
argument to me.
If my tools don't work with a workflow that is prima-facie reasonable,
then it is my tools that are at fault and I should fix them, not ask
someone else to change their workflow.

NeilBrown

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

[Jiri Kosina]

On Sun, 2 Aug 2015, NeilBrown wrote:

> Claws-mail doesn't make it easy to reply to attachments - you have to 
> use the clumsy "copy/paste/add '>'" that you describe. However asserting 
> that other people should follow a particular work flow because my tools 
> aren't very good does not sound like a convincing argument to me. If my 
> tools don't work with a workflow that is prima-facie reasonable, then it 
> is my tools that are at fault and I should fix them, not ask someone 
> else to change their workflow.

Just in case anyone is collecting data-points from this discussion, pine 
doesn't make it really easy to include attachment text in-line in reply 
either.

-- 
Jiri Kosina
SUSE Labs

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 940 bytes --]

On Sun, Aug 02, 2015 at 12:45:24AM +0200, Jiri Kosina wrote:
> On Sun, 2 Aug 2015, NeilBrown wrote:

> > Claws-mail doesn't make it easy to reply to attachments - you have to 
> > use the clumsy "copy/paste/add '>'" that you describe. However asserting 
> > that other people should follow a particular work flow because my tools 
> > aren't very good does not sound like a convincing argument to me. If my 
> > tools don't work with a workflow that is prima-facie reasonable, then it 
> > is my tools that are at fault and I should fix them, not ask someone 
> > else to change their workflow.

> Just in case anyone is collecting data-points from this discussion, pine 
> doesn't make it really easy to include attachment text in-line in reply 
> either.

mutt is a bit fun here - it only works if the attachment has a text MIME
type which a lot of the systems that force people to attach patches seem
to struggle with.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[James Bottomley]

[-- Attachment #1: Type: text/plain, Size: 1459 bytes --]

On Mon, 2015-08-03 at 16:49 +0100, Mark Brown wrote:
> On Sun, Aug 02, 2015 at 12:45:24AM +0200, Jiri Kosina wrote:
> > On Sun, 2 Aug 2015, NeilBrown wrote:
> 
> > > Claws-mail doesn't make it easy to reply to attachments - you have to 
> > > use the clumsy "copy/paste/add '>'" that you describe. However asserting 
> > > that other people should follow a particular work flow because my tools 
> > > aren't very good does not sound like a convincing argument to me. If my 
> > > tools don't work with a workflow that is prima-facie reasonable, then it 
> > > is my tools that are at fault and I should fix them, not ask someone 
> > > else to change their workflow.
> 
> > Just in case anyone is collecting data-points from this discussion, pine 
> > doesn't make it really easy to include attachment text in-line in reply 
> > either.
> 
> mutt is a bit fun here - it only works if the attachment has a text MIME
> type which a lot of the systems that force people to attach patches seem
> to struggle with.

You mean the windows habit of attaching them as octet-stream types?  I
set my binary handler to be emacs (you could make it your editor of
choice) so I can pop it up on the attachment and cut and paste quote
from the editor.  I have to report that this does have some unwanted sid
effects in mozilla: some pdf attachments come as octet-stream as well
and the binary handler overrides the file type handler ...

James


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1140 bytes --]

On Mon, Aug 03, 2015 at 08:53:30AM -0700, James Bottomley wrote:
> On Mon, 2015-08-03 at 16:49 +0100, Mark Brown wrote:

> > mutt is a bit fun here - it only works if the attachment has a text MIME
> > type which a lot of the systems that force people to attach patches seem
> > to struggle with.

> You mean the windows habit of attaching them as octet-stream types?  I

Something, I guess it's people on Windows systems but I've never really
investigated.

> set my binary handler to be emacs (you could make it your editor of
> choice) so I can pop it up on the attachment and cut and paste quote
> from the editor.  I have to report that this does have some unwanted sid
> effects in mozilla: some pdf attachments come as octet-stream as well
> and the binary handler overrides the file type handler ...

That actually isn't needed with mutt - it will *display* binary
attachements it doesn't otherwise understand as text as a last resort
which does the right thing here.  What breaks is that if you reply to a
mail with text attacments it'll quote them into the reply but for
obvious reasons it doesn't do that for binary attachments.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Jonathan Corbet]

On Sun, 2 Aug 2015 08:16:00 +1000
NeilBrown <neilb@suse.com> wrote:

> Claws-mail doesn't make it easy to reply to attachments - you have to
> use the clumsy "copy/paste/add '>'" that you describe.

Two useful claws tricks:

1) "display as text" makes grabbing stuff out of attachments easy

2) "Edit->Special Paste->As quotation" handles much of the rest.

With those, dealing with patches in attachments is fairly painless.

jon

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

[NeilBrown]

On Sun, 2 Aug 2015 14:12:03 +0200 Jonathan Corbet <corbet@lwn.net>
wrote:

> On Sun, 2 Aug 2015 08:16:00 +1000
> NeilBrown <neilb@suse.com> wrote:
> 
> > Claws-mail doesn't make it easy to reply to attachments - you have to
> > use the clumsy "copy/paste/add '>'" that you describe.
> 
> Two useful claws tricks:
> 
> 1) "display as text" makes grabbing stuff out of attachments easy
> 
> 2) "Edit->Special Paste->As quotation" handles much of the rest.
> 
> With those, dealing with patches in attachments is fairly painless.
> 
> jon


Thanks...
So, better add another line to that summary:

> If my tools don't work with a workflow that is prima-facie reasonable,
  or if I don't know how to use them properly,
> then it is *ME OR* my tools that are at fault and I should fix them, not ask
> someone else to change their workflow.

NeilBrown

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

[Greg KH]

On Thu, Jul 16, 2015 at 12:16:20PM -0400, Steven Rostedt wrote:
> I heard that IBM once had a method where if you submitted a change, and
> that change made it into kernel, even if the final change was not
> authored by you, you still got credit for it. That's a fabulous way of
> looking at contributions and giving credit to your employees.

You also got a big stuffed penguin for your first kernel patch being
accepted, which turned out to be a good motivator for people when half
of the cubes on the floor had the penguin but you didn't.

I like the idea of sending out something for a kernel patch, I'll see if
the LF could sponsor something like that...

greg k-h

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

[Peter Hüwe]

Am Donnerstag, 16. Juli 2015, 18:28:47 schrieb Greg KH:
> On Thu, Jul 16, 2015 at 12:16:20PM -0400, Steven Rostedt wrote:
> > I heard that IBM once had a method where if you submitted a change, and
> > that change made it into kernel, even if the final change was not
> > authored by you, you still got credit for it. That's a fabulous way of
> > looking at contributions and giving credit to your employees.
> 
> You also got a big stuffed penguin for your first kernel patch being
> accepted, which turned out to be a good motivator for people when half
> of the cubes on the floor had the penguin but you didn't.
> 
> I like the idea of sending out something for a kernel patch, I'll see if
> the LF could sponsor something like that...

Nice idea :)

Peter

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

[Nicolas Ferre]

Le 16/07/2015 18:28, Greg KH a écrit :
> On Thu, Jul 16, 2015 at 12:16:20PM -0400, Steven Rostedt wrote:
>> I heard that IBM once had a method where if you submitted a change, and
>> that change made it into kernel, even if the final change was not
>> authored by you, you still got credit for it. That's a fabulous way of
>> looking at contributions and giving credit to your employees.
> 
> You also got a big stuffed penguin for your first kernel patch being
> accepted, which turned out to be a good motivator for people when half
> of the cubes on the floor had the penguin but you didn't.
> 
> I like the idea of sending out something for a kernel patch, I'll see if
> the LF could sponsor something like that...

Being named in the in the "Kernel development" section of lwn.net is
generally a valuable and nice reward.

Bye,
-- 
Nicolas Ferre

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

[Mel Gorman]

On Thu, Jul 16, 2015 at 12:16:20PM -0400, Steven Rostedt wrote:
> On Thu, 16 Jul 2015 09:09:35 -0700
> Tim Bird <tim.bird@sonymobile.com> wrote:
> 
> > Here's just an anecdote to support this.  There's a highly qualified 
> > developer at Sony I was talking to this week, who said that when he
> > sees a bug in the mainline kernel, he usually just ignores it because
> > the hassle-factor of submitting a patch is too high.
> 
> Ouch! But that's still no excuse to ignore it. There should be no
> hassle factor in reporting a bug.

Agreed that there is no excuse to ignore it but the hassle factor of
reporting is not just the only issue. I find it difficult to just file a
bug unless the issue is extremely difficult or I'm completely swamped with
other work. I like to think that I generally know what I'm doing and that
bug reports should be accompanied with some sort of patch in the common
case just out of pride. Other experienced people might be the same but
realistically we can't do anything about that because it's about feelings.

The hassle factor of sending patches to unfamiliar maintainers is real
though. If I'm privately helping someone post a patch I will try and give
them additional information on the maintainer they are dealing with and
what snags are specific to that person.  Obviously it is not information
that is documented anywhere.  This hazard is fine if you have someone on
hand with that information but I imagine it's rougher if you're on your own.

It's possible that the only tangiable way to address this is if maintainers,
where possible, do the basic fixups of a patch *for new people* and explain
what they changed and why. Let that person know that in the future they
should do the same steps themselves. This is a additional work unfortunately
but with luck it would only have to be done one or twice per new person. If
it persists then bounce it back saying "ah, this is the same snags as before,
you should know how to fix them now". Basic fixups for new peoples patches
is something that could potentially be delegated if a maintainer found a
few volunteers.

Andrew has a good system for dealing with this class of fixup which works
for his workflow. If there are minor fixes then he'll apply "-fix" patches
on top and collapse them together before the final merge with Linus.
The commit message will have a short note on why the fix was necessary
which is enough to know to avoid it in the future. You get an email with
the -fix patch is applied and you know you have screwed up when he gets
to the -fix-fix-fix-fix patch. The problem gets addressed, the patch
gets picked up and the patch submitter learns to avoid that problem in
the future.  This workflow does not work well with git without rebasing
but it is effective.

> <SNIP>
> Sending a patch along with it is a
> plus. It at least demonstrates what is wrong. Now it may be a different
> matter if you want your patch to make it into the kernel.
> I've sent hundreds of patches to different subsystem maintainers (and
> even Linus), where the patch was mostly used to show where the bug was,
> and my version of the fix, but the final fix was authored by someone
> else with just a Reported-by contributed to me. I'm fine with that, but
> others may not be.
> 

I like using this option on occasion, I think there are a number of
people do.

> I heard that IBM once had a method where if you submitted a change, and
> that change made it into kernel, even if the final change was not
> authored by you, you still got credit for it. That's a fabulous way of
> looking at contributions and giving credit to your employees.
> 

That one varied a little and applies to an extent to my current company.
A developer assigned a particular task was responsible for getting the job
done. If that was with their patch, something functionally equivalent or
with someone elses work did not matter. For example, someone else might
be fine with the idea, think it's important but hate the method and do it
themselves. Your immediate boss might distinguish between whether it was
your patch or not but beyond that credit was for getting the job done.
That company attitude is not something the community can do much about
though unless corporate attitude is being discussed at a high level.

-- 
Mel Gorman
SUSE Labs

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

[Steven Rostedt]

On Fri, 17 Jul 2015 11:16:29 +0100
Mel Gorman <mgorman@suse.de> wrote:


> Agreed that there is no excuse to ignore it but the hassle factor of
> reporting is not just the only issue. I find it difficult to just file a
> bug unless the issue is extremely difficult or I'm completely swamped with
> other work. I like to think that I generally know what I'm doing and that
> bug reports should be accompanied with some sort of patch in the common
> case just out of pride. Other experienced people might be the same but
> realistically we can't do anything about that because it's about feelings.
> 
> The hassle factor of sending patches to unfamiliar maintainers is real
> though. If I'm privately helping someone post a patch I will try and give
> them additional information on the maintainer they are dealing with and
> what snags are specific to that person.  Obviously it is not information
> that is documented anywhere.  This hazard is fine if you have someone on
> hand with that information but I imagine it's rougher if you're on your own.

But as I said below, it's only a hassle if you want your patch applied.
It isn't a hassle if you just simply report the bug and say "btw, this
patch fixes the issue, use it or make your own, but please fix the bug".

-- Steve

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

[James Bottomley]

On Thu, 2015-07-16 at 09:41 -0600, Jonathan Corbet wrote:
> On Thu, 16 Jul 2015 08:04:30 -0700
> Tim Bird <tim.bird@sonymobile.com> wrote:
> 
> > On 07/16/2015 06:47 AM, Steven Rostedt wrote:
> > > One of the issues with newcomers coming to development of the Linux
> > > kernel, is that every maintainer is different. We should be trying
> > > harder to let people know what we prefer. Every maintainer expects
> > > something different, but it's up to the maintainer to explicitly let
> > > others know what they want. You can't expect everyone to read your mind.  
> > 
> > I agree with this completely.  When you switch systems (which I've done
> > something like 5 times in the last 2 years), you are essentially a newbie
> > in that new system.
> > 
> > How about putting some notes in the MAINTAINER file for things like
> > this, that some get_maintainer.pl option could show? 
> > We could use a I: prefix, for "Instructions:"  (only because 'N:'
> > is already used.)
> 
> So somebody has to play the devil's advocate and ask this question...
> Are we really better off documenting the fact that what looks like a
> single project is actually a collection of a hundred or so idiosyncratic
> fiefdoms with their own contact protocols, coding styles, beer
> preferences, and more? Or perhaps we might think about gravitating toward
> a more uniform set of conventions?  Preferably the ones I use? :)
> 
> Seriously, this area is a minefield for new developers; it can be
> discouraging to put together your first patch, carefully follow
> everything found in SubmittingPatches, CodingStyle, SubmitChecklist, and
> HOWTO, appease the checkpatch.pl beast, carefully run get_maintainer.pl
> with the correct command-line options, and follow all the suggestions
> provided by reddit, Phoronix and 4chan, only to be told that the patch
> came in during the wrong phase of the moon and they really should have
> known better.

If I play Devil's advocate to the existing Devil's advocate, does that
make me one of the good guys ...?

Before we all beat ourselves up for being a complete cesspool of process
and timing obsessed freaks, perhaps people would like to reflect on
this:

http://www.alexconrad.org/2014/04/the-painful-process-of-submitting-your.html

Sometimes adding layers of carefully documented process and automated
abstractions actually ends up giving you precisely what you were trying
to avoid.

Seriously, what is the actual problem?  Who bites the heads off newbies
for sport?  I ask because the first patch submission is usually treated
with helpfulness and tolerance, at least where I've been on the cc list.
The wrong phase of the merge cycle can be a bugger, particularly when
most people's attention is elsewhere, but it's not like it's a huge
deterrent.  We all have developers who'd rather spit rats than submit a
patch to $opensourceprojecttheyfoundabugin but then, it's sometimes
because the reply might contradict their own mythology (or question
their reputation).  Before we embark on a huge does of hair shirt and a
lavish process dump, what is the problem we're trying to solve?

James

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

[Steven Rostedt]

On Thu, 16 Jul 2015 19:24:35 +0300
James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

> Seriously, what is the actual problem?  Who bites the heads off newbies
> for sport?  I ask because the first patch submission is usually treated
> with helpfulness and tolerance, at least where I've been on the cc list.
> The wrong phase of the merge cycle can be a bugger, particularly when
> most people's attention is elsewhere, but it's not like it's a huge
> deterrent.  We all have developers who'd rather spit rats than submit a
> patch to $opensourceprojecttheyfoundabugin but then, it's sometimes
> because the reply might contradict their own mythology (or question
> their reputation).  Before we embark on a huge does of hair shirt and a
> lavish process dump, what is the problem we're trying to solve?

Our reputation. No seriously, the issue isn't really with what we do
today, it's more about what we did yesterday. LKML use to be extremely
cruel. It can still be with a few maintainers, but they are now the
exception and not the norm.

It's also headlines with Linus swearing and calling people names.
Although, those too are few and far between, and Linus only does that
to people he knows. I haven't seen him do that with anyone that is new
to the list.

As I stated in other emails, we really don't need to change. We just
need to be conscious about what we say to patch submitters, and perhaps
all we need is reminders to be "nice".

I have no idea how to fix the "reputation" issue, and those that I have
met that state "I'll never participate in Linux development again!",
when asked, it has to do with something they encountered 10 years ago.
All I have to say to them is, "come back, things have changed".

-- Steve

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2063 bytes --]

On Thu, Jul 16, 2015 at 07:24:35PM +0300, James Bottomley wrote:

> Seriously, what is the actual problem?  Who bites the heads off newbies
> for sport?  I ask because the first patch submission is usually treated
> with helpfulness and tolerance, at least where I've been on the cc list.
> The wrong phase of the merge cycle can be a bugger, particularly when
> most people's attention is elsewhere, but it's not like it's a huge
> deterrent.  We all have developers who'd rather spit rats than submit a
> patch to $opensourceprojecttheyfoundabugin but then, it's sometimes
> because the reply might contradict their own mythology (or question
> their reputation).  Before we embark on a huge does of hair shirt and a
> lavish process dump, what is the problem we're trying to solve?

I think a lot of it is about perception - the whole "Linus will scream
at you for minor issues" meme is pretty strong out there and shapes
perceptions regardless of how true it is.  That said I do think there's
a couple of things that are real.

The response time issues being discussed elsewhere in the thread are
real I think - they are the biggest problem I see when I'm helping
people with patch submissions.  People get very discouraged when they
send something off and either get no response at all or find it
takes a while, they have difficulty in figuring out how to get people to
pay attention.  This is unfortunately quite common.  It's a really
difficult problem to solve with our workflows, at some point submitters
have sent a mail to the right people in close enough to the right format
so the maintainers *should* look at it but still the submitters don't
hear anything back and next steps aren't terribly clear.

I know there's also some stuff that's down to brief replies rather than
active hostility - I'm definitely part of the problem here, I need to
write a bunch of longer form replies and get a workflow for pasting them
into email (actually I think I've got that bit) sorted out.  Type the
same reply a lot and it's easy to optimise it down to brevity.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Jonathan Corbet]

On Thu, 16 Jul 2015 19:24:35 +0300
James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

> Seriously, what is the actual problem?  Who bites the heads off newbies
> for sport?  I ask because the first patch submission is usually treated
> with helpfulness and tolerance, at least where I've been on the cc list.

So, obviously, I was going for dramatic effect in my other posting.
"Biting the heads off newbies" doesn't ordinarily happen.  I think the
whole Nick episode has shown how tolerant we can be, actually.  The point
I was trying to make is that there isn't one way to submit a patch to the
kernel, there's a hundred ways to submit to various subsystems.

Over on linux-kernel, I just saw a newish developer being politely told
that a patch was unacceptable because the local variable declarations
were not in reverse-Christmas-tree order.  That's not in CodingStyle, and
it's certainly not a universal rule in the kernel; it's just one of those
things you have to know if you wander into certain scary neighborhoods.

I don't know if there's anything to be done about it, but I do think that
this thicket of weird local rules is intimidating to new developers, even
if missteps are dealt with politely.

jon

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

[Josh Triplett]

On Fri, Jul 17, 2015 at 10:11:51AM -0600, Jonathan Corbet wrote:
> On Thu, 16 Jul 2015 19:24:35 +0300
> James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> 
> > Seriously, what is the actual problem?  Who bites the heads off newbies
> > for sport?  I ask because the first patch submission is usually treated
> > with helpfulness and tolerance, at least where I've been on the cc list.
> 
> So, obviously, I was going for dramatic effect in my other posting.
> "Biting the heads off newbies" doesn't ordinarily happen.  I think the
> whole Nick episode has shown how tolerant we can be, actually.  The point
> I was trying to make is that there isn't one way to submit a patch to the
> kernel, there's a hundred ways to submit to various subsystems.
> 
> Over on linux-kernel, I just saw a newish developer being politely told
> that a patch was unacceptable because the local variable declarations
> were not in reverse-Christmas-tree order.  That's not in CodingStyle, and
> it's certainly not a universal rule in the kernel; it's just one of those
> things you have to know if you wander into certain scary neighborhoods.

That's the kind of thing that ought to be raised, politely, in response
to such a mail, pointing out that the kernel's coding style should be
universal to avoid making people deal with maintainer-specific
idiosyncrasies.  A few reminders of that from other kernel maintainers
couldn't hurt.

Such additional requirements don't seem onerous to the maintainer making
them, but add them up across all maintainers and you have a horrendous
mess.

- Josh Triplett

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

[Steven Rostedt]

On Fri, 17 Jul 2015 09:59:26 -0700
Josh Triplett <josh@joshtriplett.org> wrote:


> That's the kind of thing that ought to be raised, politely, in response
> to such a mail, pointing out that the kernel's coding style should be
> universal to avoid making people deal with maintainer-specific
> idiosyncrasies.  A few reminders of that from other kernel maintainers
> couldn't hurt.

Well, sometimes its maintainers that are telling other maintainers what
to do. It's not just newbies that get this treatment.


> 
> Such additional requirements don't seem onerous to the maintainer making
> them, but add them up across all maintainers and you have a horrendous
> mess.
> 

Perhaps if someone is sending you a one time patch, and you have your
own idiosyncrasy outside of CodingStyle, then it should be the
maintainer that makes the clean up. If someone starts sending you patch
series and may become a new player in your subsystem, then you can have
them start submitting such stylized formatting. But those types of
comments really shouldn't be made to the fly by patcher.

-- Steve

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

[josh]

On Fri, Jul 17, 2015 at 01:06:04PM -0400, Steven Rostedt wrote:
> On Fri, 17 Jul 2015 09:59:26 -0700
> Josh Triplett <josh@joshtriplett.org> wrote:
> 
> 
> > That's the kind of thing that ought to be raised, politely, in response
> > to such a mail, pointing out that the kernel's coding style should be
> > universal to avoid making people deal with maintainer-specific
> > idiosyncrasies.  A few reminders of that from other kernel maintainers
> > couldn't hurt.
> 
> Well, sometimes its maintainers that are telling other maintainers what
> to do. It's not just newbies that get this treatment.
> 
> 
> > 
> > Such additional requirements don't seem onerous to the maintainer making
> > them, but add them up across all maintainers and you have a horrendous
> > mess.
> > 
> 
> Perhaps if someone is sending you a one time patch, and you have your
> own idiosyncrasy outside of CodingStyle, then it should be the
> maintainer that makes the clean up. If someone starts sending you patch
> series and may become a new player in your subsystem, then you can have
> them start submitting such stylized formatting. But those types of
> comments really shouldn't be made to the fly by patcher.

Alternatively, if you have idiosyncrasies outside of CodingStyle (or
SubmittingPatches) that are useful, you could propose them for inclusion
in the kernel-wide style.  And if they're not useful enough to go there,
perhaps they shouldn't be enforced *anywhere*.

I'm not talking about things like how functions should be used in
various subsystems (e.g. "the function assigned to this ops field must
satisfy these invariants"); I'm talking about things like "in *this*
subsystem, your variable declarations should be sorted in descending
order of how mellifluous the letters in its name sound when mapped to a
two-octave chromatical musical scale and played through a flugelhorn".

- Josh Triplett

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

[Steven Rostedt]

On Fri, 17 Jul 2015 10:11:51 -0600
Jonathan Corbet <corbet@lwn.net> wrote:


> Over on linux-kernel, I just saw a newish developer being politely told
> that a patch was unacceptable because the local variable declarations
> were not in reverse-Christmas-tree order.  That's not in CodingStyle, and
> it's certainly not a universal rule in the kernel; it's just one of those
> things you have to know if you wander into certain scary neighborhoods.

As I know a few maintainers that like the "reverse-xmas-tree" order,
perhaps we could add that to CodingStyle in a section of:

--- Some Maintainer's prefer these styles ---

 These are some extra styles that maintainers prefer. Some are strict
 about these, others may not care. It doesn't hurt to add them.


Because things like reverse x-mas tree order isn't something people are
against doing. But some may not care if you do or don't. So listing
all the things that a few maintainers share, may be good.

Of course you hit a brick wall when there's two types of styles that
maintainers disagree on.


/*
 * What is the question?
 * To add a space at the top of a comment?
 */

/* Or not to add a space at the top of a comment?
 * That is the question!
 */


But really, when there's small things like indentation that is
submitted and I don't like, I don't even bother telling the author,
I'll just fix it myself and note in the change log "fixed up
whitespace".

-- Steve

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

[James Bottomley]

On July 17, 2015 8:37:12 PM GMT+03:00, Steven Rostedt <rostedt@goodmis.org> wrote:
>On Fri, 17 Jul 2015 10:11:51 -0600
>Jonathan Corbet <corbet@lwn.net> wrote:
>
>
>> Over on linux-kernel, I just saw a newish developer being politely
>told
>> that a patch was unacceptable because the local variable declarations
>> were not in reverse-Christmas-tree order.  That's not in CodingStyle,
>and
>> it's certainly not a universal rule in the kernel; it's just one of
>those
>> things you have to know if you wander into certain scary
>neighborhoods.
>
>As I know a few maintainers that like the "reverse-xmas-tree" order,
>perhaps we could add that to CodingStyle in a section of:
>
>--- Some Maintainer's prefer these styles ---
>
> These are some extra styles that maintainers prefer. Some are strict
> about these, others may not care. It doesn't hurt to add them.
>
>
>Because things like reverse x-mas tree order isn't something people are
>against doing. But some may not care if you do or don't. So listing
>all the things that a few maintainers share, may be good.
>
>Of course you hit a brick wall when there's two types of styles that
>maintainers disagree on.
>
>
>/*
> * What is the question?
> * To add a space at the top of a comment?
> */
>
>/* Or not to add a space at the top of a comment?
> * That is the question!
> */
>
>
>But really, when there's small things like indentation that is
>submitted and I don't like, I don't even bother telling the author,
>I'll just fix it myself and note in the change log "fixed up
>whitespace".

If you do that, and I get 500 coccinelle generated patches for SCSI switching the includes to reverse Christmas tree one file at a time, I'm afraid I'll have to shoot you.

James

>-- Steve
>
>_______________________________________________
>Ksummit-discuss mailing list
>Ksummit-discuss@lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

[Steven Rostedt]

On Fri, 17 Jul 2015 20:43:12 +0300
James Bottomley <James.Bottomley@Hansenpartnership.com> wrote:


> >--- Some Maintainer's prefer these styles ---
> >
> > These are some extra styles that maintainers prefer. Some are strict
> > about these, others may not care. It doesn't hurt to add them.
> >



> 
> If you do that, and I get 500 coccinelle generated patches for SCSI switching the includes to reverse Christmas tree one file at a time, I'm afraid I'll have to shoot you.

I'll remember to wear my bullet proof vest coming to KS.

Should stress that just some people prefer them. Heck, we can teach
checkpatch.pl to look at what file is being modified and see what
formats the maintainer of the file wants. :-)

-- Steve

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

[Chris Mason]

On Fri, Jul 17, 2015 at 01:53:13PM -0400, Steven Rostedt wrote:
> On Fri, 17 Jul 2015 20:43:12 +0300
> James Bottomley <James.Bottomley@Hansenpartnership.com> wrote:
> 
> 
> > >--- Some Maintainer's prefer these styles ---
> > >
> > > These are some extra styles that maintainers prefer. Some are strict
> > > about these, others may not care. It doesn't hurt to add them.
> > >
> 
> 
> 
> > 
> > If you do that, and I get 500 coccinelle generated patches for SCSI switching the includes to reverse Christmas tree one file at a time, I'm afraid I'll have to shoot you.
> 
> I'll remember to wear my bullet proof vest coming to KS.
> 
> Should stress that just some people prefer them. Heck, we can teach
> checkpatch.pl to look at what file is being modified and see what
> formats the maintainer of the file wants. :-)

We're way off in the weeds here, and whenever this topic comes up, we
end up focusing on the minor annoyances that come from submitting
new code.  Small variations in coding style, function naming and
general methods for working with a maintainer are sure to vary.

Looking at Jon's statistics, we don't have a problem bringing
new people into the kernel.  What can we do to help the new
people be more productive?  My own feeling is feedback,
testing and documentation are more important than
100% consistency between maintainers.

I love Greg's swag idea, I'm sure
more than one LF member would
be willing to help sponsor
such a thing.

-chris

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

[Steven Rostedt]

On Fri, 17 Jul 2015 15:30:13 -0400
Chris Mason <clm@fb.com> wrote:

> On Fri, Jul 17, 2015 at 01:53:13PM -0400, Steven Rostedt wrote:
> > On Fri, 17 Jul 2015 20:43:12 +0300
> > James Bottomley <James.Bottomley@Hansenpartnership.com> wrote:
> > 
> > 
> > > >--- Some Maintainer's prefer these styles ---
> > > >
> > > > These are some extra styles that maintainers prefer. Some are strict
> > > > about these, others may not care. It doesn't hurt to add them.
> > > >
> > 
> > 
> > 
> > > 
> > > If you do that, and I get 500 coccinelle generated patches for SCSI switching the includes to reverse Christmas tree one file at a time, I'm afraid I'll have to shoot you.
> > 
> > I'll remember to wear my bullet proof vest coming to KS.
> > 
> > Should stress that just some people prefer them. Heck, we can teach
> > checkpatch.pl to look at what file is being modified and see what
> > formats the maintainer of the file wants. :-)
> 
> We're way off in the weeds here, and whenever this topic comes up, we
> end up focusing on the minor annoyances that come from submitting
> new code.  Small variations in coding style, function naming and
> general methods for working with a maintainer are sure to vary.
> 
> Looking at Jon's statistics, we don't have a problem bringing
> new people into the kernel.  What can we do to help the new
> people be more productive?  My own feeling is feedback,
> testing and documentation are more important than
> 100% consistency between maintainers.
> 
> I love Greg's swag idea, I'm sure
> more than one LF member would
> be willing to help sponsor
> such a thing.
> 
> -chris

I wondered
why I felt like
I needed to look for
my lawn mower. Yeah, we are
bike shedding here. We need to
figure out how to get people not
afraid of submitting their first patch.
I agree, that swag idea may be a good one.

-- Steve

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

[Chris Mason]

On Fri, Jul 17, 2015 at 03:46:33PM -0400, Steven Rostedt wrote:
> On Fri, 17 Jul 2015 15:30:13 -0400
> Chris Mason <clm@fb.com> wrote:
> 
> > On Fri, Jul 17, 2015 at 01:53:13PM -0400, Steven Rostedt wrote:
> > > On Fri, 17 Jul 2015 20:43:12 +0300
> > > James Bottomley <James.Bottomley@Hansenpartnership.com> wrote:
> > > 
> > > 
> > > > >--- Some Maintainer's prefer these styles ---
> > > > >
> > > > > These are some extra styles that maintainers prefer. Some are strict
> > > > > about these, others may not care. It doesn't hurt to add them.
> > > > >
> > > 
> > > 
> > > 
> > > > 
> > > > If you do that, and I get 500 coccinelle generated patches for SCSI switching the includes to reverse Christmas tree one file at a time, I'm afraid I'll have to shoot you.
> > > 
> > > I'll remember to wear my bullet proof vest coming to KS.
> > > 
> > > Should stress that just some people prefer them. Heck, we can teach
> > > checkpatch.pl to look at what file is being modified and see what
> > > formats the maintainer of the file wants. :-)
> > 
> > We're way off in the weeds here, and whenever this topic comes up, we
> > end up focusing on the minor annoyances that come from submitting
> > new code.  Small variations in coding style, function naming and
> > general methods for working with a maintainer are sure to vary.
> > 
> > Looking at Jon's statistics, we don't have a problem bringing
> > new people into the kernel.  What can we do to help the new
> > people be more productive?  My own feeling is feedback,
> > testing and documentation are more important than
> > 100% consistency between maintainers.
> > 
> > I love Greg's swag idea, I'm sure
> > more than one LF member would
> > be willing to help sponsor
> > such a thing.
> > 
> > -chris
> 
> I wondered
> why I felt like
> I needed to look for
> my lawn mower. Yeah, we are
> bike shedding here. We need to
> figure out how to get people not
> afraid of submitting their first patch.
> I agree, that swag idea may be a good one.

The first patch really doesn't seem to be a problem.  At least from
the stats I've seen so far.  How do we get the 10..100th patches,
hopefully without 90% of them being whitespace fixes?

We're not going to be able to answer these without
actual data.  This means surveys and talking with
new developers that we really hope to turn into
long term members of the community.

-chris

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

[Tim Bird]

On 07/17/2015 01:02 PM, Chris Mason wrote:
> The first patch really doesn't seem to be a problem.  At least from
> the stats I've seen so far.  How do we get the 10..100th patches,
> hopefully without 90% of them being whitespace fixes?
> 
> We're not going to be able to answer these without
> actual data.  This means surveys and talking with
> new developers that we really hope to turn into
> long term members of the community.

I may have a data set that is relevant here.
Last year I surveyed developers, targeting those who
1) had made a change to the kernel that shipped in a commercial product,
(defined as "qualified" in the survey analysis)
and
2) did not make contributions to mainline

There were 93 out of 278 "qualified" developers who never submitted a
patch.  That's about 33% of the developers who responded to the survey.
I suspect that the no-submission rate for developers who either did
not see the survey or did not respond to it is much, much higher.
This survey was focused on developers in the consumer electronics field.

25% of all survey respondents (not just the "qualified" ones) reported
they did not know how to contribute a patch.

The survey was not detailed enough to determine what parts
of the submission process caused the most reluctance to contribute.

I would guess (not very scientifically) that although we have thousands
of developers contributing to mainline, the pool of developers paid by their
companies to make products is in the range of 10s of thousands, and
our rate of conversion to contributors is under 10%.  (I'm not sure
if that's good or bad.)
 -- Tim

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

[Chris Mason]

On Mon, Jul 20, 2015 at 10:40:55AM -0700, Tim Bird wrote:
> 
> 
> On 07/17/2015 01:02 PM, Chris Mason wrote:
> > The first patch really doesn't seem to be a problem.  At least from
> > the stats I've seen so far.  How do we get the 10..100th patches,
> > hopefully without 90% of them being whitespace fixes?
> > 
> > We're not going to be able to answer these without
> > actual data.  This means surveys and talking with
> > new developers that we really hope to turn into
> > long term members of the community.
> 
> I may have a data set that is relevant here.
> Last year I surveyed developers, targeting those who
> 1) had made a change to the kernel that shipped in a commercial product,
> (defined as "qualified" in the survey analysis)
> and
> 2) did not make contributions to mainline
> 
> There were 93 out of 278 "qualified" developers who never submitted a
> patch.  That's about 33% of the developers who responded to the survey.
> I suspect that the no-submission rate for developers who either did
> not see the survey or did not respond to it is much, much higher.
> This survey was focused on developers in the consumer electronics field.
> 
> 25% of all survey respondents (not just the "qualified" ones) reported
> they did not know how to contribute a patch.
> 
> The survey was not detailed enough to determine what parts
> of the submission process caused the most reluctance to contribute.
> 
> I would guess (not very scientifically) that although we have thousands
> of developers contributing to mainline, the pool of developers paid by their
> companies to make products is in the range of 10s of thousands, and
> our rate of conversion to contributors is under 10%.  (I'm not sure
> if that's good or bad.)

I love hard data on this topic, and I really like the idea of trying to find
the pool of actual kernel developers vs the pool of people visible on
the mailing list. 10:1 makes me sad, but I'm not that surprised.

Still, I'll channel Greg for a minute and google "how to send a patch to
the linux kernel".  I'd definitely believe people don't know how to get
their employer to prioritize (allow?) sending the patches in, but I
can't stretch to they don't know how to do it at all.

-chris

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 547 bytes --]

On Mon, Jul 20, 2015 at 01:58:51PM -0400, Chris Mason wrote:

> Still, I'll channel Greg for a minute and google "how to send a patch to
> the linux kernel".  I'd definitely believe people don't know how to get
> their employer to prioritize (allow?) sending the patches in, but I
> can't stretch to they don't know how to do it at all.

There is the gap before that where they know it's an option for "people
like them" at all, especially people who are more used to working on
proprietary or vendor systems where you just can't contribute back.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Guenter Roeck]

On 07/17/2015 10:43 AM, James Bottomley wrote:
>
>>
>>
>> But really, when there's small things like indentation that is
>> submitted and I don't like, I don't even bother telling the author,
>> I'll just fix it myself and note in the change log "fixed up
>> whitespace".
>
> If you do that, and I get 500 coccinelle generated patches for SCSI switching the includes to reverse Christmas tree one file at a time, I'm afraid I'll have to shoot you.
>
I wanted to comment that I tend to do the same, but given your reply
I'd rather be silent.

On a side note, sending an e-mail with more than 80 (or maybe 72)
columns per line may result in an angry e-mail from some maintainers.

Guenter

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

[josh]

On Fri, Jul 17, 2015 at 01:37:12PM -0400, Steven Rostedt wrote:
> On Fri, 17 Jul 2015 10:11:51 -0600
> Jonathan Corbet <corbet@lwn.net> wrote:
> 
> 
> > Over on linux-kernel, I just saw a newish developer being politely told
> > that a patch was unacceptable because the local variable declarations
> > were not in reverse-Christmas-tree order.  That's not in CodingStyle, and
> > it's certainly not a universal rule in the kernel; it's just one of those
> > things you have to know if you wander into certain scary neighborhoods.
> 
> As I know a few maintainers that like the "reverse-xmas-tree" order,
> perhaps we could add that to CodingStyle in a section of:
> 
> --- Some Maintainer's prefer these styles ---
> 
>  These are some extra styles that maintainers prefer. Some are strict
>  about these, others may not care. It doesn't hurt to add them.

A world of *no*.  If your style is not universal, and you can't get a
general consensus among kernel maintainers that it should be a
requirement across the entire kernel, then *no*.  We should not have
per-subsystem formatting rules.

> /*
>  * What is the question?
>  * To add a space at the top of a comment?
>  */
> 
> /* Or not to add a space at the top of a comment?
>  * That is the question!
>  */

While I'm not going to advocate that we mass-fix existing code in a
subsystem for consistent formatting, this is *exactly* the kind of thing
that we do not need any more of; one such idiosyncrasy is one too many.

- Josh Triplett

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

[Steven Rostedt]

On Fri, 17 Jul 2015 12:02:23 -0700
josh@joshtriplett.org wrote:


> > --- Some Maintainer's prefer these styles ---
> > 
> >  These are some extra styles that maintainers prefer. Some are strict
> >  about these, others may not care. It doesn't hurt to add them.
> 
> A world of *no*.  If your style is not universal, and you can't get a
> general consensus among kernel maintainers that it should be a
> requirement across the entire kernel, then *no*.  We should not have
> per-subsystem formatting rules.
>

Um, we have it today, and we'll have it tomorrow. Sorry, but the Linux
kernel is not run by management. It's a huge community effort with
some of the brightest minds in the world working on it. Each subsystem
of the kernel is a project in itself. We're lucky we have the consensus
that we have.

 
> > /*
> >  * What is the question?
> >  * To add a space at the top of a comment?
> >  */
> > 
> > /* Or not to add a space at the top of a comment?
> >  * That is the question!
> >  */
> 
> While I'm not going to advocate that we mass-fix existing code in a
> subsystem for consistent formatting, this is *exactly* the kind of thing
> that we do not need any more of; one such idiosyncrasy is one too many.

Then there's no issue here. Each maintainer is free to tell people to
x-mas tree their variables or not. Look, kernel development is complex
and if your biggest hangup of getting a patch into the kernel is that
the maintainer requires you to modify some whitespace on rearrange your
variables, then you probably should get out of kernel development and
enter a field of bike shed exterior design.

-- Steve

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

[josh]

On Fri, Jul 17, 2015 at 03:43:26PM -0400, Steven Rostedt wrote:
> On Fri, 17 Jul 2015 12:02:23 -0700
> josh@joshtriplett.org wrote:
> > > --- Some Maintainer's prefer these styles ---
> > > 
> > >  These are some extra styles that maintainers prefer. Some are strict
> > >  about these, others may not care. It doesn't hurt to add them.
> > 
> > A world of *no*.  If your style is not universal, and you can't get a
> > general consensus among kernel maintainers that it should be a
> > requirement across the entire kernel, then *no*.  We should not have
> > per-subsystem formatting rules.
> >
> 
> Um, we have it today, and we'll have it tomorrow. Sorry, but the Linux
> kernel is not run by management. It's a huge community effort with
> some of the brightest minds in the world working on it. Each subsystem
> of the kernel is a project in itself. We're lucky we have the consensus
> that we have.

Documenting it is giving up and saying it's OK for this to happen,
rather than continuing to address issues as we discover them.  At the
moment, there's one well-known one (the comment item mentioned below),
and it exists mostly as an extension of the standard rule "match the
surrounding code rather than rewriting it".  That isn't carte blanche
for intentionally having a gratuitously different style in different
files.

> > > /*
> > >  * What is the question?
> > >  * To add a space at the top of a comment?
> > >  */
> > > 
> > > /* Or not to add a space at the top of a comment?
> > >  * That is the question!
> > >  */
> > 
> > While I'm not going to advocate that we mass-fix existing code in a
> > subsystem for consistent formatting, this is *exactly* the kind of thing
> > that we do not need any more of; one such idiosyncrasy is one too many.
> 
> Then there's no issue here. Each maintainer is free to tell people to
> x-mas tree their variables or not.

And other maintainers can and should tell them to cut it out.  I'm not
suggesting this problem should be solved by top-down management, but by
community consensus.

> Look, kernel development is complex
> and if your biggest hangup of getting a patch into the kernel is that
> the maintainer requires you to modify some whitespace on rearrange your
> variables, then you probably should get out of kernel development and
> enter a field of bike shed exterior design.

If your biggest hangup as a maintainer is that people send you patches
that don't have variables sorted in some particular order, perhaps you
should get out of kernel development and get into bike shed colorimetry
consulting.  We have enough problems getting quality patches by the
metrics that *actually* correlate to quality.  And as others have
pointed out in this thread, many people produce patches across numerous
subsystems.

- Josh Triplett

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

[Steven Rostedt]

On Fri, 17 Jul 2015 13:24:12 -0700
josh@joshtriplett.org wrote:

> If your biggest hangup as a maintainer is that people send you patches
> that don't have variables sorted in some particular order, perhaps you
> should get out of kernel development and get into bike shed colorimetry
> consulting.  We have enough problems getting quality patches by the
> metrics that *actually* correlate to quality.  And as others have
> pointed out in this thread, many people produce patches across numerous
> subsystems.

I personally don't have any issue with my own idiosyncrasies not being
met. They are usually minor, and I'll fix up the patch (and document it
in the change log). These minor idiosyncrasies make maintaining code
easier. Everyone has a little personal style, and when the code aligns
to that style, it is usually easier to review it and understand it.

Anything that helps you to understand the code is a bonus.

I too have sent out patches across numerous subsystems. When a
maintainer asks me to modify it a certain way, I just do it.

-- Steve

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

[josh]

On Fri, Jul 17, 2015 at 04:39:03PM -0400, Steven Rostedt wrote:
> On Fri, 17 Jul 2015 13:24:12 -0700 josh@joshtriplett.org wrote:
> > If your biggest hangup as a maintainer is that people send you patches
> > that don't have variables sorted in some particular order, perhaps you
> > should get out of kernel development and get into bike shed colorimetry
> > consulting.  We have enough problems getting quality patches by the
> > metrics that *actually* correlate to quality.  And as others have
> > pointed out in this thread, many people produce patches across numerous
> > subsystems.
> 
> I personally don't have any issue with my own idiosyncrasies not being
> met. They are usually minor, and I'll fix up the patch (and document it
> in the change log). These minor idiosyncrasies make maintaining code
> easier.

That's perfectly reasonable.  If you want to take the time making the
code in your area conform to additional requirements above and beyond
those of the kernel as a whole, go for it.  I appreciate that you don't
ask others to do it for you.

- Josh Triplett

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

[Steven Rostedt]

On Fri, 17 Jul 2015 13:48:56 -0700
josh@joshtriplett.org wrote:

\ 
> That's perfectly reasonable.  If you want to take the time making the
> code in your area conform to additional requirements above and beyond
> those of the kernel as a whole, go for it.  I appreciate that you don't
> ask others to do it for you.

I can't say I never do. I just don't do it if it's the only change I'm
asking. If there's a logic change or bug I see in my review, I'll add
my comments about formatting along with it.

In fact, I went so far once to fix up a patch submitted by someone that
didn't come close to following CodingStyle. But I wanted the change. I
still gave the guy credit, but that took way too much time than it
should of. But that was an exception because the code submitted was
really worth while.

-- Steve

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

[Jiri Kosina]

On Fri, 17 Jul 2015, Steven Rostedt wrote:

[ ... snip ... ]
> But that was an exception because the code submitted was really worth 
> while

This really made me wonder. Maybe we should really focus on why such 
ocasions need to be pointed out as exceptions.

Is it that Linux kernel development got hyped so much that everyone wants 
to have that bullet in his CV, no matter how stupid the submitted patch 
would be?

If so, what should we do to change it?

I.e. I might propose a a slightly controversial topic, going a bit the 
other direction than the whole "motivating newcomers" discussion: how to 
get rid of useless submissions that are slowing maintainers down?

Should we stop publishing all the statistics? I believe there is no 
question that those are one of the primary drivers of useless submissions. 
Once maintainers get DoSed by submissions of wrong and/or useless patches 
that eat non-negligible amount of their time, we're in trouble.

-- 
Jiri Kosina
SUSE Labs

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

[Josh Triplett]

On Mon, Jul 20, 2015 at 12:19:56AM +0200, Jiri Kosina wrote:
> I.e. I might propose a a slightly controversial topic, going a bit the 
> other direction than the whole "motivating newcomers" discussion: how to 
> get rid of useless submissions that are slowing maintainers down?
> 
> Should we stop publishing all the statistics? I believe there is no 
> question that those are one of the primary drivers of useless submissions. 
> Once maintainers get DoSed by submissions of wrong and/or useless patches 
> that eat non-negligible amount of their time, we're in trouble.

I don't think it's the statistics that are the primary driver of such
contributions.  Rather, I would suggest that it's so non-trivially
difficult to follow the substantial volume of process needed to get
something into the kernel that it's worth doing a trial run with a
trivial change before trying to do something of substance.

And fixes for certain classes of compiler or sparse warnings have value
themselves.

- Josh Triplett

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

[Steven Rostedt]

On Mon, 20 Jul 2015 00:19:56 +0200 (CEST)
Jiri Kosina <jkosina@suse.com> wrote:

> On Fri, 17 Jul 2015, Steven Rostedt wrote:
> 
> [ ... snip ... ]
> > But that was an exception because the code submitted was really worth 
> > while
> 
> This really made me wonder. Maybe we should really focus on why such 
> ocasions need to be pointed out as exceptions.
> 
> Is it that Linux kernel development got hyped so much that everyone wants 
> to have that bullet in his CV, no matter how stupid the submitted patch 
> would be?
> 

Note, it was an exception because I wanted the change. There's changes
that add things I see worth while for others, but probably not so much
for myself. Those changes I wont be bending over backward for. If
someone submits a change that I really want, then I would do a lot to
make sure its in.

For an example of a change that I see worth while for others and not
for myself is live kernel patching ;-)  If those developers want those
changes in, they need to follow the process :-)

-- Steve

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

[Zefan Li]

> I.e. I might propose a a slightly controversial topic, going a bit the 
> other direction than the whole "motivating newcomers" discussion: how to 
> get rid of useless submissions that are slowing maintainers down?
> 

Do we really have this issue?

If we are encouraging more people to get involved in kernel contribution, we'll
sure occasionally see some patches with little value, but I don't think we are
suffering from this.

And When we see a patch of this kind, it won't take us much time to tell the
newbie why the patch isn't appropriate, and then he probably won't do this again.

> Should we stop publishing all the statistics? I believe there is no 
> question that those are one of the primary drivers of useless submissions. 
> Once maintainers get DoSed by submissions of wrong and/or useless patches 
> that eat non-negligible amount of their time, we're in trouble.
> 

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

[Josh Triplett]

On Mon, Jul 20, 2015 at 10:34:35AM +0800, Zefan Li wrote:
> > I.e. I might propose a a slightly controversial topic, going a bit the 
> > other direction than the whole "motivating newcomers" discussion: how to 
> > get rid of useless submissions that are slowing maintainers down?
> > 
> 
> Do we really have this issue?
> 
> If we are encouraging more people to get involved in kernel contribution, we'll
> sure occasionally see some patches with little value, but I don't think we are
> suffering from this.
> 
> And When we see a patch of this kind, it won't take us much time to tell the
> newbie why the patch isn't appropriate, and then he probably won't do this again.

That's exactly the kind of thing that we *shouldn't* do.

Think about that from the new contributor's perspective.  They've made a
change to the kernel that has a small but non-zero value.  They've just
managed to work out how to jump through all the hoops needed to prepare
and submit it properly for the kernel, through some combination of
reading, lurking, and mentorship.  And the first response they see is a
maintainer like you saying "please don't send this kind of patch".

Yeah, they probably won't do that again.  Congratulations, you defeated
the newbie and thwarted their evil maintainer-time-wasting scheme!  Hail
the conquering hero; insert victory fanfare here.  If you and others
keep up that vigilance, perhaps one day all maintainers can rest easy,
knowing they'll never again have to deal with new contributors.

</sarcasm>

It's perfectly reasonable to tell someone that, since they've gotten the
hang of sending kernel patches, they should move on to more substantial
changes, and leave simpler fixes to other potential new contributors.
But that's different than telling them their patch is unwelcome.

(If someone sends in a patch that's actively wrong, sure, go right ahead
and tell them what's wrong with it.  But there's a difference between
"wrong" and just "not that important".)

- Josh Triplett

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

[Guenter Roeck]

On 07/19/2015 10:16 PM, Josh Triplett wrote:
> On Mon, Jul 20, 2015 at 10:34:35AM +0800, Zefan Li wrote:
>>> I.e. I might propose a a slightly controversial topic, going a bit the
>>> other direction than the whole "motivating newcomers" discussion: how to
>>> get rid of useless submissions that are slowing maintainers down?
>>>
>>
>> Do we really have this issue?
>>
>> If we are encouraging more people to get involved in kernel contribution, we'll
>> sure occasionally see some patches with little value, but I don't think we are
>> suffering from this.
>>
>> And When we see a patch of this kind, it won't take us much time to tell the
>> newbie why the patch isn't appropriate, and then he probably won't do this again.
>
> That's exactly the kind of thing that we *shouldn't* do.
>
> Think about that from the new contributor's perspective.  They've made a
> change to the kernel that has a small but non-zero value.  They've just
> managed to work out how to jump through all the hoops needed to prepare
> and submit it properly for the kernel, through some combination of
> reading, lurking, and mentorship.  And the first response they see is a
> maintainer like you saying "please don't send this kind of patch".
>
> Yeah, they probably won't do that again.  Congratulations, you defeated
> the newbie and thwarted their evil maintainer-time-wasting scheme!  Hail
> the conquering hero; insert victory fanfare here.  If you and others
> keep up that vigilance, perhaps one day all maintainers can rest easy,
> knowing they'll never again have to deal with new contributors.
>
> </sarcasm>
>
> It's perfectly reasonable to tell someone that, since they've gotten the
> hang of sending kernel patches, they should move on to more substantial
> changes, and leave simpler fixes to other potential new contributors.
> But that's different than telling them their patch is unwelcome.
>
> (If someone sends in a patch that's actively wrong, sure, go right ahead
> and tell them what's wrong with it.  But there's a difference between
> "wrong" and just "not that important".)
>

Absolutely agree.

Guenter

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

[James Bottomley]

On Sun, 2015-07-19 at 22:16 -0700, Josh Triplett wrote:
> On Mon, Jul 20, 2015 at 10:34:35AM +0800, Zefan Li wrote:
> > > I.e. I might propose a a slightly controversial topic, going a bit the 
> > > other direction than the whole "motivating newcomers" discussion: how to 
> > > get rid of useless submissions that are slowing maintainers down?
> > > 
> > 
> > Do we really have this issue?
> > 
> > If we are encouraging more people to get involved in kernel contribution, we'll
> > sure occasionally see some patches with little value, but I don't think we are
> > suffering from this.
> > 
> > And When we see a patch of this kind, it won't take us much time to tell the
> > newbie why the patch isn't appropriate, and then he probably won't do this again.
> 
> That's exactly the kind of thing that we *shouldn't* do.
> 
> Think about that from the new contributor's perspective.  They've made a
> change to the kernel that has a small but non-zero value.  They've just
> managed to work out how to jump through all the hoops needed to prepare
> and submit it properly for the kernel, through some combination of
> reading, lurking, and mentorship.  And the first response they see is a
> maintainer like you saying "please don't send this kind of patch".
> 
> Yeah, they probably won't do that again.  Congratulations, you defeated
> the newbie and thwarted their evil maintainer-time-wasting scheme!  Hail
> the conquering hero; insert victory fanfare here.  If you and others
> keep up that vigilance, perhaps one day all maintainers can rest easy,
> knowing they'll never again have to deal with new contributors.
> 
> </sarcasm>
> 
> It's perfectly reasonable to tell someone that, since they've gotten the
> hang of sending kernel patches, they should move on to more substantial
> changes, and leave simpler fixes to other potential new contributors.
> But that's different than telling them their patch is unwelcome.
> 
> (If someone sends in a patch that's actively wrong, sure, go right ahead
> and tell them what's wrong with it.  But there's a difference between
> "wrong" and just "not that important".)

I think that's the wrong attitude in so many ways.  Good teachers don't
accept crap.  They throw it back at you with precisely the contempt it
deserves and a note as to how it should be improved.  Accepting less
than the best encourages mediocrity; it's bad for teaching, bad for
society and ultimately bad for the individual.

The constructive way to respond is to explain that this patch doesn't
add value, so it's not really of the calibre that we're looking for, but
then pull out one of the longstanding problems in a related area (or
sometimes something you just spotted looking at the code again) and ask
if the person would care to have a crack at that.

James

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

[Josh Triplett]

On Mon, Jul 20, 2015 at 08:15:15AM +0100, James Bottomley wrote:
> On Sun, 2015-07-19 at 22:16 -0700, Josh Triplett wrote:
> > On Mon, Jul 20, 2015 at 10:34:35AM +0800, Zefan Li wrote:
> > > > I.e. I might propose a a slightly controversial topic, going a bit the 
> > > > other direction than the whole "motivating newcomers" discussion: how to 
> > > > get rid of useless submissions that are slowing maintainers down?
> > > > 
> > > 
> > > Do we really have this issue?
> > > 
> > > If we are encouraging more people to get involved in kernel contribution, we'll
> > > sure occasionally see some patches with little value, but I don't think we are
> > > suffering from this.
> > > 
> > > And When we see a patch of this kind, it won't take us much time to tell the
> > > newbie why the patch isn't appropriate, and then he probably won't do this again.
> > 
> > That's exactly the kind of thing that we *shouldn't* do.
> > 
> > Think about that from the new contributor's perspective.  They've made a
> > change to the kernel that has a small but non-zero value.  They've just
> > managed to work out how to jump through all the hoops needed to prepare
> > and submit it properly for the kernel, through some combination of
> > reading, lurking, and mentorship.  And the first response they see is a
> > maintainer like you saying "please don't send this kind of patch".
> > 
> > Yeah, they probably won't do that again.  Congratulations, you defeated
> > the newbie and thwarted their evil maintainer-time-wasting scheme!  Hail
> > the conquering hero; insert victory fanfare here.  If you and others
> > keep up that vigilance, perhaps one day all maintainers can rest easy,
> > knowing they'll never again have to deal with new contributors.
> > 
> > </sarcasm>
> > 
> > It's perfectly reasonable to tell someone that, since they've gotten the
> > hang of sending kernel patches, they should move on to more substantial
> > changes, and leave simpler fixes to other potential new contributors.
> > But that's different than telling them their patch is unwelcome.
> > 
> > (If someone sends in a patch that's actively wrong, sure, go right ahead
> > and tell them what's wrong with it.  But there's a difference between
> > "wrong" and just "not that important".)
> 
> I think that's the wrong attitude in so many ways.  Good teachers don't
> accept crap.

We don't seem to be talking about the same kind of patches, then.  If
someone sends in incorrect patches, by all means reject those patches.
But a patch that improves code, even a very minor improvement, should
always be welcome.

(This doesn't mean that mechanically fixing compiler warnings, for
instance, is always an improvement.  For instance, shutting up the
compiler rather than actually fixing the warning is not a good idea.
But when the patch actually fixes something, even something minor, it's
worth accepting.)

- Josh Triplett

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

[James Bottomley]

On Mon, 2015-07-20 at 01:48 -0700, Josh Triplett wrote:
> On Mon, Jul 20, 2015 at 08:15:15AM +0100, James Bottomley wrote:
> > On Sun, 2015-07-19 at 22:16 -0700, Josh Triplett wrote:
> > > On Mon, Jul 20, 2015 at 10:34:35AM +0800, Zefan Li wrote:
> > > > > I.e. I might propose a a slightly controversial topic, going a bit the 
> > > > > other direction than the whole "motivating newcomers" discussion: how to 
> > > > > get rid of useless submissions that are slowing maintainers down?
> > > > > 
> > > > 
> > > > Do we really have this issue?
> > > > 
> > > > If we are encouraging more people to get involved in kernel contribution, we'll
> > > > sure occasionally see some patches with little value, but I don't think we are
> > > > suffering from this.
> > > > 
> > > > And When we see a patch of this kind, it won't take us much time to tell the
> > > > newbie why the patch isn't appropriate, and then he probably won't do this again.
> > > 
> > > That's exactly the kind of thing that we *shouldn't* do.
> > > 
> > > Think about that from the new contributor's perspective.  They've made a
> > > change to the kernel that has a small but non-zero value.  They've just
> > > managed to work out how to jump through all the hoops needed to prepare
> > > and submit it properly for the kernel, through some combination of
> > > reading, lurking, and mentorship.  And the first response they see is a
> > > maintainer like you saying "please don't send this kind of patch".
> > > 
> > > Yeah, they probably won't do that again.  Congratulations, you defeated
> > > the newbie and thwarted their evil maintainer-time-wasting scheme!  Hail
> > > the conquering hero; insert victory fanfare here.  If you and others
> > > keep up that vigilance, perhaps one day all maintainers can rest easy,
> > > knowing they'll never again have to deal with new contributors.
> > > 
> > > </sarcasm>
> > > 
> > > It's perfectly reasonable to tell someone that, since they've gotten the
> > > hang of sending kernel patches, they should move on to more substantial
> > > changes, and leave simpler fixes to other potential new contributors.
> > > But that's different than telling them their patch is unwelcome.
> > > 
> > > (If someone sends in a patch that's actively wrong, sure, go right ahead
> > > and tell them what's wrong with it.  But there's a difference between
> > > "wrong" and just "not that important".)
> > 
> > I think that's the wrong attitude in so many ways.  Good teachers don't
> > accept crap.
> 
> We don't seem to be talking about the same kind of patches, then.  If
> someone sends in incorrect patches, by all means reject those patches.
> But a patch that improves code, even a very minor improvement, should
> always be welcome.

"Improvement" is probably the issue.  Improvement to me means

     1. Adds a new user visible feature that will have consumers
     2. makes a user visible change that adds value (ideally a bug fix,
        but I think adding extra debug or other interfaces can count
        here)
     3. materially improves the maintainability of the code.

The third one seems to be where there's most disagreement.  Usually the
guideline I use for this is that for older files is just don't touch.
If someone really wants to improve the file then they get to maintain it
as well (we've had some success with this) otherwise generally such
patches aren't welcome.

> (This doesn't mean that mechanically fixing compiler warnings, for
> instance, is always an improvement.  For instance, shutting up the
> compiler rather than actually fixing the warning is not a good idea.
> But when the patch actually fixes something, even something minor, it's
> worth accepting.)

I don't agree that all improvements, however minor are worthwhile.
There's a cost to reviewing and merging ... that should be outweighed by
the value of the contribution.  The scarcest thing we have is review
bandwidth and we shouldn't waste it on minor improvements that are very
minor.  That said, I also don't direct or control the reviewers and they
mostly tend to concentrate on what they consider to be interesting
stuff, so I often find that patches like this often languish for lack of
review ... that's a good opportunity to point out that a more
substantive change would receive more attention.

James

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

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1334 bytes --]

On Mon, 2015-07-20 at 10:58 +0100, James Bottomley wrote:
> 
> I don't agree that all improvements, however minor are worthwhile.
> There's a cost to reviewing and merging ... that should be outweighed by
> the value of the contribution.  The scarcest thing we have is review
> bandwidth and we shouldn't waste it on minor improvements that are very
> minor. 

There is also a cost to *change*. How many times have we seen a trivial
patch which actually *breaks* something non-trivial?

We're normally quite good at managing change, and not being
conservative purely for conservatism's sake.

But trivial patches are actually the most risky in a number of ways.
They often come from inexperienced contributors, who might not spot
subtle problems introduced by naïve changes. And they are often made
without an in-depth knowledge or study of the code. The contributor
just spots a pattern (perhaps with checkpatch), and mechanically fixes
every instance they see, without stopping to look hard at each
instance.

Hell, I did this when fixing up the krealloc() users relatively
recently, getting it wrong in one case. And I really *ought* to know
better.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

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

[Rafael J. Wysocki]

On Monday, July 20, 2015 10:58:07 AM James Bottomley wrote:
> On Mon, 2015-07-20 at 01:48 -0700, Josh Triplett wrote:
> > On Mon, Jul 20, 2015 at 08:15:15AM +0100, James Bottomley wrote:
> > > On Sun, 2015-07-19 at 22:16 -0700, Josh Triplett wrote:
> > > > On Mon, Jul 20, 2015 at 10:34:35AM +0800, Zefan Li wrote:
> > > > > > I.e. I might propose a a slightly controversial topic, going a bit the 
> > > > > > other direction than the whole "motivating newcomers" discussion: how to 
> > > > > > get rid of useless submissions that are slowing maintainers down?
> > > > > > 
> > > > > 
> > > > > Do we really have this issue?
> > > > > 
> > > > > If we are encouraging more people to get involved in kernel contribution, we'll
> > > > > sure occasionally see some patches with little value, but I don't think we are
> > > > > suffering from this.
> > > > > 
> > > > > And When we see a patch of this kind, it won't take us much time to tell the
> > > > > newbie why the patch isn't appropriate, and then he probably won't do this again.
> > > > 
> > > > That's exactly the kind of thing that we *shouldn't* do.
> > > > 
> > > > Think about that from the new contributor's perspective.  They've made a
> > > > change to the kernel that has a small but non-zero value.  They've just
> > > > managed to work out how to jump through all the hoops needed to prepare
> > > > and submit it properly for the kernel, through some combination of
> > > > reading, lurking, and mentorship.  And the first response they see is a
> > > > maintainer like you saying "please don't send this kind of patch".
> > > > 
> > > > Yeah, they probably won't do that again.  Congratulations, you defeated
> > > > the newbie and thwarted their evil maintainer-time-wasting scheme!  Hail
> > > > the conquering hero; insert victory fanfare here.  If you and others
> > > > keep up that vigilance, perhaps one day all maintainers can rest easy,
> > > > knowing they'll never again have to deal with new contributors.
> > > > 
> > > > </sarcasm>
> > > > 
> > > > It's perfectly reasonable to tell someone that, since they've gotten the
> > > > hang of sending kernel patches, they should move on to more substantial
> > > > changes, and leave simpler fixes to other potential new contributors.
> > > > But that's different than telling them their patch is unwelcome.
> > > > 
> > > > (If someone sends in a patch that's actively wrong, sure, go right ahead
> > > > and tell them what's wrong with it.  But there's a difference between
> > > > "wrong" and just "not that important".)
> > > 
> > > I think that's the wrong attitude in so many ways.  Good teachers don't
> > > accept crap.
> > 
> > We don't seem to be talking about the same kind of patches, then.  If
> > someone sends in incorrect patches, by all means reject those patches.
> > But a patch that improves code, even a very minor improvement, should
> > always be welcome.
> 
> "Improvement" is probably the issue.  Improvement to me means
> 
>      1. Adds a new user visible feature that will have consumers
>      2. makes a user visible change that adds value (ideally a bug fix,
>         but I think adding extra debug or other interfaces can count
>         here)
>      3. materially improves the maintainability of the code.
> 
> The third one seems to be where there's most disagreement.  Usually the
> guideline I use for this is that for older files is just don't touch.
> If someone really wants to improve the file then they get to maintain it
> as well (we've had some success with this) otherwise generally such
> patches aren't welcome.

Agreed.


> > (This doesn't mean that mechanically fixing compiler warnings, for
> > instance, is always an improvement.  For instance, shutting up the
> > compiler rather than actually fixing the warning is not a good idea.
> > But when the patch actually fixes something, even something minor, it's
> > worth accepting.)
> 
> I don't agree that all improvements, however minor are worthwhile.
> There's a cost to reviewing and merging ... that should be outweighed by
> the value of the contribution.

Right.  Plus a change making an old file generate less checkpatch.pl warnings
may actually *not* be an improvement (even if it doesn't break things actively).

There is code in the kernel that was written with a coding style quite different
from the one regarded as a "standard" today and there's nothing wrong with that
in principle.

Thanks,
Rafael

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

[NeilBrown]

On Mon, 20 Jul 2015 08:15:15 +0100 James Bottomley
<James.Bottomley@HansenPartnership.com> wrote:

> On Sun, 2015-07-19 at 22:16 -0700, Josh Triplett wrote:
> > On Mon, Jul 20, 2015 at 10:34:35AM +0800, Zefan Li wrote:
> > > > I.e. I might propose a a slightly controversial topic, going a bit the 
> > > > other direction than the whole "motivating newcomers" discussion: how to 
> > > > get rid of useless submissions that are slowing maintainers down?
> > > > 
> > > 
> > > Do we really have this issue?
> > > 
> > > If we are encouraging more people to get involved in kernel contribution, we'll
> > > sure occasionally see some patches with little value, but I don't think we are
> > > suffering from this.
> > > 
> > > And When we see a patch of this kind, it won't take us much time to tell the
> > > newbie why the patch isn't appropriate, and then he probably won't do this again.
> > 
> > That's exactly the kind of thing that we *shouldn't* do.
> > 
> > Think about that from the new contributor's perspective.  They've made a
> > change to the kernel that has a small but non-zero value.  They've just
> > managed to work out how to jump through all the hoops needed to prepare
> > and submit it properly for the kernel, through some combination of
> > reading, lurking, and mentorship.  And the first response they see is a
> > maintainer like you saying "please don't send this kind of patch".
> > 
> > Yeah, they probably won't do that again.  Congratulations, you defeated
> > the newbie and thwarted their evil maintainer-time-wasting scheme!  Hail
> > the conquering hero; insert victory fanfare here.  If you and others
> > keep up that vigilance, perhaps one day all maintainers can rest easy,
> > knowing they'll never again have to deal with new contributors.
> > 
> > </sarcasm>
> > 
> > It's perfectly reasonable to tell someone that, since they've gotten the
> > hang of sending kernel patches, they should move on to more substantial
> > changes, and leave simpler fixes to other potential new contributors.
> > But that's different than telling them their patch is unwelcome.
> > 
> > (If someone sends in a patch that's actively wrong, sure, go right ahead
> > and tell them what's wrong with it.  But there's a difference between
> > "wrong" and just "not that important".)
> 
> I think that's the wrong attitude in so many ways.  Good teachers don't
> accept crap.  They throw it back at you with precisely the contempt it
> deserves and a note as to how it should be improved.  Accepting less
> than the best encourages mediocrity; it's bad for teaching, bad for
> society and ultimately bad for the individual.

"Good teachers" are sensitive to the context and abilities of their
students.  They aim to help their students further up the ladder, maybe
just one step, maybe all the way to the next landing (but they never mix
their metaphors).
Sometimes that means throwing back crap with contempt.  Sometimes it
means accepting crap because of the value mixed in with it.

If you stick to one style of teaching, you limit yourself to one class
of student.  This is probably inevitable for the individual teacher,
but should not be inevitable for a community of teachers.
Now if only we had a community of teachers rather than a community of
practitioners...



> 
> The constructive way to respond is to explain that this patch doesn't
> add value, so it's not really of the calibre that we're looking for, but
> then pull out one of the longstanding problems in a related area (or
> sometimes something you just spotted looking at the code again) and ask
> if the person would care to have a crack at that.

Certainly *a* constructive way to respond!

Thanks,
NeilBrown

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

[Zefan Li]

On 2015/7/20 13:16, Josh Triplett wrote:
> On Mon, Jul 20, 2015 at 10:34:35AM +0800, Zefan Li wrote:
>>> I.e. I might propose a a slightly controversial topic, going a bit the 
>>> other direction than the whole "motivating newcomers" discussion: how to 
>>> get rid of useless submissions that are slowing maintainers down?
>>>
>>
>> Do we really have this issue?
>>
>> If we are encouraging more people to get involved in kernel contribution, we'll
>> sure occasionally see some patches with little value, but I don't think we are
>> suffering from this.
>>
>> And When we see a patch of this kind, it won't take us much time to tell the
>> newbie why the patch isn't appropriate, and then he probably won't do this again.
> 
> That's exactly the kind of thing that we *shouldn't* do.
> 
> Think about that from the new contributor's perspective.  They've made a
> change to the kernel that has a small but non-zero value.  They've just
> managed to work out how to jump through all the hoops needed to prepare
> and submit it properly for the kernel, through some combination of
> reading, lurking, and mentorship.  And the first response they see is a
> maintainer like you saying "please don't send this kind of patch".
> 
> Yeah, they probably won't do that again.  Congratulations, you defeated
> the newbie and thwarted their evil maintainer-time-wasting scheme!  Hail
> the conquering hero; insert victory fanfare here.  If you and others
> keep up that vigilance, perhaps one day all maintainers can rest easy,
> knowing they'll never again have to deal with new contributors.
> 
> </sarcasm>
> 
> It's perfectly reasonable to tell someone that, since they've gotten the
> hang of sending kernel patches, they should move on to more substantial
> changes, and leave simpler fixes to other potential new contributors.
> But that's different than telling them their patch is unwelcome.
> 
> (If someone sends in a patch that's actively wrong, sure, go right ahead
> and tell them what's wrong with it.  But there's a difference between
> "wrong" and just "not that important".)
> 

I was saying zero-value patches like whitespace cleanups but not
small-but-non-zero ones.

And I didn't mean we should just close the doors to them. I should have
said this "tell the newbie why the patch isn't approriate and ask him
if he's interested in working on some more valuable things"

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

[James Bottomley]

On Mon, 2015-07-20 at 00:19 +0200, Jiri Kosina wrote:
> On Fri, 17 Jul 2015, Steven Rostedt wrote:
> 
> [ ... snip ... ]
> > But that was an exception because the code submitted was really worth 
> > while
> 
> This really made me wonder. Maybe we should really focus on why such 
> ocasions need to be pointed out as exceptions.
> 
> Is it that Linux kernel development got hyped so much that everyone wants 
> to have that bullet in his CV, no matter how stupid the submitted patch 
> would be?
> 
> If so, what should we do to change it?
> 
> I.e. I might propose a a slightly controversial topic, going a bit the 
> other direction than the whole "motivating newcomers" discussion: how to 
> get rid of useless submissions that are slowing maintainers down?

I second.  I think we concentrate too much on contribution and not
enough on useful contribution.

> Should we stop publishing all the statistics? I believe there is no 
> question that those are one of the primary drivers of useless submissions. 
> Once maintainers get DoSed by submissions of wrong and/or useless patches 
> that eat non-negligible amount of their time, we're in trouble.

I'm not sure it's just the stats.  We also have to be careful about
negative perceptions, so I don't think we want to go around highlighting
bad patches.  There are a couple of patch sets that are draining review
talent from my point of view: the mechanical one file at a time fixing
X.  I think we need someone to be the gatekeeper and review and apply
the script in one go.  And perhaps we should call the other "small
patches which don't fix bugs" ... I'm less sure what to do about these.

At the other end of the scale, perhaps we should be doing more to
recognise good contributions.  Greg suggested prizes for first
contributions, but what about in addition one more, say for best bug fix
of the week (or month depending on who's running it and how much time it
sucks)?  We could have the maintainers nominate ones they think are good
and whoever's running this picks the best.

James

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

[Julia Lawall]

On Mon, 20 Jul 2015, James Bottomley wrote:

> On Mon, 2015-07-20 at 00:19 +0200, Jiri Kosina wrote:
> > On Fri, 17 Jul 2015, Steven Rostedt wrote:
> >
> > [ ... snip ... ]
> > > But that was an exception because the code submitted was really worth
> > > while
> >
> > This really made me wonder. Maybe we should really focus on why such
> > ocasions need to be pointed out as exceptions.
> >
> > Is it that Linux kernel development got hyped so much that everyone wants
> > to have that bullet in his CV, no matter how stupid the submitted patch
> > would be?
> >
> > If so, what should we do to change it?
> >
> > I.e. I might propose a a slightly controversial topic, going a bit the
> > other direction than the whole "motivating newcomers" discussion: how to
> > get rid of useless submissions that are slowing maintainers down?
>
> I second.  I think we concentrate too much on contribution and not
> enough on useful contribution.
>
> > Should we stop publishing all the statistics? I believe there is no
> > question that those are one of the primary drivers of useless submissions.
> > Once maintainers get DoSed by submissions of wrong and/or useless patches
> > that eat non-negligible amount of their time, we're in trouble.
>
> I'm not sure it's just the stats.  We also have to be careful about
> negative perceptions, so I don't think we want to go around highlighting
> bad patches.  There are a couple of patch sets that are draining review
> talent from my point of view: the mechanical one file at a time fixing
> X.  I think we need someone to be the gatekeeper and review and apply
> the script in one go.  And perhaps we should call the other "small
> patches which don't fix bugs" ... I'm less sure what to do about these.

If there really is a problem that some maintainer is getting inundated
with patches addressing unimportant cosmetic issues, could it be a good
idea to:

* Fix the code and get it over with,
* Drop the code from the kernel, if no one uses it, or
* Put a comment in the file saying that the file is no longer being
actively developed and only bug fixes will be accepted.

julia

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

[Greg KH]

On Mon, Jul 20, 2015 at 10:27:39AM +0200, Julia Lawall wrote:
> 
> 
> On Mon, 20 Jul 2015, James Bottomley wrote:
> 
> > On Mon, 2015-07-20 at 00:19 +0200, Jiri Kosina wrote:
> > > On Fri, 17 Jul 2015, Steven Rostedt wrote:
> > >
> > > [ ... snip ... ]
> > > > But that was an exception because the code submitted was really worth
> > > > while
> > >
> > > This really made me wonder. Maybe we should really focus on why such
> > > ocasions need to be pointed out as exceptions.
> > >
> > > Is it that Linux kernel development got hyped so much that everyone wants
> > > to have that bullet in his CV, no matter how stupid the submitted patch
> > > would be?
> > >
> > > If so, what should we do to change it?
> > >
> > > I.e. I might propose a a slightly controversial topic, going a bit the
> > > other direction than the whole "motivating newcomers" discussion: how to
> > > get rid of useless submissions that are slowing maintainers down?
> >
> > I second.  I think we concentrate too much on contribution and not
> > enough on useful contribution.
> >
> > > Should we stop publishing all the statistics? I believe there is no
> > > question that those are one of the primary drivers of useless submissions.
> > > Once maintainers get DoSed by submissions of wrong and/or useless patches
> > > that eat non-negligible amount of their time, we're in trouble.
> >
> > I'm not sure it's just the stats.  We also have to be careful about
> > negative perceptions, so I don't think we want to go around highlighting
> > bad patches.  There are a couple of patch sets that are draining review
> > talent from my point of view: the mechanical one file at a time fixing
> > X.  I think we need someone to be the gatekeeper and review and apply
> > the script in one go.  And perhaps we should call the other "small
> > patches which don't fix bugs" ... I'm less sure what to do about these.
> 
> If there really is a problem that some maintainer is getting inundated
> with patches addressing unimportant cosmetic issues, could it be a good
> idea to:
> 
> * Fix the code and get it over with,
> * Drop the code from the kernel, if no one uses it, or
> * Put a comment in the file saying that the file is no longer being
> actively developed and only bug fixes will be accepted.

I agree with this.  If your subsystem is constantly getting hit with
coding style cleanups that you don't want (i.e. SCSI), put something in
the top of the file that says "don't clean up the style".

Of course it will be ignored (like pci_ids.h), but then you can write a
simple script that just rejects such patches with a "Sorry, but please
read the top of the file" rejection notice.

There, annoying patches taken care of.

greg k-h

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

[Guenter Roeck]

On 07/20/2015 01:30 PM, Greg KH wrote:

>> If there really is a problem that some maintainer is getting inundated
>> with patches addressing unimportant cosmetic issues, could it be a good
>> idea to:
>>
>> * Fix the code and get it over with,
>> * Drop the code from the kernel, if no one uses it, or
>> * Put a comment in the file saying that the file is no longer being
>> actively developed and only bug fixes will be accepted.
>
> I agree with this.  If your subsystem is constantly getting hit with
> coding style cleanups that you don't want (i.e. SCSI), put something in
> the top of the file that says "don't clean up the style".
>

How about a cleanup tag in MAINTAINERS ? Then checkpatch could warn
if it is used on a file tagged as do-not-clean, and every maintainer
could set preferences as desired.

Something like

C: yes
C: limited (prior to functional changes only)
C: no

Either limited or yes could be the default.

The "Obsolete" status presumably implies that cleanups are not desired,
and checkpatch could issue a warning if it is run on an obsolete file
or subsystem.

Guenter

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

[Greg KH]

On Mon, Jul 20, 2015 at 03:12:51PM -0700, Guenter Roeck wrote:
> On 07/20/2015 01:30 PM, Greg KH wrote:
> 
> >>If there really is a problem that some maintainer is getting inundated
> >>with patches addressing unimportant cosmetic issues, could it be a good
> >>idea to:
> >>
> >>* Fix the code and get it over with,
> >>* Drop the code from the kernel, if no one uses it, or
> >>* Put a comment in the file saying that the file is no longer being
> >>actively developed and only bug fixes will be accepted.
> >
> >I agree with this.  If your subsystem is constantly getting hit with
> >coding style cleanups that you don't want (i.e. SCSI), put something in
> >the top of the file that says "don't clean up the style".
> >
> 
> How about a cleanup tag in MAINTAINERS ? Then checkpatch could warn
> if it is used on a file tagged as do-not-clean, and every maintainer
> could set preferences as desired.
> 
> Something like
> 
> C: yes
> C: limited (prior to functional changes only)
> C: no
> 
> Either limited or yes could be the default.
> 
> The "Obsolete" status presumably implies that cleanups are not desired,
> and checkpatch could issue a warning if it is run on an obsolete file
> or subsystem.

Ugh, let's stop trying to add more flags to MAINTAINERS that no one will
notice and will get out of date and be a pain to maintain over time.

Is this really such a major issue?  If you don't want cleanup patches,
just politely refuse them and point people at drivers/staging/ where I
will gladly take them.  It's not tough at all.

Or better yet, take Julia's advice, and just fix up your subsystem to
not need these patches at all.  That should take all of an afternoon's
worth of effort at most, drivers/scsi/ notwithstanding, that beast is
horrid...

thanks,

greg k-h

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

[Guenter Roeck]

On 07/20/2015 03:32 PM, Greg KH wrote:
> On Mon, Jul 20, 2015 at 03:12:51PM -0700, Guenter Roeck wrote:
>> On 07/20/2015 01:30 PM, Greg KH wrote:
>>
>>>> If there really is a problem that some maintainer is getting inundated
>>>> with patches addressing unimportant cosmetic issues, could it be a good
>>>> idea to:
>>>>
>>>> * Fix the code and get it over with,
>>>> * Drop the code from the kernel, if no one uses it, or
>>>> * Put a comment in the file saying that the file is no longer being
>>>> actively developed and only bug fixes will be accepted.
>>>
>>> I agree with this.  If your subsystem is constantly getting hit with
>>> coding style cleanups that you don't want (i.e. SCSI), put something in
>>> the top of the file that says "don't clean up the style".
>>>
>>
>> How about a cleanup tag in MAINTAINERS ? Then checkpatch could warn
>> if it is used on a file tagged as do-not-clean, and every maintainer
>> could set preferences as desired.
>>
>> Something like
>>
>> C: yes
>> C: limited (prior to functional changes only)
>> C: no
>>
>> Either limited or yes could be the default.
>>
>> The "Obsolete" status presumably implies that cleanups are not desired,
>> and checkpatch could issue a warning if it is run on an obsolete file
>> or subsystem.
>
> Ugh, let's stop trying to add more flags to MAINTAINERS that no one will
> notice and will get out of date and be a pain to maintain over time.
>
It would be noticed since checkpatch would use it. And maintainers would
have interest to keep it up to date, especially those who dislike cleanup
patches.

> Is this really such a major issue?  If you don't want cleanup patches,
> just politely refuse them and point people at drivers/staging/ where I
> will gladly take them.  It's not tough at all.
>
It isn't tough or an issue for me, but I don't normally refuse cleanup
patches either.

> Or better yet, take Julia's advice, and just fix up your subsystem to
> not need these patches at all.  That should take all of an afternoon's
> worth of effort at most, drivers/scsi/ notwithstanding, that beast is
> horrid...
>

Yes, that is what I am doing once in a while, if I need a timeout from other
work. Since I don't mind cleanup patches, so I would set the tag to 'yes'
for all files where I am listed as maintainer. But other maintainers do
actively reject cleanup patches, sometimes with less then friendly words.

Without a tag, the result is to discourage cleanup patches in general,
or what I would call the lowest common denominator. While I understand
and accept that other maintainers dislike cleanup patches, I don't see
why I should have to suffer the consequences.

Guenter

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

[Bjorn Helgaas]

On Fri, Jul 17, 2015 at 10:48 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Sat, 18 Jul 2015 11:42:28 +1000
> NeilBrown <neilb@suse.com> wrote:
>
>> We talk a lot about creating tooling to help newbies submit perfect
>> patches.  Maybe we need to spend more time creating tooling to help old
>> timers accept imperfect patches.
>
> +1

+10

I do some work in gerrit, where patches are "automatically" merged by
the submitter after being approved by reviewers.  It is a real hassle
because every last nit has to be removed for the automatic merge to
work, and the nits are hard for non-experts to discover.  The
environment would feel much friendlier if there were a human
maintainer involved who could say "this patch belongs on branch X
instead," or "this patch needs to be rebased to Y," or whatever.
These are trivial for the right person to do, but often hard for the
submitter.

On the maintainer side, I spend a lot of time trying to coordinate
between patchwork (as a to-do list) and mutt (for reviewing and
applying patches).  It's a lot of pointing and clicking for not much
real value.  I know I could benefit from learning how other people do
this, because I'm sure I'm not doing it the best way.

Bjorn

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

[Julia Lawall]

> > Is this really such a major issue?  If you don't want cleanup patches,
> > just politely refuse them and point people at drivers/staging/ where I
> > will gladly take them.  It's not tough at all.
> > 
> It isn't tough or an issue for me, but I don't normally refuse cleanup
> patches either.

Politely pointing people at staging is an OK strategy, but I think newbies
would really prefer to know in advance that their patch has no chance of
being accepted.

julia

> > Or better yet, take Julia's advice, and just fix up your subsystem to
> > not need these patches at all.  That should take all of an afternoon's
> > worth of effort at most, drivers/scsi/ notwithstanding, that beast is
> > horrid...
> > 
> 
> Yes, that is what I am doing once in a while, if I need a timeout from other
> work. Since I don't mind cleanup patches, so I would set the tag to 'yes'
> for all files where I am listed as maintainer. But other maintainers do
> actively reject cleanup patches, sometimes with less then friendly words.
> 
> Without a tag, the result is to discourage cleanup patches in general,
> or what I would call the lowest common denominator. While I understand
> and accept that other maintainers dislike cleanup patches, I don't see
> why I should have to suffer the consequences.
> 
> Guenter
> 
> 

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

[Guenter Roeck]

On 07/20/2015 11:08 PM, Julia Lawall wrote:
>>> Is this really such a major issue?  If you don't want cleanup patches,
>>> just politely refuse them and point people at drivers/staging/ where I
>>> will gladly take them.  It's not tough at all.
>>>
>> It isn't tough or an issue for me, but I don't normally refuse cleanup
>> patches either.
>
> Politely pointing people at staging is an OK strategy, but I think newbies
> would really prefer to know in advance that their patch has no chance of
> being accepted.
>
Very much agreed.

Guenter

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

[Julia Lawall]

On Mon, 20 Jul 2015, Guenter Roeck wrote:

> On 07/20/2015 01:30 PM, Greg KH wrote:
> 
> > > If there really is a problem that some maintainer is getting inundated
> > > with patches addressing unimportant cosmetic issues, could it be a good
> > > idea to:
> > > 
> > > * Fix the code and get it over with,
> > > * Drop the code from the kernel, if no one uses it, or
> > > * Put a comment in the file saying that the file is no longer being
> > > actively developed and only bug fixes will be accepted.
> > 
> > I agree with this.  If your subsystem is constantly getting hit with
> > coding style cleanups that you don't want (i.e. SCSI), put something in
> > the top of the file that says "don't clean up the style".
> > 
> 
> How about a cleanup tag in MAINTAINERS ? Then checkpatch could warn
> if it is used on a file tagged as do-not-clean, and every maintainer
> could set preferences as desired.
> 
> Something like
> 
> C: yes
> C: limited (prior to functional changes only)
> C: no
> 
> Either limited or yes could be the default.
> 
> The "Obsolete" status presumably implies that cleanups are not desired,
> and checkpatch could issue a warning if it is run on an obsolete file
> or subsystem.

This seems like a good idea.  Maybe get_maintainers could add a line about 
this somehow too for people who do cleanups that are not inspired by 
checkpatch.

This does assume that the decision is mostly by maintainer rather than by 
file.

julia

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

[Josh Triplett]

On Mon, Jul 20, 2015 at 08:08:25AM +0100, James Bottomley wrote:
> the mechanical one file at a time fixing
> X.  I think we need someone to be the gatekeeper and review and apply
> the script in one go.

I often find myself writing this kind of tree-wide fix, and I find it
frustrating that it can't get merged as a unit; that would avoid the
inevitable pile of merge conflicts, as well.  For anything that can be
reliably applied as a script, I'd love to see it actually run as a
script and the result committed.

- Josh Triplett

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

[James Bottomley]

On Mon, 2015-07-20 at 01:44 -0700, Josh Triplett wrote:
> On Mon, Jul 20, 2015 at 08:08:25AM +0100, James Bottomley wrote:
> > the mechanical one file at a time fixing
> > X.  I think we need someone to be the gatekeeper and review and apply
> > the script in one go.
> 
> I often find myself writing this kind of tree-wide fix, and I find it
> frustrating that it can't get merged as a unit; that would avoid the
> inevitable pile of merge conflicts, as well.  For anything that can be
> reliably applied as a script, I'd love to see it actually run as a
> script and the result committed.

Can you propose a mechanism?  We already have the trivial tree ...
should we have the script tree, and would you volunteer to maintain it?
Probably we'd run the script just after the merge window closes, so it
would likely be a late merging tree.

James

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

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1725 bytes --]

On Mon, 2015-07-20 at 10:23 +0100, James Bottomley wrote:
> On Mon, 2015-07-20 at 01:44 -0700, Josh Triplett wrote:
> > On Mon, Jul 20, 2015 at 08:08:25AM +0100, James Bottomley wrote:
> > > the mechanical one file at a time fixing
> > > X.  I think we need someone to be the gatekeeper and review and apply
> > > the script in one go.
> > 
> > I often find myself writing this kind of tree-wide fix, and I find it
> > frustrating that it can't get merged as a unit; that would avoid the
> > inevitable pile of merge conflicts, as well.  For anything that can be
> > reliably applied as a script, I'd love to see it actually run as a
> > script and the result committed.
> 
> Can you propose a mechanism?  We already have the trivial tree ...
> should we have the script tree, and would you volunteer to maintain it?
> Probably we'd run the script just after the merge window closes, so it
> would likely be a late merging tree.

We have done that a few times, with Linus actually running the script
for himself just after the last pull for -rc1.

I think last time he may have said "never again", but perhaps that was
the nature of the changes (the include/uapi moves iirc) rather than the
act of running a script per se.

I'm not sure we need a way to handle such scripted changes in bulk.
They are relatively infrequent, aren't they?

The problem is that a lot of these really do need to be checked by a
real human after the scripted change (even Coccinelle-type changes) is
made. And thus we can't easily just let a script run free.


-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

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

[James Bottomley]

[-- Attachment #1: Type: text/plain, Size: 1842 bytes --]

On Mon, 2015-07-20 at 11:04 +0100, David Woodhouse wrote:
> On Mon, 2015-07-20 at 10:23 +0100, James Bottomley wrote:
> > On Mon, 2015-07-20 at 01:44 -0700, Josh Triplett wrote:
> > > On Mon, Jul 20, 2015 at 08:08:25AM +0100, James Bottomley wrote:
> > > > the mechanical one file at a time fixing
> > > > X.  I think we need someone to be the gatekeeper and review and apply
> > > > the script in one go.
> > > 
> > > I often find myself writing this kind of tree-wide fix, and I find it
> > > frustrating that it can't get merged as a unit; that would avoid the
> > > inevitable pile of merge conflicts, as well.  For anything that can be
> > > reliably applied as a script, I'd love to see it actually run as a
> > > script and the result committed.
> > 
> > Can you propose a mechanism?  We already have the trivial tree ...
> > should we have the script tree, and would you volunteer to maintain it?
> > Probably we'd run the script just after the merge window closes, so it
> > would likely be a late merging tree.
> 
> We have done that a few times, with Linus actually running the script
> for himself just after the last pull for -rc1.
> 
> I think last time he may have said "never again", but perhaps that was
> the nature of the changes (the include/uapi moves iirc) rather than the
> act of running a script per se.
> 
> I'm not sure we need a way to handle such scripted changes in bulk.
> They are relatively infrequent, aren't they?
> 
> The problem is that a lot of these really do need to be checked by a
> real human after the scripted change (even Coccinelle-type changes) is
> made. And thus we can't easily just let a script run free.

Agree ... that's why we need a responsible maintainer, and I believe it
would be an even more onerous task than running the trivial tree.

James


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5819 bytes --]

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

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1124 bytes --]

On Mon, 2015-07-20 at 11:30 +0100, James Bottomley wrote:
> Agree ... that's why we need a responsible maintainer, and I believe 
> it would be an even more onerous task than running the trivial tree.

I think any scripted change like this would need to come *from* a
responsible maintainer, not *through* one. I'm not sure we really need
a 'process' for it other than someone with sufficient credibility
persuading Linus to run the script.

Alternatively, it isn't *that* hard for someone like Josh (who was the
one who said he often finds himself doing this kind of thing) to create
a git tree which runs the script *regularly* on the tip of Linus' tree
(or linux-next), creating a new version of the commit which can be
pulled at that moment.

Then it should just be case of of asking Stephen to "put this tree last
in linux-next", and Linus to "pull this one last, right before
releasing -rc1". And getting the timing right for the script to run.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

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

[Zefan Li]

> Then it should just be case of of asking Stephen to "put this tree last
> in linux-next", and Linus to "pull this one last, right before
> releasing -rc1". And getting the timing right for the script to run.
> 

This makes git-blame less useful, and that's one of the reasons some
maintainers don't like trivial cleanups.

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

[Julia Lawall]

On Tue, 21 Jul 2015, Zefan Li wrote:

> > Then it should just be case of of asking Stephen to "put this tree last
> > in linux-next", and Linus to "pull this one last, right before
> > releasing -rc1". And getting the timing right for the script to run.
> > 
> 
> This makes git-blame less useful, and that's one of the reasons some
> maintainers don't like trivial cleanups.

Josh was asking about useful tree-wide changes.  How does that mae git 
blame less useful than doing the changes one by one?

And actually couldn't git blame be made to work better?

julia

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

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 500 bytes --]

On Tue, 21 Jul 2015 10:00:33 +0800 Zefan Li <lizefan@huawei.com> wrote:

> > Then it should just be case of of asking Stephen to "put this tree last
> > in linux-next", and Linus to "pull this one last, right before
> > releasing -rc1". And getting the timing right for the script to run.
> > 
> 
> This makes git-blame less useful, and that's one of the reasons some
> maintainers don't like trivial cleanups.

Sounds like we need to propose an enhancement to "git-blame"...

NeilBrown

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

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

[Steven Rostedt]

On Tue, 21 Jul 2015 18:54:36 +1000
NeilBrown <neilb@suse.com> wrote:

> On Tue, 21 Jul 2015 10:00:33 +0800 Zefan Li <lizefan@huawei.com> wrote:
> 
> > > Then it should just be case of of asking Stephen to "put this tree last
> > > in linux-next", and Linus to "pull this one last, right before
> > > releasing -rc1". And getting the timing right for the script to run.
> > > 
> > 
> > This makes git-blame less useful, and that's one of the reasons some
> > maintainers don't like trivial cleanups.
> 
> Sounds like we need to propose an enhancement to "git-blame"...
> 

No need. I use git blame all the time. Trivial patches don't bother me.

$ git blame foo.c

$ git show abc123

Sees that it's a trivial fix

$ git blame abc123~1 foo.c

$ git show def890

More changes I don't care about

$ git blame def890~1 foo.c

$ git show cde456

Ah! that's the change I was looking for!

-- Steve

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

[Bjorn Helgaas]

On Wed, Jul 22, 2015 at 8:04 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Tue, 21 Jul 2015 18:54:36 +1000
> NeilBrown <neilb@suse.com> wrote:
>
>> On Tue, 21 Jul 2015 10:00:33 +0800 Zefan Li <lizefan@huawei.com> wrote:
>>
>> > > Then it should just be case of of asking Stephen to "put this tree last
>> > > in linux-next", and Linus to "pull this one last, right before
>> > > releasing -rc1". And getting the timing right for the script to run.
>> > >
>> >
>> > This makes git-blame less useful, and that's one of the reasons some
>> > maintainers don't like trivial cleanups.
>>
>> Sounds like we need to propose an enhancement to "git-blame"...
>>
>
> No need. I use git blame all the time. Trivial patches don't bother me.
>
> $ git blame foo.c
>
> $ git show abc123
>
> Sees that it's a trivial fix
>
> $ git blame abc123~1 foo.c
>
> $ git show def890
>
> More changes I don't care about
>
> $ git blame def890~1 foo.c
>
> $ git show cde456
>
> Ah! that's the change I was looking for!

I don't know if you'd find this more work or less, but I use "git log
-p foo.c" for this instead of git blame.  Unless there's been a rename
or a move between files, one invocation is usually enough.

Bjorn

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

[Steven Rostedt]

On Wed, 22 Jul 2015 08:57:34 -0500
Bjorn Helgaas <bhelgaas@google.com> wrote:


> > Ah! that's the change I was looking for!
> 
> I don't know if you'd find this more work or less, but I use "git log
> -p foo.c" for this instead of git blame.  Unless there's been a rename
> or a move between files, one invocation is usually enough.

I've used "git log -p foo.c" before, but I find that some of my files I
work with, that is way too much info. Especially, when the commit I'm
looking for happens to be years old. I use the log -p for when I know
the change has been recent.

-- Steve

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

[James Bottomley]

On Wed, 2015-07-22 at 10:10 -0400, Steven Rostedt wrote:
> On Wed, 22 Jul 2015 08:57:34 -0500
> Bjorn Helgaas <bhelgaas@google.com> wrote:
> 
> 
> > > Ah! that's the change I was looking for!
> > 
> > I don't know if you'd find this more work or less, but I use "git log
> > -p foo.c" for this instead of git blame.  Unless there's been a rename
> > or a move between files, one invocation is usually enough.
> 
> I've used "git log -p foo.c" before, but I find that some of my files I
> work with, that is way too much info. Especially, when the commit I'm
> looking for happens to be years old. I use the log -p for when I know
> the change has been recent.

I think what we need is a git log --line <name> <path> which would track
the commits that touched a given line in <path> (hopefully even across
renames).  It shouldn't be too hard to come up with that.

James

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

[James Bottomley]

On Wed, 2015-07-22 at 07:42 -0700, James Bottomley wrote:
> On Wed, 2015-07-22 at 10:10 -0400, Steven Rostedt wrote:
> > On Wed, 22 Jul 2015 08:57:34 -0500
> > Bjorn Helgaas <bhelgaas@google.com> wrote:
> > 
> > 
> > > > Ah! that's the change I was looking for!
> > > 
> > > I don't know if you'd find this more work or less, but I use "git log
> > > -p foo.c" for this instead of git blame.  Unless there's been a rename
> > > or a move between files, one invocation is usually enough.
> > 
> > I've used "git log -p foo.c" before, but I find that some of my files I
> > work with, that is way too much info. Especially, when the commit I'm
> > looking for happens to be years old. I use the log -p for when I know
> > the change has been recent.
> 
> I think what we need is a git log --line <name> <path> which would track
> the commits that touched a given line in <path> (hopefully even across
> renames).  It shouldn't be too hard to come up with that.

Well, duh, we do, it's git log -L ... I take it no-one uses it because
like me, no-one knows about it?

James

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

[Steven Rostedt]

On Wed, 22 Jul 2015 07:42:01 -0700
James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

> I think what we need is a git log --line <name> <path> which would track
> the commits that touched a given line in <path> (hopefully even across
> renames).  It shouldn't be too hard to come up with that.

That may not be trivial. It would have to keep track of changes before
the line, to match the line in previous commits. What happens if the
line completely changes, or is in a complete rewrite of that code. I
doubt it will be smart enough to follow a single line. Perhaps a range
would be better?

-- Steve

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

[James Bottomley]

On Wed, 2015-07-22 at 10:48 -0400, Steven Rostedt wrote:
> On Wed, 22 Jul 2015 07:42:01 -0700
> James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> 
> > I think what we need is a git log --line <name> <path> which would track
> > the commits that touched a given line in <path> (hopefully even across
> > renames).  It shouldn't be too hard to come up with that.
> 
> That may not be trivial. It would have to keep track of changes before
> the line, to match the line in previous commits. What happens if the
> line completely changes, or is in a complete rewrite of that code. I
> doubt it will be smart enough to follow a single line. Perhaps a range
> would be better?

I assume you missed the follow up?  It does exist: git log -L

It will follow a single line, a line range or a regex delimited search
set.

James

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

[Josh Triplett]

On Wed, Jul 22, 2015 at 09:04:57AM -0400, Steven Rostedt wrote:
> On Tue, 21 Jul 2015 18:54:36 +1000
> NeilBrown <neilb@suse.com> wrote:
> 
> > On Tue, 21 Jul 2015 10:00:33 +0800 Zefan Li <lizefan@huawei.com> wrote:
> > 
> > > > Then it should just be case of of asking Stephen to "put this tree last
> > > > in linux-next", and Linus to "pull this one last, right before
> > > > releasing -rc1". And getting the timing right for the script to run.
> > > > 
> > > 
> > > This makes git-blame less useful, and that's one of the reasons some
> > > maintainers don't like trivial cleanups.
> > 
> > Sounds like we need to propose an enhancement to "git-blame"...
> > 
> 
> No need. I use git blame all the time. Trivial patches don't bother me.
> 
> $ git blame foo.c
> 
> $ git show abc123
> 
> Sees that it's a trivial fix
> 
> $ git blame abc123~1 foo.c
> 
> $ git show def890

If you use vim, try vim-fugitive for this.  While editing a file,
:Gblame to get the blame info.  Hit o in the blame window to open a
commit, showing the commit message and patch, automatically jumping to
the patch line that changed the line you're looking at.  If that's not
the commit you want, hit P in the blame window to re-blame from the
parent of that commit.

- Josh Triplett

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

[Luis R. Rodriguez]

On Mon, Jul 20, 2015 at 12:09:06PM +0100, David Woodhouse wrote:
> On Mon, 2015-07-20 at 11:30 +0100, James Bottomley wrote:
> > Agree ... that's why we need a responsible maintainer, and I believe 
> > it would be an even more onerous task than running the trivial tree.
> 
> I think any scripted change like this would need to come *from* a
> responsible maintainer, not *through* one. I'm not sure we really need
> a 'process' for it other than someone with sufficient credibility
> persuading Linus to run the script.
> 
> Alternatively, it isn't *that* hard for someone like Josh (who was the
> one who said he often finds himself doing this kind of thing) to create
> a git tree which runs the script *regularly* on the tip of Linus' tree
> (or linux-next), creating a new version of the commit which can be
> pulled at that moment.
> 
> Then it should just be case of of asking Stephen to "put this tree last
> in linux-next", and Linus to "pull this one last, right before
> releasing -rc1". And getting the timing right for the script to run.

I ran into quite a bit of delay / coordination through another types of
tree-wide changes recently: tree wide collateral evolutions which affect more
than one subsystem. One of the issues with this is such type of changes
may end up having 1-2 release delays before being complete unless the stars
align and everone can get in sync and agree for all changes to go through
one tree. I'm sure this is not a new thing either, but with tools like
Coccinelle I do suspect the amount of work to do this has reduced and as
such we should be able to more easily make these changes. What I found was
that our pipes were not as smooth to handle these types of changes when
needed, even if everyone was in total agreement.

I proposed a linux-oven tree [0], pricicely as David describes, which can be
used after all trees are merged. So not only would it be useful for scraped
cleanups but also tree wide collateral evolutions which span multiple
subsystems. If such a tree existed and folks knew such maintainer would
go through proper dilligence for testing, review, vetting from maintainers
I think it would make both scripted changes and tree wide collateral evolutions
easier to manage. If done through a separate tree Linus would also not need
to be involved, instread the onus of correcting patches lies on the developers
submitting to the tree and the maintainer.

[0] http://lkml.kernel.org/r/20150619231255.GC7487@garbanzo.do-not-panic.com

  Luis

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

[Tim Bird]

On 07/20/2015 12:08 AM, James Bottomley wrote:
> At the other end of the scale, perhaps we should be doing more to
> recognise good contributions.  Greg suggested prizes for first
> contributions, but what about in addition one more, say for best bug fix
> of the week (or month depending on who's running it and how much time it
> sucks)?  We could have the maintainers nominate ones they think are good
> and whoever's running this picks the best.

I think this is a great idea, and I'd be willing to help work through
the Linux Foundation on prizes and coordination.  One thing which I can
possibly put in the prize "pool", is free admission to ELC or
ELC Europe (maybe even some paid travel expenses)  I can
also talk to companies about donations for prizes (we do this for our
closing game session at events anyway).
 -- Tim

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

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1875 bytes --]

On Fri, 2015-07-17 at 13:48 -0700, josh@joshtriplett.org wrote:
> On Fri, Jul 17, 2015 at 04:39:03PM -0400, Steven Rostedt wrote:
> > On Fri, 17 Jul 2015 13:24:12 -0700 josh@joshtriplett.org wrote:
> > > If your biggest hangup as a maintainer is that people send you patches
> > > that don't have variables sorted in some particular order, perhaps you
> > > should get out of kernel development and get into bike shed colorimetry
> > > consulting.  We have enough problems getting quality patches by the
> > > metrics that *actually* correlate to quality.  And as others have
> > > pointed out in this thread, many people produce patches across numerous
> > > subsystems.
> > 
> > I personally don't have any issue with my own idiosyncrasies not being
> > met. They are usually minor, and I'll fix up the patch (and document it
> > in the change log). These minor idiosyncrasies make maintaining code
> > easier.
> 
> That's perfectly reasonable.  If you want to take the time making the
> code in your area conform to additional requirements above and beyond
> those of the kernel as a whole, go for it.  I appreciate that you don't
> ask others to do it for you.

I tend to do the same. I'll fairly consistently fix up (C) to ©, u to
µ, and found myself bitching at David Howells for using 'sec' instead
of § the other day. This far into the 21st century, there really isn't
any excuse for people not doing that, but I don't reject patches
because of it.

I do *sometimes* make people fix things to say 'KiB', 'MiB' etc. for
themselves if they've sent me something that is plain wrong and using
the powers-of-ten versions inappropriately. But often I just fix that
up for myself too.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

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

[Jiri Kosina]

On Sat, 18 Jul 2015, David Woodhouse wrote:

> I tend to do the same. I'll fairly consistently fix up (C) to ©

Slightly OT, but I'd suggest you be careful with that. I've heard lawyers 
saying that those two are unfortunately not legally equivalent.

-- 
Jiri Kosina
SUSE Labs

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

[James Bottomley]

On Mon, 2015-07-20 at 00:21 +0200, Jiri Kosina wrote:
> On Sat, 18 Jul 2015, David Woodhouse wrote:
> 
> > I tend to do the same. I'll fairly consistently fix up (C) to ©
> 
> Slightly OT, but I'd suggest you be careful with that. I've heard lawyers 
> saying that those two are unfortunately not legally equivalent.

Just to note that under the Berne convention and in most jurisdictions,
neither is actually necessary to acquire copyright.

James

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

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 716 bytes --]

On Mon, 2015-07-20 at 08:18 +0100, James Bottomley wrote:
> On Mon, 2015-07-20 at 00:21 +0200, Jiri Kosina wrote:
> > On Sat, 18 Jul 2015, David Woodhouse wrote:
> > 
> > > I tend to do the same. I'll fairly consistently fix up (C) to ©
> > 
> > Slightly OT, but I'd suggest you be careful with that. I've heard lawyers 
> > saying that those two are unfortunately not legally equivalent.
> 
> Just to note that under the Berne convention and in most jurisdictions,
> neither is actually necessary to acquire copyright.

Indeed. And although I *have* heard rumours of non-equivalence in the
past, it was always the fake (c) version that wasn't functional, while
the real © sign was.


-- 
dwmw2

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

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

[Takashi Iwai]

On Sat, 18 Jul 2015 08:17:57 +0200,
David Woodhouse wrote:
> 
> On Fri, 2015-07-17 at 13:48 -0700, josh@joshtriplett.org wrote:
> > On Fri, Jul 17, 2015 at 04:39:03PM -0400, Steven Rostedt wrote:
> > > On Fri, 17 Jul 2015 13:24:12 -0700 josh@joshtriplett.org wrote:
> > > > If your biggest hangup as a maintainer is that people send you patches
> > > > that don't have variables sorted in some particular order, perhaps you
> > > > should get out of kernel development and get into bike shed colorimetry
> > > > consulting.  We have enough problems getting quality patches by the
> > > > metrics that *actually* correlate to quality.  And as others have
> > > > pointed out in this thread, many people produce patches across numerous
> > > > subsystems.
> > > 
> > > I personally don't have any issue with my own idiosyncrasies not being
> > > met. They are usually minor, and I'll fix up the patch (and document it
> > > in the change log). These minor idiosyncrasies make maintaining code
> > > easier.
> > 
> > That's perfectly reasonable.  If you want to take the time making the
> > code in your area conform to additional requirements above and beyond
> > those of the kernel as a whole, go for it.  I appreciate that you don't
> > ask others to do it for you.
> 
> I tend to do the same. I'll fairly consistently fix up (C) to ©, u to
> µ, and found myself bitching at David Howells for using 'sec' instead
> of § the other day. This far into the 21st century, there really isn't
> any excuse for people not doing that, but I don't reject patches
> because of it.

A further off-topic note: these letters may still cause troubles even
in the 21th century because of their width definition: East Asian
Ambiguous.  It can be rendered as a wide character depending on the
system.  So, if the comment text is written with the assumption of
fixed width glyph, the alignment may be broken.


Takashi

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

[Tim Bird]

On 07/17/2015 10:37 AM, Steven Rostedt wrote:
> As I know a few maintainers that like the "reverse-xmas-tree" order,
> perhaps we could add that to CodingStyle in a section of:
> 
> --- Some Maintainer's prefer these styles ---
> 
>  These are some extra styles that maintainers prefer. Some are strict
>  about these, others may not care. It doesn't hurt to add them.
> 
> Because things like reverse x-mas tree order isn't something people are
> against doing. But some may not care if you do or don't. So listing
> all the things that a few maintainers share, may be good.

OK - I had never even heard of reverse christmas-tree order before this 
discussion, so I did some research.  For those unfamiliar, it is
sorting things by line length (most commonly include file lines 
and variable declaration lines), from longest to shortest.  This
has the effect of somewhat randomizing these items relative to
each other, which reduces the probability of patch conflicts.

I think everyone has looked at where to put a new include statement,
or local variable declaration, and wondered where the best spot is.
The reverse-christmas-tree order rule provides a definitive answer
for this question, as well as decreases the chance of patch conflicts.
What's not to love?

Well, I think this is exactly the wrong solution to the problem
this rule is trying to solve.  First, this adds one more rule
(which only a few maintainers appear to care about) to the already
lengthy "death-by-a-thousand-cuts" patch submission process which
we've been discussing in this thread.  It's a trivial rule that's
easy to follow, and it reduces patch conflicts, which are a very
real maintainer burden to resolve.  But still it adds to the submission
process incrementally.

Also, it doesn't actually solve all patch conflicts on these lines -
it just decreases the probability of them.  And it does so in a way
that sacrifices human logic and readability to make the code easier
for tools to process.  Isn't this exactly backwards?

I've long thought that patch or wiggle should be able to ignore
context lines for include statements.  It might be possible with
some work to handle the variable declaration case as well.
I'll either work on this myself, or (this is more my style ;-) )
propose funding a project through the Linux Foundation to work on this.

I'm very interested in this topic of reducing the process of
submitting patches and easing maintainer load through automation.
Part of this would be to determine what things maintainers actually
spend their time responding to, that can be addressed through
automation.  I believe this discussion has been very helpful to 
highlight some issues that at least some maintainers have. But maybe a
brainstorming session at the summit would give more areas to
consider working on.
 -- Tim

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

[Peter Hüwe]

> Seriously, this area is a minefield for new developers; it can be
> discouraging to put together your first patch, carefully follow
> everything found in SubmittingPatches, CodingStyle, SubmitChecklist, and
> HOWTO, appease the checkpatch.pl beast, carefully run get_maintainer.pl
> with the correct command-line options, and follow all the suggestions
> provided by reddit, Phoronix and 4chan, only to be told that the patch
> came in during the wrong _phase of the moon_ and they really should have
> known better.


Since when is Linus opening up the merge window by moon phases? :P 

Peter

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

[Guenter Roeck]

On 07/16/2015 06:25 AM, Mark Brown wrote:
> On Wed, Jul 15, 2015 at 09:20:43PM -0400, Steven Rostedt wrote:
>> Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
>
>>> Another problem, when a newbie tries to move out of staging to some other
>>> subsystem he likes, the maintainer may not be that much responsive. Just
>>> for example, i submitted a patch on November, 2014 and I am yet to receive
>>> a reply or review to that and the patch was not a style correction patch.
>
>> BTW, it should always be OK to ping the maintainer if they ignore a
>> patch. I believe one week is a good time to wait. And again in another
>> week if they still do not reply. I know a few maintainers that think if
>> they get to a patch that is old and the author never pinged them, they
>> think the author doesn't think that patch is too important and they
>> just delete it.
>
> Please don't encourage people to send content free pings bit instead
> resend it - a content free ping mostly just adds to mail volume which is
> pretty much the original problem.  If the patch has actually been lost
> then a resend is going to be needed anyway and if not then it's mostly
> just adding to mail volume.  With a lot of mail clients (including mutt
> which I use) the nag will get threaded in with the original patch buried
> back in the mailbox and not even be seen if that's still sitting waiting
> for handling.
>

I tried both (ping and resend). In either case the response depends on the
maintainer. Some will accept either, some will say you should have res-sent
the patch if you sent a ping, some will tell you that you should have
pinged if you re-sent it. Depending on the maintainer the response can be
pretty strong.

It would be great to have a single well defined and documented mechanism
to avoid the "whatever you do is wrong" response.

Guenter

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

[Steven Rostedt]

On Fri, 17 Jul 2015 09:10:25 -0700
Guenter Roeck <linux@roeck-us.net> wrote:


> I tried both (ping and resend). In either case the response depends on the
> maintainer. Some will accept either, some will say you should have res-sent
> the patch if you sent a ping, some will tell you that you should have
> pinged if you re-sent it. Depending on the maintainer the response can be
> pretty strong.
> 
> It would be great to have a single well defined and documented mechanism
> to avoid the "whatever you do is wrong" response.

Or at least a polite reply to have them do it the other way.

 "Hi! Sorry, I've been busy and haven't had time to review your patch.
 Can you please resend the patch to me again, my inbox corrupted your
 old one"

Sure the corruption message may be a lie, but at least it will keep
them from saying "why not use what I already sent you".

-- Steve

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

[Laurent Pinchart]

On Friday 17 July 2015 12:23:03 Steven Rostedt wrote:
> On Fri, 17 Jul 2015 09:10:25 -0700 Guenter Roeck wrote:
> > I tried both (ping and resend). In either case the response depends on the
> > maintainer. Some will accept either, some will say you should have
> > res-sent the patch if you sent a ping, some will tell you that you should
> > have pinged if you re-sent it. Depending on the maintainer the response
> > can be pretty strong.
> > 
> > It would be great to have a single well defined and documented mechanism
> > to avoid the "whatever you do is wrong" response.
> 
> Or at least a polite reply to have them do it the other way.
> 
>  "Hi! Sorry, I've been busy and haven't had time to review your patch.
>  Can you please resend the patch to me again, my inbox corrupted your
>  old one"
> 
> Sure the corruption message may be a lie,

"My dog ate your patch" sounds better to me. We could then have a contest to 
see who will come up with the best fake excuse :-)

> but at least it will keep them from saying "why not use what I already sent
> you".

-- 
Regards,

Laurent Pinchart

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

[Dan Carpenter]

One week is too short.  What's the rush?  You still have to wait over a
month to the next merge window.

I don't like [RESEND] patches.  I always treat them like a process
failure and investigate what went wrong.  Normally in staging they are
really supposed to be v2 patches with an note what changed or they are
staging/media patches which are supposed to go to linux-media.  Greg
seldom loses patches.

Steve's people who let patches age and then silently drop them...  It's
less then ideal.

regards,
dan carpenter

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

[Steven Rostedt]

On Sat, 18 Jul 2015 13:50:55 +0300
Dan Carpenter <dan.carpenter@oracle.com> wrote:

> One week is too short.  What's the rush?  You still have to wait over a
> month to the next merge window.

One ping a week is just a reminder. It doesn't fill your mailbox
quickly. It doesn't mean you need to do it in that week. Also, the
quicker it goes in before the merge window, the more testing it will
receive.

Really, a ping once a week will bother you? The once a week was what I
and a few others started to enforce when we were getting pings once a
day.

-- Steve

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1506 bytes --]

On Sat, Jul 18, 2015 at 08:19:14AM -0400, Steven Rostedt wrote:

> One ping a week is just a reminder. It doesn't fill your mailbox
> quickly. It doesn't mean you need to do it in that week. Also, the
> quicker it goes in before the merge window, the more testing it will
> receive.

It adds up pretty quickly.  No argument that merging things quickly is
good but having to read more content free e-mails is not going to help
with that.  Indeed if I'm expecting someone else to review a patch for
some reason (eg, driver maintainers) a week is about the normal time I'd
give for them to ack it if I'm confident in the patch myself so it's
sometimes a deliberately introduced delay.

Like I say my experience as a patch submitter is that I'd be sending
pings more often than not at a week whereas it's reasonably infrequent
that I need to resend anything.

> Really, a ping once a week will bother you? The once a week was what I
> and a few others started to enforce when we were getting pings once a
> day.

Yes, it does.  It's far too close to the window of normal delays that
happen (finding time to read larger or more complicated patches and
serieses, travel, whatever) and my guess is that my response if everyone
was nagging at that rate would be to treat the nags as noise and ignore
them which defeats the purpose.  These things only work if they're
unusual.

Two weeks feels like a better lower bound to me for the point between
people being "normally" busy and there being some kind of problem.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Steven Rostedt]

On Sat, 18 Jul 2015 22:29:32 +0100
Mark Brown <broonie@kernel.org> wrote:


> Two weeks feels like a better lower bound to me for the point between
> people being "normally" busy and there being some kind of problem.

Like I have previously said. I (and others) suggest one week as a
minimum. It's a general rule that we came up as the minimum (for us)
that it wouldn't bother us, because we were getting pings after a day
or two. This happened a number of times, and we finally ended up telling
people that if you send pings less than a week we are going to ignore
the patch.

If we are going to make any general rule (for adding to
SubittingPatches), it should say something like "If you don't hear from
a maintainer after sending a patch, it probably means they are busy.
Wait at least a week (and if you don't want to annoy the maintainer too
much, wait two weeks), before asking about it".

-- Steve

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

[Julia Lawall]

> All of these are the "simple" issues that really don't take long to
> resolve.  We have it documented in great detail on how to set up an
> email client, how to format the patch, and how to get everything right
> on the kernelnewbies.org site.  I also teach a class on this, one hour
> max is all it takes, unless you are at a company with a broken email
> system.  And then all bets are off, you better just install a Linux
> email server in the corner to resolve your email issues, just like all
> the major companies did (IBM, Intel, Microsoft, etc.)
>
> I applaud your attempt here, and don't want to stop you from working on
> it, but I think the real issue is having people actually look for the
> documentation and tools we already have created to do this.  If you make
> yet-another-tool, how are you going to advertise it any better than the
> existing tools/documentation are?

I agree that we have lots of very detailed documentation, but the process
is still a bit complex, and it is easy to make a mistake before one gets a
feel for it.  Having an easy way to do everything in the normal way, but
have the email end up at some test address rather than in the inboxes of
maintainers could help people get started.  On the other hand, I'm not sure
that a web form would be helpful, unless there is the expectation that some
peope would never use anything other than the web form.  There doesn't seem
to be a clear pathway from the web form to email.

julia

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

[Steven Rostedt]

On Thu, 9 Jul 2015 12:37:18 -0700
Darren Hart <dvhart@infradead.org> wrote:

> I've come to believe that this is one of many side effects of our dependency on
> a completely free form mechanism for the management of our patches, a mechanism
> which is becoming harder and harder to setup "correctly" with modern tooling
> (since the industry is killing "real email").
> 
> I spend a highly disproportionate amount of my time, relative to measurable
> quality impact to the kernel, going over the nuances of submitting patches.
> 
> 1) Must have a complete commit message
> 2) DCO goes above the ---
> 3) Include a patch changelog, do so below ---
> 4) Cc maintainers :-)
> 5) Checkpatch... checkpatch... checkpatch...

Ug, don't emphasize checkpatch. I see people making patches uglier due
to it. I have an old version of checkpatch that I sometimes run, but
the new version, IMHO, has more noise than signal.

> 6) Compiler warnings
> 7) CodingStyle :-)
> 8) Use ascii or utf8 character encodings
> 


> Looking forward a bit, I would love to see some tooling in place for people to
> submit patches either via a web form (which eliminates all the email tooling for
> submitting patches - which is where the formatting is especially critical) or
> through one of the more managed git systems, like gerrit, etc.

You mean like a web page that has a bunch of entries (like submitting a
paper to a LF conference), and you need to fill out.

Subject:  

 Fill out a one line top of this patch

Problem or enhancement :

 Why did you write this patch? Was there a problem you discovered, or
 is this a new feature you want to add.

Why this patch is needed:

 Why is this patch needed. If you fixed the problem, describe what you
 did and why you did it this way. If it is a feature, explain why this
 feature is needed, use cases for this feature, and how to use this new
 feature. If this adds a new user space interface, make sure you
 provide a man page (separate)

Patch file to upload:


Captcha:  We don't want bots doing this


Then this web server could run get_maintainers.pl and email the
appropriate people with a generated formatted patch. It could also
allow versioning. Today, people seem to be use to filling out web
forms. Obviously, this isn't a requirement to use, but could be used by
people that don't already know the Linux process.

It could be a bit smarter than get maintainers, as it could possibly
detect typo and whitespace patches and then send it off to the trivial
maintainer only.


-- Steve

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

[Darren Hart]

On Fri, Jul 10, 2015 at 11:44:09AM -0400, Steven Rostedt wrote:
> On Thu, 9 Jul 2015 12:37:18 -0700
> Darren Hart <dvhart@infradead.org> wrote:
> 
> > I've come to believe that this is one of many side effects of our dependency on
> > a completely free form mechanism for the management of our patches, a mechanism
> > which is becoming harder and harder to setup "correctly" with modern tooling
> > (since the industry is killing "real email").
> > 
> > I spend a highly disproportionate amount of my time, relative to measurable
> > quality impact to the kernel, going over the nuances of submitting patches.
> > 
> > 1) Must have a complete commit message
> > 2) DCO goes above the ---
> > 3) Include a patch changelog, do so below ---
> > 4) Cc maintainers :-)
> > 5) Checkpatch... checkpatch... checkpatch...
> 
> Ug, don't emphasize checkpatch. I see people making patches uglier due
> to it. I have an old version of checkpatch that I sometimes run, but
> the new version, IMHO, has more noise than signal.
> 
> > 6) Compiler warnings
> > 7) CodingStyle :-)
> > 8) Use ascii or utf8 character encodings
> > 
> 
> 
> > Looking forward a bit, I would love to see some tooling in place for people to
> > submit patches either via a web form (which eliminates all the email tooling for
> > submitting patches - which is where the formatting is especially critical) or
> > through one of the more managed git systems, like gerrit, etc.
> 
> You mean like a web page that has a bunch of entries (like submitting a
> paper to a LF conference), and you need to fill out.
> 
> Subject:  
> 
>  Fill out a one line top of this patch
> 
> Problem or enhancement :
> 
>  Why did you write this patch? Was there a problem you discovered, or
>  is this a new feature you want to add.
> 
> Why this patch is needed:
> 
>  Why is this patch needed. If you fixed the problem, describe what you
>  did and why you did it this way. If it is a feature, explain why this
>  feature is needed, use cases for this feature, and how to use this new
>  feature. If this adds a new user space interface, make sure you
>  provide a man page (separate)
> 
> Patch file to upload:
> 
> 
> Captcha:  We don't want bots doing this
> 
> 
> Then this web server could run get_maintainers.pl and email the
> appropriate people with a generated formatted patch. It could also
> allow versioning. Today, people seem to be use to filling out web
> forms. Obviously, this isn't a requirement to use, but could be used by
> people that don't already know the Linux process.
> 
> It could be a bit smarter than get maintainers, as it could possibly
> detect typo and whitespace patches and then send it off to the trivial
> maintainer only.

That's the general idea, yes. For people that need to fix a single thing, or are
just getting started, this could be a good sanity checker. It can then use
the standard form entry validation processes and return with a bunch of red text
indicating errors without even sending the patch to the list.

-- 
Darren Hart
Intel Open Source Technology Center

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

[Josh Triplett]

On Fri, Jul 10, 2015 at 11:44:09AM -0400, Steven Rostedt wrote:
> On Thu, 9 Jul 2015 12:37:18 -0700
> Darren Hart <dvhart@infradead.org> wrote:
> 
> > I've come to believe that this is one of many side effects of our dependency on
> > a completely free form mechanism for the management of our patches, a mechanism
> > which is becoming harder and harder to setup "correctly" with modern tooling
> > (since the industry is killing "real email").
> > 
> > I spend a highly disproportionate amount of my time, relative to measurable
> > quality impact to the kernel, going over the nuances of submitting patches.
> > 
> > 1) Must have a complete commit message
> > 2) DCO goes above the ---
> > 3) Include a patch changelog, do so below ---
> > 4) Cc maintainers :-)
> > 5) Checkpatch... checkpatch... checkpatch...
> 
> Ug, don't emphasize checkpatch. I see people making patches uglier due
> to it. I have an old version of checkpatch that I sometimes run, but
> the new version, IMHO, has more noise than signal.

If we could get some of the worst offenders turned *off*, like line
length limits, many of its most basic checks are quite useful.

> > 6) Compiler warnings
> > 7) CodingStyle :-)
> > 8) Use ascii or utf8 character encodings
> > 
> 
> 
> > Looking forward a bit, I would love to see some tooling in place for people to
> > submit patches either via a web form (which eliminates all the email tooling for
> > submitting patches - which is where the formatting is especially critical) or
> > through one of the more managed git systems, like gerrit, etc.
> 
> You mean like a web page that has a bunch of entries (like submitting a
> paper to a LF conference), and you need to fill out.
> 
> Subject:  
> 
>  Fill out a one line top of this patch
> 
> Problem or enhancement :
> 
>  Why did you write this patch? Was there a problem you discovered, or
>  is this a new feature you want to add.
> 
> Why this patch is needed:
> 
>  Why is this patch needed. If you fixed the problem, describe what you
>  did and why you did it this way. If it is a feature, explain why this
>  feature is needed, use cases for this feature, and how to use this new
>  feature. If this adds a new user space interface, make sure you
>  provide a man page (separate)
> 
> Patch file to upload:
> 
> 
> Captcha:  We don't want bots doing this
> 
> 
> Then this web server could run get_maintainers.pl and email the
> appropriate people with a generated formatted patch. It could also
> allow versioning. Today, people seem to be use to filling out web
> forms. Obviously, this isn't a requirement to use, but could be used by
> people that don't already know the Linux process.
> 
> It could be a bit smarter than get maintainers, as it could possibly
> detect typo and whitespace patches and then send it off to the trivial
> maintainer only.

I think it would make sense for such a bot to be driven by git pushes,
rather than solely by a web form.  A web form, if any, would just handle
automatic submission of a specified git series to the test address.

- Josh Triplett

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

[Darren Hart]

On Fri, Jul 10, 2015 at 09:34:51AM -0700, Josh Triplett wrote:
> On Fri, Jul 10, 2015 at 11:44:09AM -0400, Steven Rostedt wrote:
> > On Thu, 9 Jul 2015 12:37:18 -0700
> > Darren Hart <dvhart@infradead.org> wrote:
> > 
> > > I've come to believe that this is one of many side effects of our dependency on
> > > a completely free form mechanism for the management of our patches, a mechanism
> > > which is becoming harder and harder to setup "correctly" with modern tooling
> > > (since the industry is killing "real email").
> > > 
> > > I spend a highly disproportionate amount of my time, relative to measurable
> > > quality impact to the kernel, going over the nuances of submitting patches.
> > > 
> > > 1) Must have a complete commit message
> > > 2) DCO goes above the ---
> > > 3) Include a patch changelog, do so below ---
> > > 4) Cc maintainers :-)
> > > 5) Checkpatch... checkpatch... checkpatch...
> > 
> > Ug, don't emphasize checkpatch. I see people making patches uglier due
> > to it. I have an old version of checkpatch that I sometimes run, but
> > the new version, IMHO, has more noise than signal.
> 
> If we could get some of the worst offenders turned *off*, like line
> length limits, many of its most basic checks are quite useful.
> 
> > > 6) Compiler warnings
> > > 7) CodingStyle :-)
> > > 8) Use ascii or utf8 character encodings
> > > 
> > 
> > 
> > > Looking forward a bit, I would love to see some tooling in place for people to
> > > submit patches either via a web form (which eliminates all the email tooling for
> > > submitting patches - which is where the formatting is especially critical) or
> > > through one of the more managed git systems, like gerrit, etc.
> > 
> > You mean like a web page that has a bunch of entries (like submitting a
> > paper to a LF conference), and you need to fill out.
> > 
> > Subject:  
> > 
> >  Fill out a one line top of this patch
> > 
> > Problem or enhancement :
> > 
> >  Why did you write this patch? Was there a problem you discovered, or
> >  is this a new feature you want to add.
> > 
> > Why this patch is needed:
> > 
> >  Why is this patch needed. If you fixed the problem, describe what you
> >  did and why you did it this way. If it is a feature, explain why this
> >  feature is needed, use cases for this feature, and how to use this new
> >  feature. If this adds a new user space interface, make sure you
> >  provide a man page (separate)
> > 
> > Patch file to upload:
> > 
> > 
> > Captcha:  We don't want bots doing this
> > 
> > 
> > Then this web server could run get_maintainers.pl and email the
> > appropriate people with a generated formatted patch. It could also
> > allow versioning. Today, people seem to be use to filling out web
> > forms. Obviously, this isn't a requirement to use, but could be used by
> > people that don't already know the Linux process.
> > 
> > It could be a bit smarter than get maintainers, as it could possibly
> > detect typo and whitespace patches and then send it off to the trivial
> > maintainer only.
> 
> I think it would make sense for such a bot to be driven by git pushes,
> rather than solely by a web form.  A web form, if any, would just handle
> automatic submission of a specified git series to the test address.

Keep in mind first-timers. They may just have a patch they want to submit. That
is where the most value is to be had in automation in my opinion. I agree we
should also support a git url and branch, and ultimately more automation on git
pushes would be great, but I think that's secondary to the impact on
recruitment. However, that may vary by maintainer and where their burden lies
from their submitters.

-- 
Darren Hart
Intel Open Source Technology Center

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

[Steven Rostedt]

On Fri, 10 Jul 2015 09:34:51 -0700
Josh Triplett <josh@joshtriplett.org> wrote:

> > Then this web server could run get_maintainers.pl and email the
> > appropriate people with a generated formatted patch. It could also
> > allow versioning. Today, people seem to be use to filling out web
> > forms. Obviously, this isn't a requirement to use, but could be used by
> > people that don't already know the Linux process.
> > 
> > It could be a bit smarter than get maintainers, as it could possibly
> > detect typo and whitespace patches and then send it off to the trivial
> > maintainer only.
> 
> I think it would make sense for such a bot to be driven by git pushes,
> rather than solely by a web form.  A web form, if any, would just handle
> automatic submission of a specified git series to the test address.

But who's doing the git push?

This is about new comers that are submitting their own patch and don't
understand the process. If we just point them to a web interface that
lets them do a one time shot to submit a fix for something they found,
this would eliminate a lot of back and forth that is needed for newbies
to get the processing right.

-- Steve

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

[Christian Couder]

From: Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [Ksummit-discuss] [CORE TOPIC] Recruitment (Reviewers, Testers, Maintainers, Hobbyists)
Date: Fri, 10 Jul 2015 11:44:09 -0400

> On Thu, 9 Jul 2015 12:37:18 -0700
> Darren Hart <dvhart@infradead.org> wrote:
> 
>> I've come to believe that this is one of many side effects of our dependency on
>> a completely free form mechanism for the management of our patches, a mechanism
>> which is becoming harder and harder to setup "correctly" with modern tooling
>> (since the industry is killing "real email").
>> 
>> I spend a highly disproportionate amount of my time, relative to measurable
>> quality impact to the kernel, going over the nuances of submitting patches.
>> 
>> 1) Must have a complete commit message
>> 2) DCO goes above the ---
>> 3) Include a patch changelog, do so below ---
>> 4) Cc maintainers :-)
>> 5) Checkpatch... checkpatch... checkpatch...
> 
> Ug, don't emphasize checkpatch. I see people making patches uglier due
> to it. I have an old version of checkpatch that I sometimes run, but
> the new version, IMHO, has more noise than signal.
> 
>> 6) Compiler warnings
>> 7) CodingStyle :-)
>> 8) Use ascii or utf8 character encodings
>> 
> 
> 
>> Looking forward a bit, I would love to see some tooling in place for people to
>> submit patches either via a web form (which eliminates all the email tooling for
>> submitting patches - which is where the formatting is especially critical) or
>> through one of the more managed git systems, like gerrit, etc.
> 
> You mean like a web page that has a bunch of entries (like submitting a
> paper to a LF conference), and you need to fill out.

To send patch emails created from git repos on GitHub to the Git
mailing list, there is now submitGit:

https://submitgit.herokuapp.com/
https://github.com/rtyley/submitgit

Maybe Roberto, its author (cced), could be convince to do something
for the kernel?

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

[Darren Hart]

On Fri, Jul 10, 2015 at 07:32:55PM +0200, Christian Couder wrote:
> From: Steven Rostedt <rostedt@goodmis.org>
> Subject: Re: [Ksummit-discuss] [CORE TOPIC] Recruitment (Reviewers, Testers, Maintainers, Hobbyists)
> Date: Fri, 10 Jul 2015 11:44:09 -0400
> 
> > On Thu, 9 Jul 2015 12:37:18 -0700
> > Darren Hart <dvhart@infradead.org> wrote:
> > 
> >> I've come to believe that this is one of many side effects of our dependency on
> >> a completely free form mechanism for the management of our patches, a mechanism
> >> which is becoming harder and harder to setup "correctly" with modern tooling
> >> (since the industry is killing "real email").
> >> 
> >> I spend a highly disproportionate amount of my time, relative to measurable
> >> quality impact to the kernel, going over the nuances of submitting patches.
> >> 
> >> 1) Must have a complete commit message
> >> 2) DCO goes above the ---
> >> 3) Include a patch changelog, do so below ---
> >> 4) Cc maintainers :-)
> >> 5) Checkpatch... checkpatch... checkpatch...
> > 
> > Ug, don't emphasize checkpatch. I see people making patches uglier due
> > to it. I have an old version of checkpatch that I sometimes run, but
> > the new version, IMHO, has more noise than signal.
> > 
> >> 6) Compiler warnings
> >> 7) CodingStyle :-)
> >> 8) Use ascii or utf8 character encodings
> >> 
> > 
> > 
> >> Looking forward a bit, I would love to see some tooling in place for people to
> >> submit patches either via a web form (which eliminates all the email tooling for
> >> submitting patches - which is where the formatting is especially critical) or
> >> through one of the more managed git systems, like gerrit, etc.
> > 
> > You mean like a web page that has a bunch of entries (like submitting a
> > paper to a LF conference), and you need to fill out.
> 
> To send patch emails created from git repos on GitHub to the Git
> mailing list, there is now submitGit:
> 
> https://submitgit.herokuapp.com/
> https://github.com/rtyley/submitgit
> 
> Maybe Roberto, its author (cced), could be convince to do something
> for the kernel?

Something along those lines would be nice, yes. I think a lot of people would
find something like this which enforces the "mechanical" rules to be very
useful.

-- 
Darren Hart
Intel Open Source Technology Center

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

[Roberto Tyley]

It would be great to turn on submitGit for development of the Linux
Kernel. Just to clarify, submitGit is a bridge for sending GitHub pull
requests on https://github.com/git/git to git@vger.kernel.org as
correctly formatted emails

I've never submitted a patch to the kernel, but I understand there are
many development trees and corresponding maintainers/mailing lists. It
would be an interesting task to teach submitGit _where_ a patch should
go - and we would need GitHub repos which mirrored the maintainer
trees in order for people to open good pull requests against them (I'm
assuming it would be wrong for people to just open pull requests
against https://github.com/torvalds/linux/).

This script looks interesting:
https://github.com/torvalds/linux/blob/master/scripts/get_maintainer.pl

I'd be interested to hear if anyone would like to try out submitGit
for the kernel, and has any further advice.

Roberto



On 10 July 2015 at 18:49, Darren Hart <dvhart@infradead.org> wrote:
> On Fri, Jul 10, 2015 at 07:32:55PM +0200, Christian Couder wrote:
>> From: Steven Rostedt <rostedt@goodmis.org>
>> Subject: Re: [Ksummit-discuss] [CORE TOPIC] Recruitment (Reviewers, Testers, Maintainers, Hobbyists)
>> Date: Fri, 10 Jul 2015 11:44:09 -0400
>>
>> > On Thu, 9 Jul 2015 12:37:18 -0700
>> > Darren Hart <dvhart@infradead.org> wrote:
>> >
>> >> I've come to believe that this is one of many side effects of our dependency on
>> >> a completely free form mechanism for the management of our patches, a mechanism
>> >> which is becoming harder and harder to setup "correctly" with modern tooling
>> >> (since the industry is killing "real email").
>> >>
>> >> I spend a highly disproportionate amount of my time, relative to measurable
>> >> quality impact to the kernel, going over the nuances of submitting patches.
>> >>
>> >> 1) Must have a complete commit message
>> >> 2) DCO goes above the ---
>> >> 3) Include a patch changelog, do so below ---
>> >> 4) Cc maintainers :-)
>> >> 5) Checkpatch... checkpatch... checkpatch...
>> >
>> > Ug, don't emphasize checkpatch. I see people making patches uglier due
>> > to it. I have an old version of checkpatch that I sometimes run, but
>> > the new version, IMHO, has more noise than signal.
>> >
>> >> 6) Compiler warnings
>> >> 7) CodingStyle :-)
>> >> 8) Use ascii or utf8 character encodings
>> >>
>> >
>> >
>> >> Looking forward a bit, I would love to see some tooling in place for people to
>> >> submit patches either via a web form (which eliminates all the email tooling for
>> >> submitting patches - which is where the formatting is especially critical) or
>> >> through one of the more managed git systems, like gerrit, etc.
>> >
>> > You mean like a web page that has a bunch of entries (like submitting a
>> > paper to a LF conference), and you need to fill out.
>>
>> To send patch emails created from git repos on GitHub to the Git
>> mailing list, there is now submitGit:
>>
>> https://submitgit.herokuapp.com/
>> https://github.com/rtyley/submitgit
>>
>> Maybe Roberto, its author (cced), could be convince to do something
>> for the kernel?
>
> Something along those lines would be nice, yes. I think a lot of people would
> find something like this which enforces the "mechanical" rules to be very
> useful.
>
> --
> Darren Hart
> Intel Open Source Technology Center

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

[Darren Hart]

On Fri, Jul 10, 2015 at 08:35:59PM +0100, Roberto Tyley wrote:

Hi Roberto,

Thanks for chiming in.

> It would be great to turn on submitGit for development of the Linux
> Kernel. Just to clarify, submitGit is a bridge for sending GitHub pull
> requests on https://github.com/git/git to git@vger.kernel.org as
> correctly formatted emails

While there is value there and would help a lot of people, given the popularity
of git-hub, I think we're looking for something more generic.

I'd prefer a web-form hosted on kernel.org that could accept a raw patch, or a
git URL and tag or branch from any reposiory (github or otherwise), and submit
the patch after performing a number of validation checks before ever sending to
the list.

I understand this maybe isn't an extension of submitGit, but the concept of
submitGit is interesting from a precedence perspective.

> I've never submitted a patch to the kernel, but I understand there are
> many development trees and corresponding maintainers/mailing lists. It
> would be an interesting task to teach submitGit _where_ a patch should
> go - and we would need GitHub repos which mirrored the maintainer
> trees in order for people to open good pull requests against them (I'm
> assuming it would be wrong for people to just open pull requests
> against https://github.com/torvalds/linux/).
> 
> This script looks interesting:
> https://github.com/torvalds/linux/blob/master/scripts/get_maintainer.pl

Yes, this should be used to identify lists and maintainers who should be Cc'd.

> I'd be interested to hear if anyone would like to try out submitGit
> for the kernel, and has any further advice.
> 
> Roberto
> 

Thanks,

Darren

P.S. I don't know if your top posting was intentional (very clever) or
accidental (case in point), but either way it's dripping with irony. ;-)



> 
> 
> On 10 July 2015 at 18:49, Darren Hart <dvhart@infradead.org> wrote:
> > On Fri, Jul 10, 2015 at 07:32:55PM +0200, Christian Couder wrote:
> >> From: Steven Rostedt <rostedt@goodmis.org>
> >> Subject: Re: [Ksummit-discuss] [CORE TOPIC] Recruitment (Reviewers, Testers, Maintainers, Hobbyists)
> >> Date: Fri, 10 Jul 2015 11:44:09 -0400
> >>
> >> > On Thu, 9 Jul 2015 12:37:18 -0700
> >> > Darren Hart <dvhart@infradead.org> wrote:
> >> >
> >> >> I've come to believe that this is one of many side effects of our dependency on
> >> >> a completely free form mechanism for the management of our patches, a mechanism
> >> >> which is becoming harder and harder to setup "correctly" with modern tooling
> >> >> (since the industry is killing "real email").
> >> >>
> >> >> I spend a highly disproportionate amount of my time, relative to measurable
> >> >> quality impact to the kernel, going over the nuances of submitting patches.
> >> >>
> >> >> 1) Must have a complete commit message
> >> >> 2) DCO goes above the ---
> >> >> 3) Include a patch changelog, do so below ---
> >> >> 4) Cc maintainers :-)
> >> >> 5) Checkpatch... checkpatch... checkpatch...
> >> >
> >> > Ug, don't emphasize checkpatch. I see people making patches uglier due
> >> > to it. I have an old version of checkpatch that I sometimes run, but
> >> > the new version, IMHO, has more noise than signal.
> >> >
> >> >> 6) Compiler warnings
> >> >> 7) CodingStyle :-)
> >> >> 8) Use ascii or utf8 character encodings
> >> >>
> >> >
> >> >
> >> >> Looking forward a bit, I would love to see some tooling in place for people to
> >> >> submit patches either via a web form (which eliminates all the email tooling for
> >> >> submitting patches - which is where the formatting is especially critical) or
> >> >> through one of the more managed git systems, like gerrit, etc.
> >> >
> >> > You mean like a web page that has a bunch of entries (like submitting a
> >> > paper to a LF conference), and you need to fill out.
> >>
> >> To send patch emails created from git repos on GitHub to the Git
> >> mailing list, there is now submitGit:
> >>
> >> https://submitgit.herokuapp.com/
> >> https://github.com/rtyley/submitgit
> >>
> >> Maybe Roberto, its author (cced), could be convince to do something
> >> for the kernel?
> >
> > Something along those lines would be nice, yes. I think a lot of people would
> > find something like this which enforces the "mechanical" rules to be very
> > useful.
> >
> > --
> > Darren Hart
> > Intel Open Source Technology Center
> 

-- 
Darren Hart
Intel Open Source Technology Center

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

[Laura Abbott]

On 07/10/2015 03:49 PM, Darren Hart wrote:
> On Fri, Jul 10, 2015 at 08:35:59PM +0100, Roberto Tyley wrote:
>
> Hi Roberto,
>
> Thanks for chiming in.
>
>> It would be great to turn on submitGit for development of the Linux
>> Kernel. Just to clarify, submitGit is a bridge for sending GitHub pull
>> requests on https://github.com/git/git to git@vger.kernel.org as
>> correctly formatted emails
>
> While there is value there and would help a lot of people, given the popularity
> of git-hub, I think we're looking for something more generic.
>
> I'd prefer a web-form hosted on kernel.org that could accept a raw patch, or a
> git URL and tag or branch from any reposiory (github or otherwise), and submit
> the patch after performing a number of validation checks before ever sending to
> the list.
>

FWIW, an upload system has existed for a while for ARM Linux for final
submissions. Note this is distinctly not for review so correctly
e-mailing a patch is still necessary. I still find the web form useful
though for making submissions.

http://www.arm.linux.org.uk/developer/patches/info.php
  

Thanks,
Laura

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

[Roberto Tyley]

On 10 July 2015 at 23:49, Darren Hart <dvhart@infradead.org> wrote:
> On Fri, Jul 10, 2015 at 08:35:59PM +0100, Roberto Tyley wrote:
>> It would be great to turn on submitGit for development of the Linux
>> Kernel. Just to clarify, submitGit is a bridge for sending GitHub pull
>> requests on https://github.com/git/git to git@vger.kernel.org as
>> correctly formatted emails
>
> While there is value there and would help a lot of people, given the popularity
> of git-hub, I think we're looking for something more generic.
>
> I'd prefer a web-form hosted on kernel.org that could accept a raw patch, or a
> git URL and tag or branch from any reposiory (github or otherwise), and submit
> the patch after performing a number of validation checks before ever sending to
> the list.
>
> I understand this maybe isn't an extension of submitGit, but the concept of
> submitGit is interesting from a precedence perspective.

Fair enough - glad to provide a precedent, if not an implementation!


> P.S. I don't know if your top posting was intentional (very clever) or
> accidental (case in point), but either way it's dripping with irony. ;-)

Totally unintentional irony :-)

[Ksummit-discuss] checkpatch.pl stuff...

[Dan Carpenter]

On Fri, Jul 10, 2015 at 11:44:09AM -0400, Steven Rostedt wrote:
> Ug, don't emphasize checkpatch. I see people making patches uglier due
> to it. I have an old version of checkpatch that I sometimes run, but
> the new version, IMHO, has more noise than signal.

I have seen people do some very ugly things to satisfy the 80 character
limit.  Recently someone sent a patch to make a config description long
enough for checkpatch and
the they did it
by adding by adding
lots and lots of
newlines like this.  :)

Anyway, I ran checkpatch.pl on your last 500 patches to see what you
were complaining about specifically.

    230 WARNING: please, no spaces at the start of a line

Checkpatch doesn't handle perl well.

    207 WARNING: line over 80 characters

These are over reported because of a bug in checkpatch.pl which should
be fixed in Mondays linux-next.

    149 ERROR: space prohibited after that open parenthesis '('
    137 ERROR: space prohibited before that close parenthesis ')'

The spaces were added deliberately to make things line up nicely.
Because the table is longish then it creates a lot of warnings.

    115 WARNING: Possible unwrapped commit description (prefer a maximum 75 chars per line)

These were mostly oops output and fixes-lines.

    106 ERROR: trailing whitespace
     43 WARNING: macros should not use a trailing semicolon

The other main issue is that trace code is written in preprocessor
instead of C.  It's a bit unique like that.

     27 WARNING: Prefer pr_warn(... to pr_warning(...

A bunch of things are quite picky.  Why don't we just sed away
pr_warning() and get rid of this checkpatch warning?

     18 WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
     17 ERROR: Macros with complex values should be enclosed in parentheses
     15 ERROR: Macros with multiple statements should be enclosed in a do - while loop
     13 ERROR: space required after that ',' (ctx:VxV)
     11 WARNING: Prefer seq_puts to seq_printf
     10 WARNING: externs should be avoided in .c files
     10 ERROR: Do not include the paragraph about writing to the Free Software Foundation's mailing address from the sample GPL notice. The FSF has changed addresses in the past, and may do so again. Linux already includes a copy of the GPL.
      8 WARNING: quoted string split across lines
      8 WARNING: Missing a blank line after declarations
      6 WARNING: use relative pathname instead of absolute in changelog text
      6 WARNING: printk() should include KERN_ facility level
      5 WARNING: please, no space before tabs
      4 WARNING: Prefer [subsystem eg: netdev]_cont([subsystem]dev, ... then dev_cont(dev, ... then pr_cont(...  to printk(KERN_CONT ...
      4 WARNING: networking block comments don't use an empty /* line, use /* Comment...
      4 WARNING: Macros with flow control statements should be avoided
      4 ERROR: code indent should use tabs where possible
      3 WARNING: Possible switch case/default not preceeded by break or fallthrough comment
      3 ERROR: space required after that close brace '}'
      2 WARNING: Use a single space after To:
      2 WARNING: suspect code indent for conditional statements (16, 20)
      2 WARNING: 'charater' may be misspelled - perhaps 'character'?
      2 WARNING: braces {} are not necessary for single statement blocks
      2 WARNING: 'agaist' may be misspelled - perhaps 'against'?
      2 ERROR: Unrecognized email address: ''
      1 WARNING: 'writting' may be misspelled - perhaps 'writing'?
      1 WARNING: unnecessary whitespace before a quoted newline
      1 WARNING: 'teh' may be misspelled - perhaps 'the'?
      1 WARNING: struct file_operations should normally be const
      1 WARNING: static const char * array should probably be static const char * const
      1 WARNING: space prohibited between function name and open parenthesis '('
      1 WARNING: space prohibited before semicolon
      1 WARNING: simple_strtoull is obsolete, use kstrtoull instead
      1 WARNING: 'seach' may be misspelled - perhaps 'search'?
      1 WARNING: Possible unnecessary 'out of memory' message

The rest are spelling mistakes and minor things.

Looking through this, your code is different and special so it doesn't
work for you, but you aren't dealing with as many newbies as the rest of
us so that's ok.

I also ran checkpatch over the last 1000 patches from drivers/.

    741 WARNING: line over 80 characters
    141 WARNING: Possible unwrapped commit description (prefer a maximum 75 chars per line)
     41 WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
     32 ERROR: space prohibited after that open parenthesis '('
     28 WARNING: quoted string split across lines
     17 WARNING: braces {} are not necessary for single statement blocks
     15 WARNING: Missing a blank line after declarations
     11 WARNING: space prohibited between function name and open parenthesis '('
     11 WARNING: please, no spaces at the start of a line
      8 ERROR: code indent should use tabs where possible
      6 ERROR: "foo * bar" should be "foo *bar"
      5 WARNING: use relative pathname instead of absolute in changelog text
      5 WARNING: Possible unnecessary 'out of memory' message
      5 WARNING: msleep < 20ms can sleep for up to 20ms; see Documentation/timers/timers-howto.txt
      4 WARNING: unnecessary whitespace before a quoted newline
      4 ERROR: space required after that ',' (ctx:VxV)
      3 WARNING: Use #include <linux/io.h> instead of <asm/io.h>
      3 WARNING: sizeof *sctx should be sizeof(*sctx)
      3 WARNING: please write a paragraph that describes the config symbol fully
      3 WARNING: networking block comments don't use an empty /* line, use /* Comment...
      3 WARNING: braces {} are not necessary for any arm of this statement
      3 ERROR: Unrecognized email address: 'robh+dt@kernel.org'
      3 ERROR: Unrecognized email address: 'ijc+devicetree@hellion.org.uk'
      3 ERROR: space required after that ',' (ctx:OxV)
      3 ERROR: do not use assignment in if condition
      2 WARNING: Use of volatile is usually wrong: see Documentation/volatile-considered-harmful.txt
      2 WARNING: Use a single space after Cc:
      2 WARNING: 'unecessary' may be misspelled - perhaps 'unnecessary'?
      2 WARNING: sizeof(& should be avoided
      2 WARNING: Single statement macros should not use a do {} while (0) loop
      2 WARNING: Prefer [subsystem eg: netdev]_info([subsystem]dev, ... then dev_info(dev, ... then pr_info(...  to printk(KERN_INFO ...
      2 WARNING: Prefer [subsystem eg: netdev]_err([subsystem]dev, ... then dev_err(dev, ... then pr_err(...  to printk(KERN_ERR ...
      2 WARNING: please, no space before tabs
      2 WARNING: 'overriden' may be misspelled - perhaps 'overridden'?
      2 WARNING: Non-standard signature: Requested-by:
      2 WARNING: Macros with flow control statements should be avoided
      2 WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable
      2 WARNING: else is not generally useful after a break or return
      2 WARNING: A patch subject line should describe the change not the tool that found it
      2 ERROR: space required before the open parenthesis '('
      2 ERROR: space required before that '&' (ctx:OxV)

Checkpatch.pl basically works for drivers.  There are a lot fewer
warnings and even the warnings that make it through the review process
are often correct.

regards,
dan carpenter

Re: [Ksummit-discuss] checkpatch.pl stuff...

[Heiko Carstens]

On Sat, Jul 11, 2015 at 12:31:26PM +0300, Dan Carpenter wrote:
> On Fri, Jul 10, 2015 at 11:44:09AM -0400, Steven Rostedt wrote:
> > Ug, don't emphasize checkpatch. I see people making patches uglier due
> > to it. I have an old version of checkpatch that I sometimes run, but
> > the new version, IMHO, has more noise than signal.
> 
> I have seen people do some very ugly things to satisfy the 80 character
> limit.  Recently someone sent a patch to make a config description long
> enough for checkpatch and
> the they did it
> by adding by adding
> lots and lots of
> newlines like this.  :)

The 80 character limit warning is the only thing I really dislike about
checkpatch. I've seen so many patches with insane ;) line breaks just to
satisfy this rule.
Unfortunately even experienced developers think this is a hard limit.
Argueing that checkpatch just gives you a hint that something _could_ be
improved are most of the time pointless. "But checkpatch says... therefore
it has be to like that." ;)

Besides that it I think it works just fine.

Re: [Ksummit-discuss] checkpatch.pl stuff...

[Steven Rostedt]

On Sat, 11 Jul 2015 13:34:47 +0200
Heiko Carstens <heiko.carstens@de.ibm.com> wrote:

> The 80 character limit warning is the only thing I really dislike about
> checkpatch. I've seen so many patches with insane ;) line breaks just to
> satisfy this rule.
> Unfortunately even experienced developers think this is a hard limit.
> Argueing that checkpatch just gives you a hint that something _could_ be
> improved are most of the time pointless. "But checkpatch says... therefore
> it has be to like that." ;)
> 
> Besides that it I think it works just fine.

I'll admit, as Dan said, that my patches are somewhat "special". But
what I really hate, is that argument I have had with people where I
comment on a patch, and they argue the "but checkpatch says". Yeah,
that can get annoying.

-- Steve

Re: [Ksummit-discuss] checkpatch.pl stuff...

[Joe Perches]

On Sat, 2015-07-11 at 08:51 -0400, Steven Rostedt wrote:
> On Sat, 11 Jul 2015 13:34:47 +0200
> Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
> 
> > The 80 character limit warning is the only thing I really dislike about
> > checkpatch. I've seen so many patches with insane ;) line breaks just to
> > satisfy this rule.
> > Unfortunately even experienced developers think this is a hard limit.
> > Argueing that checkpatch just gives you a hint that something _could_ be
> > improved are most of the time pointless. "But checkpatch says... therefore
> > it has be to like that." ;)
> > 
> > Besides that it I think it works just fine.
> 
> I'll admit, as Dan said, that my patches are somewhat "special". But
> what I really hate, is that argument I have had with people where I
> comment on a patch, and they argue the "but checkpatch says". Yeah,
> that can get annoying.

It can and does.  Especially the "long_lines" message.

It'd be good if somehow checkpatch output could be
viewed more as lighthearted suggestions rather than
iron-clad rules.

Maybe changing the "WARNING" type messages to a new
"SUGGESTION" might be better to let people know that
it's OK to ignore some rules.

Maybe reclassifying some ERROR type messages to
WARNING/SUGGESTION might help.

I'd like to see checkpatch used quite a bit less on
files and perhaps a bit more on actual patches.

I've suggested a few things.

https://lkml.org/lkml/2015/2/11/433

o Only allow checkpatch to be used with the -f/--file
  option for drivers/staging/
o Add an undocumented --force command line option
o Make --strict the default for drivers/staging

I think these checkpatch style-based --type=<foo>
white-space rules are generally reasonable and should
nearly always be followed for basic kernel style
conformance:

o spacing
o space_before_tab
o pointer_location
o trailing_whitespace
o bracket_space
o leading_space

The brace line position rules are generally reasonable:

o open_brace
o braces
o else_after_brace
o while_after_brace

The vertical line rules like "blank line after
declarations" and "consecutive blank lines" are
likely reasonable but may be dubious.

o line_spacing

There are some additional rules active only when
the --strict option is used that some like

o spacing 
  (space after a cast)
  (spaces around operators and arithmetic)
o line spacing
  (blank line after function/struct/union/enum)

These style-based rules are perhaps a bit dubious:

o long_line
o logical_continuations
o parenthesis_alignment

This one I think senseless (minimum 4 line), but
there is an override capability:

o config_description

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

[Bjorn Helgaas]

On Tue, Jul 7, 2015 at 7:50 PM, Guenter Roeck <linux@roeck-us.net> wrote:

> ... In once recent case, where I did spend the time,
> and I thought the maintainer had agreed to accept the patch, I ended up
> getting an automated patchwork email telling me that the patch was
> deferred indefinitely. Not really encouraging either.

Hmm, I use patchwork, but I don't have any idea what it looks like on
the submitter's side.  If it generates discouraging emails, that's bad
news to me.  I change the state of lots of patches because (a) they
were cross-posted and I expect another maintainer to deal with them,
(b) they have been superseded, (c) there have been reviews that
require a respin, etc.  I'm not very careful about the actual state
because from my point of view, all the states do the same thing:
remove the patch from my to-do list.

I wish I knew how to use patchwork better, or had a smarter workflow
that could comprehend a series as a single entity.  Patchwork is a lot
of clicking, but I don't know anything better.

Bjorn

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

[Guenter Roeck]

On 07/08/2015 07:20 AM, Bjorn Helgaas wrote:
> On Tue, Jul 7, 2015 at 7:50 PM, Guenter Roeck <linux@roeck-us.net> wrote:
>
>> ... In once recent case, where I did spend the time,
>> and I thought the maintainer had agreed to accept the patch, I ended up
>> getting an automated patchwork email telling me that the patch was
>> deferred indefinitely. Not really encouraging either.
>
> Hmm, I use patchwork, but I don't have any idea what it looks like on
> the submitter's side.  If it generates discouraging emails, that's bad
> news to me.  I change the state of lots of patches because (a) they
> were cross-posted and I expect another maintainer to deal with them,
> (b) they have been superseded, (c) there have been reviews that
> require a respin, etc.  I'm not very careful about the actual state
> because from my point of view, all the states do the same thing:
> remove the patch from my to-do list.
>
> I wish I knew how to use patchwork better, or had a smarter workflow
> that could comprehend a series as a single entity.  Patchwork is a lot
> of clicking, but I don't know anything better.
>

Wasn't you (in case you think so), and I don't think it is a problem that
patchwork sends e-mail. The problem in this case was that the maintainer
seemed to suggest that he would accept the patch before deferring it.
At that point I gave up pushing for it.

Now, if you set a bug to "deferred" state because you intend to pick it
up for the next release, that would be different and might in fact be
considered discouraging, unless you let the submitter know what is going on.

Guenter

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

[Bjorn Helgaas]

On Wed, Jul 8, 2015 at 9:34 AM, Guenter Roeck <linux@roeck-us.net> wrote:
> On 07/08/2015 07:20 AM, Bjorn Helgaas wrote:
>> On Tue, Jul 7, 2015 at 7:50 PM, Guenter Roeck <linux@roeck-us.net> wrote:
>>
>>> ... In once recent case, where I did spend the time,
>>> and I thought the maintainer had agreed to accept the patch, I ended up
>>> getting an automated patchwork email telling me that the patch was
>>> deferred indefinitely. Not really encouraging either.
>>
>> Hmm, I use patchwork, but I don't have any idea what it looks like on
>> the submitter's side.  If it generates discouraging emails, that's bad
>> news to me.  I change the state of lots of patches because (a) they
>> were cross-posted and I expect another maintainer to deal with them,
>> (b) they have been superseded, (c) there have been reviews that
>> require a respin, etc.  I'm not very careful about the actual state
>> because from my point of view, all the states do the same thing:
>> remove the patch from my to-do list.
>>
>> I wish I knew how to use patchwork better, or had a smarter workflow
>> that could comprehend a series as a single entity.  Patchwork is a lot
>> of clicking, but I don't know anything better.
>
> Wasn't you (in case you think so), and I don't think it is a problem that
> patchwork sends e-mail. The problem in this case was that the maintainer
> seemed to suggest that he would accept the patch before deferring it.
> At that point I gave up pushing for it.
>
> Now, if you set a bug to "deferred" state because you intend to pick it
> up for the next release, that would be different and might in fact be
> considered discouraging, unless you let the submitter know what is going on.

That's one thing I don't like about patchwork: there's no way that I
know of to annotate the state change.  I'd like a way to change the
state to "Changes requested" along with a pointer to the relevant
email.  Or to "Not applicable" along with a pointer to the other tree
I expect it to go through.

It'd be nice if one could include patchwork directives in an email,
the way you can with the Debian bug tracker.

Bjorn

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

[Daniel Vetter]

On Wed, Jul 8, 2015 at 4:20 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> I wish I knew how to use patchwork better, or had a smarter workflow
> that could comprehend a series as a single entity.  Patchwork is a lot
> of clicking, but I don't know anything better.

We're working on improving patchwork here to understand series and
help out with auto-deprecating patches when new versions show up.
Currently being tested internally and we plan to push to upstream ofc
and deploy on freedesktop.org (since that's where all the drm/gfx
folks hang out), but because of all the things going on it's really
slow. Damien knows more, maybe we could push the current state to some
git branch somewhere.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

[Laurent Pinchart]

On Wednesday 08 July 2015 21:19:27 Daniel Vetter wrote:
> On Wed, Jul 8, 2015 at 4:20 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> > I wish I knew how to use patchwork better, or had a smarter workflow
> > that could comprehend a series as a single entity.  Patchwork is a lot
> > of clicking, but I don't know anything better.
> 
> We're working on improving patchwork here to understand series and
> help out with auto-deprecating patches when new versions show up.
> Currently being tested internally and we plan to push to upstream ofc
> and deploy on freedesktop.org (since that's where all the drm/gfx
> folks hang out), but because of all the things going on it's really
> slow. Damien knows more, maybe we could push the current state to some
> git branch somewhere.

I implemented support for auto-delegating patches to developers based on the 
files touched by the patch, using regular expressions. We're using this for 
the media subsystem, but I've never found^H^H^H^H^Htook the time to push the 
changes upstream. Would anyone be interested in that ?

-- 
Regards,

Laurent Pinchart

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

[Michael Ellerman]

On Wed, 2015-07-08 at 21:19 +0200, Daniel Vetter wrote:
> On Wed, Jul 8, 2015 at 4:20 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> > I wish I knew how to use patchwork better, or had a smarter workflow
> > that could comprehend a series as a single entity.  Patchwork is a lot
> > of clicking, but I don't know anything better.
> 
> We're working on improving patchwork here to understand series and
> help out with auto-deprecating patches when new versions show up.
> Currently being tested internally and we plan to push to upstream ofc
> and deploy on freedesktop.org (since that's where all the drm/gfx
> folks hang out), but because of all the things going on it's really
> slow. Damien knows more, maybe we could push the current state to some
> git branch somewhere.

I'd be interested in that if you can publish it somewhere.

At the moment I have a very hacky script that tries to recognise a series on
the client, which usually works, but not always.

cheers

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

[Damien Lespiau]

On Thu, Jul 09, 2015 at 01:56:53PM +1000, Michael Ellerman wrote:
> On Wed, 2015-07-08 at 21:19 +0200, Daniel Vetter wrote:
> > On Wed, Jul 8, 2015 at 4:20 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> > > I wish I knew how to use patchwork better, or had a smarter workflow
> > > that could comprehend a series as a single entity.  Patchwork is a lot
> > > of clicking, but I don't know anything better.
> > 
> > We're working on improving patchwork here to understand series and
> > help out with auto-deprecating patches when new versions show up.
> > Currently being tested internally and we plan to push to upstream ofc
> > and deploy on freedesktop.org (since that's where all the drm/gfx
> > folks hang out), but because of all the things going on it's really
> > slow. Damien knows more, maybe we could push the current state to some
> > git branch somewhere.
> 
> I'd be interested in that if you can publish it somewhere.
> 
> At the moment I have a very hacky script that tries to recognise a series on
> the client, which usually works, but not always.

I have quite a few patches on top of upstream now. It's really a back
burner distraction, so well, I have no ETA to give for when I'd be happy
with the state of this work.

I have a work-in-progress branch here:

  https://github.com/dlespiau/patchwork

What's on there is roughly a re-design of the interface, a new REST API
and parsing/presenting series to the user, not just patches.

I have some more work (unpublished because not quite ready) on top of
this to parse and present new versions/revisions of series when:
  - people post a v2/3/4/... of a patch as a reply to one of the series
  - people post a full new series as a v2/3/4/..

The goal being one series object (with a unique ID for that patchwork
instance) represents the whole life cycle of that work, including
multiple versions.

-- 
Damien

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

[Michael Ellerman]

On Mon, 2015-07-13 at 12:05 +0100, Damien Lespiau wrote:
> On Thu, Jul 09, 2015 at 01:56:53PM +1000, Michael Ellerman wrote:
> > On Wed, 2015-07-08 at 21:19 +0200, Daniel Vetter wrote:
> > > On Wed, Jul 8, 2015 at 4:20 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> > > > I wish I knew how to use patchwork better, or had a smarter workflow
> > > > that could comprehend a series as a single entity.  Patchwork is a lot
> > > > of clicking, but I don't know anything better.
> > > 
> > > We're working on improving patchwork here to understand series and
> > > help out with auto-deprecating patches when new versions show up.
> > > Currently being tested internally and we plan to push to upstream ofc
> > > and deploy on freedesktop.org (since that's where all the drm/gfx
> > > folks hang out), but because of all the things going on it's really
> > > slow. Damien knows more, maybe we could push the current state to some
> > > git branch somewhere.
> > 
> > I'd be interested in that if you can publish it somewhere.
> > 
> > At the moment I have a very hacky script that tries to recognise a series on
> > the client, which usually works, but not always.
> 
> I have quite a few patches on top of upstream now. It's really a back
> burner distraction, so well, I have no ETA to give for when I'd be happy
> with the state of this work.

Yeah fair enough, I'm in the same boat, it's a tool I use for my job but it's
not my job to work on the tool :)

> I have a work-in-progress branch here:
> 
>   https://github.com/dlespiau/patchwork
> 
> What's on there is roughly a re-design of the interface, a new REST API
> and parsing/presenting series to the user, not just patches.
> 
> I have some more work (unpublished because not quite ready) on top of
> this to parse and present new versions/revisions of series when:
>   - people post a v2/3/4/... of a patch as a reply to one of the series
>   - people post a full new series as a v2/3/4/..
> 
> The goal being one series object (with a unique ID for that patchwork
> instance) represents the whole life cycle of that work, including
> multiple versions.

Sounds great.

Maybe we can slowly get some of it merged, I'll try and have a look at it in my
copious spare time.

cheers

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

[Damien Lespiau]

On Tue, Jul 14, 2015 at 03:41:40PM +1000, Michael Ellerman wrote:
> Maybe we can slowly get some of it merged, I'll try and have a look at it in my
> copious spare time.

I did give it a go with a first batch[1] and Jeremy sounded open to the
ideas and came back with a few comments. After that, it's all a big blur
with actual work taking over.

I do hope to go back at it soon-ish, it's becoming increasingly
important for the i915 driver and mesa (talking about the the patchwork
instance on freedeskop.org).

-- 
Damien

[1] https://lists.ozlabs.org/pipermail/patchwork/2014-November/001148.html

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1555 bytes --]

On Wed, Jul 08, 2015 at 02:49:47AM +0300, Laurent Pinchart wrote:
> On Wednesday 08 July 2015 01:21:40 Peter Huewe wrote:

> > We are definitely short on reviewers and thus have mostly overloaded
> > maintainers.

> I was about to propose a related core topic.

> The reviewing and maintainership process seems to have a hard time scaling to 
> the amount of contributions we receive, to the point where even well known and 
> respected kernel developers get discourages.

tl;dr - upstreaming support for out of tree SoCs is currently often
hard and time consuming.

> Throwing more maintainers, co-maintainers or sub-maintainers at the kernel 
> won't magically solve this, as the more core developers a subsystem has the 
> more difficult it will be for them to synchronize. I would like share 
> experience about good practice rules that have proved to be effective.

Right.  In the specific case of upstreaming out of tree SoCs it's often
in a large part part that there's some massive technical debt in the out
of tree code working around generic problems in mainline, things like
missing features or subsystems.  On the one hand those are the hardest
bits to get solved upstream, but equally because they present generic
issues they should be the easiest to collaborate on.

Tim Bird (CCed) has been working to try to get people together to try to
analyze what's in the kernels people ship on product and see what we can
do to bring that debt down, there's already some people starting to do
some active work on this.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Jason Cooper]

On Wed, Jul 08, 2015 at 05:43:10PM +0100, Mark Brown wrote:
> On Wed, Jul 08, 2015 at 02:49:47AM +0300, Laurent Pinchart wrote:
> > On Wednesday 08 July 2015 01:21:40 Peter Huewe wrote:
> 
> > > We are definitely short on reviewers and thus have mostly overloaded
> > > maintainers.
> 
> > I was about to propose a related core topic.
> 
> > The reviewing and maintainership process seems to have a hard time scaling to 
> > the amount of contributions we receive, to the point where even well known and 
> > respected kernel developers get discourages.
> 
> tl;dr - upstreaming support for out of tree SoCs is currently often
> hard and time consuming.
> 
> > Throwing more maintainers, co-maintainers or sub-maintainers at the kernel 
> > won't magically solve this, as the more core developers a subsystem has the 
> > more difficult it will be for them to synchronize. I would like share 
> > experience about good practice rules that have proved to be effective.
> 
> Right.  In the specific case of upstreaming out of tree SoCs it's often
> in a large part part that there's some massive technical debt in the out
> of tree code working around generic problems in mainline, things like
> missing features or subsystems.  On the one hand those are the hardest
> bits to get solved upstream, but equally because they present generic
> issues they should be the easiest to collaborate on.
> 
> Tim Bird (CCed) has been working to try to get people together to try to
> analyze what's in the kernels people ship on product and see what we can
> do to bring that debt down, there's already some people starting to do
> some active work on this.

I'd like to include Sebastian Hesslebarth (maintainer of mach-berlin) in
this discussion.  Him and the free-electron's guys (Thomas, Gregory,
etc) have a lot of valuable first hand experience in this topic.

thx,

Jason.

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

[Greg KH]

On Wed, Jul 08, 2015 at 01:21:40AM +0200, Peter Huewe wrote:
> Hi,
> 
> In order to continue our traditions I would like to propose again the topic of 
> recruitment, but this time not only limiting to the hobbyists market.
> 
> We are definitely short on reviewers and thus have mostly overloaded 
> maintainers.
> For testers it's usually even worse - how many patches are actually tested?
> Judging from what I read on LKML not that many.
> 
> So we should definitely discuss:
> - how can we encourage hobbyists to become regular contributors
> -- how to keep people interested, the drop-out rates are huge.
> - encourage regular contributors to become reviewers and testers
> - reviewers to become co-maintainers and finally maintainers (once the 
> original maintainer is used up or moves up/on)

I like this proposal, thanks for making it.  I'd be glad to help talk
about this issue as I spend a lot of time working on dragging companies
and developers into our community.  We have a real lack of ways that
people who are "reasonably skilled yet don't know what to work on" can
do more to help contribute to the kernel.

> -> Or how can we raise more funds to sponsor subsystem maintainer ship e.g. 
> via Linux Foundation. 
> (so that the maintainer atleast can buy some test-hardware)

Buying test hardware is always a good thing, if people have a hard time
with this, let me know, I've been able to get hardware for people in the
past.

> Nominations:
> Jason Cooper           (auto-nominated), last years 'speaker'
> Greg KH				please... ;-)

Again, I'd be glad to help talk about this, thanks.

greg k-h

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 708 bytes --]

On Tue, Jul 07, 2015 at 05:16:50PM -0700, Greg KH wrote:

> I like this proposal, thanks for making it.  I'd be glad to help talk
> about this issue as I spend a lot of time working on dragging companies
> and developers into our community.  We have a real lack of ways that
> people who are "reasonably skilled yet don't know what to work on" can
> do more to help contribute to the kernel.

I think this *might* be something that the efforts to reduce the amount
of out of tree embedded code can help with?  A part of that effort is
identifying areas that need fixing, there will be a large enough list I
imagine.  The hard part is always matching people up with things that
they are interested in though.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Laurent Pinchart]

On Wednesday 08 July 2015 19:06:37 Mark Brown wrote:
> On Tue, Jul 07, 2015 at 05:16:50PM -0700, Greg KH wrote:
> > I like this proposal, thanks for making it.  I'd be glad to help talk
> > about this issue as I spend a lot of time working on dragging companies
> > and developers into our community.  We have a real lack of ways that
> > people who are "reasonably skilled yet don't know what to work on" can
> > do more to help contribute to the kernel.
> 
> I think this *might* be something that the efforts to reduce the amount
> of out of tree embedded code can help with?  A part of that effort is
> identifying areas that need fixing, there will be a large enough list I
> imagine.  The hard part is always matching people up with things that
> they are interested in though.

There's also the issue of documentation. Datasheets for embedded SoCs are 
often not publicly available. Even when out-of-tree code exists, the lack of 
documentation makes it more difficult to understand it and port it to 
mainline. I've seen many such cases in practice for camera sensor drivers that 
are often provided by vendors with a small set (or even a single) hardcoded 
configurations, using large register address/value tables. Porting such a 
driver to the mainline APIs often require computing register values from 
parameters received through the subsystem API, which requires a good 
understanding of the hardware.

-- 
Regards,

Laurent Pinchart

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1416 bytes --]

On Wed, Jul 08, 2015 at 10:27:10PM +0300, Laurent Pinchart wrote:
> On Wednesday 08 July 2015 19:06:37 Mark Brown wrote:

> > I think this *might* be something that the efforts to reduce the amount
> > of out of tree embedded code can help with?  A part of that effort is
> > identifying areas that need fixing, there will be a large enough list I
> > imagine.  The hard part is always matching people up with things that
> > they are interested in though.

> There's also the issue of documentation. Datasheets for embedded SoCs are 
> often not publicly available. Even when out-of-tree code exists, the lack of 
> documentation makes it more difficult to understand it and port it to 
> mainline. I've seen many such cases in practice for camera sensor drivers that 
> are often provided by vendors with a small set (or even a single) hardcoded 
> configurations, using large register address/value tables. Porting such a 
> driver to the mainline APIs often require computing register values from 
> parameters received through the subsystem API, which requires a good 
> understanding of the hardware.

Yeah, if you're doing device support.  The generic subsystem bits are
less impacted by these issues, though you can't completely get away from
it.  Fortunately I don't think we've got a great shortage of problems
that need addressing so there should be some things that are tractable!

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Rafael J. Wysocki]

On Wednesday, July 08, 2015 01:21:40 AM Peter Huewe wrote:
> Hi,
> 
> In order to continue our traditions I would like to propose again the topic of 
> recruitment, but this time not only limiting to the hobbyists market.
> 
> We are definitely short on reviewers and thus have mostly overloaded 
> maintainers.
> For testers it's usually even worse - how many patches are actually tested?
> Judging from what I read on LKML not that many.
> 
> So we should definitely discuss:
> - how can we encourage hobbyists to become regular contributors
> -- how to keep people interested, the drop-out rates are huge.
> - encourage regular contributors to become reviewers and testers
> - reviewers to become co-maintainers and finally maintainers (once the 
> original maintainer is used up or moves up/on)

Good topic.

Unfortunately, there are not too many incentives for people to become
code reviewers or testers, or at least to spend more time reviewing patches.

Most of the time there's a little to no recognition for doing that work and,
quite frankly, writing code is more rewarding than that for the majority of
people anyway.

The only way to address this problem I can see is to recognize reviewers
*much* more than we tend to do and not just "encourage" them, because that's
way insufficient.

Thanks,
Rafael

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

[Josh Boyer]

On Tue, Jul 7, 2015 at 9:29 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Wednesday, July 08, 2015 01:21:40 AM Peter Huewe wrote:
>> Hi,
>>
>> In order to continue our traditions I would like to propose again the topic of
>> recruitment, but this time not only limiting to the hobbyists market.
>>
>> We are definitely short on reviewers and thus have mostly overloaded
>> maintainers.
>> For testers it's usually even worse - how many patches are actually tested?
>> Judging from what I read on LKML not that many.
>>
>> So we should definitely discuss:
>> - how can we encourage hobbyists to become regular contributors
>> -- how to keep people interested, the drop-out rates are huge.
>> - encourage regular contributors to become reviewers and testers
>> - reviewers to become co-maintainers and finally maintainers (once the
>> original maintainer is used up or moves up/on)
>
> Good topic.
>
> Unfortunately, there are not too many incentives for people to become
> code reviewers or testers, or at least to spend more time reviewing patches.
>
> Most of the time there's a little to no recognition for doing that work and,
> quite frankly, writing code is more rewarding than that for the majority of
> people anyway.
>
> The only way to address this problem I can see is to recognize reviewers
> *much* more than we tend to do and not just "encourage" them, because that's
> way insufficient.

You could make a Reviewed-by tag required before a patch can be
included in a submaintainer's tree.  At least some maintainers seem to
(arbitrarily?) require this at times.  However, if you do that then it
would likely slow down development quite a bit.  Then Greg might cry
because he wouldn't get to show pretty graphs at conferences about how
fast the rate of change is in the kernel.

(I would love to see a graph comparing rate of change to rate of
regressions/bugs, but then people would have to know the latter.)

josh

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

[NeilBrown]

On Tue, 7 Jul 2015 21:14:00 -0400 Josh Boyer
<jwboyer@fedoraproject.org> wrote:

> On Tue, Jul 7, 2015 at 9:29 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > On Wednesday, July 08, 2015 01:21:40 AM Peter Huewe wrote:
> >> Hi,
> >>
> >> In order to continue our traditions I would like to propose again the topic of
> >> recruitment, but this time not only limiting to the hobbyists market.
> >>
> >> We are definitely short on reviewers and thus have mostly overloaded
> >> maintainers.
> >> For testers it's usually even worse - how many patches are actually tested?
> >> Judging from what I read on LKML not that many.
> >>
> >> So we should definitely discuss:
> >> - how can we encourage hobbyists to become regular contributors
> >> -- how to keep people interested, the drop-out rates are huge.
> >> - encourage regular contributors to become reviewers and testers
> >> - reviewers to become co-maintainers and finally maintainers (once the
> >> original maintainer is used up or moves up/on)
> >
> > Good topic.
> >
> > Unfortunately, there are not too many incentives for people to become
> > code reviewers or testers, or at least to spend more time reviewing patches.
> >
> > Most of the time there's a little to no recognition for doing that work and,
> > quite frankly, writing code is more rewarding than that for the majority of
> > people anyway.
> >
> > The only way to address this problem I can see is to recognize reviewers
> > *much* more than we tend to do and not just "encourage" them, because that's
> > way insufficient.
> 
> You could make a Reviewed-by tag required before a patch can be
> included in a submaintainer's tree.

Nah, you need carrots, not sticks.  And that really comes down to time
and/or money.  As the original post quoted:

> Subsystem maintainership is also, increasingly, not a job for 
> volunteer developers.."

In academia, there is a "sabbatical" system (or there was - at some
Unis) where an academic could take 6 months or a year off to go and do
something else: visit another institution - do some new research or
new sort of teaching. Would you like a 6-month secondment to the Linux
Foundation to be spent reviewing patches?  I think I would...
It would undoubtedly be a challenge to organise and to fund.  But this
issue has been ongoing and unanswered for so long that it seems likely
that a radical change is required.

NeilBrown


>  At least some maintainers seem to
> (arbitrarily?) require this at times.  However, if you do that then it
> would likely slow down development quite a bit.  Then Greg might cry
> because he wouldn't get to show pretty graphs at conferences about how
> fast the rate of change is in the kernel.
> 
> (I would love to see a graph comparing rate of change to rate of
> regressions/bugs, but then people would have to know the latter.)
> 
> josh
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

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

[Davidlohr Bueso]

On Wed, 2015-07-08 at 11:49 +1000, NeilBrown wrote:
> In academia, there is a "sabbatical" system (or there was - at some
> Unis) where an academic could take 6 months or a year off to go and do
> something else: visit another institution - do some new research or
> new sort of teaching. Would you like a 6-month secondment to the Linux
> Foundation to be spent reviewing patches?  I think I would...

There's also consulting. Given enough cash, you could probably hire
subsystem specialists to pay close attention at patches that are trying
to be pushed by some individual or company. Objectively, of course.

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

[Peter Hüwe]

Am Mittwoch, 8. Juli 2015, 03:49:13 schrieb NeilBrown:
> Nah, you need carrots, not sticks.  And that really comes down to time
> 
> and/or money.  As the original post quoted:
> > Subsystem maintainership is also, increasingly, not a job for
> > volunteer developers.."
> 
> In academia, there is a "sabbatical" system (or there was - at some
> Unis) where an academic could take 6 months or a year off to go and do
> something else: visit another institution - do some new research or
> new sort of teaching. Would you like a 6-month secondment to the Linux
> Foundation to be spent reviewing patches?  I think I would...
+1





Maybe this would also address overcoming the problem mentioned in the other 
emails that different subsystems have different expectations etc.

If I would have enough time to get to know other subsystems well 
(so that I can make the transistion "one-off"->"steady contributor"-
>"reviewer" -> "co-maintainer") this would defnitely reduce the friction 
between the different subsystems and also smothen out the differences.


Peter

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

[Krzysztof Kozłowski]

2015-07-08 10:14 GMT+09:00 Josh Boyer <jwboyer@fedoraproject.org>:
> On Tue, Jul 7, 2015 at 9:29 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>> On Wednesday, July 08, 2015 01:21:40 AM Peter Huewe wrote:
>>> Hi,
>>>
>>> In order to continue our traditions I would like to propose again the topic of
>>> recruitment, but this time not only limiting to the hobbyists market.
>>>
>>> We are definitely short on reviewers and thus have mostly overloaded
>>> maintainers.
>>> For testers it's usually even worse - how many patches are actually tested?
>>> Judging from what I read on LKML not that many.
>>>
>>> So we should definitely discuss:
>>> - how can we encourage hobbyists to become regular contributors
>>> -- how to keep people interested, the drop-out rates are huge.
>>> - encourage regular contributors to become reviewers and testers
>>> - reviewers to become co-maintainers and finally maintainers (once the
>>> original maintainer is used up or moves up/on)
>>
>> Good topic.
>>
>> Unfortunately, there are not too many incentives for people to become
>> code reviewers or testers, or at least to spend more time reviewing patches.
>>
>> Most of the time there's a little to no recognition for doing that work and,
>> quite frankly, writing code is more rewarding than that for the majority of
>> people anyway.
>>
>> The only way to address this problem I can see is to recognize reviewers
>> *much* more than we tend to do and not just "encourage" them, because that's
>> way insufficient.
>
> You could make a Reviewed-by tag required before a patch can be
> included in a submaintainer's tree.  At least some maintainers seem to
> (arbitrarily?) require this at times.  However, if you do that then it
> would likely slow down development quite a bit.  Then Greg might cry
> because he wouldn't get to show pretty graphs at conferences about how
> fast the rate of change is in the kernel.

Enforcing reviewed-by or tested-by tags won't be enough if no one
actually will do the review and testing. The patch can wait
indefinitely with maintainer's response "I expect an independent
review". This goes back to first question - will such enforcement
boost number of reviews or tests?

Before doing some work there is always a cause, an answer to "why I am
doing this"? Employer may pay for my commits but would he pay for
reviewing time? That is his decision and it would be difficult to
change policies inside companies.

Other reason for doing open source work may be the fame. Being
recognizable, getting better job offers, doing tasks which are
sensible and meaningful for someone. Currently probably most of the
fame goes to authors and maintainers. For example in the form of `git
log --author/committer=` or LWN articles about statistics.

How to get more reviews from such people (when employer does not pay
for it)? Give them fame! :)

Best regards,
Krzysztof

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

[Peter Hüwe]

Am Mittwoch, 8. Juli 2015, 04:03:04 schrieb Krzysztof Kozłowski:
> 
> Before doing some work there is always a cause, an answer to "why I am
> doing this"? Employer may pay for my commits but would he pay for
> reviewing time? That is his decision and it would be difficult to
> change policies inside companies.
> 
> Other reason for doing open source work may be the fame. Being
> recognizable, getting better job offers, doing tasks which are
> sensible and meaningful for someone. Currently probably most of the
> fame goes to authors and maintainers. For example in the form of `git
> log --author/committer=` or LWN articles about statistics.
> 
> How to get more reviews from such people (when employer does not pay
> for it)? Give them fame! :)

Exactly! 
This is also what Rafael wrote in the other mail:

> Most of the time there's a little to no recognition for doing that work
> and, quite frankly, writing code is more rewarding than that for the
> majority of people anyway.


So changing our fame-statistics from commits to reviews and tested by might 
change the situation a bit.
-> The next LWN stats and coverage should probably focus on the reviewed-by / 
tested-by stats. 
People love to be on some "top 10" lists - and also they can show something 
like that to their bosses.

"I've been a kernel reviewer and tester" -- meh, who cares
"I've been a top 100 kernel reviewer and tester over the last X releases" -- 
give him a raise/the job (esp. if kernel is not the core competency of the 
company :)




Another thing I noticed over the last few years (also in corporate), people 
get really motivated by memorabilia - "tokens of appreciation".
E.g. I constantly wear my Google T-Shirt which I received for a contribution 
with such proud and so often that it is almost faded --- but still everytime I 
look at it I have a good feeling.

--> Maybe LF can organize something?
"Here is a small token of appreciation (t-shirt, cup)  for spending countless 
hours on reviewing and testing stuff in the Linux kernel -- keep up the good 
work"





> The only way to address this problem I can see is to recognize reviewers
> *much* more than we tend to do and not just "encourage" them, because
> that's way insufficient.
Yes again!

What I definitely would also recommend is to organize some 'get togethers',
like a miniconf/minisummit at the next conference near you -- and where you 
grab a beer _together_ with the reviewers / testers afterwards (and maybe the 
maintainer can pay). 
This also helps as forms of appreciation.



Thanks,
Peter

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

[jic23]

Peter Hüwe writes: 

> Am Mittwoch, 8. Juli 2015, 04:03:04 schrieb Krzysztof Kozłowski:
>> 
>> Before doing some work there is always a cause, an answer to "why I am
>> doing this"? Employer may pay for my commits but would he pay for
>> reviewing time? That is his decision and it would be difficult to
>> change policies inside companies. 
>> 
>> Other reason for doing open source work may be the fame. Being
>> recognizable, getting better job offers, doing tasks which are
>> sensible and meaningful for someone. Currently probably most of the
>> fame goes to authors and maintainers. For example in the form of `git
>> log --author/committer=` or LWN articles about statistics. 
>> 
>> How to get more reviews from such people (when employer does not pay
>> for it)? Give them fame! :)
> 
> Exactly! 
> This is also what Rafael wrote in the other mail: 
> 
>> Most of the time there's a little to no recognition for doing that work
>> and, quite frankly, writing code is more rewarding than that for the
>> majority of people anyway.
>  
> 
> So changing our fame-statistics from commits to reviews and tested by might 
> change the situation a bit.
> -> The next LWN stats and coverage should probably focus on the reviewed-by / 
> tested-by stats. 
> People love to be on some "top 10" lists - and also they can show something 
> like that to their bosses.

I think we also need to encourage multiple sign offs from one person
on drivers sometimes.   Often you'll get a 'I tested this and also
reviewed it' but as I'm the author / maintainer of the original driver
I'll Ack it.  Perhaps these cases should have all 3 tags in the commit. 

> 
> "I've been a kernel reviewer and tester" -- meh, who cares
> "I've been a top 100 kernel reviewer and tester over the last X releases" -- 
> give him a raise/the job (esp. if kernel is not the core competency of the 
> company :)

I'm very luck in IIO in that I have a core set of very good reviewers
with (I think) a mix of paid and volunteers.  As a volunteer Maintainer
I couldn't cope with the rate of patches without them! 

One thing that happens fairly often is that I get a very good initial
review in then the reviewer moves on to other patches.  I suspect this
is because they are focusing on where they can do the most productive
work.  Sometimes I go to the effort of chasing them up for an
ack / reviewed by, but often they get no recognition at all. 

Note I tend to do an additional review (often v3 or later by the
time I get to them) but these guys have done a lot of the leg work.
One of my reviewers specializes in very detailed reviews slightly after
I have applied the patches, but that's another story :) 

So how to give these incredibly helpful people more recognition?
Do other maintainers add reviewed-by tags sometimes without the reviewer
specifically giving them?  The docs have always said these should
indicate that the reviewer is happy with the result.  In this case the
reviewer may not have looked at the result, but contributed earlier
in the process. 

Does anyone else actually get these sorts of reviews? 

>  
> 
>  
> 
> Another thing I noticed over the last few years (also in corporate), people 
> get really motivated by memorabilia - "tokens of appreciation".
> E.g. I constantly wear my Google T-Shirt which I received for a contribution 
> with such proud and so often that it is almost faded --- but still everytime I 
> look at it I have a good feeling. 
> 
> --> Maybe LF can organize something?
> "Here is a small token of appreciation (t-shirt, cup)  for spending countless 
> hours on reviewing and testing stuff in the Linux kernel -- keep up the good 
> work" 
> 
>  
> 
>  
> 
>> The only way to address this problem I can see is to recognize reviewers
>> *much* more than we tend to do and not just "encourage" them, because
>> that's way insufficient.
> Yes again! 
> 
> What I definitely would also recommend is to organize some 'get togethers',
> like a miniconf/minisummit at the next conference near you -- and where you 
> grab a beer _together_ with the reviewers / testers afterwards (and maybe the 
> maintainer can pay). 
> This also helps as forms of appreciation.

I'm particularly bad at this.  Have only ever actually met one of
my regular reviewers (out of 6+).  Note that for some subsystems
the conference attendance is actually pretty limited / random and
chances of a actually encountering many of the reviewers is lowish. 

Guys who put in a few hours a week are the bread and butter or
reviewing for my area, but that may well be all the time they have
as much as they'd like to travel to conferences! 

Jonathan

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

[Peter Huewe]

Hey,


>I'm very luck in IIO in that I have a core set of very good reviewers
>with (I think) a mix of paid and volunteers.  As a volunteer Maintainer
>I couldn't cope with the rate of patches without them! 
>
>One thing that happens fairly often is that I get a very good initial
>review in then the reviewer moves on to other patches.  I suspect this
>is because they are focusing on where they can do the most productive
>work.  Sometimes I go to the effort of chasing them up for an
>ack / reviewed by, but often they get no recognition at all. 
>
>Note I tend to do an additional review (often v3 or later by the
>time I get to them) but these guys have done a lot of the leg work.
>One of my reviewers specializes in very detailed reviews slightly after
>I have applied the patches, but that's another story :) 
>
>So how to give these incredibly helpful people more recognition?
>Do other maintainers add reviewed-by tags sometimes without the
>reviewer
>specifically giving them?  The docs have always said these should
>indicate that the reviewer is happy with the result.  In this case the
>reviewer may not have looked at the result, but contributed earlier
>in the process. 

Actually I do, at least if I have the feeling that it would be in the reviewers intention.
Credit where credit is due.

If I'm unsure I mail the reviewers and ask them (or via IRC)



>Does anyone else actually get these sorts of reviews? 


Yes happens a lot - v1-5 get a lot of reviews , v8 gets none except my own :)
But the important stuff is usually dealt with in v1-3. so I usually add the reviewed-by tags if nothing fundamentally has changed
So the Situation is much likr in iio
(Yes in TPM we usually need v5 or more:)



Peter
-- 
Sent from my mobile

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

[Jonathan Corbet]

On Wed, 8 Jul 2015 09:04:58 +0200
Peter Hüwe <PeterHuewe@gmx.de> wrote:

> So changing our fame-statistics from commits to reviews and tested by might 
> change the situation a bit.
> -> The next LWN stats and coverage should probably focus on the reviewed-by /   
> tested-by stats. 

I do occasionally report those numbers with the rest.  The reason it
doesn't happen very often is simple: it's a small minority of patches that
carry such tags.  As such, I don't think the numbers actually reflect the
reviewing and testing going on; they just reflect the placement of the
tags.  Among other things, that makes the system relatively easy to game,
and, in the past, I've seen that happening.

Should anybody be curious, I'll append the latest, hot-off-the-repo numbers
for 4.2.

jon

[12,099 non-merge changesets total when I ran this]

Developers with the most reviews (total 2597)
Ian Abbott                 149 (5.7%)
Borislav Petkov            148 (5.7%)
Hannes Reinecke            100 (3.9%)
Christoph Hellwig           73 (2.8%)
H Hartley Sweeten           62 (2.4%)
Christian König             57 (2.2%)
Tomas Henzl                 54 (2.1%)
Alex Deucher                51 (2.0%)
David Gibson                49 (1.9%)
Scott Teel                  42 (1.6%)

Developers with the most test credits (total 775)
Joerg Roedel                35 (4.5%)
Keita Kobayashi             35 (4.5%)
Krishneil Singh             31 (4.0%)
Arnaldo Carvalho de Melo    30 (3.9%)
Ira Weiny                   23 (3.0%)
Doug Ledford                23 (3.0%)
Aaron Brown                 21 (2.7%)
Alex Ng                     21 (2.7%)
Javier Martinez Canillas    19 (2.5%)

Developers who gave the most tested-by credits (total 775)
Michael Wang                46 (5.9%)
Joerg Roedel                42 (5.4%)
Kuninori Morimoto           36 (4.6%)
Jiang Liu                   35 (4.5%)
Mel Gorman                  31 (4.0%)
Vitaly Kuznetsov            21 (2.7%)
Andre Przywara              20 (2.6%)
Marek Szyprowski            19 (2.5%)
Lv Zheng                    17 (2.2%)
Don Skidmore                17 (2.2%)

Developers with the most report credits (total 467)
Fengguang Wu                65 (13.9%)
Dan Carpenter               26 (5.6%)
Russell King                21 (4.5%)
Ingo Molnar                 10 (2.1%)
Stephen Rothwell             9 (1.9%)
Christoph Hellwig            5 (1.1%)
Kevin Hilman                 5 (1.1%)
Sergey Senozhatsky           5 (1.1%)
Jim Davis                    5 (1.1%)
Arnaldo Carvalho de Melo     4 (0.9%)

Developers who gave the most report credits (total 467)
Thomas Gleixner             30 (6.4%)
Paul E. McKenney            14 (3.0%)
Lv Zheng                    12 (2.6%)
Eric Dumazet                 8 (1.7%)
Paul Gortmaker               8 (1.7%)
Peter Zijlstra               8 (1.7%)
Takashi Iwai                 7 (1.5%)
Stephen Boyd                 7 (1.5%)
Aleksey Makarov              7 (1.5%)
Filipe Manana                6 (1.3%)

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

[Jason Cooper]

On Wed, Jul 08, 2015 at 09:04:58AM +0200, Peter Hüwe wrote:
> Am Mittwoch, 8. Juli 2015, 04:03:04 schrieb Krzysztof Kozłowski:
> > 
> > Before doing some work there is always a cause, an answer to "why I am
> > doing this"? Employer may pay for my commits but would he pay for
> > reviewing time? That is his decision and it would be difficult to
> > change policies inside companies.
> > 
> > Other reason for doing open source work may be the fame. Being
> > recognizable, getting better job offers, doing tasks which are
> > sensible and meaningful for someone. Currently probably most of the
> > fame goes to authors and maintainers. For example in the form of `git
> > log --author/committer=` or LWN articles about statistics.
> > 
> > How to get more reviews from such people (when employer does not pay
> > for it)? Give them fame! :)
> 
> Exactly! 
> This is also what Rafael wrote in the other mail:
> 
> > Most of the time there's a little to no recognition for doing that work
> > and, quite frankly, writing code is more rewarding than that for the
> > majority of people anyway.
> 
> 
> So changing our fame-statistics from commits to reviews and tested by might 
> change the situation a bit.
> -> The next LWN stats and coverage should probably focus on the reviewed-by / 
> tested-by stats. 
> People love to be on some "top 10" lists - and also they can show something 
> like that to their bosses.

gack.  see below.

> "I've been a kernel reviewer and tester" -- meh, who cares

Show me a concrete example where that has been expressed.  I've had the
exact opposite experience.  Typically I've had to tone down the
expectations of others.

> "I've been a top 100 kernel reviewer and tester over the last X releases" -- 
> give him a raise/the job (esp. if kernel is not the core competency of the 
> company :)

Gah!  Please don't add gamification into this.  It attracts the wrong
sorts of people.  We already have a large swath of society that want a
cookie and a pat on the head for doing the most mundane things.

Plus these systems built with good intentions always go awry.  "Hey!
You didn't add a tag for me because I spotted a typo!" <stomps and
huffs>  Or, "My boss / HR gave me less of a raise because my stats
dropped this quarter, wtf?"

This is a path we do *not* want to walk down.

> --> Maybe LF can organize something?
> "Here is a small token of appreciation (t-shirt, cup)  for spending countless 
> hours on reviewing and testing stuff in the Linux kernel -- keep up the good 
> work"

How about "Here's an invite to the KS, because we value your opinion and
would like you to take part in the process." ;-)

> > The only way to address this problem I can see is to recognize reviewers
> > *much* more than we tend to do and not just "encourage" them, because
> > that's way insufficient.
> Yes again!

Disagree.  But I've said my piece above.

> What I definitely would also recommend is to organize some 'get togethers',
> like a miniconf/minisummit at the next conference near you -- and where you 
> grab a beer _together_ with the reviewers / testers afterwards (and maybe the 
> maintainer can pay). 

Enhancing the community effect is something I can get on board with.
Buying a few rounds of drinks goes a long way.  Getting the folks
together in meat-space is the hard ($$) part.

thx,

Jason.

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

[Guenter Roeck]

On 07/08/2015 08:02 AM, Jason Cooper wrote:
> On Wed, Jul 08, 2015 at 09:04:58AM +0200, Peter Hüwe wrote:

>> "I've been a kernel reviewer and tester" -- meh, who cares
>
> Show me a concrete example where that has been expressed.  I've had the
> exact opposite experience.  Typically I've had to tone down the
> expectations of others.
>
Lucky you.

In my experience, code reviews often don't get much attention by project
managers responsible for commercial projects. If anything, quite the opposite.
The Linux kernel development culture is quite different.

Linux kernel:
	"Thanks a lot for reviewing my code and making it better".
Commercial:
	"Why do your reviews always take such a long time ?
	You are holding up the release!"

Granted, that doesn't happen everywhere, but I have seen it more than once,
and I would content that this kind of culture is pretty widely spread.

Anyone entering such an environment might actually encounter negative
reactions to "I am a kernel reviewer and tester". Of course, one might
argue that joining an affected company might not be a good idea in the
first place, but not everyone has that much flexibility or choice.

I am not saying that it would be a bad idea to give code reviewers more
credit; quite the contrary. However, I think it would be wrong to assume
or expect that giving reviewers more credit would improve their chances
for employment. It would, however, result in reviewers feeling recognized
for themselves, which is a good thing.

Why does it matter ? I had a discussion a while ago with the founder of
one of the web sites providing product reviews. I suggested to give product
reviewers some kind of monetary reward for their reviews, eg part of the
advertising revenue created by the site. Feedback I got was that reviewers
typically don't care about monetary rewards, but they do care about recognition
and about their standing in the community.

Guenter

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

[Jason Cooper]

On Wed, Jul 08, 2015 at 09:36:26AM -0700, Guenter Roeck wrote:
> On 07/08/2015 08:02 AM, Jason Cooper wrote:
> >On Wed, Jul 08, 2015 at 09:04:58AM +0200, Peter Hüwe wrote:
> 
> >>"I've been a kernel reviewer and tester" -- meh, who cares
> >
> >Show me a concrete example where that has been expressed.  I've had the
> >exact opposite experience.  Typically I've had to tone down the
> >expectations of others.
> >
> Lucky you.

Well, my point wasn't to brag, but I think you knew that.

I'd hope that my experience isn't isolated, and if it is, why?

> In my experience, code reviews often don't get much attention by project
> managers responsible for commercial projects. If anything, quite the opposite.
> The Linux kernel development culture is quite different.
> 
> Linux kernel:
> 	"Thanks a lot for reviewing my code and making it better".
> Commercial:
> 	"Why do your reviews always take such a long time ?
> 	You are holding up the release!"

These are responses to reviews during employment.  I was referring to,
perhaps not clearly, the hiring process.

> Granted, that doesn't happen everywhere, but I have seen it more than once,
> and I would content that this kind of culture is pretty widely spread.

wrt actual code reviews, I agree.

> Of course, one might
> argue that joining an affected company might not be a good idea in the
> first place, but not everyone has that much flexibility or choice.

When interviewing potential engineers, folks who demonstrate regular,
real contributions to open source projects move up a notch or two in my
book.  Because the applicant has then demonstrated an ability to work
with others, at a distance, for the good of the project.

iow, working in open source projects demonstrates you know how to
telecommute.  For companies looking to hire engineers into telecommuting
positions, open source contributors are much lower risk.

What percentage of the overall market is that?  I dunno.  But devs
wanting to live in odd places have a better shot of finding jobs by
becoming regular contributors to open source.

> I am not saying that it would be a bad idea to give code reviewers more
> credit; quite the contrary. However, I think it would be wrong to assume
> or expect that giving reviewers more credit would improve their chances
> for employment. It would, however, result in reviewers feeling recognized
> for themselves, which is a good thing.

I think we can get more results for our efforts by bringing folks in to
community events.  Buy beers and so forth.  I'll never forget the
evening in San Diego drinking blended single-malt (?!) with Olof, Tony
and others.

If I enjoy working with someone, I take them out for beers, spend *time*
with them.  This works a lot better that adding a bullet to an eval.

> Why does it matter ? I had a discussion a while ago with the founder of
> one of the web sites providing product reviews. I suggested to give product
> reviewers some kind of monetary reward for their reviews, eg part of the
> advertising revenue created by the site. Feedback I got was that reviewers
> typically don't care about monetary rewards, but they do care about recognition
> and about their standing in the community.

Fully agree.  And it argues my point, things which can be counted and
accrued (money, tokens, Reviewed-by [1], etc) rarely have the desired
affect.  At the end of the day, there's no substitute for making genuine
gestures.  Invites to KS or other events, dinner, drinks, socialization.

The problem with doing that is it costs money.  Who pays?  Does the 17
year old in Poland have the money to fly to $event?

If we agree that:

  a) increasing the opportunities for trial run contributors/reviewers
  b) developing community by getting together regularly
  c) collecting statistics to determine program efficacy

Are good targets, then I'd like to discuss putting together a
program/proposal that we could take to LF.  Something quantifiable, e.g.
company X can 'sponsor' 5 newcomers over the next year for $Y.  It
includes, per newcomer, a travel allowance for one trip and a small sum
for a piece of gear.  Gear issuance is determined by the
co-maintainer/established kernel dev working with the newcomer.

Events could be small, 2 day regional affairs, or 1 big annual get
together.  Or both.  If we go with small and regional, we would need to
include the cost of flying the relevant established devs to the event.
Regional events could be hosted by Linux-friendly companies to reduce
cost.


thx,

Jason.

[1] It's worth noting that I view the tags as a *responsibility*, not a
reward.  It informs a bug hunter which devs had a hand it creation /
merging of the blamed commit.  Overloading the tags has been discussed
before, with much resistance.

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

[Peter Huewe]

Hey Jason
 
>> --> Maybe LF can organize something?
>> "Here is a small token of appreciation (t-shirt, cup) for spending countless
>> hours on reviewing and testing stuff in the Linux kernel -- keep up the good
>> work"

> How about "Here's an invite to the KS, because we value your opinion and
> would like you to take part in the process." ;-)

Personally I think that's also a valuable approach - but since KS space is limited maybe not so feasible.
T-Shirts etc are easier :)

Peter

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

[Jason Cooper]

On Wed, Jul 08, 2015 at 09:09:42PM +0200, Peter Huewe wrote:
> Hey Jason
>  
> >> --> Maybe LF can organize something?
> >> "Here is a small token of appreciation (t-shirt, cup) for spending countless
> >> hours on reviewing and testing stuff in the Linux kernel -- keep up the good
> >> work"
> 
> > How about "Here's an invite to the KS, because we value your opinion and
> > would like you to take part in the process." ;-)
> 
> Personally I think that's also a valuable approach - but since KS
> space is limited maybe not so feasible.  T-Shirts etc are easier :)

Right, later on I said (or in another mail) "KS or other event".

T-shirts are a given.  Coffee mugs, thumbdrives that are modifiable a-la
bad-usb.  It's all good.  ;-)

The chromecasts that were given out two years ago directly resulted in
mach-berlin/ ... So maybe we should be giving out HW that *isn't*
supported by mainline.

thx,

Jason.

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

[Peter Huewe]

> The chromecasts that were given out two years ago directly resulted in
> mach-berlin/ ... 
> So maybe we should be giving out HW that *isn't*
> supported by mainline.
+1 - also a nice idea. :)

Thanks,
Peter

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

[John W. Linville]

On Wed, Jul 08, 2015 at 09:04:58AM +0200, Peter Hüwe wrote:
> Am Mittwoch, 8. Juli 2015, 04:03:04 schrieb Krzysztof Kozłowski:

> > The only way to address this problem I can see is to recognize reviewers
> > *much* more than we tend to do and not just "encourage" them, because
> > that's way insufficient.
> Yes again!
> 
> What I definitely would also recommend is to organize some 'get togethers',
> like a miniconf/minisummit at the next conference near you -- and where you 
> grab a beer _together_ with the reviewers / testers afterwards (and maybe the 
> maintainer can pay). 
> This also helps as forms of appreciation.

I think that this was a major purpose served by Kernel Summit when it
was founded.  Over time KS grew along with the importance of the kernel
until we started trying to cap KS attendance in the "about 100" range.

Various mini-summits, workshops, and such have been instituted
over time.  At least part of the goal of providing such outlets is
to include a broader swath of the kernel community.  I believe that
was part (perhaps most) of the motivation for the KS format change
to include workshops over the past several years as well.  Do you
think that we need even more such events?  Or just bigger ones?

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

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

[Laurent Pinchart]

On Wednesday 08 July 2015 09:04:58 Peter Hüwe wrote:
> Am Mittwoch, 8. Juli 2015, 04:03:04 schrieb Krzysztof Kozłowski:
> > Before doing some work there is always a cause, an answer to "why I am
> > doing this"? Employer may pay for my commits but would he pay for
> > reviewing time? That is his decision and it would be difficult to
> > change policies inside companies.
> > 
> > Other reason for doing open source work may be the fame. Being
> > recognizable, getting better job offers, doing tasks which are
> > sensible and meaningful for someone. Currently probably most of the
> > fame goes to authors and maintainers. For example in the form of `git
> > log --author/committer=` or LWN articles about statistics.
> > 
> > How to get more reviews from such people (when employer does not pay
> > for it)? Give them fame! :)
> 
> Exactly!
> 
> This is also what Rafael wrote in the other mail:
> > Most of the time there's a little to no recognition for doing that work
> > and, quite frankly, writing code is more rewarding than that for the
> > majority of people anyway.
> 
> So changing our fame-statistics from commits to reviews and tested by might
> change the situation a bit.
> -> The next LWN stats and coverage should probably focus on the reviewed-by
> / tested-by stats.
> People love to be on some "top 10" lists - and also they can show something
> like that to their bosses.
> 
> "I've been a kernel reviewer and tester" -- meh, who cares
> "I've been a top 100 kernel reviewer and tester over the last X releases" --
> give him a raise/the job (esp. if kernel is not the core competency of the
> company :)
> 
> 
> Another thing I noticed over the last few years (also in corporate), people
> get really motivated by memorabilia - "tokens of appreciation".
> E.g. I constantly wear my Google T-Shirt which I received for a contribution
> with such proud and so often that it is almost faded --- but still
> everytime I look at it I have a good feeling.
> 
> --> Maybe LF can organize something?
> "Here is a small token of appreciation (t-shirt, cup)  for spending
> countless hours on reviewing and testing stuff in the Linux kernel -- keep
> up the good work"
> 
> > The only way to address this problem I can see is to recognize reviewers
> > *much* more than we tend to do and not just "encourage" them, because
> > that's way insufficient.
> 
> Yes again!
> 
> What I definitely would also recommend is to organize some 'get togethers',
> like a miniconf/minisummit at the next conference near you -- and where you
> grab a beer _together_ with the reviewers / testers afterwards (and maybe
> the maintainer can pay).
> This also helps as forms of appreciation.

While real life meetings are invaluable, let's not forgot that they also have 
a major drawback: not everybody can attend them. In a very distributed 
development environment like the Linux kernel contributors come from many 
different horizons, and not all of them can afford to attend conferences (or 
sometimes just don't want to, for various reasons). If we focus too much on a 
groups of contributors who can meet in real life we'll alienate the rest of 
the "online" crowd, and risk losing contributors who will feel left out.

-- 
Regards,

Laurent Pinchart

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

[Greg KH]

On Tue, Jul 07, 2015 at 09:14:00PM -0400, Josh Boyer wrote:
> You could make a Reviewed-by tag required before a patch can be
> included in a submaintainer's tree.  At least some maintainers seem to
> (arbitrarily?) require this at times.  However, if you do that then it
> would likely slow down development quite a bit.

It doesn't seem to have slowed down the rate of change for the
subsystems that currently require this, so why do you think it would?

> Then Greg might cry because he wouldn't get to show pretty graphs at
> conferences about how fast the rate of change is in the kernel.

I don't have any graphs showing rate of change.  I have a few "raw"
numbers that I talk about, but that's just to scare people.  Even if we
went back to 2.5 development speeds (2.5 changes per hour), that's
enough to scare people for my needs :)

> (I would love to see a graph comparing rate of change to rate of
> regressions/bugs, but then people would have to know the latter.)

Want to start tracking that?  We've needed someone to do that work for
quite some time now, the fact that we've gotten by without it either
means that no one sees the value in funding such a position and/or it's
not really something that anyone cares about...

thanks,

greg k-h

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

[Dan Carpenter]

On Tue, Jul 07, 2015 at 07:11:28PM -0700, Greg KH wrote:
> On Tue, Jul 07, 2015 at 09:14:00PM -0400, Josh Boyer wrote:
> > You could make a Reviewed-by tag required before a patch can be
> > included in a submaintainer's tree.  At least some maintainers seem to
> > (arbitrarily?) require this at times.  However, if you do that then it
> > would likely slow down development quite a bit.
> 
> It doesn't seem to have slowed down the rate of change for the
> subsystems that currently require this, so why do you think it would?

That's SCSI and who else?

I think it improved SCSI a lot and got more people involved.  Before
there were some companies that didn't reply at all when you emailed them
fixes for their driver.  They just left everything for James.  Adding
the rule that every patch needed two reviews probably sped things up.

regards,
dan carpenter

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1358 bytes --]

On Tue, Jul 07, 2015 at 07:11:28PM -0700, Greg KH wrote:
> On Tue, Jul 07, 2015 at 09:14:00PM -0400, Josh Boyer wrote:

> > You could make a Reviewed-by tag required before a patch can be
> > included in a submaintainer's tree.  At least some maintainers seem to
> > (arbitrarily?) require this at times.  However, if you do that then it
> > would likely slow down development quite a bit.

> It doesn't seem to have slowed down the rate of change for the
> subsystems that currently require this, so why do you think it would?

I think there's probably a cause and effect thing going on there - it's
more likely that a subsystem will start to impose such requirements if
they are confident that it is practical to get reviews of sufficient
quality in.  I'd guess at least some of the time it's a formalisation of
existing practice rather than a completely new requirement.

> > (I would love to see a graph comparing rate of change to rate of
> > regressions/bugs, but then people would have to know the latter.)

> Want to start tracking that?  We've needed someone to do that work for
> quite some time now, the fact that we've gotten by without it either
> means that no one sees the value in funding such a position and/or it's
> not really something that anyone cares about...

Well, first we'd need to find a way of counting the bugs and
regressions.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Josh Boyer]

On Tue, Jul 7, 2015 at 10:11 PM, Greg KH <greg@kroah.com> wrote:
> On Tue, Jul 07, 2015 at 09:14:00PM -0400, Josh Boyer wrote:
>> You could make a Reviewed-by tag required before a patch can be
>> included in a submaintainer's tree.  At least some maintainers seem to
>> (arbitrarily?) require this at times.  However, if you do that then it
>> would likely slow down development quite a bit.
>
> It doesn't seem to have slowed down the rate of change for the
> subsystems that currently require this, so why do you think it would?

Probably because such subsystems have always required it?  If it were
a new imposition on a subsystem, I suspect it would certainly impact
things, at least at first.

>> Then Greg might cry because he wouldn't get to show pretty graphs at
>> conferences about how fast the rate of change is in the kernel.
>
> I don't have any graphs showing rate of change.  I have a few "raw"
> numbers that I talk about, but that's just to scare people.  Even if we
> went back to 2.5 development speeds (2.5 changes per hour), that's
> enough to scare people for my needs :)

Heh.

>> (I would love to see a graph comparing rate of change to rate of
>> regressions/bugs, but then people would have to know the latter.)
>
> Want to start tracking that?  We've needed someone to do that work for
> quite some time now, the fact that we've gotten by without it either
> means that no one sees the value in funding such a position and/or it's
> not really something that anyone cares about...

I think you're wrong on both counts there, sorry.

In order to track this well, you need data from users.  And therein
lies one of the problems.  The majority of users don't use kernel.org
kernels.  They use distro kernels.  The distros have data and tools to
help track bugs and regressions, but upstream is somewhat loathe to
look at anything that starts with b and ends with zilla.  Why?
Because the data coming from users is often utterly junk.  You get a
kernel splat and a "I don't know why this happened."  And frankly, I
don't expect them to know why it happened either.  Particularly when
you have subsystems that are using WARN_ON as a fixme comment and
sprinkling them all over the damn place.

So you have users that don't/are afraid to talk to upstream, distro
maintainers trying to play middle men and being overwhelmed, and
upstream who is very responsive when contacted directly but because
they use self-built kernels the request is usually "bisect".  End
users can't bisect without hand-holding, so the distro maintainers are
left doing that too.  The learning curve for creating a good bug
report is pretty steep, and the ability to help debug it is even
steeper.

Now that isn't to say that data doesn't exist.  As I alluded to, the
various bugzillas are full of regressions and bugs.  But there is no
aggregation of that data across instances, and everything is terrible.
I literally spent a year doing very little other than bug triage and
random fixing.  Fedora's bug count for the kernel went from over 1000
bugs to just under 500.  That sounds great, but it really isn't.  The
net result wasn't 500 bugfixes.  I don't have 500 commits in the
kernel, nor 500 Reviewed-by or Tested-by or Reported-by tags.  It was
literally cleanup of bugzilla, not kernel issues.  (To be sure, some
issues were fixes for the users, but those were rare.)  And this was
with Fedora, which sticks very very closely to the latest upstream
release.

Ignoring the bug reporting pipeline problem for a minute, there is
other data as well.  The new Fixes: tag could easily be scripted to
count as a bug/regression.  Except it is fairly new, and isn't as
widely used as one would like yet.  That is pretty trivial to count
though and I don't think it would paint an accurate picture at all.

I intended this to be short, but it wasn't.  Hopefully it didn't come
off as a big rant.  I simply think the problem is a lot more
complicated that "no one sees value or no one cares."  It is really
signal to noise, a huge backlog, and figuring out how to get the end
users working with the developers without needed a distro translator.
Or getting the developers working the other way, but when has that
ever happened in the software industry?

josh

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

[Steven Rostedt]

On Wed, 8 Jul 2015 07:43:25 -0400
Josh Boyer <jwboyer@fedoraproject.org> wrote:
 
> In order to track this well, you need data from users.  And therein
> lies one of the problems.  The majority of users don't use kernel.org
> kernels.  They use distro kernels.  The distros have data and tools to
> help track bugs and regressions, but upstream is somewhat loathe to
> look at anything that starts with b and ends with zilla.  Why?
> Because the data coming from users is often utterly junk.  You get a
> kernel splat and a "I don't know why this happened."  And frankly, I
> don't expect them to know why it happened either.  Particularly when
> you have subsystems that are using WARN_ON as a fixme comment and
> sprinkling them all over the damn place.
> 

Just a note. I hate the use of WARN_ON()s in this case. I bitch quite
loudly when I stumble across them (and I do often), because my ktest
scripts I use to test my own patches will fail if a WARN_ON() is
triggered.

At least if my test boxes have the hardware that does this, it wont
last long, as I'm pretty good at bitching ;-)

-- Steve

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

[Josh Boyer]

On Wed, Jul 8, 2015 at 2:49 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Wed, 8 Jul 2015 07:43:25 -0400
> Josh Boyer <jwboyer@fedoraproject.org> wrote:
>
>> In order to track this well, you need data from users.  And therein
>> lies one of the problems.  The majority of users don't use kernel.org
>> kernels.  They use distro kernels.  The distros have data and tools to
>> help track bugs and regressions, but upstream is somewhat loathe to
>> look at anything that starts with b and ends with zilla.  Why?
>> Because the data coming from users is often utterly junk.  You get a
>> kernel splat and a "I don't know why this happened."  And frankly, I
>> don't expect them to know why it happened either.  Particularly when
>> you have subsystems that are using WARN_ON as a fixme comment and
>> sprinkling them all over the damn place.
>>
>
> Just a note. I hate the use of WARN_ON()s in this case. I bitch quite
> loudly when I stumble across them (and I do often), because my ktest
> scripts I use to test my own patches will fail if a WARN_ON() is
> triggered.
>
> At least if my test boxes have the hardware that does this, it wont
> last long, as I'm pretty good at bitching ;-)

Are you test boxes headless?  Because i915 is littered with WARN and
WARN_ON, to the point where we carry a patch in Fedora to quiet most
of the state machine related ones.  If you look at retrace and filter
out all the proprietary oopses, i915 is always most of the top 10
kernel issues Fedora sees.

https://retrace.fedoraproject.org/faf/problems/?component_names=&associate=__None&daterange=2015-06-24%3A2015-07-08&exclude_taintflags=7&exclude_taintflags=9&exclude_taintflags=5&bug_filter=None&function_names=&binary_names=&source_file_names=&since_version=&since_release=&to_version=&to_release=#

josh

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

[Steven Rostedt]

On Wed, 8 Jul 2015 15:11:32 -0400
Josh Boyer <jwboyer@fedoraproject.org> wrote:


> > At least if my test boxes have the hardware that does this, it wont
> > last long, as I'm pretty good at bitching ;-)
> 
> Are you test boxes headless?  Because i915 is littered with WARN and
> WARN_ON, to the point where we carry a patch in Fedora to quiet most
> of the state machine related ones.  If you look at retrace and filter
> out all the proprietary oopses, i915 is always most of the top 10
> kernel issues Fedora sees.

Sadly, my bitching skills didn't work well here:

 https://lkml.org/lkml/2015/5/7/867

Maybe I let it slide. ktest allows you to run PRE_BUILD scripts, and
what I've gotten use to doing was adding:

 PRE_BUILD = patch -p1 < fix.patch
 POST_BUILD = git reset --hard

Where that fix.patch would include silencing those damn warnings.

As I was under the impression that this was unique to my test box
(which happens to be a development machine).

> 
> https://retrace.fedoraproject.org/faf/problems/?component_names=&associate=__None&daterange=2015-06-24%3A2015-07-08&exclude_taintflags=7&exclude_taintflags=9&exclude_taintflags=5&bug_filter=None&function_names=&binary_names=&source_file_names=&since_version=&since_release=&to_version=&to_release=#

Maybe I should tone my bitching skills again. This time with some
backup ;-)

-- Steve

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

[Geert Uytterhoeven]

On Wed, Jul 8, 2015 at 3:14 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>> The only way to address this problem I can see is to recognize reviewers
>> *much* more than we tend to do and not just "encourage" them, because that's
>> way insufficient.
>
> You could make a Reviewed-by tag required before a patch can be
> included in a submaintainer's tree.  At least some maintainers seem to
> (arbitrarily?) require this at times.  However, if you do that then it
> would likely slow down development quite a bit.  Then Greg might cry
> because he wouldn't get to show pretty graphs at conferences about how
> fast the rate of change is in the kernel.

It's far too common to send out a patch series, receive lots of valuable
comments and suggestions, adapt according to feedback, and send out again
(repeat a few cycles). Suddenly the patches looks perfect, no more comments,
but also no Acked-by or Reviewed-By. Just silence.

Requiring a Reviewed-by tag is not a solution, unless there's a real
incentive for people to add such tags. Finding such an incentive can be
difficult, and may turn out to make matters worse (cfr. patent officers paid
per patent granted).

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[James Bottomley]

On Wed, 2015-07-08 at 03:29 +0200, Rafael J. Wysocki wrote:
> On Wednesday, July 08, 2015 01:21:40 AM Peter Huewe wrote:
> > Hi,
> > 
> > In order to continue our traditions I would like to propose again the topic of 
> > recruitment, but this time not only limiting to the hobbyists market.
> > 
> > We are definitely short on reviewers and thus have mostly overloaded 
> > maintainers.
> > For testers it's usually even worse - how many patches are actually tested?
> > Judging from what I read on LKML not that many.
> > 
> > So we should definitely discuss:
> > - how can we encourage hobbyists to become regular contributors
> > -- how to keep people interested, the drop-out rates are huge.
> > - encourage regular contributors to become reviewers and testers
> > - reviewers to become co-maintainers and finally maintainers (once the 
> > original maintainer is used up or moves up/on)
> 
> Good topic.
> 
> Unfortunately, there are not too many incentives for people to become
> code reviewers or testers, or at least to spend more time reviewing patches.

We can alter that somewhat.  We used to run a Maintainers lottery for
the kernel summit ... we could instead offer places based on the number
of Reviewed-by: tags ... we have all the machinery to calculate that.  I
know an invitation to the kernel summit isn't a huge incentive, but it's
a useful one.

> Most of the time there's a little to no recognition for doing that work and,
> quite frankly, writing code is more rewarding than that for the majority of
> people anyway.
> 
> The only way to address this problem I can see is to recognize reviewers
> *much* more than we tend to do and not just "encourage" them, because that's
> way insufficient.

What other incentives or recognition mechanisms would you propose?

James

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

[jic23]

James Bottomley writes: 

> On Wed, 2015-07-08 at 03:29 +0200, Rafael J. Wysocki wrote:
>> On Wednesday, July 08, 2015 01:21:40 AM Peter Huewe wrote:
>> > Hi,
>> > 
>> > In order to continue our traditions I would like to propose again the topic of 
>> > recruitment, but this time not only limiting to the hobbyists market.
>> > 
>> > We are definitely short on reviewers and thus have mostly overloaded 
>> > maintainers.
>> > For testers it's usually even worse - how many patches are actually tested?
>> > Judging from what I read on LKML not that many.
>> > 
>> > So we should definitely discuss:
>> > - how can we encourage hobbyists to become regular contributors
>> > -- how to keep people interested, the drop-out rates are huge.
>> > - encourage regular contributors to become reviewers and testers
>> > - reviewers to become co-maintainers and finally maintainers (once the 
>> > original maintainer is used up or moves up/on) 
>> 
>> Good topic. 
>> 
>> Unfortunately, there are not too many incentives for people to become
>> code reviewers or testers, or at least to spend more time reviewing patches.
> 
> We can alter that somewhat.  We used to run a Maintainers lottery for
> the kernel summit ... we could instead offer places based on the number
> of Reviewed-by: tags ... we have all the machinery to calculate that.  I
> know an invitation to the kernel summit isn't a huge incentive, but it's
> a useful one.

Sounds like a good idea to me, though it would only effect a tiny
percentage of our reviewers.  I suppose publishing a short list of the top 
n% of reviewers from which the lottery runs might give some
recognition. 

> 
>> Most of the time there's a little to no recognition for doing that work and,
>> quite frankly, writing code is more rewarding than that for the majority of
>> people anyway. 
>> 
>> The only way to address this problem I can see is to recognize reviewers
>> *much* more than we tend to do and not just "encourage" them, because that's
>> way insufficient.
> 
> What other incentives or recognition mechanisms would you propose?

Again, it's not much an an incentive (and has disadvantages) but
explicitly acknowledging reviewers for more areas in MAINTAINERS
might give them more of a warm fuzzy feeling! (keeping these entries
up to date is also important - another nightmare for Maintainers as
they don't want anyone to feel not acknowledged as they weren't
included in the 'official' reviewers list). 

They do then get personally emailed lots and lots of patches as a result
but they clearly like that sort of thing :) 

So to me it seems like it's the small stuff that just gives a warm
fuzzy feeling that may make all the difference. 

Jonathan
> 
> James 
> 
> 
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

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

[Peter Huewe]

I totally agree with Jonathan.
The warm fuzzy feeling makes the difference.
Beginning with thank you emails and seasonal greetings, but also being listed in MAINTAINERS creates a feeling of belonging. So this is something we already have improved... But still a long way to go!

I also think that an invite to something like KS is usually  seen  as a reward, since it is an invite only event with the big penguins. 

Peter
-- 
Sent from my mobile

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

[Steven Rostedt]

On Wed, 08 Jul 2015 09:00:32 +0100
jic23@jic23.retrosnub.co.uk wrote:


> > We can alter that somewhat.  We used to run a Maintainers lottery for
> > the kernel summit ... we could instead offer places based on the number
> > of Reviewed-by: tags ... we have all the machinery to calculate that.  I
> > know an invitation to the kernel summit isn't a huge incentive, but it's
> > a useful one.
> 
> Sounds like a good idea to me, though it would only effect a tiny
> percentage of our reviewers.  I suppose publishing a short list of the top 
> n% of reviewers from which the lottery runs might give some
> recognition. 
> 

I personally don't trust a Reviewed-by tag much, as I sometimes see
them appear without any comments.

I was thinking of writing a perl script that would read my LKML archive
and somewhat intelligently looking at people who replied to patches,
that also has snippets of the patch in the reply, and counting them. I
think that would be a more accurate use of real reviewers than just the
Reviewed-by tag.

-- Steve

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

[Laurent Pinchart]

On Wednesday 08 July 2015 14:53:15 Steven Rostedt wrote:
> On Wed, 08 Jul 2015 09:00:32 +0100 jic23@jic23.retrosnub.co.uk wrote:
> > > We can alter that somewhat.  We used to run a Maintainers lottery for
> > > the kernel summit ... we could instead offer places based on the number
> > > of Reviewed-by: tags ... we have all the machinery to calculate that.  I
> > > know an invitation to the kernel summit isn't a huge incentive, but it's
> > > a useful one.
> > 
> > Sounds like a good idea to me, though it would only effect a tiny
> > percentage of our reviewers.  I suppose publishing a short list of the top
> > n% of reviewers from which the lottery runs might give some
> > recognition.
> 
> I personally don't trust a Reviewed-by tag much, as I sometimes see
> them appear without any comments.
> 
> I was thinking of writing a perl script that would read my LKML archive
> and somewhat intelligently looking at people who replied to patches,
> that also has snippets of the patch in the reply, and counting them. I
> think that would be a more accurate use of real reviewers than just the
> Reviewed-by tag.

Reviewed-by or Acked-by metrics are unfortunately very easy to game. If we 
could make them more robust, we could publish statistics as we do for commits 
authorship (http://remword.com/kps_result/ for instance) and start mentioning 
people's names in kernel development reports. That might not be much, but it 
could help reviewers feeling valued for their work.

-- 
Regards,

Laurent Pinchart

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

[Steven Rostedt]

On Wed, 08 Jul 2015 22:56:38 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
 
> Reviewed-by or Acked-by metrics are unfortunately very easy to game. If we 

I'm not worried about Acked-by, as that (to me anyway) is just a
maintainer telling other maintainers that they are fine with the
change, and they are OK with it going in via another tree.

I also sometimes give an Acked-by, as a "I took a quick look, and it
looks good to me". I only add a Reviewed-by tag if I took enough effort
to understand every part of the patch as if I wrote it myself.

-- Steve

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

[Rafael J. Wysocki]

On Wednesday, July 08, 2015 04:07:15 PM Steven Rostedt wrote:
> On Wed, 08 Jul 2015 22:56:38 +0300
> Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
>  
> > Reviewed-by or Acked-by metrics are unfortunately very easy to game. If we 
> 
> I'm not worried about Acked-by, as that (to me anyway) is just a
> maintainer telling other maintainers that they are fine with the
> change, and they are OK with it going in via another tree.
> 
> I also sometimes give an Acked-by, as a "I took a quick look, and it
> looks good to me". I only add a Reviewed-by tag if I took enough effort
> to understand every part of the patch as if I wrote it myself.

I do that too and that's my understanding of what the tag is for.

However, some people treat it as a this-patch-looks-good-to-me tag.

But regardless of what tags you use, if you say something along the lines of:

- I like A (because of X).
- I don't like B (because of Y).
- C will break things because of Z.

in your review, every maintainer will be grateful for that.  I'd like people
doing that kind of stuff to be recognized in some special way, because that's
really really helpful (and we need it).

Honestly, I'm not sure how to make that happen.

Thanks,
Rafael

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

[Frank Rowand]

On 7/8/2015 2:31 PM, Rafael J. Wysocki wrote:
> On Wednesday, July 08, 2015 04:07:15 PM Steven Rostedt wrote:
>> On Wed, 08 Jul 2015 22:56:38 +0300
>> Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
>>  
>>> Reviewed-by or Acked-by metrics are unfortunately very easy to game. If we 
>>
>> I'm not worried about Acked-by, as that (to me anyway) is just a
>> maintainer telling other maintainers that they are fine with the
>> change, and they are OK with it going in via another tree.
>>
>> I also sometimes give an Acked-by, as a "I took a quick look, and it
>> looks good to me". I only add a Reviewed-by tag if I took enough effort
>> to understand every part of the patch as if I wrote it myself.
> 
> I do that too and that's my understanding of what the tag is for.

That seems to dilute the value of Acked-by.  Acked-by requires a review,
although the example statement of "yep, looks good to me" in SubmittingPatches
is a lot less stringent than the "Reviewer's statement of oversight" that is
attached to the Reviewed-by tag.

"I took a quick look" is not what I would like to encourage for reviews.

   ITAQL-by: frank.rowand@sonymobile.com

Would the "Cc:" tag be a more appropriate tag in this case?  (Described in the
same section as Acked-by in SubmittingPatches.)  Or maybe SubmittingPatches
needs to change to match reality?

SubmittingPatches:

   Acked-by: is not as formal as Signed-off-by:.  It is a record that the acker
   has at least reviewed the patch and has indicated acceptance.  Hence patch
   mergers will sometimes manually convert an acker's "yep, looks good to me"
   into an Acked-by: (but note that it is usually better to ask for an
   explicit ack).

Then the next paragraph also allows a subsystem maintainer to acknowledge just
that subsystem's part of a multiple subsystem patch.


> 
> However, some people treat it as a this-patch-looks-good-to-me tag.
> 
> But regardless of what tags you use, if you say something along the lines of:
> 
> - I like A (because of X).
> - I don't like B (because of Y).
> - C will break things because of Z.
> 
> in your review, every maintainer will be grateful for that.  I'd like people
> doing that kind of stuff to be recognized in some special way, because that's
> really really helpful (and we need it).
> 
> Honestly, I'm not sure how to make that happen.
> 
> Thanks,
> Rafael

- Frank

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

[Guenter Roeck]

On 07/08/2015 11:53 AM, Steven Rostedt wrote:
> On Wed, 08 Jul 2015 09:00:32 +0100
> jic23@jic23.retrosnub.co.uk wrote:
>
>
>>> We can alter that somewhat.  We used to run a Maintainers lottery for
>>> the kernel summit ... we could instead offer places based on the number
>>> of Reviewed-by: tags ... we have all the machinery to calculate that.  I
>>> know an invitation to the kernel summit isn't a huge incentive, but it's
>>> a useful one.
>>
>> Sounds like a good idea to me, though it would only effect a tiny
>> percentage of our reviewers.  I suppose publishing a short list of the top
>> n% of reviewers from which the lottery runs might give some
>> recognition.
>>
>
> I personally don't trust a Reviewed-by tag much, as I sometimes see
> them appear without any comments.
>

Except for the following, they are always reliable and can be trusted.

Reviewed-by: Edsel Murphy <edsel@murphy.com>

Seriously, it does happen that I send Reviewed-by: or Acked-by: feedback if
a patch is just fine as-is. What do you expect the reviewer to do in such
a case ?

Thanks,
Guenter

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

[Michael Ellerman]

On Wed, 2015-07-08 at 13:08 -0700, Guenter Roeck wrote:
> On 07/08/2015 11:53 AM, Steven Rostedt wrote:
> > On Wed, 08 Jul 2015 09:00:32 +0100
> > jic23@jic23.retrosnub.co.uk wrote:
> >
> >
> >>> We can alter that somewhat.  We used to run a Maintainers lottery for
> >>> the kernel summit ... we could instead offer places based on the number
> >>> of Reviewed-by: tags ... we have all the machinery to calculate that.  I
> >>> know an invitation to the kernel summit isn't a huge incentive, but it's
> >>> a useful one.
> >>
> >> Sounds like a good idea to me, though it would only effect a tiny
> >> percentage of our reviewers.  I suppose publishing a short list of the top
> >> n% of reviewers from which the lottery runs might give some
> >> recognition.
> >>
> >
> > I personally don't trust a Reviewed-by tag much, as I sometimes see
> > them appear without any comments.
> >
> 
> Except for the following, they are always reliable and can be trusted.
> 
> Reviewed-by: Edsel Murphy <edsel@murphy.com>
> 
> Seriously, it does happen that I send Reviewed-by: or Acked-by: feedback if
> a patch is just fine as-is. What do you expect the reviewer to do in such
> a case ?

There's almost always something you can say.

Even if it's a trivial patch, eg. a spelling fix, as the reviewer you should be
confirming that only the spelling fix happened, ie. no other changes slipped
into the diff. And so you can say that.

If it's more complex than a spelling fix then there's usually something you can
comment on.

There might be times when all you can say is "Yep, logic looks right" which
might seem redundant, but personally I'd prefer to see that than just a plain
Reviewed-by.

cheers

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

[Frank Rowand]

On 7/8/2015 9:06 PM, Michael Ellerman wrote:
> On Wed, 2015-07-08 at 13:08 -0700, Guenter Roeck wrote:
>> On 07/08/2015 11:53 AM, Steven Rostedt wrote:
>>> On Wed, 08 Jul 2015 09:00:32 +0100
>>> jic23@jic23.retrosnub.co.uk wrote:
>>>
>>>
>>>>> We can alter that somewhat.  We used to run a Maintainers lottery for
>>>>> the kernel summit ... we could instead offer places based on the number
>>>>> of Reviewed-by: tags ... we have all the machinery to calculate that.  I
>>>>> know an invitation to the kernel summit isn't a huge incentive, but it's
>>>>> a useful one.
>>>>
>>>> Sounds like a good idea to me, though it would only effect a tiny
>>>> percentage of our reviewers.  I suppose publishing a short list of the top
>>>> n% of reviewers from which the lottery runs might give some
>>>> recognition.
>>>>
>>>
>>> I personally don't trust a Reviewed-by tag much, as I sometimes see
>>> them appear without any comments.

I don't expect my Reviewed-by tag with no extra comments to carry much weight
if I send it to a maintainer who does not know me.

But if I have a history of good reviews to a specific maintainer, then why
should I have to add a message that says: Yes, I really, really did review
the patch.  I truly mean that the patch "has been reviewed and found acceptable
according to the Reviewer's Statement" as listed in SubmittingPatches.

And I read Steve's qualification of "don't trust ... _much_" as being
consistent with what I am saying, so I'm fine with that.  The point I
want to make is that a Reviewed-by tag without comments should not
always be assumed to be without meaning or value.

>>>
>>
>> Except for the following, they are always reliable and can be trusted.
>>
>> Reviewed-by: Edsel Murphy <edsel@murphy.com>
>>
>> Seriously, it does happen that I send Reviewed-by: or Acked-by: feedback if
>> a patch is just fine as-is. What do you expect the reviewer to do in such
>> a case ?
> 
> There's almost always something you can say.

And there is a time to not nit-pick a patch to death.

If my comment will not result in a significantly better patch, then I am
wasting the patch submitter's time, and the time of everyone else on the
mail list that will have to read my comment, and potentially have to read
and review a new spin of the patch.

Reviewed-by does not mean that I believe the patch is perfect and could not
possibly be improved.  From the "Reviewer's statement of oversight":

  (c) While there may be things that could be improved with this
      submission, I believe that it is, at this time, (1) a
      worthwhile modification to the kernel, and (2) free of known
      issues which would argue against its inclusion.

> 
> Even if it's a trivial patch, eg. a spelling fix, as the reviewer you should be
> confirming that only the spelling fix happened, ie. no other changes slipped
> into the diff. And so you can say that.
> 
> If it's more complex than a spelling fix then there's usually something you can
> comment on.
> 
> There might be times when all you can say is "Yep, logic looks right" which
> might seem redundant, but personally I'd prefer to see that than just a plain
> Reviewed-by.

"Yep, logic looks right" actually seems like a useful comment, because it tells
me that the reviewer probably does not understand the full context, but the code
is self consistent and does not have any obvious problems.  So I will not think
that the review is complete.

-Frank

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2004 bytes --]

On Thu, Jul 09, 2015 at 11:28:28AM -0700, Frank Rowand wrote:
> On 7/8/2015 9:06 PM, Michael Ellerman wrote:
> > On Wed, 2015-07-08 at 13:08 -0700, Guenter Roeck wrote:
> >> On 07/08/2015 11:53 AM, Steven Rostedt wrote:

> >>> I personally don't trust a Reviewed-by tag much, as I sometimes see
> >>> them appear without any comments.
> 
> I don't expect my Reviewed-by tag with no extra comments to carry much weight
> if I send it to a maintainer who does not know me.

> But if I have a history of good reviews to a specific maintainer, then why
> should I have to add a message that says: Yes, I really, really did review
> the patch.  I truly mean that the patch "has been reviewed and found acceptable
> according to the Reviewer's Statement" as listed in SubmittingPatches.

> And I read Steve's qualification of "don't trust ... _much_" as being
> consistent with what I am saying, so I'm fine with that.  The point I
> want to make is that a Reviewed-by tag without comments should not
> always be assumed to be without meaning or value.

Indeed, and when I'm the one dealing with applying the patches it's
actually helpful to not have extra text that needs reading and
thinking about when applying things if I trust whoever did the review.
Past history as a reviewer is much more important than any verbiage
around the review and review that consists of a simple tag takes seconds
to read.

> >> Seriously, it does happen that I send Reviewed-by: or Acked-by: feedback if
> >> a patch is just fine as-is. What do you expect the reviewer to do in such
> >> a case ?

> > There's almost always something you can say.

> And there is a time to not nit-pick a patch to death.

> If my comment will not result in a significantly better patch, then I am
> wasting the patch submitter's time, and the time of everyone else on the
> mail list that will have to read my comment, and potentially have to read
> and review a new spin of the patch.

Very much so.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Guenter Roeck]

On Thu, Jul 09, 2015 at 11:28:28AM -0700, Frank Rowand wrote:
> On 7/8/2015 9:06 PM, Michael Ellerman wrote:
> > On Wed, 2015-07-08 at 13:08 -0700, Guenter Roeck wrote:
> >> On 07/08/2015 11:53 AM, Steven Rostedt wrote:
> >>> On Wed, 08 Jul 2015 09:00:32 +0100
> >>> jic23@jic23.retrosnub.co.uk wrote:
> >>>
> >>>
> >>>>> We can alter that somewhat.  We used to run a Maintainers lottery for
> >>>>> the kernel summit ... we could instead offer places based on the number
> >>>>> of Reviewed-by: tags ... we have all the machinery to calculate that.  I
> >>>>> know an invitation to the kernel summit isn't a huge incentive, but it's
> >>>>> a useful one.
> >>>>
> >>>> Sounds like a good idea to me, though it would only effect a tiny
> >>>> percentage of our reviewers.  I suppose publishing a short list of the top
> >>>> n% of reviewers from which the lottery runs might give some
> >>>> recognition.
> >>>>
> >>>
> >>> I personally don't trust a Reviewed-by tag much, as I sometimes see
> >>> them appear without any comments.
> 
> I don't expect my Reviewed-by tag with no extra comments to carry much weight
> if I send it to a maintainer who does not know me.
> 
> But if I have a history of good reviews to a specific maintainer, then why
> should I have to add a message that says: Yes, I really, really did review
> the patch.  I truly mean that the patch "has been reviewed and found acceptable
> according to the Reviewer's Statement" as listed in SubmittingPatches.
> 
> And I read Steve's qualification of "don't trust ... _much_" as being
> consistent with what I am saying, so I'm fine with that.  The point I
> want to make is that a Reviewed-by tag without comments should not
> always be assumed to be without meaning or value.
> 
Absolutely agree.

It looks like we have yet another set of diverging maintainer expectations.
Some maintainers will expect me to provide an extra comment, which I'll
have to phrase carefully to avoid it being misinterpreted as "I just
glanced at the code and didn't find an obvious issue with it".
Others will get annoyed at me providing the extra comment.

Guenter

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

[Darren Hart]

On Thu, Jul 09, 2015 at 12:23:20PM -0700, Guenter Roeck wrote:
> On Thu, Jul 09, 2015 at 11:28:28AM -0700, Frank Rowand wrote:
> > On 7/8/2015 9:06 PM, Michael Ellerman wrote:
> > > On Wed, 2015-07-08 at 13:08 -0700, Guenter Roeck wrote:
> > >> On 07/08/2015 11:53 AM, Steven Rostedt wrote:
> > >>> On Wed, 08 Jul 2015 09:00:32 +0100
> > >>> jic23@jic23.retrosnub.co.uk wrote:
> > >>>
> > >>>
> > >>>>> We can alter that somewhat.  We used to run a Maintainers lottery for
> > >>>>> the kernel summit ... we could instead offer places based on the number
> > >>>>> of Reviewed-by: tags ... we have all the machinery to calculate that.  I
> > >>>>> know an invitation to the kernel summit isn't a huge incentive, but it's
> > >>>>> a useful one.
> > >>>>
> > >>>> Sounds like a good idea to me, though it would only effect a tiny
> > >>>> percentage of our reviewers.  I suppose publishing a short list of the top
> > >>>> n% of reviewers from which the lottery runs might give some
> > >>>> recognition.
> > >>>>
> > >>>
> > >>> I personally don't trust a Reviewed-by tag much, as I sometimes see
> > >>> them appear without any comments.
> > 
> > I don't expect my Reviewed-by tag with no extra comments to carry much weight
> > if I send it to a maintainer who does not know me.
> > 
> > But if I have a history of good reviews to a specific maintainer, then why
> > should I have to add a message that says: Yes, I really, really did review
> > the patch.  I truly mean that the patch "has been reviewed and found acceptable
> > according to the Reviewer's Statement" as listed in SubmittingPatches.
> > 
> > And I read Steve's qualification of "don't trust ... _much_" as being
> > consistent with what I am saying, so I'm fine with that.  The point I
> > want to make is that a Reviewed-by tag without comments should not
> > always be assumed to be without meaning or value.
> > 
> Absolutely agree.
> 
> It looks like we have yet another set of diverging maintainer expectations.
> Some maintainers will expect me to provide an extra comment, which I'll
> have to phrase carefully to avoid it being misinterpreted as "I just
> glanced at the code and didn't find an obvious issue with it".
> Others will get annoyed at me providing the extra comment.

Why would a couple lines of context be any harder to deal with than all the
meta-data that comes along with an email including a Reviewed-by?

-- 
Darren Hart
Intel Open Source Technology Center

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

[Theodore Ts'o]

No matter what we ask people to type, the system can be gamed so long
as we (a) use automated systems, and (b) we're transparent what the
automated system uses as a signal about what's a valid review versus a
garbage review.  This is basically the same problem that Google has
when trying to deal with SEO folks who are trying to game the search
algorithm, and it's not really a soluble problem unless you have a lot
of people constantly working on refining the system and adjusting in
response to humans who are trying to attack the system.

And if there are companies who are using reviews, or signed-off-by
counts as a basis of performance reviews, humans *will* be
incentivized to game the system, regardless of what the kernel summit
program committee might be doing to use these systems.

(Although I will say there is one person who I've consistently
downgraded *because* it's obvious s/he has been sending lots of
trivial patches, and while that person may (or may not) have changed,
it's still human nature that I assume that this person's scores are
inflated.  And this is true of whoever sends huge number of checkpatch
or coccinelle generated or inspired patches.  So people should be
aware that attempts to game the system can backfire, when people start
imposing informal "manual penalties" to their evaluation of that
particular person.  Which is exactly what happens in the Search Engine
Optimization world, by the way....)

							- Ted

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

[Guenter Roeck]

On Thu, Jul 09, 2015 at 04:13:15PM -0400, Theodore Ts'o wrote:
> No matter what we ask people to type, the system can be gamed so long
> as we (a) use automated systems, and (b) we're transparent what the
> automated system uses as a signal about what's a valid review versus a
> garbage review.  This is basically the same problem that Google has
> when trying to deal with SEO folks who are trying to game the search
> algorithm, and it's not really a soluble problem unless you have a lot
> of people constantly working on refining the system and adjusting in
> response to humans who are trying to attack the system.
> 
> And if there are companies who are using reviews, or signed-off-by
> counts as a basis of performance reviews, humans *will* be
> incentivized to game the system, regardless of what the kernel summit
> program committee might be doing to use these systems.
> 
While this may be correct in some circumstances, there are also
companies which do just the opposite, especially when it comes
to reviews. At least for my part I still have to encounter a
company where "provides excellent and thorough code reviews"
can be found as positive statement in a performance review.

Earlier it was discussed how to improve the recognition of reviewers.
Your comments seems to suggest the opposite, and may actually discourage
reviewers. Why should I review Linux kernel code if that is seen
by some as me trying to "game" the system ?

I used to submit some more or less random cleanup patches into various
areas of the kernel, just for fun, because I liked doing it, and because
I needed some distraction. I stopped doing it after I realized that this
may be seen as "gaming the system". Nowadays I only submit such random
patches to fix build errors or real bugs. Would I continue to do that
if I get accused of trying to game the system ? Probably not.

I am not much if at all concerned with people gaming the system
to improve their standing, whereever that may be. I am much more
concerned that we may drive people off by accusing them to just
submit patches or reviews to game the system. At the end this is our
loss, not theirs. If their work results in better code, who cares
what their motivation might be ? And who are we to judge their
motivation ?

> (Although I will say there is one person who I've consistently
> downgraded *because* it's obvious s/he has been sending lots of
> trivial patches, and while that person may (or may not) have changed,
> it's still human nature that I assume that this person's scores are
> inflated.  And this is true of whoever sends huge number of checkpatch
> or coccinelle generated or inspired patches.  So people should be
> aware that attempts to game the system can backfire, when people start
> imposing informal "manual penalties" to their evaluation of that
> particular person.  Which is exactly what happens in the Search Engine
> Optimization world, by the way....)
> 
That may be true for some people, but at the same time I think statements
like the above might discourage people who just like cleaning up code for
fun. There are several of those working on cleaning up the Linux kernel,
and I truly appreciate their efforts.

Guenter

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

[Theodore Ts'o]

On Thu, Jul 09, 2015 at 01:50:49PM -0700, Guenter Roeck wrote:
> 
> Earlier it was discussed how to improve the recognition of reviewers.
> Your comments seems to suggest the opposite, and may actually discourage
> reviewers. Why should I review Linux kernel code if that is seen
> by some as me trying to "game" the system ?

So I were designing an initial system that automatically scored
reviewers, I'd be looking to see, from a holistic point of view, how
many reviews were zero-length:

Reviewed-by: John Q. Random <seventeen@random.org>

... and nothing else,

.... versus how many reviews had specific comments on various
different portions of the patch.  If possible, the automated system
would try to distinguish between comments that were just pointing out
whitespace issues (which would be a slight positive) with comments
that point out genuine design issues (this will be really hard to do
in an automated fashion, but a very sophisticated nueral network[1]
mgiht be able to hack it).

I might also try using some kind scheme that counted the number of
words in a review (stripping out lines of patch or commit description
that the review was a reply to), etc.  But of course, if it was public
knowledge that the system was just stripping out the original e-mail,
and then just doing a "wc -w", then people would game the system by
adding list of random words at the bottom of the review.

And, of course, I'd have the system give a huge negative score if a
commit that got a "LGTM" positive review caused a bug that required
the patch to be reverted.  *That* signal, at least, would be hard to
game, and would hopefuly encourage people to actually take time
reviewing a commit, and not blindly slapping a reviewed-by on a commit
they don't understand.

You see?  It's not that reviews in and of themselves are attempts to
game the system ---- just so long as they are genuine reviews.  If
there is evidence that the reviews are issued within seconds of the
original patch going out, with a Reviewed-by: line and nothing else,
what would *you* think about the quality of that review?

> That may be true for some people, but at the same time I think statements
> like the above might discourage people who just like cleaning up code for
> fun. There are several of those working on cleaning up the Linux kernel,
> and I truly appreciate their efforts.

Sure, but that's not the people who (in my opinion as a program
committee member) should be attendingt he Kernel Summit, where we want
people who are genuinely clueful about technical and policy issues,
and not people like (for example) Nick Krause.

Regards,

						- Ted

[1] http://googleresearch.blogspot.com/2015/06/inceptionism-going-deeper-into-neural.html

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

[josh]

On Thu, Jul 09, 2015 at 05:47:18PM -0400, Theodore Ts'o wrote:
> On Thu, Jul 09, 2015 at 01:50:49PM -0700, Guenter Roeck wrote:
> > 
> > Earlier it was discussed how to improve the recognition of reviewers.
> > Your comments seems to suggest the opposite, and may actually discourage
> > reviewers. Why should I review Linux kernel code if that is seen
> > by some as me trying to "game" the system ?
> 
> So I were designing an initial system that automatically scored
> reviewers, I'd be looking to see, from a holistic point of view, how
> many reviews were zero-length:
> 
> Reviewed-by: John Q. Random <seventeen@random.org>
> 
> ... and nothing else,
> 
> .... versus how many reviews had specific comments on various
> different portions of the patch.  If possible, the automated system
> would try to distinguish between comments that were just pointing out
> whitespace issues (which would be a slight positive) with comments
> that point out genuine design issues (this will be really hard to do
> in an automated fashion, but a very sophisticated nueral network[1]
> mgiht be able to hack it).

That assumes the patch actually has issues.  To use the reviews I do on
RCU patches as an example, in a patch series, I might reply to a few
patches with "here are some issues; with those fixed, Reviewed-by...",
and then reply to the remaining unproblematic patches (individually or
in aggregate) with just the Reviewed-by.

- Josh Triplett

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

[Theodore Ts'o]

On Thu, Jul 09, 2015 at 04:13:52PM -0700, josh@joshtriplett.org wrote:
> 
> That assumes the patch actually has issues.  To use the reviews I do on
> RCU patches as an example, in a patch series, I might reply to a few
> patches with "here are some issues; with those fixed, Reviewed-by...",
> and then reply to the remaining unproblematic patches (individually or
> in aggregate) with just the Reviewed-by.

Right, that's why I talked about doing this on a holistic way.  It's
true that individual patches, and maybe even all of the patches in a
patch series, might be *perfect*.  But presumably that won't be true
for **all** of the patches you review.

This is why creating a system to do patch reviewer ranking is so
complicated.  You need to do this by looking at the entire corpus of
patches reviewed by the reviewer, so (for example) you can find out
which patch reviewers are allowing bad patches to get through to Linus
by giving a thumbs up to a patch that needed to be reverted.

(At $WORK, if someone creates a CL that causes a massive failure, it's
not just the engineer who submitted the CL who is at fault, but also
the reviewers who gave the CL a positive review --- and that's as it
should be.  Of course we also ask if there is something about the
development and regression test environment that might be a systematic
cause of problems, but if someone is consistently giving LGTM's
without doing enough due diligence, that's a issue that ultimately
need to be addressed by the engineer's manager.  The question is how to
deal with this kind of failure mode in an open source, volunteer
world.)

          	     	     	     	- Ted

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

[Steven Rostedt]

On Thu, 9 Jul 2015 16:13:52 -0700
josh@joshtriplett.org wrote:


> That assumes the patch actually has issues.  To use the reviews I do on
> RCU patches as an example, in a patch series, I might reply to a few
> patches with "here are some issues; with those fixed, Reviewed-by...",
> and then reply to the remaining unproblematic patches (individually or
> in aggregate) with just the Reviewed-by.
> 


Josh, I read your reviews. Yes, you have a bunch of single "Reviewed-by"
tags, but you also have a lot of emails with substantially significant
comments. What Ted is saying, is to see how many significant replies one
has. In fact, I would say if we were to automate this, each significant
reply (one with actual comments), would increase the weight that a
single "Reviewed-by" email would carry. That way people like yourself
would have more weight attached to emails with single "Reviewed-by"
than others that don't have many emails with actual comments attached.

Anyway, for consideration to KS, the top reviewers that an automated
system would produce, would only get the program committee's eyes
looking at it. It by no way guarantees an invite. No matter what
automated system is in place, at least for KS, there will always be
humans involved in analyzing that data.

-- Steve

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

[josh]

On Fri, Jul 10, 2015 at 04:49:38PM -0400, Steven Rostedt wrote:
> On Thu, 9 Jul 2015 16:13:52 -0700 josh@joshtriplett.org wrote:
> > That assumes the patch actually has issues.  To use the reviews I do on
> > RCU patches as an example, in a patch series, I might reply to a few
> > patches with "here are some issues; with those fixed, Reviewed-by...",
> > and then reply to the remaining unproblematic patches (individually or
> > in aggregate) with just the Reviewed-by.
> 
> Josh, I read your reviews. Yes, you have a bunch of single "Reviewed-by"
> tags, but you also have a lot of emails with substantially significant
> comments. What Ted is saying, is to see how many significant replies one
> has. In fact, I would say if we were to automate this, each significant
> reply (one with actual comments), would increase the weight that a
> single "Reviewed-by" email would carry. That way people like yourself
> would have more weight attached to emails with single "Reviewed-by"
> than others that don't have many emails with actual comments attached.

Ah, I see what you're getting at now.  I thought you were trying to
figure out the value of a "Reviewed-by" on an individual patch.  But
you're right, a review doesn't carry much weight if your reviews *never*
find issues; that would imply you're either chery-picking easy patches
to review or rubber-stamping bad patches.

(And conversely, a Reviewed-by on a patch that turns out to be wrong
shouldn't carry any more stigma than submitting such a patch yourself.
Everybody has submitted a brown-paper-bag at some point; as long as
there's not a pattern of it, that's not a critical issue with
reviewing.)

- Josh Triplett

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

[Paul E. McKenney]

On Fri, Jul 10, 2015 at 04:49:38PM -0400, Steven Rostedt wrote:
> On Thu, 9 Jul 2015 16:13:52 -0700
> josh@joshtriplett.org wrote:
> 
> 
> > That assumes the patch actually has issues.  To use the reviews I do on
> > RCU patches as an example, in a patch series, I might reply to a few
> > patches with "here are some issues; with those fixed, Reviewed-by...",
> > and then reply to the remaining unproblematic patches (individually or
> > in aggregate) with just the Reviewed-by.
> 
> Josh, I read your reviews. Yes, you have a bunch of single "Reviewed-by"
> tags, but you also have a lot of emails with substantially significant
> comments. What Ted is saying, is to see how many significant replies one
> has. In fact, I would say if we were to automate this, each significant
> reply (one with actual comments), would increase the weight that a
> single "Reviewed-by" email would carry. That way people like yourself
> would have more weight attached to emails with single "Reviewed-by"
> than others that don't have many emails with actual comments attached.

Just to state the obvious, I greatly value Josh's reviews as well,
especially the ones where he points out a bug.  Much easier than
finding them the hard way!  ;-)

							Thanx, Paul

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

[Guenter Roeck]

On Thu, Jul 09, 2015 at 05:47:18PM -0400, Theodore Ts'o wrote:
> On Thu, Jul 09, 2015 at 01:50:49PM -0700, Guenter Roeck wrote:
> > 
> > Earlier it was discussed how to improve the recognition of reviewers.
> > Your comments seems to suggest the opposite, and may actually discourage
> > reviewers. Why should I review Linux kernel code if that is seen
> > by some as me trying to "game" the system ?
> 
> So I were designing an initial system that automatically scored
> reviewers, I'd be looking to see, from a holistic point of view, how
> many reviews were zero-length:
> 
> Reviewed-by: John Q. Random <seventeen@random.org>
> 
> ... and nothing else,
> 
> .... versus how many reviews had specific comments on various
> different portions of the patch.  If possible, the automated system
> would try to distinguish between comments that were just pointing out
> whitespace issues (which would be a slight positive) with comments
> that point out genuine design issues (this will be really hard to do
> in an automated fashion, but a very sophisticated nueral network[1]
> mgiht be able to hack it).
> 
> I might also try using some kind scheme that counted the number of
> words in a review (stripping out lines of patch or commit description
> that the review was a reply to), etc.  But of course, if it was public
> knowledge that the system was just stripping out the original e-mail,
> and then just doing a "wc -w", then people would game the system by
> adding list of random words at the bottom of the review.
> 
> And, of course, I'd have the system give a huge negative score if a
> commit that got a "LGTM" positive review caused a bug that required
> the patch to be reverted.  *That* signal, at least, would be hard to
> game, and would hopefuly encourage people to actually take time
> reviewing a commit, and not blindly slapping a reviewed-by on a commit
> they don't understand.
> 
> You see?  It's not that reviews in and of themselves are attempts to
> game the system ---- just so long as they are genuine reviews.  If
> there is evidence that the reviews are issued within seconds of the
> original patch going out, with a Reviewed-by: line and nothing else,
> what would *you* think about the quality of that review?
> 
Agreed. On the other side, is gaming really a problem with kernel code
reviews ? Sure, a search engine provider will have to look out for
abuse patterns, but for code reviews I am not sure if it is worth the
effort. I would suspect that it is much more likely that the simple
"wc -w" approach should provide you with worthy candidates for the KS.
Since you are not dealing with hundreds or thousands of candidates,
I'd assume you'll do a hand screening anyway, and quickly identify any
gamers. I'd be quite surprised if there are any, though.

> > That may be true for some people, but at the same time I think statements
> > like the above might discourage people who just like cleaning up code for
> > fun. There are several of those working on cleaning up the Linux kernel,
> > and I truly appreciate their efforts.
> 
> Sure, but that's not the people who (in my opinion as a program
> committee member) should be attendingt he Kernel Summit, where we want
> people who are genuinely clueful about technical and policy issues,
> and not people like (for example) Nick Krause.
> 
Nick is such an outlier that I really hope he isn't used as a baseline
to set any kind of policy. But how do you evaluate someone like, say,
Axel Lin, who makes excellent contributions all over the place ?

Thanks,
Guenter

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 848 bytes --]

On Fri, Jul 10, 2015 at 11:20:45AM -0700, Guenter Roeck wrote:

> Agreed. On the other side, is gaming really a problem with kernel code
> reviews ? Sure, a search engine provider will have to look out for
> abuse patterns, but for code reviews I am not sure if it is worth the
> effort. I would suspect that it is much more likely that the simple
> "wc -w" approach should provide you with worthy candidates for the KS.
> Since you are not dealing with hundreds or thousands of candidates,
> I'd assume you'll do a hand screening anyway, and quickly identify any
> gamers. I'd be quite surprised if there are any, though.

I think the concern is more long term - if we're trying to reward
reviewers in order to encourage review then probably now we're fine but
if we do it in a way that's gameable will that end up having the effect
that we want?

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Jason Cooper]

On Fri, Jul 10, 2015 at 11:20:45AM -0700, Guenter Roeck wrote:
> On Thu, Jul 09, 2015 at 05:47:18PM -0400, Theodore Ts'o wrote:
> > On Thu, Jul 09, 2015 at 01:50:49PM -0700, Guenter Roeck wrote:
> > > 
> > > Earlier it was discussed how to improve the recognition of reviewers.
> > > Your comments seems to suggest the opposite, and may actually discourage
> > > reviewers. Why should I review Linux kernel code if that is seen
> > > by some as me trying to "game" the system ?
> > 
> > So I were designing an initial system that automatically scored
> > reviewers, I'd be looking to see, from a holistic point of view, how
> > many reviews were zero-length:
> > 
> > Reviewed-by: John Q. Random <seventeen@random.org>
> > 
> > ... and nothing else,
> > 
> > .... versus how many reviews had specific comments on various
> > different portions of the patch.  If possible, the automated system
> > would try to distinguish between comments that were just pointing out
> > whitespace issues (which would be a slight positive) with comments
> > that point out genuine design issues (this will be really hard to do
> > in an automated fashion, but a very sophisticated nueral network[1]
> > mgiht be able to hack it).
> > 
> > I might also try using some kind scheme that counted the number of
> > words in a review (stripping out lines of patch or commit description
> > that the review was a reply to), etc.  But of course, if it was public
> > knowledge that the system was just stripping out the original e-mail,
> > and then just doing a "wc -w", then people would game the system by
> > adding list of random words at the bottom of the review.
> > 
> > And, of course, I'd have the system give a huge negative score if a
> > commit that got a "LGTM" positive review caused a bug that required
> > the patch to be reverted.  *That* signal, at least, would be hard to
> > game, and would hopefuly encourage people to actually take time
> > reviewing a commit, and not blindly slapping a reviewed-by on a commit
> > they don't understand.
> > 
> > You see?  It's not that reviews in and of themselves are attempts to
> > game the system ---- just so long as they are genuine reviews.  If
> > there is evidence that the reviews are issued within seconds of the
> > original patch going out, with a Reviewed-by: line and nothing else,
> > what would *you* think about the quality of that review?
> > 
> Agreed. On the other side, is gaming really a problem with kernel code
> reviews ? Sure, a search engine provider will have to look out for
> abuse patterns, but for code reviews I am not sure if it is worth the
> effort. I would suspect that it is much more likely that the simple
> "wc -w" approach should provide you with worthy candidates for the KS.
> Since you are not dealing with hundreds or thousands of candidates,
> I'd assume you'll do a hand screening anyway, and quickly identify any
> gamers. I'd be quite surprised if there are any, though.

I've personally seen it, and I don't think I'm alone.  It seems to follow
a pattern of:

 - Manager/HR thinks counting tags is a useful metric (#!@$ laziness).
 - tag-count becomes an evaluation item.
 - Pay raises are affected.
 - patch submitters do the obvious.
 - maintainers weep and die a little inside.

The easy ones to spot are multiple-S-o-bs.  I've actually been told "No,
he didn't write any code, I was just trying to help him out."

The hard ones are when a patch was developed by a company, say a new
driver.  On the first patch submission, there's a Reviewed-by tag for
someone I've never seen on the list.  He *could* be the HW engineer that
designed the IP block, or he could be the likable guy that got a bad
eval last time around.  We don't know.

I keep those tags for one simple reason.  If a bisect lands on that
commit, he'll be in the list of emails for trying to figure out what
went wrong.  imo, it's better to include him to help diagnose a problem
than to play catch-up "Who else remembers this commit?", then
Cc/Fwd/Bounce during triage.  Which comes back to my "Tags are a
responsibility, not a reward."

As has been expressed elsewhere, it also depends on who's doing the
patch submitting.  There's certainly an element of trust to all of this.
Unfamiliar submitters with red flags get asked awkward questions.

thx,

Jason.

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

[Guenter]

On Fri, Jul 10, 2015 at 06:58:00PM +0000, Jason Cooper wrote:
> > Agreed. On the other side, is gaming really a problem with kernel code
> > reviews ? Sure, a search engine provider will have to look out for
> > abuse patterns, but for code reviews I am not sure if it is worth the
> > effort. I would suspect that it is much more likely that the simple
> > "wc -w" approach should provide you with worthy candidates for the KS.
> > Since you are not dealing with hundreds or thousands of candidates,
> > I'd assume you'll do a hand screening anyway, and quickly identify any
> > gamers. I'd be quite surprised if there are any, though.
> 
> I've personally seen it, and I don't think I'm alone.  It seems to follow
> a pattern of:
> 
>  - Manager/HR thinks counting tags is a useful metric (#!@$ laziness).
>  - tag-count becomes an evaluation item.
>  - Pay raises are affected.
>  - patch submitters do the obvious.
>  - maintainers weep and die a little inside.
> 
Sigh :-(. Guess I never had the pleasure of working for any of those
companies, and the areas of the kernel I care about may be too obscure
to get much attention by the gamers.

> The easy ones to spot are multiple-S-o-bs.  I've actually been told "No,
> he didn't write any code, I was just trying to help him out."
> 
Multiple S-o-b's don't always mean gaming, though. For example, my
company's workflow requires me to sign off upstream patches, not to
get annother S-o-b with my name on it, but to certify that the patch 
does not accidentially publish any company IP (and, if it does, it is
my fault, not the fault of the person who wrote the code).

Guenter

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

[Luis R. Rodriguez]

On Fri, Jul 10, 2015 at 01:24:07PM -0700, Guenter wrote:
> On Fri, Jul 10, 2015 at 06:58:00PM +0000, Jason Cooper wrote:
> > > Agreed. On the other side, is gaming really a problem with kernel code
> > > reviews ? Sure, a search engine provider will have to look out for
> > > abuse patterns, but for code reviews I am not sure if it is worth the
> > > effort. I would suspect that it is much more likely that the simple
> > > "wc -w" approach should provide you with worthy candidates for the KS.
> > > Since you are not dealing with hundreds or thousands of candidates,
> > > I'd assume you'll do a hand screening anyway, and quickly identify any
> > > gamers. I'd be quite surprised if there are any, though.
> > 
> > I've personally seen it, and I don't think I'm alone.  It seems to follow
> > a pattern of:
> > 
> >  - Manager/HR thinks counting tags is a useful metric (#!@$ laziness).
> >  - tag-count becomes an evaluation item.
> >  - Pay raises are affected.
> >  - patch submitters do the obvious.
> >  - maintainers weep and die a little inside.
> > 
> Sigh :-(. Guess I never had the pleasure of working for any of those
> companies, and the areas of the kernel I care about may be too obscure
> to get much attention by the gamers.
> 
> > The easy ones to spot are multiple-S-o-bs.  I've actually been told "No,
> > he didn't write any code, I was just trying to help him out."
> > 
> Multiple S-o-b's don't always mean gaming, though. For example, my
> company's workflow requires me to sign off upstream patches, not to
> get annother S-o-b with my name on it, but to certify that the patch 
> does not accidentially publish any company IP (and, if it does, it is
> my fault, not the fault of the person who wrote the code).

There is a danger to having people interpret the s-o-b tag differently
than what it originally was intended for, such confusion deserves
serious attention and my hope is that if folks detect these misuses
they can try to educate folks on it. The s-o-b tag means the person
is certifying under the Developer Certificate or Origin (DCO) the
patch in question. That's it. The practical gains of such a leight
weight development tool to use something like the s-o-b combined
with the huge legal merit behind it has convinced us to generalize
the DCO and encourage people outside of Linux to use it:

http://developercertificate.org/

There was coverage over this on lwn:

https://lwn.net/Articles/592503/

I've also written about the importance here:

http://www.do-not-panic.com/2014/02/developer-certificate-of-origin.html

The list of users is outdated and I cannot keep up counting folks
using it, but the more, quite recently the docker project announced
it was embracing it for instance (although it seems they modified it
mildly, WTF(?)):

https://blog.docker.com/2014/01/docker-code-contributions-require-developer-certificate-of-origin/

Because of its legal value, and because we all stand to gain from this
legal value then as a commnity at large we should try to correc
innappropriate uses of the s-o-b and educate folks on it.

I'll stay out of the conversation of other tag's, only to second Julia's
sentiments

  Luis

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

[Guenter]

Hi Luis,

On Fri, Jul 10, 2015 at 11:14:05PM +0200, Luis R. Rodriguez wrote:
> > > 
> > Multiple S-o-b's don't always mean gaming, though. For example, my
> > company's workflow requires me to sign off upstream patches, not to
> > get annother S-o-b with my name on it, but to certify that the patch 
> > does not accidentially publish any company IP (and, if it does, it is
> > my fault, not the fault of the person who wrote the code).
> 
> There is a danger to having people interpret the s-o-b tag differently
> than what it originally was intended for, such confusion deserves
> serious attention and my hope is that if folks detect these misuses
> they can try to educate folks on it. The s-o-b tag means the person
> is certifying under the Developer Certificate or Origin (DCO) the
> patch in question. That's it. The practical gains of such a leight
> weight development tool to use something like the s-o-b combined
> with the huge legal merit behind it has convinced us to generalize
> the DCO and encourage people outside of Linux to use it:
> 
Not really sure if I understand you correctly. Are you saying that you
consider the above to be a mis-use of s-o-b ?

By co-signing a patch I do (co-)certify it under DCO; I am well aware
of that. That it may have an additional context doesn't change that,
or limit its value. I can well imagine that other companies have a
similar approval flow, and I don't really understand why that would
or could be a problem. Can you educate me ?

Thanks,
Guenter

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

[Luis R. Rodriguez]

On Fri, Jul 10, 2015 at 05:52:12PM -0700, Guenter wrote:
> Hi Luis,
> 
> On Fri, Jul 10, 2015 at 11:14:05PM +0200, Luis R. Rodriguez wrote:
> > > > 
> > > Multiple S-o-b's don't always mean gaming, though. For example, my
> > > company's workflow requires me to sign off upstream patches, not to
> > > get annother S-o-b with my name on it, but to certify that the patch 
> > > does not accidentially publish any company IP (and, if it does, it is
> > > my fault, not the fault of the person who wrote the code).
> > 
> > There is a danger to having people interpret the s-o-b tag differently
> > than what it originally was intended for, such confusion deserves
> > serious attention and my hope is that if folks detect these misuses
> > they can try to educate folks on it. The s-o-b tag means the person
> > is certifying under the Developer Certificate or Origin (DCO) the
> > patch in question. That's it. The practical gains of such a leight
> > weight development tool to use something like the s-o-b combined
> > with the huge legal merit behind it has convinced us to generalize
> > the DCO and encourage people outside of Linux to use it:
> > 
> Not really sure if I understand you correctly. Are you saying that you
> consider the above to be a mis-use of s-o-b ?

Only if folks disregard or not aware of the DCO.

> By co-signing a patch I do (co-)certify it under DCO; I am well aware
> of that. That it may have an additional context doesn't change that,
> or limit its value.

Sure.

> I can well imagine that other companies have a
> similar approval flow, and I don't really understand why that would
> or could be a problem. Can you educate me ?

The concern is when folks document SOB practices which do not address
first and foremost that the SOB *is* primarily for the DCO, now if
companies or groups like to have their own other internal ammendments
for it, that's fine, its just that for patches that go into Linux
the SOB just is meant to implicate the DCO. Nothing more.

 Luis

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

[Jason Cooper]

On Fri, Jul 10, 2015 at 01:24:07PM -0700, Guenter wrote:
> On Fri, Jul 10, 2015 at 06:58:00PM +0000, Jason Cooper wrote:
> > > Agreed. On the other side, is gaming really a problem with kernel code
> > > reviews ? Sure, a search engine provider will have to look out for
> > > abuse patterns, but for code reviews I am not sure if it is worth the
> > > effort. I would suspect that it is much more likely that the simple
> > > "wc -w" approach should provide you with worthy candidates for the KS.
> > > Since you are not dealing with hundreds or thousands of candidates,
> > > I'd assume you'll do a hand screening anyway, and quickly identify any
> > > gamers. I'd be quite surprised if there are any, though.
> > 
> > I've personally seen it, and I don't think I'm alone.  It seems to follow
> > a pattern of:
> > 
> >  - Manager/HR thinks counting tags is a useful metric (#!@$ laziness).
> >  - tag-count becomes an evaluation item.
> >  - Pay raises are affected.
> >  - patch submitters do the obvious.
> >  - maintainers weep and die a little inside.
> > 
> Sigh :-(. Guess I never had the pleasure of working for any of those
> companies, and the areas of the kernel I care about may be too obscure
> to get much attention by the gamers.
> 
> > The easy ones to spot are multiple-S-o-bs.  I've actually been told "No,
> > he didn't write any code, I was just trying to help him out."
> > 
> Multiple S-o-b's don't always mean gaming, though. 

Agreed, if two people edited a patch, or there's one person approved to
cleanup/email LKML, etc.  Then multiple-SoB makes sense wrt DCO.  My
wording could have been better.  I had a specific incident in mind, but
that doesn't make a rule.

thx,

Jason.

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

[josh]

On Fri, Jul 10, 2015 at 06:58:00PM +0000, Jason Cooper wrote:
> I've personally seen it, and I don't think I'm alone.  It seems to follow
> a pattern of:
> 
>  - Manager/HR thinks counting tags is a useful metric (#!@$ laziness).
>  - tag-count becomes an evaluation item.
>  - Pay raises are affected.
>  - patch submitters do the obvious.
>  - maintainers weep and die a little inside.
> 
> The easy ones to spot are multiple-S-o-bs.  I've actually been told "No,
> he didn't write any code, I was just trying to help him out."

On the flip side, I've submitted patches with two Signed-off-by tags
specifically because both people actually wrote the code and are
agreeing to the DCO (and more generally claiming responsibility/blame
for the patch), and gotten complaints from maintainers that it "doesn't
reflect the chain of git trees the patch went through" or similar.
Which seems ridiculous.

- Josh Triplett

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

[Jason Cooper]

On Fri, Jul 10, 2015 at 02:00:40PM -0700, josh@joshtriplett.org wrote:
> On Fri, Jul 10, 2015 at 06:58:00PM +0000, Jason Cooper wrote:
> > I've personally seen it, and I don't think I'm alone.  It seems to follow
> > a pattern of:
> > 
> >  - Manager/HR thinks counting tags is a useful metric (#!@$ laziness).
> >  - tag-count becomes an evaluation item.
> >  - Pay raises are affected.
> >  - patch submitters do the obvious.
> >  - maintainers weep and die a little inside.
> > 
> > The easy ones to spot are multiple-S-o-bs.  I've actually been told "No,
> > he didn't write any code, I was just trying to help him out."
> 
> On the flip side, I've submitted patches with two Signed-off-by tags
> specifically because both people actually wrote the code and are
> agreeing to the DCO (and more generally claiming responsibility/blame
> for the patch), 

This seems perfectly sane to me.

> and gotten complaints from maintainers that it "doesn't
> reflect the chain of git trees the patch went through" or similar.
> Which seems ridiculous.

Agreed.

thx,

Jason.

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

[Guenter Roeck]

On Thu, Jul 09, 2015 at 12:47:34PM -0700, Darren Hart wrote:
> On Thu, Jul 09, 2015 at 12:23:20PM -0700, Guenter Roeck wrote:
> > On Thu, Jul 09, 2015 at 11:28:28AM -0700, Frank Rowand wrote:
> > > On 7/8/2015 9:06 PM, Michael Ellerman wrote:
> > > > On Wed, 2015-07-08 at 13:08 -0700, Guenter Roeck wrote:
> > > >> On 07/08/2015 11:53 AM, Steven Rostedt wrote:
> > > >>> On Wed, 08 Jul 2015 09:00:32 +0100
> > > >>> jic23@jic23.retrosnub.co.uk wrote:
> > > >>>
> > > >>>
> > > >>>>> We can alter that somewhat.  We used to run a Maintainers lottery for
> > > >>>>> the kernel summit ... we could instead offer places based on the number
> > > >>>>> of Reviewed-by: tags ... we have all the machinery to calculate that.  I
> > > >>>>> know an invitation to the kernel summit isn't a huge incentive, but it's
> > > >>>>> a useful one.
> > > >>>>
> > > >>>> Sounds like a good idea to me, though it would only effect a tiny
> > > >>>> percentage of our reviewers.  I suppose publishing a short list of the top
> > > >>>> n% of reviewers from which the lottery runs might give some
> > > >>>> recognition.
> > > >>>>
> > > >>>
> > > >>> I personally don't trust a Reviewed-by tag much, as I sometimes see
> > > >>> them appear without any comments.
> > > 
> > > I don't expect my Reviewed-by tag with no extra comments to carry much weight
> > > if I send it to a maintainer who does not know me.
> > > 
> > > But if I have a history of good reviews to a specific maintainer, then why
> > > should I have to add a message that says: Yes, I really, really did review
> > > the patch.  I truly mean that the patch "has been reviewed and found acceptable
> > > according to the Reviewer's Statement" as listed in SubmittingPatches.
> > > 
> > > And I read Steve's qualification of "don't trust ... _much_" as being
> > > consistent with what I am saying, so I'm fine with that.  The point I
> > > want to make is that a Reviewed-by tag without comments should not
> > > always be assumed to be without meaning or value.
> > > 
> > Absolutely agree.
> > 
> > It looks like we have yet another set of diverging maintainer expectations.
> > Some maintainers will expect me to provide an extra comment, which I'll
> > have to phrase carefully to avoid it being misinterpreted as "I just
> > glanced at the code and didn't find an obvious issue with it".
> > Others will get annoyed at me providing the extra comment.
> 
> Why would a couple lines of context be any harder to deal with than all the
> meta-data that comes along with an email including a Reviewed-by?
> 

No, but that isn't the point. I use patchwork, which takes care of
automatically adding all tags and removing the clutter around it,
so I don't really care one way or another.

I neither expect reviewers to provide additional comments, nor do I mind
if they do provide such comments. I see comments as beneficial on complex
reviews, or if a reviewer had an earlier concern which was addressed by
feedback from the submitter but did not result in code changes. Overall
comments may be either positive or neutral to me, depending on the context.
But a Reviewed-by: tag does not have less value to me just because there
is no comment associated with it.  

I _do_ expect reviewers to understand the statement they are making by
providing a Reviewed-by: tag, just as I expect patch submitters to
understand the statement they are making with their Signed-off: tag.

The point I am making, which has been confirmed by this e-mail exchange,
is that reviewers have to be careful of yet another detail when providing
feedback on a patch. Some, like you and Stephen, may expect me to provide
some feedback around a Reviewed-by: tag, while others may get annoyed
at me for providing such additional feedback.

Guenter

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

[Darren Hart]

On Thu, Jul 09, 2015 at 01:23:25PM -0700, Guenter Roeck wrote:
> On Thu, Jul 09, 2015 at 12:47:34PM -0700, Darren Hart wrote:
> > On Thu, Jul 09, 2015 at 12:23:20PM -0700, Guenter Roeck wrote:
> > > On Thu, Jul 09, 2015 at 11:28:28AM -0700, Frank Rowand wrote:
> > > > On 7/8/2015 9:06 PM, Michael Ellerman wrote:
> > > > > On Wed, 2015-07-08 at 13:08 -0700, Guenter Roeck wrote:
> > > > >> On 07/08/2015 11:53 AM, Steven Rostedt wrote:
> > > > >>> On Wed, 08 Jul 2015 09:00:32 +0100
> > > > >>> jic23@jic23.retrosnub.co.uk wrote:
> > > > >>>
> > > > >>>
> > > > >>>>> We can alter that somewhat.  We used to run a Maintainers lottery for
> > > > >>>>> the kernel summit ... we could instead offer places based on the number
> > > > >>>>> of Reviewed-by: tags ... we have all the machinery to calculate that.  I
> > > > >>>>> know an invitation to the kernel summit isn't a huge incentive, but it's
> > > > >>>>> a useful one.
> > > > >>>>
> > > > >>>> Sounds like a good idea to me, though it would only effect a tiny
> > > > >>>> percentage of our reviewers.  I suppose publishing a short list of the top
> > > > >>>> n% of reviewers from which the lottery runs might give some
> > > > >>>> recognition.
> > > > >>>>
> > > > >>>
> > > > >>> I personally don't trust a Reviewed-by tag much, as I sometimes see
> > > > >>> them appear without any comments.
> > > > 
> > > > I don't expect my Reviewed-by tag with no extra comments to carry much weight
> > > > if I send it to a maintainer who does not know me.
> > > > 
> > > > But if I have a history of good reviews to a specific maintainer, then why
> > > > should I have to add a message that says: Yes, I really, really did review
> > > > the patch.  I truly mean that the patch "has been reviewed and found acceptable
> > > > according to the Reviewer's Statement" as listed in SubmittingPatches.
> > > > 
> > > > And I read Steve's qualification of "don't trust ... _much_" as being
> > > > consistent with what I am saying, so I'm fine with that.  The point I
> > > > want to make is that a Reviewed-by tag without comments should not
> > > > always be assumed to be without meaning or value.
> > > > 
> > > Absolutely agree.
> > > 
> > > It looks like we have yet another set of diverging maintainer expectations.
> > > Some maintainers will expect me to provide an extra comment, which I'll
> > > have to phrase carefully to avoid it being misinterpreted as "I just
> > > glanced at the code and didn't find an obvious issue with it".
> > > Others will get annoyed at me providing the extra comment.
> > 
> > Why would a couple lines of context be any harder to deal with than all the
> > meta-data that comes along with an email including a Reviewed-by?
> > 
> 
> No, but that isn't the point. I use patchwork, which takes care of
> automatically adding all tags and removing the clutter around it,
> so I don't really care one way or another.
> 
> I neither expect reviewers to provide additional comments, nor do I mind
> if they do provide such comments. I see comments as beneficial on complex
> reviews, or if a reviewer had an earlier concern which was addressed by
> feedback from the submitter but did not result in code changes. Overall
> comments may be either positive or neutral to me, depending on the context.
> But a Reviewed-by: tag does not have less value to me just because there
> is no comment associated with it.  
> 
> I _do_ expect reviewers to understand the statement they are making by
> providing a Reviewed-by: tag, just as I expect patch submitters to
> understand the statement they are making with their Signed-off: tag.
> 
> The point I am making, which has been confirmed by this e-mail exchange,
> is that reviewers have to be careful of yet another detail when providing
> feedback on a patch. Some, like you and Stephen, may expect me to provide
> some feedback around a Reviewed-by: tag, while others may get annoyed
> at me for providing such additional feedback.
> 
> Guenter
> 

I do agree that a plain reviewed-by from an established contributor adds
value without additional comment.

Stepping back a bit though, We are talking about Recruitment, which implies new
people. In my opinion, encouraging new people to provide context is a good idea.

-- 
Darren Hart
Intel Open Source Technology Center

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1307 bytes --]

On Thu, Jul 09, 2015 at 12:47:34PM -0700, Darren Hart wrote:
> On Thu, Jul 09, 2015 at 12:23:20PM -0700, Guenter Roeck wrote:

> > It looks like we have yet another set of diverging maintainer expectations.
> > Some maintainers will expect me to provide an extra comment, which I'll
> > have to phrase carefully to avoid it being misinterpreted as "I just
> > glanced at the code and didn't find an obvious issue with it".
> > Others will get annoyed at me providing the extra comment.

I guess I'm one of those you're thinking about here - annoyed is very
strong, it's definitely not an active problem.  If it's saying something
out of the ordinary then it's adding value but a lot of patches really
are just pretty routine.

> Why would a couple lines of context be any harder to deal with than all the
> meta-data that comes along with an email including a Reviewed-by?

Personally it's the difference between one line of new text that can be
read by pattern matching and new text which requires looking at the
actual words.  It's not the end of the world (and I'd go so far as to
say it's actually a good thing if it's adding something) but in cases
where I've got a big stack of things I've already looked at where I'm
waiting for acks it does help make things a bit smoother.  

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Darren Hart]

On Thu, Jul 09, 2015 at 02:06:38PM +1000, Michael Ellerman wrote:
> On Wed, 2015-07-08 at 13:08 -0700, Guenter Roeck wrote:
> > On 07/08/2015 11:53 AM, Steven Rostedt wrote:
> > > On Wed, 08 Jul 2015 09:00:32 +0100
> > > jic23@jic23.retrosnub.co.uk wrote:
> > >
> > >
> > >>> We can alter that somewhat.  We used to run a Maintainers lottery for
> > >>> the kernel summit ... we could instead offer places based on the number
> > >>> of Reviewed-by: tags ... we have all the machinery to calculate that.  I
> > >>> know an invitation to the kernel summit isn't a huge incentive, but it's
> > >>> a useful one.
> > >>
> > >> Sounds like a good idea to me, though it would only effect a tiny
> > >> percentage of our reviewers.  I suppose publishing a short list of the top
> > >> n% of reviewers from which the lottery runs might give some
> > >> recognition.
> > >>
> > >
> > > I personally don't trust a Reviewed-by tag much, as I sometimes see
> > > them appear without any comments.
> > >
> > 
> > Except for the following, they are always reliable and can be trusted.
> > 
> > Reviewed-by: Edsel Murphy <edsel@murphy.com>
> > 
> > Seriously, it does happen that I send Reviewed-by: or Acked-by: feedback if
> > a patch is just fine as-is. What do you expect the reviewer to do in such
> > a case ?
> 
> There's almost always something you can say.
> 
> Even if it's a trivial patch, eg. a spelling fix, as the reviewer you should be
> confirming that only the spelling fix happened, ie. no other changes slipped
> into the diff. And so you can say that.
> 
> If it's more complex than a spelling fix then there's usually something you can
> comment on.
> 
> There might be times when all you can say is "Yep, logic looks right" which
> might seem redundant, but personally I'd prefer to see that than just a plain
> Reviewed-by.

Agreed. I have this same conversation about commit messages. I don't care if
it's a whitespace fix, if it is worth patching, building, testing, and
submitting, it is worth writing a sentence about why you did it and what it's
for. The same applies to a review. What did you confirm? Did you build it? Run
checkpatch or some other static analysis? I think I'm also guilty of a one-line
review now and then, but I'll be sure to include detail in the future.

-- 
Darren Hart
Intel Open Source Technology Center

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

[Steven Rostedt]

On Thu, 9 Jul 2015 12:44:56 -0700
Darren Hart <dvhart@infradead.org> wrote:

> Agreed. I have this same conversation about commit messages. I don't care if
> it's a whitespace fix, if it is worth patching, building, testing, and
> submitting, it is worth writing a sentence about why you did it and what it's
> for. The same applies to a review. What did you confirm? Did you build it? Run
> checkpatch or some other static analysis? I think I'm also guilty of a one-line
> review now and then, but I'll be sure to include detail in the future.
> 

Very good point.

Again, not talking about regular people that a maintainer knows well.
But a Reviewed-by tag could at least also add what the reviewer did to
add it. "I examined the entire patch, and found nothing wrong with it",
is an acceptable comment. So is, "I looked at the patch and even built
and booted it. Looks good".

Again, I have a few people I ask to review patches, and just them
replying with "Reviewed-by" is good enough for me. Because I know them
well and know what they usually do when they do a review. I don't need
them to be constantly telling me what they did.

-- Steve

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

[Darren Hart]

On Wed, Jul 08, 2015 at 02:53:15PM -0400, Steven Rostedt wrote:
> On Wed, 08 Jul 2015 09:00:32 +0100
> jic23@jic23.retrosnub.co.uk wrote:
> 
> 
> > > We can alter that somewhat.  We used to run a Maintainers lottery for
> > > the kernel summit ... we could instead offer places based on the number
> > > of Reviewed-by: tags ... we have all the machinery to calculate that.  I
> > > know an invitation to the kernel summit isn't a huge incentive, but it's
> > > a useful one.
> > 
> > Sounds like a good idea to me, though it would only effect a tiny
> > percentage of our reviewers.  I suppose publishing a short list of the top 
> > n% of reviewers from which the lottery runs might give some
> > recognition. 
> > 
> 
> I personally don't trust a Reviewed-by tag much, as I sometimes see
> them appear without any comments.
> 
> I was thinking of writing a perl script that would read my LKML archive
> and somewhat intelligently looking at people who replied to patches,
> that also has snippets of the patch in the reply, and counting them. I
> think that would be a more accurate use of real reviewers than just the
> Reviewed-by tag.

Agreed. Unless there is commentary accompanying the review, it doesn't add a
lot. While the nod of approval builds incremental confidence, the true measure
of a review is a resulting change to the patch for the better. Of course, a good
review takes the same amount of time regardless of if a change is required.

-- 
Darren Hart
Intel Open Source Technology Center

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

[Dmitry Torokhov]

On Thu, Jul 09, 2015 at 12:39:51PM -0700, Darren Hart wrote:
> On Wed, Jul 08, 2015 at 02:53:15PM -0400, Steven Rostedt wrote:
> > On Wed, 08 Jul 2015 09:00:32 +0100
> > jic23@jic23.retrosnub.co.uk wrote:
> > 
> > 
> > > > We can alter that somewhat.  We used to run a Maintainers lottery for
> > > > the kernel summit ... we could instead offer places based on the number
> > > > of Reviewed-by: tags ... we have all the machinery to calculate that.  I
> > > > know an invitation to the kernel summit isn't a huge incentive, but it's
> > > > a useful one.
> > > 
> > > Sounds like a good idea to me, though it would only effect a tiny
> > > percentage of our reviewers.  I suppose publishing a short list of the top 
> > > n% of reviewers from which the lottery runs might give some
> > > recognition. 
> > > 
> > 
> > I personally don't trust a Reviewed-by tag much, as I sometimes see
> > them appear without any comments.
> > 
> > I was thinking of writing a perl script that would read my LKML archive
> > and somewhat intelligently looking at people who replied to patches,
> > that also has snippets of the patch in the reply, and counting them. I
> > think that would be a more accurate use of real reviewers than just the
> > Reviewed-by tag.
> 
> Agreed. Unless there is commentary accompanying the review, it doesn't add a
> lot.

No, that is not always true. If I see a naked "reviewed-by" from a
person who's been working on the subsystem quite a bit and shown a good
judgement it is enough for me. I do not need them to find something to
nitpick over so that there is "meat" to the review.

> While the nod of approval builds incremental confidence, the true measure
> of a review is a resulting change to the patch for the better. Of course, a good
> review takes the same amount of time regardless of if a change is required.

Thanks.

-- 
Dmitry

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

[Steven Rostedt]

On Thu, 9 Jul 2015 13:21:52 -0700
Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
 
> > Agreed. Unless there is commentary accompanying the review, it doesn't add a
> > lot.
> 
> No, that is not always true. If I see a naked "reviewed-by" from a
> person who's been working on the subsystem quite a bit and shown a good
> judgement it is enough for me. I do not need them to find something to
> nitpick over so that there is "meat" to the review.


And this is where the problem lies. Every review by tag is different,
and it really matters from who it's from. I've had people send me a
"Reviewed-by" tag that I had no idea who it is from, and with no
commentary. That to me is worthless.

But I've sent patches out and have asked people like Masami Hiramatsu
to review it, and if he returns just a "Reviewed-by" with no
commentary, I take that as a positive, and that he didn't find anything
wrong with what I wrote. And I gladly add that tag as it has meaning to
me.

It really does come down to the maintainer. They should only add a
Reviewed-by tag from someone they trust, or from someone that has given
them constructive criticisms for the patch. I really don't know how
strict maintainers of other subsystems are with regard to adding those
tags.

I personally don't add that tag unless I have done an extensive review
of the patch. I don't want some stupid bug come back to a patch that
has my Reviewed-by tag on it. But I have reviewed lots of patches where
I haven't put enough effort into adding a RB tag. Perhaps I should just
add "Looks-fine-to-me-by:" tag, stating I did a light review but not a
thorough one. ;-)

-- Steve

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

[Theodore Ts'o]

On Thu, Jul 09, 2015 at 01:21:52PM -0700, Dmitry Torokhov wrote:
> 
> No, that is not always true. If I see a naked "reviewed-by" from a
> person who's been working on the subsystem quite a bit and shown a good
> judgement it is enough for me. I do not need them to find something to
> nitpick over so that there is "meat" to the review.

Absolutely.  If I'm looking at a patch for ext4, and I see a bare
Reviewed-by: from Jan Kara, I treat that very differently compared to
a Reviewed-by: coming from someone like Nick Krause.

The challenge is if we are using a scheme that uses some kind of
automated counting of Reviewed-by lines, how do we make the system
smart enough so it counts the former, but not the latter?  Or worse,
*encourages* more of the latter, which just adds more noise which
actually increases the load on Maintainers, not decreases.

(Which is also my objection to people sending patches generated from
"checkpatch --file" runs.  Maybe it's fine in for staging code, but
for other subsystems, it basically just means there are more patches
that require review by someone clueful --- since sometimes "cleanup"
patches from trolls actually introduce bugs.)

						- Ted

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

[Rafael J. Wysocki]

On Thursday, July 09, 2015 08:14:11 PM Theodore Ts'o wrote:
> On Thu, Jul 09, 2015 at 01:21:52PM -0700, Dmitry Torokhov wrote:
> > 
> > No, that is not always true. If I see a naked "reviewed-by" from a
> > person who's been working on the subsystem quite a bit and shown a good
> > judgement it is enough for me. I do not need them to find something to
> > nitpick over so that there is "meat" to the review.
> 
> Absolutely.  If I'm looking at a patch for ext4, and I see a bare
> Reviewed-by: from Jan Kara, I treat that very differently compared to
> a Reviewed-by: coming from someone like Nick Krause.
> 
> The challenge is if we are using a scheme that uses some kind of
> automated counting of Reviewed-by lines, how do we make the system
> smart enough so it counts the former, but not the latter?  Or worse,
> *encourages* more of the latter, which just adds more noise which
> actually increases the load on Maintainers, not decreases.

The Reviewed-by: tags are added to commits by people who ckeck them in,
ie. maintainers.  They should be responsible for using those tags wisely.

If the maintainers exercise enough due dilligence in that area, as they do
with the SoB tags, it actually should be OK to collect and publish Reviewed-by:
statistics too.

> (Which is also my objection to people sending patches generated from
> "checkpatch --file" runs.  Maybe it's fine in for staging code, but
> for other subsystems, it basically just means there are more patches
> that require review by someone clueful --- since sometimes "cleanup"
> patches from trolls actually introduce bugs.)

Or mindless cleanups for that matter.  I completely agree here.

Thanks,
Rafael

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

[Darren Hart]

On Thu, Jul 09, 2015 at 08:14:11PM -0400, Theodore Ts'o wrote:
> On Thu, Jul 09, 2015 at 01:21:52PM -0700, Dmitry Torokhov wrote:
> > 
> > No, that is not always true. If I see a naked "reviewed-by" from a
> > person who's been working on the subsystem quite a bit and shown a good
> > judgement it is enough for me. I do not need them to find something to
> > nitpick over so that there is "meat" to the review.
> 
> Absolutely.  If I'm looking at a patch for ext4, and I see a bare
> Reviewed-by: from Jan Kara, I treat that very differently compared to
> a Reviewed-by: coming from someone like Nick Krause.
> 
> The challenge is if we are using a scheme that uses some kind of
> automated counting of Reviewed-by lines, how do we make the system
> smart enough so it counts the former, but not the latter?  Or worse,
> *encourages* more of the latter, which just adds more noise which
> actually increases the load on Maintainers, not decreases.

I suppose the scan should read the tags from what is committed, not from LKML,
then the maintainers are responsible to include only meaningful tags in the
commit history? You then of course run the risk of putting someone off by
ignoring their work - and I'd rather err in favor of the reviewer (false
positive).

-- 
Darren Hart
Intel Open Source Technology Center

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

[Julia Lawall]

On Thu, 9 Jul 2015, Theodore Ts'o wrote:

> On Thu, Jul 09, 2015 at 01:21:52PM -0700, Dmitry Torokhov wrote:
> >
> > No, that is not always true. If I see a naked "reviewed-by" from a
> > person who's been working on the subsystem quite a bit and shown a good
> > judgement it is enough for me. I do not need them to find something to
> > nitpick over so that there is "meat" to the review.
>
> Absolutely.  If I'm looking at a patch for ext4, and I see a bare
> Reviewed-by: from Jan Kara, I treat that very differently compared to
> a Reviewed-by: coming from someone like Nick Krause.
>
> The challenge is if we are using a scheme that uses some kind of
> automated counting of Reviewed-by lines, how do we make the system
> smart enough so it counts the former, but not the latter?

I guess it's possible using various features of what the person has done
in the past to devise a machine learning algorithm that could make this
distinction.

julia

> Or worse,
> *encourages* more of the latter, which just adds more noise which
> actually increases the load on Maintainers, not decreases.
>
> (Which is also my objection to people sending patches generated from
> "checkpatch --file" runs.  Maybe it's fine in for staging code, but
> for other subsystems, it basically just means there are more patches
> that require review by someone clueful --- since sometimes "cleanup"
> patches from trolls actually introduce bugs.)
>
> 						- Ted
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>

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

[Josh Poimboeuf]

On Wed, Jul 08, 2015 at 02:53:15PM -0400, Steven Rostedt wrote:
> I personally don't trust a Reviewed-by tag much, as I sometimes see
> them appear without any comments.
> 
> I was thinking of writing a perl script that would read my LKML archive
> and somewhat intelligently looking at people who replied to patches,
> that also has snippets of the patch in the reply, and counting them. I
> think that would be a more accurate use of real reviewers than just the
> Reviewed-by tag.

I'm relatively new to lkml so my perceptions might be skewed.  But it
seems to me that, for non-trivial patches, the Reviewed-by tag is pretty
much useless as a metric.  From what I can tell, the biggest problems
with relying on Reviewed-by to get meaningful statistics are:

1. It's self-reported by the reviewer.

   Maybe a reviewer gave some hugely valuable feedback in versions 1-4
   of the patch, but wasn't around to provide the Reviewed-by tag for
   the final v6.

   Or maybe they're just focused on the review, and forget or don't care
   to ask for credit for it at the time by adding a tag.

   Or maybe they're a maintainer who used Signed-off-by instead (but
   Signed-off-by doesn't necessarily imply a review).

   Also, as others have mentioned, it creates the ability to game the
   system by saying you've reviewed a patch when you really haven't.

2. It's too broad of a statement.  It requires the reviewer to make an
   official certification that they fully understand and approve of the
   *entire* patch.  That's certainly a useful statement, but:

   A reviewer might review only part of the patch, and provide some
   useful comments for just the part of the patch they reviewed.  But
   they don't want to take responsibility for saying, to quote Steven,
   "I took enough effort to understand every part of the patch as if I
   wrote it myself."

   Or maybe they didn't carefully review the patch, but instead added
   something valuable to the discussion which improved the patch in a
   future version.

   So it denies credit to all the other people who provided useful
   comments along the way.

Review comments such as "here's a problem with your code" or "have you
thought about doing this instead?" can often be more useful a comment
than "your code looks good".  Maybe it would be a good idea to
acknowledge those people who give valuable feedback, in all its forms.
Maybe a new tag would be useful?  Something which:

a) is reported by the patch author and/or maintainer, since they're in
   the best position to keep track of useful comments across versions;

   and

b) means something like "I'm grateful to this person for giving some
   valuable feedback".


-- 
Josh

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

[Davidlohr Bueso]

On Fri, 2015-07-10 at 13:14 -0500, Josh Poimboeuf wrote:
> On Wed, Jul 08, 2015 at 02:53:15PM -0400, Steven Rostedt wrote:
> > I personally don't trust a Reviewed-by tag much, as I sometimes see
> > them appear without any comments.
> > 
> > I was thinking of writing a perl script that would read my LKML archive
> > and somewhat intelligently looking at people who replied to patches,
> > that also has snippets of the patch in the reply, and counting them. I
> > think that would be a more accurate use of real reviewers than just the
> > Reviewed-by tag.
> 
> I'm relatively new to lkml so my perceptions might be skewed.  But it
> seems to me that, for non-trivial patches, the Reviewed-by tag is pretty
> much useless as a metric.  From what I can tell, the biggest problems
> with relying on Reviewed-by to get meaningful statistics are:
> 
> 1. It's self-reported by the reviewer.
> 
>    Maybe a reviewer gave some hugely valuable feedback in versions 1-4
>    of the patch, but wasn't around to provide the Reviewed-by tag for
>    the final v6.

Normally good maintainers pick up ack/review tags along the way when
they pickup the final patch.

> 
>    Or maybe they're just focused on the review, and forget or don't care
>    to ask for credit for it at the time by adding a tag.
> 
>    Or maybe they're a maintainer who used Signed-off-by instead (but
>    Signed-off-by doesn't necessarily imply a review).

At least at some level any patches picked up by a maintainer should at
least be compile tested and looked at any obvious issues -- when the
maintainer trusts other devs/submaintainers that did the more thorough
review process.

> 
>    Also, as others have mentioned, it creates the ability to game the
>    system by saying you've reviewed a patch when you really haven't.

The system can always be gamed.

> 
> 2. It's too broad of a statement.  It requires the reviewer to make an
>    official certification that they fully understand and approve of the
>    *entire* patch.  That's certainly a useful statement, but:
> 
>    A reviewer might review only part of the patch, and provide some
>    useful comments for just the part of the patch they reviewed.  But
>    they don't want to take responsibility for saying, to quote Steven,
>    "I took enough effort to understand every part of the patch as if I
>    wrote it myself."
> 
>    Or maybe they didn't carefully review the patch, but instead added
>    something valuable to the discussion which improved the patch in a
>    future version.
> 
>    So it denies credit to all the other people who provided useful
>    comments along the way.

Mentioning/thanking others that helped in any meaningful way is always a
good idea.

> 
> Review comments such as "here's a problem with your code" or "have you
> thought about doing this instead?" can often be more useful a comment
> than "your code looks good".  Maybe it would be a good idea to
> acknowledge those people who give valuable feedback, in all its forms.
> Maybe a new tag would be useful?  Something which:
> 
> a) is reported by the patch author and/or maintainer, since they're in
>    the best position to keep track of useful comments across versions;
> 
>    and
> 
> b) means something like "I'm grateful to this person for giving some
>    valuable feedback".

A tag for this? Nah.

Thanks,
Davidlohr

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

[Josh Poimboeuf]

On Fri, Jul 10, 2015 at 06:00:50PM -0700, Davidlohr Bueso wrote:
> On Fri, 2015-07-10 at 13:14 -0500, Josh Poimboeuf wrote:
> > On Wed, Jul 08, 2015 at 02:53:15PM -0400, Steven Rostedt wrote:
> > > I personally don't trust a Reviewed-by tag much, as I sometimes see
> > > them appear without any comments.
> > > 
> > > I was thinking of writing a perl script that would read my LKML archive
> > > and somewhat intelligently looking at people who replied to patches,
> > > that also has snippets of the patch in the reply, and counting them. I
> > > think that would be a more accurate use of real reviewers than just the
> > > Reviewed-by tag.
> > 
> > I'm relatively new to lkml so my perceptions might be skewed.  But it
> > seems to me that, for non-trivial patches, the Reviewed-by tag is pretty
> > much useless as a metric.  From what I can tell, the biggest problems
> > with relying on Reviewed-by to get meaningful statistics are:
> > 
> > 1. It's self-reported by the reviewer.
> > 
> >    Maybe a reviewer gave some hugely valuable feedback in versions 1-4
> >    of the patch, but wasn't around to provide the Reviewed-by tag for
> >    the final v6.
> 
> Normally good maintainers pick up ack/review tags along the way when
> they pickup the final patch.

A maintainer can't pick up the tag if the reviewer doesn't post it.

In this example the reviewer wouldn't have posted Reviewed-by because,
despite the fact that they did a thorough review, the patch still had
issues in its earlier versions.  The reviewer did a lot of work but
didn't get credit for it.

> >    Or maybe they're just focused on the review, and forget or don't
> >    care to ask for credit for it at the time by adding a tag.
> > 
> >    Or maybe they're a maintainer who used Signed-off-by instead (but
> >    Signed-off-by doesn't necessarily imply a review).
> 
> At least at some level any patches picked up by a maintainer should at
> least be compile tested and looked at any obvious issues -- when the
> maintainer trusts other devs/submaintainers that did the more thorough
> review process.

Right, as I said, Signed-off-by doesn't necessarily imply Reviewed-by.

So any review done by a maintainer who only adds Signed-off-by goes
uncredited.

> >    Also, as others have mentioned, it creates the ability to game the
> >    system by saying you've reviewed a patch when you really haven't.
> 
> The system can always be gamed.
> 
> > 
> > 2. It's too broad of a statement.  It requires the reviewer to make an
> >    official certification that they fully understand and approve of the
> >    *entire* patch.  That's certainly a useful statement, but:
> > 
> >    A reviewer might review only part of the patch, and provide some
> >    useful comments for just the part of the patch they reviewed.  But
> >    they don't want to take responsibility for saying, to quote Steven,
> >    "I took enough effort to understand every part of the patch as if I
> >    wrote it myself."
> > 
> >    Or maybe they didn't carefully review the patch, but instead added
> >    something valuable to the discussion which improved the patch in a
> >    future version.
> > 
> >    So it denies credit to all the other people who provided useful
> >    comments along the way.
> 
> Mentioning/thanking others that helped in any meaningful way is always a
> good idea.

Sure, but if you only thank them informally then their contribution
can't be quantified, which was one of the proposed goals of this
discussion.

> > Review comments such as "here's a problem with your code" or "have you
> > thought about doing this instead?" can often be more useful a comment
> > than "your code looks good".  Maybe it would be a good idea to
> > acknowledge those people who give valuable feedback, in all its forms.
> > Maybe a new tag would be useful?  Something which:
> > 
> > a) is reported by the patch author and/or maintainer, since they're in
> >    the best position to keep track of useful comments across versions;
> > 
> >    and
> > 
> > b) means something like "I'm grateful to this person for giving some
> >    valuable feedback".
> 
> A tag for this? Nah.
> 
> Thanks,
> Davidlohr
> 

-- 
Josh

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

[Josh Triplett]

On Sat, Jul 11, 2015 at 10:48:24PM -0500, Josh Poimboeuf wrote:
> On Fri, Jul 10, 2015 at 06:00:50PM -0700, Davidlohr Bueso wrote:
> > On Fri, 2015-07-10 at 13:14 -0500, Josh Poimboeuf wrote:
> > > On Wed, Jul 08, 2015 at 02:53:15PM -0400, Steven Rostedt wrote:
> > > > I personally don't trust a Reviewed-by tag much, as I sometimes see
> > > > them appear without any comments.
> > > > 
> > > > I was thinking of writing a perl script that would read my LKML archive
> > > > and somewhat intelligently looking at people who replied to patches,
> > > > that also has snippets of the patch in the reply, and counting them. I
> > > > think that would be a more accurate use of real reviewers than just the
> > > > Reviewed-by tag.
> > > 
> > > I'm relatively new to lkml so my perceptions might be skewed.  But it
> > > seems to me that, for non-trivial patches, the Reviewed-by tag is pretty
> > > much useless as a metric.  From what I can tell, the biggest problems
> > > with relying on Reviewed-by to get meaningful statistics are:
> > > 
> > > 1. It's self-reported by the reviewer.
> > > 
> > >    Maybe a reviewer gave some hugely valuable feedback in versions 1-4
> > >    of the patch, but wasn't around to provide the Reviewed-by tag for
> > >    the final v6.
> > 
> > Normally good maintainers pick up ack/review tags along the way when
> > they pickup the final patch.
> 
> A maintainer can't pick up the tag if the reviewer doesn't post it.
> 
> In this example the reviewer wouldn't have posted Reviewed-by because,
> despite the fact that they did a thorough review, the patch still had
> issues in its earlier versions.  The reviewer did a lot of work but
> didn't get credit for it.

And that's not always a bad thing.  Sometimes I review the previous
version of a patch, and then see that tag applied to a later version
that is substantially different from the version I reviewed; that makes
me uncomfortable.  I care less about getting credit for a review and
more about not having my Reviewed-by tag attached to something I didn't
review.  (Obviously, this is a fuzzy thing; for instance, if three
people note issues and offer a Reviewed-by with those issues fixed,
fixing all the issues and applying all three Reviewed-by tags seems
reasonable.)

- Josh Triplett

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

[Josh Poimboeuf]

On Sat, Jul 11, 2015 at 10:23:17PM -0700, Josh Triplett wrote:
> On Sat, Jul 11, 2015 at 10:48:24PM -0500, Josh Poimboeuf wrote:
> > On Fri, Jul 10, 2015 at 06:00:50PM -0700, Davidlohr Bueso wrote:
> > > On Fri, 2015-07-10 at 13:14 -0500, Josh Poimboeuf wrote:
> > > > On Wed, Jul 08, 2015 at 02:53:15PM -0400, Steven Rostedt wrote:
> > > > > I personally don't trust a Reviewed-by tag much, as I sometimes see
> > > > > them appear without any comments.
> > > > > 
> > > > > I was thinking of writing a perl script that would read my LKML archive
> > > > > and somewhat intelligently looking at people who replied to patches,
> > > > > that also has snippets of the patch in the reply, and counting them. I
> > > > > think that would be a more accurate use of real reviewers than just the
> > > > > Reviewed-by tag.
> > > > 
> > > > I'm relatively new to lkml so my perceptions might be skewed.  But it
> > > > seems to me that, for non-trivial patches, the Reviewed-by tag is pretty
> > > > much useless as a metric.  From what I can tell, the biggest problems
> > > > with relying on Reviewed-by to get meaningful statistics are:
> > > > 
> > > > 1. It's self-reported by the reviewer.
> > > > 
> > > >    Maybe a reviewer gave some hugely valuable feedback in versions 1-4
> > > >    of the patch, but wasn't around to provide the Reviewed-by tag for
> > > >    the final v6.
> > > 
> > > Normally good maintainers pick up ack/review tags along the way when
> > > they pickup the final patch.
> > 
> > A maintainer can't pick up the tag if the reviewer doesn't post it.
> > 
> > In this example the reviewer wouldn't have posted Reviewed-by because,
> > despite the fact that they did a thorough review, the patch still had
> > issues in its earlier versions.  The reviewer did a lot of work but
> > didn't get credit for it.
> 
> And that's not always a bad thing.  Sometimes I review the previous
> version of a patch, and then see that tag applied to a later version
> that is substantially different from the version I reviewed; that makes
> me uncomfortable.  I care less about getting credit for a review and
> more about not having my Reviewed-by tag attached to something I didn't
> review.

If our goal is to quantify the work of good reviewers, so that we can
shine a light on them and hopefully motivate them to do more review,
then I'd argue that having a reviewer doing a lot of work and not
getting credit for it *is* a bad thing.

I agree that the Reviewed-by tag doesn't apply here.  It communicates
patch approval, rather than review helpfulness.  That's why I proposed a
new tag from the patch author and/or maintainer.

-- 
Josh

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

[Dan Carpenter]

On Sun, Jul 12, 2015 at 07:28:23AM -0500, Josh Poimboeuf wrote:
> I agree that the Reviewed-by tag doesn't apply here.  It communicates
> patch approval, rather than review helpfulness.  That's why I proposed a
> new tag from the patch author and/or maintainer.

I've lobbied for:

With-Fixes-from: xxx

It would only be given for actual bug fixes and not for complaining
about the subject line, white space or spelling mistakes.

regards,
dan carpenter

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

[Jan Kara]

On Mon 13-07-15 17:20:47, Dan Carpenter wrote:
> On Sun, Jul 12, 2015 at 07:28:23AM -0500, Josh Poimboeuf wrote:
> > I agree that the Reviewed-by tag doesn't apply here.  It communicates
> > patch approval, rather than review helpfulness.  That's why I proposed a
> > new tag from the patch author and/or maintainer.
> 
> I've lobbied for:
> 
> With-Fixes-from: xxx
> 
> It would only be given for actual bug fixes and not for complaining
> about the subject line, white space or spelling mistakes.

This seems like overengineering to me. I usually give a credit in the changelog
if I find someone's contribution big enough. Also a persistent reviewer will
eventually get his credit via Reviewed-by :). So I don't think yet another
tag is really necessary.

									Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

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

[Dan Carpenter]

On Mon, Jul 13, 2015 at 04:33:31PM +0200, Jan Kara wrote:
> On Mon 13-07-15 17:20:47, Dan Carpenter wrote:
> > On Sun, Jul 12, 2015 at 07:28:23AM -0500, Josh Poimboeuf wrote:
> > > I agree that the Reviewed-by tag doesn't apply here.  It communicates
> > > patch approval, rather than review helpfulness.  That's why I proposed a
> > > new tag from the patch author and/or maintainer.
> > 
> > I've lobbied for:
> > 
> > With-Fixes-from: xxx
> > 
> > It would only be given for actual bug fixes and not for complaining
> > about the subject line, white space or spelling mistakes.
> 
> This seems like overengineering to me. I usually give a credit in the changelog
> if I find someone's contribution big enough. Also a persistent reviewer will
> eventually get his credit via Reviewed-by :). So I don't think yet another
> tag is really necessary.

I could get as many reviewed-by tags as I wanted...  I basically only
write reviewed-by tags as a way of being nice to people sending patches.

Lots of people give credit for fixes in the changlog like but it's more
common to leave it out.  Also it's not searchable.

This happened hours ago in staging.  Someone sent a buggy patch and
reviewers spotted the bug but no one got credit.

http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2015-July/072662.html
http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2015-July/072668.html

Imagine how special Patrick would feel if we gave him a nice
"With-fix-from: Patrick Farrell <paf@cray.com>" tag.  :)  Also the other
rule would be that only the first person to report the bug gets the
credit (Sorry, Sudip).  The next version of the patch had a process
problem which Sudip noticed as well but that still doesn't earn a
with-fix-from tag.

regards,
dan carpenter

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

[Jonathan Cameron]

On 13 July 2015 17:28:25 BST, Dan Carpenter <dan.carpenter@oracle.com> wrote:
>On Mon, Jul 13, 2015 at 04:33:31PM +0200, Jan Kara wrote:
>> On Mon 13-07-15 17:20:47, Dan Carpenter wrote:
>> > On Sun, Jul 12, 2015 at 07:28:23AM -0500, Josh Poimboeuf wrote:
>> > > I agree that the Reviewed-by tag doesn't apply here.  It
>communicates
>> > > patch approval, rather than review helpfulness.  That's why I
>proposed a
>> > > new tag from the patch author and/or maintainer.
>> > 
>> > I've lobbied for:
>> > 
>> > With-Fixes-from: xxx
>> > 
>> > It would only be given for actual bug fixes and not for complaining
>> > about the subject line, white space or spelling mistakes.
>> 
>> This seems like overengineering to me. I usually give a credit in the
>changelog
>> if I find someone's contribution big enough. Also a persistent
>reviewer will
>> eventually get his credit via Reviewed-by :). So I don't think yet
>another
>> tag is really necessary.
>
>I could get as many reviewed-by tags as I wanted...  I basically only
>write reviewed-by tags as a way of being nice to people sending
>patches.
>
>Lots of people give credit for fixes in the changlog like but it's more
>common to leave it out.  Also it's not searchable.
>
>This happened hours ago in staging.  Someone sent a buggy patch and
>reviewers spotted the bug but no one got credit.
>
>http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2015-July/072662.html
>http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2015-July/072668.html
>
>Imagine how special Patrick would feel if we gave him a nice
>"With-fix-from: Patrick Farrell <paf@cray.com>" tag.  :)  Also the
>other
>rule would be that only the first person to report the bug gets the
>credit (Sorry, Sudip).  The next version of the patch had a process
>problem which Sudip noticed as well but that still doesn't earn a
>with-fix-from tag.

I like this idea in principle. Not entirely sure if it will work perfectly in practice.

Likely that in high revision count series some earlier work will not get credit...
 Unless patch authors get to propose such tags as suggestions to the
 maintainer.  Preferably with description in the change log!  Guessing I am not the
 only maintainer who doesn't keep up with all the versions of some patches other
 than a quick controversy check!

>
>regards,
>dan carpenter
>
>_______________________________________________
>Ksummit-discuss mailing list
>Ksummit-discuss@lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

[Sudip Mukherjee]

On Mon, Jul 13, 2015 at 07:28:25PM +0300, Dan Carpenter wrote:
> On Mon, Jul 13, 2015 at 04:33:31PM +0200, Jan Kara wrote:
> > On Mon 13-07-15 17:20:47, Dan Carpenter wrote:
> > > On Sun, Jul 12, 2015 at 07:28:23AM -0500, Josh Poimboeuf wrote:
> 
> This happened hours ago in staging.  Someone sent a buggy patch and
> reviewers spotted the bug but no one got credit.
> 
> http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2015-July/072662.html
> http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2015-July/072668.html
> 
> Imagine how special Patrick would feel if we gave him a nice
> "With-fix-from: Patrick Farrell <paf@cray.com>" tag.  :)  Also the other
> rule would be that only the first person to report the bug gets the
> credit (Sorry, Sudip).
Doesn't matter. I am a volunteer and contributing here is not part of
my dayjob. I do it because I like doing it.
>The next version of the patch had a process
> problem which Sudip noticed as well but that still doesn't earn a
> with-fix-from tag.
Then will the first reviewer always get the credit? Suppose a hypothetial
situation where v1 is just having a bug like the one you mentioned,
reviewer X points that out so he gets "With-fix-from:", but v2 has a more
serious problem and results in build failure and reviewer Y points that out
and v3 is the final patch that is accepted. So now who will get
"With-fix-from:" ?

regards
sudip

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

[Jonathan Cameron]

On 14 July 2015 05:38:03 BST, Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
>On Mon, Jul 13, 2015 at 07:28:25PM +0300, Dan Carpenter wrote:
>> On Mon, Jul 13, 2015 at 04:33:31PM +0200, Jan Kara wrote:
>> > On Mon 13-07-15 17:20:47, Dan Carpenter wrote:
>> > > On Sun, Jul 12, 2015 at 07:28:23AM -0500, Josh Poimboeuf wrote:
>> 
>> This happened hours ago in staging.  Someone sent a buggy patch and
>> reviewers spotted the bug but no one got credit.
>> 
>>
>http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2015-July/072662.html
>>
>http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2015-July/072668.html
>> 
>> Imagine how special Patrick would feel if we gave him a nice
>> "With-fix-from: Patrick Farrell <paf@cray.com>" tag.  :)  Also the
>other
>> rule would be that only the first person to report the bug gets the
>> credit (Sorry, Sudip).
>Doesn't matter. I am a volunteer and contributing here is not part of
>my dayjob. I do it because I like doing it.
>>The next version of the patch had a process
>> problem which Sudip noticed as well but that still doesn't earn a
>> with-fix-from tag.
>Then will the first reviewer always get the credit? Suppose a
>hypothetial
>situation where v1 is just having a bug like the one you mentioned,
>reviewer X points that out so he gets "With-fix-from:", but v2 has a
>more
>serious problem and results in build failure and reviewer Y points that
>out
>and v3 is the final patch that is accepted. So now who will get
>"With-fix-from:" ?
Both surely. Different bug, different tag (though only one per bug finder)
>
>regards
>sudip

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

[Dan Carpenter]

On Tue, Jul 14, 2015 at 10:08:03AM +0530, Sudip Mukherjee wrote:
> >The next version of the patch had a process
> > problem which Sudip noticed as well but that still doesn't earn a
> > with-fix-from tag.
> Then will the first reviewer always get the credit? Suppose a hypothetial
> situation where v1 is just having a bug like the one you mentioned,
> reviewer X points that out so he gets "With-fix-from:", but v2 has a more
> serious problem and results in build failure and reviewer Y points that out
> and v3 is the final patch that is accepted. So now who will get
> "With-fix-from:" ?

No no.  Build fixes don't count...  Only runtime bugs.  But, yes, if
there are two bugs you give credit for both.

regards,
dan carpenter

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

[Greg KH]

On Tue, Jul 14, 2015 at 10:08:03AM +0530, Sudip Mukherjee wrote:
> On Mon, Jul 13, 2015 at 07:28:25PM +0300, Dan Carpenter wrote:
> > On Mon, Jul 13, 2015 at 04:33:31PM +0200, Jan Kara wrote:
> > > On Mon 13-07-15 17:20:47, Dan Carpenter wrote:
> > > > On Sun, Jul 12, 2015 at 07:28:23AM -0500, Josh Poimboeuf wrote:
> > 
> > This happened hours ago in staging.  Someone sent a buggy patch and
> > reviewers spotted the bug but no one got credit.
> > 
> > http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2015-July/072662.html
> > http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2015-July/072668.html
> > 
> > Imagine how special Patrick would feel if we gave him a nice
> > "With-fix-from: Patrick Farrell <paf@cray.com>" tag.  :)  Also the other
> > rule would be that only the first person to report the bug gets the
> > credit (Sorry, Sudip).
> Doesn't matter. I am a volunteer and contributing here is not part of
> my dayjob. I do it because I like doing it.
> >The next version of the patch had a process
> > problem which Sudip noticed as well but that still doesn't earn a
> > with-fix-from tag.
> Then will the first reviewer always get the credit? Suppose a hypothetial
> situation where v1 is just having a bug like the one you mentioned,
> reviewer X points that out so he gets "With-fix-from:", but v2 has a more
> serious problem and results in build failure and reviewer Y points that out
> and v3 is the final patch that is accepted. So now who will get
> "With-fix-from:" ?

Or even more important, how in the world will the maintainer be adding
these tags in a simple manner?  It's a manual thing for me to do today,
which is a pain, and given that I have no "state" of previous patches
remembering what happened in previous versions, I don't know how I would
be expected to keep track of all of this.

So whatever scheme people come up with, please remember that it has to
be easy to actually implement...

thanks,

greg k-h

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

[Josh Poimboeuf]

On Tue, Jul 14, 2015 at 08:16:18AM -0700, Greg KH wrote:
> On Tue, Jul 14, 2015 at 10:08:03AM +0530, Sudip Mukherjee wrote:
> > On Mon, Jul 13, 2015 at 07:28:25PM +0300, Dan Carpenter wrote:
> > > On Mon, Jul 13, 2015 at 04:33:31PM +0200, Jan Kara wrote:
> > > > On Mon 13-07-15 17:20:47, Dan Carpenter wrote:
> > > > > On Sun, Jul 12, 2015 at 07:28:23AM -0500, Josh Poimboeuf wrote:
> > > 
> > > This happened hours ago in staging.  Someone sent a buggy patch and
> > > reviewers spotted the bug but no one got credit.
> > > 
> > > http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2015-July/072662.html
> > > http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2015-July/072668.html
> > > 
> > > Imagine how special Patrick would feel if we gave him a nice
> > > "With-fix-from: Patrick Farrell <paf@cray.com>" tag.  :)  Also the other
> > > rule would be that only the first person to report the bug gets the
> > > credit (Sorry, Sudip).
> > Doesn't matter. I am a volunteer and contributing here is not part of
> > my dayjob. I do it because I like doing it.
> > >The next version of the patch had a process
> > > problem which Sudip noticed as well but that still doesn't earn a
> > > with-fix-from tag.
> > Then will the first reviewer always get the credit? Suppose a hypothetial
> > situation where v1 is just having a bug like the one you mentioned,
> > reviewer X points that out so he gets "With-fix-from:", but v2 has a more
> > serious problem and results in build failure and reviewer Y points that out
> > and v3 is the final patch that is accepted. So now who will get
> > "With-fix-from:" ?
> 
> Or even more important, how in the world will the maintainer be adding
> these tags in a simple manner?  It's a manual thing for me to do today,
> which is a pain, and given that I have no "state" of previous patches
> remembering what happened in previous versions, I don't know how I would
> be expected to keep track of all of this.
> 
> So whatever scheme people come up with, please remember that it has to
> be easy to actually implement...

I think it would need to be up to the patch author, not the maintainer,
to add the tag.  The patch author already tracks the patch state from
version to version.  And the author is in the best position to know
which comments are helpful.

Also I'd suggest something a little broader than "With-fix-from".  Not
all useful comments are "fixes".  For example, an insightful question or
comment can sometimes result in big changes in the next version of the
patch.

-- 
Josh

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

[Dan Carpenter]

On Tue, Jul 14, 2015 at 10:52:49AM -0500, Josh Poimboeuf wrote:
> Also I'd suggest something a little broader than "With-fix-from".  Not
> all useful comments are "fixes".  For example, an insightful question or
> comment can sometimes result in big changes in the next version of the
> patch.

I wouldn't want it to be too broad.  Sending complaints about style
issues is its own reward.  Painting the woodshed etc.

regards,
dan carpenter

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

[Dan Carpenter]

On Tue, Jul 14, 2015 at 08:16:18AM -0700, Greg KH wrote:
> Or even more important, how in the world will the maintainer be adding
> these tags in a simple manner?  It's a manual thing for me to do today,
> which is a pain, and given that I have no "state" of previous patches
> remembering what happened in previous versions, I don't know how I would
> be expected to keep track of all of this.
> 
> So whatever scheme people come up with, please remember that it has to
> be easy to actually implement...

It's like Reported-by: the patch sender adds it when they write the
patch (re-write it in this case).

regards,
dan carpenter

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

[Steven Rostedt]

On Sat, 11 Jul 2015 22:48:24 -0500
Josh Poimboeuf <jpoimboe@redhat.com> wrote:

> Right, as I said, Signed-off-by doesn't necessarily imply Reviewed-by.
> 
> So any review done by a maintainer who only adds Signed-off-by goes
> uncredited.
> 

A Signed-off-by sure as well better mean a reviewed by! It holds a much
heavier meaning to the patch than a Reviewed-by does.

A Signed-off-by means that you are responsible for that patch. Even if
you don't necessarily understand the patch (like a high level
maintainer pulling in patches for low level hardware that the
maintainer doesn't fully understand), you should review it as much as
you can before adding an SoB to it. Otherwise you are not doing your
job.

And regardless, there's more weight for "credit" to Signed-off-by's
than for Reviewed-by's anyway. So much so, that my own scripts for
analysis ignores all other tags for anyone with a Signed-off-by
attached to a commit.

-- Steve

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

[Jason Cooper]

On Wed, Jul 08, 2015 at 01:21:40AM +0200, Peter Huewe wrote:
> Hi,
> 
> In order to continue our traditions I would like to propose again the topic of 
> recruitment, but this time not only limiting to the hobbyists market.

Agreed.  I have a few fresh thoughts on this area.  Not necessarily good
ones, but at least fresh. :-P

> We are definitely short on reviewers and thus have mostly overloaded 
> maintainers.

Ack.

> For testers it's usually even worse - how many patches are actually tested?
> Judging from what I read on LKML not that many.
> 
> So we should definitely discuss:
> - how can we encourage hobbyists to become regular contributors
> -- how to keep people interested, the drop-out rates are huge.

Here we need to have the correct mindset.  Kernel development is hard,
detailed work.  It's very rewarding, but simply put, most people aren't
cut out to do it.  I view the dropout rate as a *good* thing.  It's a
_selection_ process more than a education/training process.

With most of the hard jobs in life, take a look at the
training/education program, and you'll see it:  80% drop out rate?
That's selection.  Kernel work is one of those 'hard jobs'.

This is important to realize because it changes how we view recruitment.
We shouldn't be trying to keep everybody we recruit.  Rather, we should
be giving more people trial runs and see how they work out as they learn
the process.

iow, if an 80% drop out rate gives us the caliber of dev we need for the
long term health of the community, then it's a numbers game.  Say we saw
40 new people last year, which turned into 8 regular contributors.  Now
we want to double that.  We can lower the standard to get 16 out
of 40, yuck.  Or, we can outreach to 80 for trial runs, and get 16.

The discussion, I think, would revolve around: Am I smoking crack, or
does everyone agree with this view?  How can we create slots for
newcomers to contribute real changes?  Where do we reach out to for
candidates?  And, how do we quantify success or failure at some point in
the future?

> - encourage regular contributors to become reviewers and testers
> - reviewers to become co-maintainers and finally maintainers (once the 
> original maintainer is used up or moves up/on)

heh.  'used up' :-)

> From the 4.1 kernel report by jon corbet:
> "over 60% of the changes going into this kernel passed through the hands of 
> developers working for just five companies. This concentration reflects a 
> simple fact: while many companies are willing to support developers working on 
> specific tasks, the number of companies supporting subsystem maintainers is 
> far smaller. Subsystem maintainership is also, increasingly, not a job for 
> volunteer developers.."

Well, I disagree.  Not because I think Jon is wrong, but because we need
to bring in new blood *somewhere*.  co-maintainer/reviewer is one of
many possibilities.  If we don't have enough slots for newcomers
(especially on a trial basis), that's our fault.

I think it's also worth noting how many of those kernel developers
started out as hobbyist/volunteers.  The truth is, once you've been
around a few cycles as a hobbyist/volunteer, job offers come out of
nowhere.  So a statistic I'd love to see is the percentage of
conversions.

> -> How do we get companies to actively sponsor subsystem maintainership - if 
> only at driver or subsubsystem level.
> e.g.: I unfortunately failed at that with my company :/

meh, companies are fickle.  I think it's enough for them to be paying a
salary of a kernel dev/maintainer.  It's a cost they can quantify the
benefits of.  If a company does a Crazy Ivan [1], then the kernel dev
goes to work someplace else.  iow, it's the human that matters and can
be relied on, not the company.

> Also I would be interested in:
> - What are the effects of the Eudyptula Challenge? how many people are still 
> actively contributing (more than whitespace changes)

If the Eudyptula folks have statistics, I'd love to see them.

> Nominations:
> Jason Cooper           (auto-nominated), last years 'speaker'

I think it was the year before last, I couldn't make it last year. :-(

thx,

Jason.

[1] https://en.wikipedia.org/wiki/Crazy_Ivan (rapid, unexpected course
    changes)

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

[Peter Huewe]

Hey Jason,

> > For testers it's usually even worse - how many patches are actually tested?
> > Judging from what I read on LKML not that many.
> >
> > So we should definitely discuss:
> > - how can we encourage hobbyists to become regular contributors
> > -- how to keep people interested, the drop-out rates are huge.
> 
> Here we need to have the correct mindset. Kernel development is hard,
> detailed work. It's very rewarding, but simply put, most people aren't
> cut out to do it. I view the dropout rate as a *good* thing. It's a
> _selection_ process more than a education/training process.
> 
> With most of the hard jobs in life, take a look at the
> training/education program, and you'll see it: 80% drop out rate?
> That's selection. Kernel work is one of those 'hard jobs'.
> 
> This is important to realize because it changes how we view recruitment.
> We shouldn't be trying to keep everybody we recruit. Rather, we should
> be giving more people trial runs and see how they work out as they learn
> the process.
> 
> iow, if an 80% drop out rate gives us the caliber of dev we need for the
> long term health of the community, then it's a numbers game. Say we saw
> 40 new people last year, which turned into 8 regular contributors. Now
> we want to double that. We can lower the standard to get 16 out
> of 40, yuck. Or, we can outreach to 80 for trial runs, and get 16.

I think that's an interesting take on the topic - although I'm not 100% whether I agree with everything.
I agree that our goal is not to lower the standards, and also using more "trial runs".

However high standards should not be the reason to drive people away --
and especially not the reason not to keep good people interested.

Not only the bad people drop out, I've seen quite a lot of good devs vanish for good - and these should be the ones we also should try to keep - especially since I'm not sure whether we can allow such high drop out rates over a long time.


> ... but because we need
> to bring in new blood *somewhere*. co-maintainer/reviewer is one of
> many possibilities. If we don't have enough slots for newcomers
> (especially on a trial basis), that's our fault.

Agreed.


Interesting discussion about this topic - thanks for your opinion!

Thanks,
Peter

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

[Jason Cooper]

On Wed, Jul 08, 2015 at 09:29:57PM +0200, Peter Huewe wrote:
> > > For testers it's usually even worse - how many patches are actually tested?
> > > Judging from what I read on LKML not that many.
> > >
> > > So we should definitely discuss:
> > > - how can we encourage hobbyists to become regular contributors
> > > -- how to keep people interested, the drop-out rates are huge.
> > 
> > Here we need to have the correct mindset. Kernel development is hard,
> > detailed work. It's very rewarding, but simply put, most people aren't
> > cut out to do it. I view the dropout rate as a *good* thing. It's a
> > _selection_ process more than a education/training process.
> > 
> > With most of the hard jobs in life, take a look at the
> > training/education program, and you'll see it: 80% drop out rate?
> > That's selection. Kernel work is one of those 'hard jobs'.
> > 
> > This is important to realize because it changes how we view recruitment.
> > We shouldn't be trying to keep everybody we recruit. Rather, we should
> > be giving more people trial runs and see how they work out as they learn
> > the process.
> > 
> > iow, if an 80% drop out rate gives us the caliber of dev we need for the
> > long term health of the community, then it's a numbers game. Say we saw
> > 40 new people last year, which turned into 8 regular contributors. Now
> > we want to double that. We can lower the standard to get 16 out
> > of 40, yuck. Or, we can outreach to 80 for trial runs, and get 16.
> 
> I think that's an interesting take on the topic - although I'm not
> 100% whether I agree with everything.  I agree that our goal is not to
> lower the standards, and also using more "trial runs".
> 
> However high standards should not be the reason to drive people away --
> and especially not the reason not to keep good people interested.

Sure, I'm not suggesting anything like testing or anything formal.
Merely that everyone understand there's an attrition rate, and that's
*ok*.

Recruitment, imo, isn't about trying to keep everyone that tries.
Rather it's about opening the doors and providing real opportunities for
more people to contribute.

> Not only the bad people drop out, I've seen quite a lot of good devs
> vanish for good - and these should be the ones we also should try to
> keep - especially since I'm not sure whether we can allow such high
> drop out rates over a long time.

I'd love to hear some specific examples, links to email threads so we
can quantify this.  I suspect a lot of it is: "I scratched the itch,
and didn't have anything else I wanted to add. Then daily life took me
away."

Which is the hard part about qualified people.  They're busy. :-)

Perhaps this can help direct the outreach portion.  Should we focus on
students who have stretches of downtime?  That certainly has pluses and
minuses.

thx,

Jason.

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

[Rafael J. Wysocki]

On Wednesday, July 08, 2015 10:18:36 PM Jason Cooper wrote:
> On Wed, Jul 08, 2015 at 09:29:57PM +0200, Peter Huewe wrote:
> > > > For testers it's usually even worse - how many patches are actually tested?
> > > > Judging from what I read on LKML not that many.
> > > >
> > > > So we should definitely discuss:
> > > > - how can we encourage hobbyists to become regular contributors
> > > > -- how to keep people interested, the drop-out rates are huge.
> > > 
> > > Here we need to have the correct mindset. Kernel development is hard,
> > > detailed work. It's very rewarding, but simply put, most people aren't
> > > cut out to do it. I view the dropout rate as a *good* thing. It's a
> > > _selection_ process more than a education/training process.
> > > 
> > > With most of the hard jobs in life, take a look at the
> > > training/education program, and you'll see it: 80% drop out rate?
> > > That's selection. Kernel work is one of those 'hard jobs'.
> > > 
> > > This is important to realize because it changes how we view recruitment.
> > > We shouldn't be trying to keep everybody we recruit. Rather, we should
> > > be giving more people trial runs and see how they work out as they learn
> > > the process.
> > > 
> > > iow, if an 80% drop out rate gives us the caliber of dev we need for the
> > > long term health of the community, then it's a numbers game. Say we saw
> > > 40 new people last year, which turned into 8 regular contributors. Now
> > > we want to double that. We can lower the standard to get 16 out
> > > of 40, yuck. Or, we can outreach to 80 for trial runs, and get 16.
> > 
> > I think that's an interesting take on the topic - although I'm not
> > 100% whether I agree with everything.  I agree that our goal is not to
> > lower the standards, and also using more "trial runs".
> > 
> > However high standards should not be the reason to drive people away --
> > and especially not the reason not to keep good people interested.
> 
> Sure, I'm not suggesting anything like testing or anything formal.
> Merely that everyone understand there's an attrition rate, and that's
> *ok*.
> 
> Recruitment, imo, isn't about trying to keep everyone that tries.
> Rather it's about opening the doors and providing real opportunities for
> more people to contribute.

The opportunities are there, but in addition to the opportunities themselves
people need some incentives to use them.  It's all about their time which
they can spend in many ways, some of them more rewarding than others.

If they don't have an incentive, an opportunity itself may not be sufficient.

Thanks,
Rafael

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

[Laurent Pinchart]

On Thursday 09 July 2015 01:09:00 Rafael J. Wysocki wrote:
> On Wednesday, July 08, 2015 10:18:36 PM Jason Cooper wrote:
> > On Wed, Jul 08, 2015 at 09:29:57PM +0200, Peter Huewe wrote:
> > > > > For testers it's usually even worse - how many patches are actually
> > > > > tested? Judging from what I read on LKML not that many.
> > > > > 
> > > > > So we should definitely discuss:
> > > > > - how can we encourage hobbyists to become regular contributors
> > > > > -- how to keep people interested, the drop-out rates are huge.
> > > > 
> > > > Here we need to have the correct mindset. Kernel development is hard,
> > > > detailed work. It's very rewarding, but simply put, most people aren't
> > > > cut out to do it. I view the dropout rate as a *good* thing. It's a
> > > > _selection_ process more than a education/training process.
> > > > 
> > > > With most of the hard jobs in life, take a look at the
> > > > training/education program, and you'll see it: 80% drop out rate?
> > > > That's selection. Kernel work is one of those 'hard jobs'.
> > > > 
> > > > This is important to realize because it changes how we view
> > > > recruitment. We shouldn't be trying to keep everybody we recruit.
> > > > Rather, we should be giving more people trial runs and see how they
> > > > work out as they learn the process.
> > > > 
> > > > iow, if an 80% drop out rate gives us the caliber of dev we need for
> > > > the long term health of the community, then it's a numbers game. Say
> > > > we saw 40 new people last year, which turned into 8 regular
> > > > contributors. Now we want to double that. We can lower the standard to
> > > > get 16 out of 40, yuck. Or, we can outreach to 80 for trial runs, and
> > > > get 16.
> > > 
> > > I think that's an interesting take on the topic - although I'm not
> > > 100% whether I agree with everything.  I agree that our goal is not to
> > > lower the standards, and also using more "trial runs".
> > > 
> > > However high standards should not be the reason to drive people away --
> > > and especially not the reason not to keep good people interested.
> > 
> > Sure, I'm not suggesting anything like testing or anything formal.
> > Merely that everyone understand there's an attrition rate, and that's
> > *ok*.
> > 
> > Recruitment, imo, isn't about trying to keep everyone that tries.
> > Rather it's about opening the doors and providing real opportunities for
> > more people to contribute.
> 
> The opportunities are there, but in addition to the opportunities themselves
> people need some incentives to use them.  It's all about their time which
> they can spend in many ways, some of them more rewarding than others.
> 
> If they don't have an incentive, an opportunity itself may not be
> sufficient.

We also need to ensure that the opportunities can be identified as such by 
potential newcomers. As core kernel contributors it's easy for us to see the 
myriad of places where a newcomer could help, but it's much harder to do so 
when you have no experience with kernel development. Projects such as kernel 
janitors can help in that regard, but might not be enough.

There's also the issue that the kernel (and its developers) is often seen as a 
scary beast. I've heard too many programmers saying that contributing to the 
Linux kernel is too difficult, without having given it a try. We are seen as 
experts by the outside world. There's nothing wrong with that as such, but I 
believe we should work on broadcasting the message that newcomers should still 
give it a try.

-- 
Regards,

Laurent Pinchart

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

[John W. Linville]

On Wed, Jul 08, 2015 at 10:18:36PM +0000, Jason Cooper wrote:
> On Wed, Jul 08, 2015 at 09:29:57PM +0200, Peter Huewe wrote:

> > Not only the bad people drop out, I've seen quite a lot of good devs
> > vanish for good - and these should be the ones we also should try to
> > keep - especially since I'm not sure whether we can allow such high
> > drop out rates over a long time.
> 
> I'd love to hear some specific examples, links to email threads so we
> can quantify this.  I suspect a lot of it is: "I scratched the itch,
> and didn't have anything else I wanted to add. Then daily life took me
> away."
> 
> Which is the hard part about qualified people.  They're busy. :-)

Hopefully I'm not one of the "bad people", and I don't reallly
consider myself a "drop out".  But, I am someone that recently
(i.e. since the last KS) extracted himself from a maintainer role.
It seems like I should have something to add here...

I was the wireless maintainer for roughly seven years.  My situation
may be a bit unique in that I was always more of a "Linux guy" than a
"wireless guy", and most of the contributors were bigger experts in
the technology itself than I ever was.  That was fine for a while, but
over time that became less and less comfortable for me.  I've never
really heard anyone else express that sentiment, so this is probably
not a widespread concern...

The bigger concern was that while I was wrangling everyone else's
wireless patches, I had less and less time to do useful work elsewhere
in the kernel.  I definitely have heard other maintainers express
similar complaints, so this seems like a relatively common concern.
It would be good to find and promote maintainer organizations within
subsystems that are less likely to monopolize the mainainer's
development time.  Previously we have had discussions of how the
TIP tree is run, but I'm not sure that works well in every case.
Are there other working models for this?

I guess I'm suggesting the opposite of a "professional maintainer".
Some people thrive at being the center of a subsystem, as I did for
some time with wireless.  But burnout is a problem, and I think we
can limit some of that if somehow we can encourage less expansive
roles for individual maintainers.

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

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

[Guenter Roeck]

On Thu, Jul 09, 2015 at 11:09:38AM -0400, John W. Linville wrote:
> 
> I guess I'm suggesting the opposite of a "professional maintainer".
> Some people thrive at being the center of a subsystem, as I did for
> some time with wireless.  But burnout is a problem, and I think we
> can limit some of that if somehow we can encourage less expansive
> roles for individual maintainers.
> 

I hear you.

However, having individual maintainers with a high level of responsibility
and sense of ownership is one of the reasons why the Linux kernel
development model works as well as it does.

In a corporate environment, there is often no sense of ownership in a
specific piece of code. Quite often there _is_ no owner. As a result,
engineers don't feel the need to keep the code clean. They need to make
a change, they make it, they move on. The code gets more and more messy
and buggy over time, and no one really cares.

Whatever we change, we need to make sure this doesn't happen with the
Linux kernel, or it will fall apart quickly.

Guenter

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

[John W. Linville]

On Thu, Jul 09, 2015 at 10:45:35AM -0700, Guenter Roeck wrote:
> On Thu, Jul 09, 2015 at 11:09:38AM -0400, John W. Linville wrote:
> > 
> > I guess I'm suggesting the opposite of a "professional maintainer".
> > Some people thrive at being the center of a subsystem, as I did for
> > some time with wireless.  But burnout is a problem, and I think we
> > can limit some of that if somehow we can encourage less expansive
> > roles for individual maintainers.
> > 
> 
> I hear you.
> 
> However, having individual maintainers with a high level of responsibility
> and sense of ownership is one of the reasons why the Linux kernel
> development model works as well as it does.
> 
> In a corporate environment, there is often no sense of ownership in a
> specific piece of code. Quite often there _is_ no owner. As a result,
> engineers don't feel the need to keep the code clean. They need to make
> a change, they make it, they move on. The code gets more and more messy
> and buggy over time, and no one really cares.
> 
> Whatever we change, we need to make sure this doesn't happen with the
> Linux kernel, or it will fall apart quickly.

That is a good point, and I agree in principle.  I would _not_ want
to see any sort of "everyone can commit" model.  Still, I think there
might be ways to spread the maintainership load a bit wider.

I guess the suggestion becomes a deeper maintainer hierarchy where
maintainers only pull from sub-maintainers, and sub-maintainers handle
individual patches and smaller pull requests from contributors.
This is essentially the model used for wireless.  That introduces
the problem of increased patch merge latency, for which I have no
good suggestions...

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

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

[Jason Cooper]

On Thu, Jul 09, 2015 at 02:08:46PM -0400, John W. Linville wrote:
> I guess the suggestion becomes a deeper maintainer hierarchy where
> maintainers only pull from sub-maintainers, and sub-maintainers handle
> individual patches and smaller pull requests from contributors.
> This is essentially the model used for wireless.  That introduces
> the problem of increased patch merge latency, for which I have no
> good suggestions...

We haven't found that to be a problem in mvebu/arm-soc.  It does
increase the lead time a bit.  We stop accepting patches for the coming
merge window around -rc5/6 or so.  Judicious use of linux-next gives
sub-trees good coverage before landing in arm-soc.

I wouldn't advise adding another layer to that tree though.  Rather, as
I said in my other email, co-maintaining with lead rotation works well.

thx,

Jason.

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

[Olof Johansson]

On Thu, Jul 9, 2015 at 5:09 PM, John W. Linville <linville@tuxdriver.com> wrote:

> The bigger concern was that while I was wrangling everyone else's
> wireless patches, I had less and less time to do useful work elsewhere
> in the kernel.  I definitely have heard other maintainers express
> similar complaints, so this seems like a relatively common concern.
> It would be good to find and promote maintainer organizations within
> subsystems that are less likely to monopolize the mainainer's
> development time.  Previously we have had discussions of how the
> TIP tree is run, but I'm not sure that works well in every case.
> Are there other working models for this?

arm-soc is ran a bit like TIP, but not identically. It's usually Arnd
and I who handle most of it, with Kevin Kilman stepping in in
particular when Arnd goes on paternity leave.

On a whole, I can say that Arnd seems to have time left to deal with
other parts of the kernel and posting patches, since he spends most or
all of his work on upstream stuff while it's mostly a side activity
for me.

One thing that we're doing that's quite helpful is that we hand off
and mostly time-slice our maintainership, which means you get to be
off from it for a while every now and then. That's different from TIP
where they instead tend to have areas of the kernel that each
co-maintainer focuses on. The last couple of months I've been overly
busy with work and life and I've stepped away shortly, which our model
makes fairly easy to do. I'm re-engaging now though, since Arnd is out
on paternity leave again so me and Kevin are looking after things
through the fall.

We also don't engage all that much with developers directly -- mostly
new lead developers/maintainers on new platforms and people
upstreaming new SoC families. Most of the day to day work is delegated
to per-vendor maintainers below us and we work with them on the back
end and merge their branches.

I think we've talked about how we handle our work in the past, but I'd
be happy to elaborate more (here over email or elsewhere) if anyone
wants to learn more about what we've found to work pretty well for us.


-Olof

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

[Darren Hart]

On Thu, Jul 09, 2015 at 11:09:38AM -0400, John W. Linville wrote:
> On Wed, Jul 08, 2015 at 10:18:36PM +0000, Jason Cooper wrote:
> > On Wed, Jul 08, 2015 at 09:29:57PM +0200, Peter Huewe wrote:
> 
> > > Not only the bad people drop out, I've seen quite a lot of good devs
> > > vanish for good - and these should be the ones we also should try to
> > > keep - especially since I'm not sure whether we can allow such high
> > > drop out rates over a long time.
> > 
> > I'd love to hear some specific examples, links to email threads so we
> > can quantify this.  I suspect a lot of it is: "I scratched the itch,
> > and didn't have anything else I wanted to add. Then daily life took me
> > away."
> > 
> > Which is the hard part about qualified people.  They're busy. :-)
> 
> Hopefully I'm not one of the "bad people", and I don't reallly
> consider myself a "drop out".  But, I am someone that recently
> (i.e. since the last KS) extracted himself from a maintainer role.
> It seems like I should have something to add here...
> 
> I was the wireless maintainer for roughly seven years.  My situation
> may be a bit unique in that I was always more of a "Linux guy" than a
> "wireless guy", and most of the contributors were bigger experts in
> the technology itself than I ever was.  That was fine for a while, but
> over time that became less and less comfortable for me.  I've never
> really heard anyone else express that sentiment, so this is probably
> not a widespread concern...

I've certainly found this to be the case for me where my little corner of the
kernel, platform-drivers-x86, is basically an integration point for many other
subsystems, such as rfkill, backlight, input, etc. with a lot of ACPI thrown in
the mix. I also never have the hardware to be able to do any testing myself. I'm
100% dependent on my submitters for any testing beyond build and static
analysis.

> 
> The bigger concern was that while I was wrangling everyone else's
> wireless patches, I had less and less time to do useful work elsewhere
> in the kernel.  I definitely have heard other maintainers express
> similar complaints, so this seems like a relatively common concern.
> It would be good to find and promote maintainer organizations within
> subsystems that are less likely to monopolize the mainainer's
> development time.

For me, the concern is that I'm basically acting as a pro-bono proxy for various
vendors who don't maintain drivers for the products. So speaking of recruitment,
we could use the vendors to get more involved with the drivers for their
platforms. Some, Dell and Toshiba most notably, have been providing more
documentation, fortunately.

> Previously we have had discussions of how the
> TIP tree is run, but I'm not sure that works well in every case.
> Are there other working models for this?
>
> I guess I'm suggesting the opposite of a "professional maintainer".
> Some people thrive at being the center of a subsystem, as I did for
> some time with wireless.  But burnout is a problem, and I think we
> can limit some of that if somehow we can encourage less expansive
> roles for individual maintainers.

Something along these lines is probably relevant to a number of subsystems where
the professional maintainer is problematic since some to all of the content is
of no interest to the employer (unless it's the LF).

-- 
Darren Hart
Intel Open Source Technology Center

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

[Jason Cooper]

On Thu, Jul 09, 2015 at 11:09:38AM -0400, John W. Linville wrote:
> On Wed, Jul 08, 2015 at 10:18:36PM +0000, Jason Cooper wrote:
> > On Wed, Jul 08, 2015 at 09:29:57PM +0200, Peter Huewe wrote:
> 
> > > Not only the bad people drop out, I've seen quite a lot of good devs
> > > vanish for good - and these should be the ones we also should try to
> > > keep - especially since I'm not sure whether we can allow such high
> > > drop out rates over a long time.
> > 
> > I'd love to hear some specific examples, links to email threads so we
> > can quantify this.  I suspect a lot of it is: "I scratched the itch,
> > and didn't have anything else I wanted to add. Then daily life took me
> > away."
> > 
> > Which is the hard part about qualified people.  They're busy. :-)
> 
> Hopefully I'm not one of the "bad people", and I don't reallly
> consider myself a "drop out".  

Absolutely not.  It was a sad day when I heard you were stepping down.

fwiw, I reached out to someone who I felt was capable to see
if he could help.  Unfortunately, he had some PhD-thesis thingy going
on.  :(  Back to the 'qualified people are busy' ...

Our greatest mistake is if we don't learn from your experience and make
the system better.

> But, I am someone that recently
> (i.e. since the last KS) extracted himself from a maintainer role.
> It seems like I should have something to add here...
> 
> I was the wireless maintainer for roughly seven years.  My situation
> may be a bit unique in that I was always more of a "Linux guy" than a
> "wireless guy", and most of the contributors were bigger experts in
> the technology itself than I ever was.  That was fine for a while, but
> over time that became less and less comfortable for me.  I've never
> really heard anyone else express that sentiment, so this is probably
> not a widespread concern...

I certainly don't have a lot of the hardware people are submitting
patches for, ergo ...

> The bigger concern was that while I was wrangling everyone else's
> wireless patches, I had less and less time to do useful work elsewhere
> in the kernel.  I definitely have heard other maintainers express
> similar complaints, so this seems like a relatively common concern.
> It would be good to find and promote maintainer organizations within
> subsystems that are less likely to monopolize the mainainer's
> development time.  Previously we have had discussions of how the
> TIP tree is run, but I'm not sure that works well in every case.
> Are there other working models for this?

Olof has already mentioned how arm-soc is handled.  As a submitter of
pull requests to them for years, I can vouch that it works quite well.
Additionally, mach-mvebu is co-maintained by myself and three others
(there are multiple SoCs in there, we each have our focus).

Since I started a new job (hence less time for kernel work), we've
rotated out who takes the lead for each cycle.  It's a *huge* relief to
know it's not up to me *every* cycle.

Similar experience with Thomas and I on irqchip.

tl;dr:  co-maintaining works, works well, and helps avoid burnout.  It
also opens the door for part-time involvement.

> I guess I'm suggesting the opposite of a "professional maintainer".
> Some people thrive at being the center of a subsystem, as I did for
> some time with wireless.  But burnout is a problem, and I think we
> can limit some of that if somehow we can encourage less expansive
> roles for individual maintainers.

Fully agree.

thx,

Jason.

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 527 bytes --]

On Wed, Jul 08, 2015 at 01:21:40AM +0200, Peter Huewe wrote:

> -> How do we get companies to actively sponsor subsystem maintainership - if 
> only at driver or subsubsystem level.
> e.g.: I unfortunately failed at that with my company :/

One thing I found worked really well when I was working for a silicon
vendor was using employing maintainers as evidence of good software
support for shiny new features on Linux, both internally and externally.
That's obviously somewhat situation specific but it's one route.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]