> akkor onnantól annak karbantartása is upstream felelőssége
Dehogy is :) Szerencsére ez nem így van. Ha egy kiegészítés bekerül az upstreambe akkor a contributor felelőssége azt a részt karban tartani. A patch-ek elfogadásához ezért alapvető elvárás szokott lenni, hogy a contributor az vállalja a karbantartást. Esetünkben ez nem volt kérdés.
Az én csapatom napi rendszerességgel tol be a Qt-ba meg a QtCreatorba patch-eket. Mindig rendesen megyünk is utána minden ilyen kódnak. Ezért is nettó ostobaság, hogy a Canonical csak downstreamel... mert nagyon sok projektbe toljuk a kódot.
> a probléma gyökere az nem a driver kiegészítés visszautasítása, hanem a mir létrehozása.
Akkor gondolom a Windows-zal sincsen és nem is volt semmi gond. A gond az, hogy létrehozták a Linuxot, ugye? :D :D :D :D
Figyusz... ha te csinálsz egy drájvert egy hardverhez és valaki kitalál egy alkalmazást a drájvered fölé, de az alkalmazás működéséhez a drájverben szükség van egy bővítésre akkor pontosan mi a francért is nem lehet a drájver source tree-jébe betolni a kiegészítést???
Ez nevetségesen kicsinyes gecizés... semmi más.
> Nagyon helyes.
Egyáltalán nem helyes, mert az Intel ezzel forkolásra kényszerítette egy downstream fogyasztóját, ami az opensource világban egy erősen elítélendő dolog.
Figyelem! Egy már létező megoldás használata helyett egy másikat csinálni _NEM_ helytelen dolog. Az opensource világa telis tele van ilyen megoldásokkal. Ezért van tucatnyi browser, tucatnyi levelezőkliens. Ez az a szabadság amitől az opensource és a szabad szoftver világa nagyszerű. Ha tetszik vigyed, szabad... ha nem tetszik csinálj másikat. Ez nem fregementáció hanem a szavbd szoftver világának az esszenciája.
Az amit az Intel csinált, na az fregmentáció. Bezárni a kontribúció előtt a kaput pusztán azért mert egy havernek az a kontributor a versenytársa az nettó bunkóság, sőt etikátlanság.
> egy plusz patch karbantartása már csak egy laza ujjgyakorlat.
Nem egy nagy ügy tényleg. Csak egy otromba tuskó az aki ilyenre kéynszerít egy disztrót.