Re: Slow DOWN, please!!!

[Adrian Bunk]

On Wed, Apr 30, 2008 at 07:30:13PM -0700, Linus Torvalds wrote:
> 
> 
> On Thu, 1 May 2008, Adrian Bunk wrote:
> > 
> > I am saying that it was merged too early, and that there are points that 
> > should have been addressed before the driver got merged.
> > 
> > Get it submitted for review to linux-kernel.
> > Give the maintainers some time to incorporate all comments.
> > Even one month later it could still have made it into 2.6.25.
> > 
> > The only problem with my suggestion is that it's currently pretty random 
> > whether someone takes the time to review such a driver on linux-kernel.
> 
> Now, I do agree that we could/should have some more process in general. I 
> really _would_ like to have a process in place that basically says:
> 
>  - everything must have gone through lkml at least once
> 
>  - after that point, it should have been in linux-next or the -mm queue
> 
>  - and then it can get merged (and if it didn't get any review by then, 
>    maybe it was because nobody was interested, and it simply won't be 
>    getting any until it oopses or catches peoples interest some other way)
> 
> HOWEVER.
> 
> That process doesn't actually work for everything anyway (a lot of trivial 
> fixes are really best not being so noisy, and various patches that are 
> specific to some subsystem really _are_ better off just discussed on that 
> subsystem mailing lists).

Cc linux-kernel on 3 patches "specific to some subsystem" that add the 
word "select" to Kconfig files and I'll catch at least one bug before it 
enters your tree...

> And perhaps more pertinently, right now that kind of process is very 
> inconvenient (to the point of effectively being impossible) for me to 
> check. Obviously, if the patch comes from Andrew, I know it was in -mm, 
> and I seldom drop those patches for obvious reasons anyway, but the last 
> thing we want is some process that depends even _more_ on Andrew being a 
> burnt-out-excuse-for-a-man in a few years (*).
> 
> So I could ask for people to always have pointers to "it was discussed 
> here" on patches they send (and I'd likely mostly trust them without even 
> bothering to verify), the same way -git maintainers often talk about "most 
> of this has been in -mm for the last two months".

It should be enough to trust maintainers that they follow the rules.

And in the unlikely case someone didn't follow them you know whom you 
have to watch closely during his next merge requests...

> That might work. But then there would still be the patches that are 
> obvious and don't need them.
> 
> And then even the obvious patches do break. And people will complain. Even 
> though requiring that kind of process for the stupid stuff would just slow 
> everybody down, and would be really painful.

There's a middle way.

Requiring the submission of bigger changes and new drivers to be Cc'ed 
to linux-kernel can help and shouldn't cause real problems.

And requiring this kind of patches to be in linux-next for some time
should also be possible.

Both can improve the quality of the kernel.

Trivial patches and bugfixes might not have to follow these rules, but 
that's similar to e.g. the current merge window process also having 
exceptions for new drivers. 

>...
> 			Linus
>...

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/