On Wed, 3 Sep 2008, Luis R. Rodriguez wrote:
>
> What I think really happens here IMHO is communication needs to be
> enhanced. I only recently noticed that "regression only" policy for
> 2.6.27 for example. I think some of us were rather surprised by it too.
It's really not a "2.6.27" policy, it's always been a "merge window" vs
"-rc" policy. It's just that I've started making more noise about it,
since many people don't seem to see what the point of the merge window is.
And no, the problem isn't new either. But it does seem to have been
getting somewhat worse lately. Possibly simply because we have more code
(ie releases have grown, which has made the problem more visible, even if
it hasn't necessarily changed in any other way).
> Before snapping at people for not following "orders" we need a clear
> guideline for what should or not be sent.
The basic rule really should be:
- *any* new development should target the merge window.
I think some of the driver people in particular have been mislead by
the fact that we have actually accepted new drivers even after the
merge window ("they can't regress"), and that in turn has probably
de-sensitized people a bit to the whole merge window.
Similarly, drivers (and other wholly self-contained modules like
filesystems etc) that didn't exist before - even if they were then
merged _during_ the merge window - have also been getting leeway in the
-rc code, since again they cannot regress.
And it really does appear like a lot of driver people just get very comfy
and used to that _first_ release, when we allow almost anything. And then
they just continue with it.
> To avoid it I do think another exception needs to be made for patches:
>
> * Small fixes which make something that was not working, which was
> supposed to work work
Not really.
The thing is, if it's a driver that has been around for more than a single
release, then those "small fixes" really can't be worth all that much. And
yes, they may be small, and yes, they may be "obvious", but the fact is,
they definitely can regress.
Sure, if some driver really haven't been around for very long, I can see
your point. Not very many people have used it, and I can well imagine that
there are lots of those "small fixes" that really do matter.
but if the driver has been in active use for a few kernel versions, there
really is almost no excuse to say "this fix is so important that it needs
to go in even though it's not a regression/security/oops fix".
So I would agree that the very first release a new driver (or filesystem)
is in is special. Almost anything goes during the -rc releases leading up
to that. And yes, I can well imagine that during the -rc for the second
release it perhaps makes sense to be a _bit_ more relaxed, simply because
it's young and as more people use it, silly (but serious) issues can just
become more obvious.
But in the long run? No. Drivers are not different from any other code,
and the -rc rules should be "regressions only".
In fact, in many ways we should be even _more_ careful with drivers than
with most other things, because driver changes are seldom "obvious". Even
really trivial stuff can interact with hardware in odd ways, in ways that
is seldom true of normal code that you can think about and analyze (since
we assume that the CPU itself doesn't have subtle timing etc bugs, of
course).
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
