ro=20
=20
Common, yes. Popular, maybe. The only one, not. Taking that as reason
for breaking out-of-tree open source modules is throwing out the baby
with the bathwater.
o=20
They are doing that already. But somehow it fails to magically cause
open source drivers to spring into existence immediately. The crucial
word here is *time*.
Hmmm. "Your existing hardware isn't supported anymore, buy new one?"
I thought that was a Microsoft line. (SCNR)
red=20
te?
Exactly. Again, the problem is time. Deliberately breaking external
modules now and promising an in-tree alternative for later leaves
users out in the cold. That won't do much to improve the reputation
of Linux.
They are all there already.
Granted.
=20
Granted. But that's not the point I was arguing anyway.
There is still a point in arguing that breaking out-of-tree modules
is not a goal. It's acceptable collateral damage if there is a good
reason for a change, but it doesn't by and in itself constitute such
a reason. That's why I'm taking exception with your statement in
<20071024223124.GI30533@stusta.de>:
=20
Breaking external modules is *not* positive. It's acceptable, but
everything else being equal it's still better to avoid it.
ch=20
?
I'm convinced all of them have possible solutions. The challenge
is to turn a possible solution into an actual one. And again, the
problem is time.
Not every problem can be solved faster by throwing more people at
it. Take mISDN as an example. Its developers have stated the goal
of inclusion in the main kernel tree years ago and it's still not
there. Deliberately breaking this external module "to make people
aware that their code should get into the kernel" would only delay
this goal even more. But sending them a handful of new volunteers
now would probably constitute the proverbial "adding manpower to a
late project".
Because every in-tree code starts as out-of-tree code, so as long
as there's development at all there's always a certain amount of
code which isn't in-tree yet - or of which it isn't even sure yet
whether it will get in-tree.
HTH
--=20
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Unge=C3=B6ffnet mindestens haltbar bis: (siehe R=C3=BCckseite)