Johannes Berg wrote:
quoted text
>>> FWIW, wireless isn't unique in this regard. For eg, the last few months we've
>>> always been shipping the latest ALSA bits rather than what's in kernel.org too,
>>> for similar reasons -- when bugs appear, the developers want to know
>>> "does it still happen with the latest bits?"
>>>
>>
>> this is the part that concerns me.  The fact that you feel the need to use "not yet in mainline" pieces
>> (I'm not so much talking about backporting from 2.6.26-git to 2.6.25; that's perfectly fine, but I'm
>> talking about code not in 2.6.26-git) is NOT a healthy sign.... if that truely is the case then that code surely
>> deserves to be in mainline as well?
> 
> That's more a case of Fedora living on the bleeding edge. The code is
> fairly stable, all in linux-next, but the churn tends to be high because
> of internal API changes that affect all drivers. Currently, I don't
> think there is actually any _feature_ pending in linux-next, only
> internal cleanups. Such cleanups are desirable, but at the same time can
> lead to instability, hence being kept out of .26-git for the time being,
> and are in -next for .27. Mostly because we only wrote them after .26
> started.
> 

My concern is that if there's something technological in the "bleeding tree" that is so valuable to users
that distros feel that it's ready "enough" and that they need to pick it up for their users, we have a flaw
in our processes in moving to slow for users. From what you described that's not the case for wireless
(more a case of Fedora jumping off the bridge while forgetting to tie down the bungee cord ;-), and
that's good. I hope the same applies for the ALSA parts....

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