Re: [PATCH] s390: claw network device driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Andrew Morton wrote:
Jeff Garzik <[email protected]> wrote:

Andrew Morton wrote:

Jeff Garzik <[email protected]> wrote:


Was cc'ed to linux-net last Thursday, but it looks like the messages was
too large and the vger server munched it.

This also brings up a larger question... why was a completely unreviewed
net driver merged?


Because nobody noticed that it didn't make it to the mailing list,
obviously.

That's ducking the question.  Let me rephrase.

Why was a complete lack of response judged to be an ACK?


That's not uncommon.  I don't ask people "are you reading the mailing list
which you should be reading" unless I think it's someone who doesn't read
the mailing lists which they should be reading.


For new drivers, that's a -horrible- precedent. You are quite skilled at poking random hackers :) why not poke somebody to ack a new drivers?


In this case I didn't think about it very hard, sorry - figured it was s390
stuff and it hence falls under the "if it breaks, it's the s390 team's
problem" exemption.

Yeah, and I -am- sympathetic to that sort of thing. I just feel really strongly that we need to have a higher-than-normal barrier for new code.

It may be an S/390 driver, but Jeff's Law of Bad Code states "where there is bad code, it will be copied." Propagating the 2.2.x-era 'tbusy' flag to yet more drivers is something I absolutely do not want to happen.

I also feel that we have shifted from a "Linus doesn't scale" problem to an "akpm doesn't scale" problem. As much work as you put it (lots!), you can't possibly be expected to review all the new drivers and such.

I would prefer a "new driver must be acked by at least one non-author" rule. We need -some- barrier to entry. If that rule is OK with others, I'm quite willing to do that for my areas like libata.


It's not like this driver (or many of the other new drivers) desperately need to get into the kernel ASAP, so desperate that a lack of review was OK.


True.  But it's not as if we can't fix stuff up after it's merged up.  The
reasons for holding off on a merge would be:

a) We're not sure that the feature should be merged at all

b) Holding off on a merge is a tool we use to motivate the submitter to
   fix the code up

c) The merge breaks existing stuff.

I don't think any of those things apply here.  The only downside is the
increased bk patch volume.

In general, I have supported your philosophy of accelerated upstreaming of code. I just worry about going too far, and this driver was a case-in-point.

As Linus and others have pointed out many times in the past, there is no harm in -not- upstreaming code until it is "ready." Our current system of maintainers/lieutenants is sufficiently distributed as to allow this.

	Jeff


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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux