Post by Andrew MortonPost by Jeff GarzikPost by Jeff GarzikWas 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.
Post by Jeff GarzikFor 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.
Post by Andrew MortonPost by Jeff GarzikIt'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
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 ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------