Linus Torvalds: Linux 2.6.9-rc1

Címkék

Linus visszatérve a vakációról kiadta a 2.6.9-rc1-es Linux kernelt. A változások számos területet érintenek: arm, ppc, sparc, acpi, i2c, usb, fbcon, ntfs, xfs, nfs, cpufreq, agp, sata, hálózati driverek... Linus hosszasan gondolkozott azon, hogy a 2.6.8-as vagy a 2.6.8.1-es kernelhez készítse a patchet, de végül úgy döntött, hogy 2.6.8-hoz adja ki. Akinek 2.6.8.1-es forrása van, annak a .1 patchet vissza kell patchelni (-R).

A patch letölthető tükörszerverekről.

Változások logja Linus levelében itt.

Hozzászólások

>nagyon fontos lenne elkezdeni megreformálni a fejlesztési rendszert

Elkestel. Epp most valtoztattak az eddigi stiluson. pl nem lesz 2.7-es fejlesztoi fa.

Az meg hogy nem erted miert/hogyan jobb ez, mint az eddigi, nem az o bajuk, hanem a tied;-))

Majd nehany honap/fel ev utan latszani is fog valami eredmeny. El lehet donteni, hogy javult-e vele a dolog, vagy nem.

Egyebkent akinek gondot okoz a patcheles ne patcheljen. toltse le az egeszet, fenn van a mirroron.;-)

Most mi a fasznak kell 2.6.8-ra patchelni? Ez kesz. Amugy eleve baromsag volt a .1 verziot is kiadni, de igy mar duplan el van baszva. Thx kerneldevz

A következő verzió mi lesz? 2.6.10?

Nem az a baj, hogy nehéz, hanem az, hogy össze-vissza következetlen. Miért nem lehetett az egészet úgy csinálni, ahogy a 2.4.11 esetén? Lehetett volna 2.6.8-dontuse és a fixált lett volna a 2.6.9. A 2.4.12 is elég apró változtatás volt, mégis új verziót kapott.

Végülis most értem a racionálét benne, feltéve, hogy a végleges 2.6.9 patch is a 2.6.8 ra lesz. Így mondjuk a későbbiekben nem kell külön figyelni arra, hogy a 2.6.8-nak volt egy 2.6.8.1-es mellékvágánya is. Viszont ugyanakkor nem ártana valami "broken" jelzés a 2.6.8-ra, az utókor számára.

Na mindegy. A lényeg, hogy ez az egész úgy ahogy van nagyon hülyén sült el. A kisegér befutott a csőbe és most már csak előre menekülhet belőle. Remélem, hogy ez azért megkondította a vészharangot a fejlesztési modellt illetően.

Nem beszólás volt, hanem kérdés.

Fene se tudja. Alpha-n beforgattam a 2.6.8.1-et, es valahol az alsa detect korul kemenyre fagyott. Gondoltam, utananyomozok es bereportolom, de ha gyakrabban jon ki uj kernel, mint fogkefereklam, akkor nem sok ertelmet latom.

Nem tudom, ki hogy van vele, de szerintem ilyen tempo mellett nem hogy letesztelni, de rendesen megcsinalni se lehet tul sok mindent. Felek, hogy a sok 'quick hack' eredmenye egy akkora gany lesz, amit nem lesz ido rendbetenni.

Azt hiszem, en megallok 2.6.7-nel, aztan legkozelebb azt fogom megnezni, amire legalabb egy honapig nem jon ujabb verzio.

Nagyon nem ide tartozik, de valahol olvastam, hogy A'rpinak is voltak gondjai az Mplayer-el a vége felé, mert egy nagy gányolás volt már az egész. (Bár szeretnék ilyen "gányolva" programozni)

Én azt nem értem, hogy ha kiadták a 2.6.8.1-et egy bu miatt, akkor az ismert cdírás hiba miatt miért nem készült .2 is?

Következetlenek, következetlenek, következetlenek! Mint ahogy bra is említette: tényleg el kéne gondolkodni valami patch-o-matic féleség bevezetésén. El lehetne képzelni úgy, mint ahogy sok distro működik, hogy van egy -stable ág és van egy -current ág. A stable ágba csak bugfix update-ek kerülnek, a -currentbe meg a fejlesztések. És aztán időnként a -current-et rendberaknák és kiadnák egy új -stable verzióként. Kb ahogy a Slackware csinálja. Miben térne ez el a jelenlegi modelltől? Hát abban, hogy ez a minor version kiadásokra vonatkozna. Lehet, hogy így valamivel riktákbbak lennének a kiadások (mondjuk 2 havonta egy stable kiadás), de így azért a stable ág is feature szempontból up to date lenne, és mégis megmaradna a stabilitása is. Emellet a stable ág a kiadás után még tovább kapná bugfixeket, pont ahogy a distrokban. Tulajdonképpen a 2.6.8.1 felfogható így is. De akkor így kéne folytatni 2.6.8.x felelne meg a stable-nek, a 2.6.9-pre meg a -currentnek.

Apropó észrevettétek, hogy most egyáltalán nincs -pre? A 2.6.8(.1) után rögtön 2.6.9-rc jön! Ez is azt tükrözi, hogy a minor verziók esetében teljesen felhagytak a "feature add -> feature freeze -> stabilize -> release" rendszerrel.

Persze amit felvázoltam, ahhoz sok mindenen kellene változtatni. Ki kellene dolgozni a patch-ek egyenkénti applikálásának az infrastruktúráját; nyilván kell dependency rendszer is.

Szerintem túlnőtt a projekt rajtuk. Túl nagy ahhoz, hogy egy ember átlásson mindent, és ilyenkor kezdődik az, a "gányolás", amit valaki már A'rpitól idézett előttem. A jelenlegi "alrendszer karbantartós", illetve Andrew Mortonos előszűrős rendszer időt nyert nekik, de hosszú távon ez sem lesz elég, és szerintem ennek a kezdeti jelei mutatkoznak most. Úgy gondolom nagyon fontos lenne elkezdeni megreformálni a fejlesztési rendszert minél hamarabb (nyilván nem egy-két napos átállási időre lesz szükség, elsősorban azért mert a fent említett infrastruktúrát ki kell dolgozni), mert a későbbiekben csak rosszabb lesz a helyzet és szerintem egy elkésett reform miatti "stabilitási hullámvölgy" nagyon ártana a linux megítélésének.