Re: 463 kernel developers missing!

[Nick Piggin <nickpiggin@yahoo.com.au>]

On Tuesday 29 July 2008 06:46, Dave Jones wrote:
> On Mon, Jul 28, 2008 at 04:22:36PM -0400, Theodore Tso wrote:
>  > On Mon, Jul 28, 2008 at 03:00:13PM -0400, Jon Smirl wrote:
>  > > Other people aren't perfect, I've found over 1,000 typos in the those
>  > > names and emails. We need a validation mechanism.
>  >
>  > You keep using the word "need"; I do not think it means what you think
>  > it does.  :-)
>  >
>  > Seriously, why is it so important?  It's a nice to have, and I
>  > recognize that you've spent a bunch of time on it.  But if the goal is
>  > to get better statistics, and in exchange we forcibly map all Mark
>  > Browns to one e-mail address, and/or force them to all adopt middle
>  > initials (what if there are two Dan Smith's that don't have middle
>  > initials) just for the convenience of your statistics gathering, I
>  > would gently suggest to you that you've forgotten which is the tail,
>  > and which is the dog.
>
> I'm beginning to question just how useful the continued measuring
> of things like Signed-off-by's is.   Last week at OLS, I overheard
> a conversation where someone was talking about the "top 10" lists
> that Greg has been talking about at various conferences.
> The conversation went along the lines of "my manager really wants
> to see us on that list, at any cost".
> Whilst the niave may think 'more patches == more better', this isn't
> necessarily the case given we have nowhere near enough review bandwidth
> *now*

This is one way of looking at "the problem". The other way to look at
it is that things are merged too quickly / without enough review, etc.

That is the problem kernel maintainers can actually do something about.
Or, they can just whine about "not enough review bandwidth".

There has been this complaining from lots of people about not enough
review bandwidth for quite a few years now. So I doubt it is going to
magically get better by making more noise.

Consider that there is probably virtually limitless amount of crap that
people want to try to merge, so there is always going to be a lack of
review bandwidth if the aim is to merge as much as we possibly can as
fast as we can.

The answer is to not make the problem worse by merging stuff faster
than can be reviewed. When that happens, developers and companies
should eventually assign a higher value to patch review.