- A hozzászóláshoz be kell jelentkezni
- 1843 megtekintés
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.;-)
- A hozzászóláshoz be kell jelentkezni
hath azert a 2.6 ag kinn van mar egy ideje. az eredmeny is latszik:)
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
Ejj de qrva bonyolult! Uj fejlesztési modell suxx
- A hozzászóláshoz be kell jelentkezni
A következő verzió mi lesz? 2.6.10?
- A hozzászóláshoz be kell jelentkezni
Uram-atyam micsoda nehezsegek. Senki nem mondta, hogy egy atlagembernek barmilyen -rc kernelt kell hasznalnia. Aki developer, annak ez kb 10 masodperc. De lehet, hogy tuloztam. 5 masodperc.
- A hozzászóláshoz be kell jelentkezni
2.6.9-rcN majd 2.6.10
Gyenge beszólás volt.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Nem beszólás volt, hanem kérdés.
- A hozzászóláshoz be kell jelentkezni
nyilván 2.6.9 lesz
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
Szerintem az egészet ott rontották el, hogy nem szoktatták rá a Linux usereket valamilyen verziókövető rendszer használatára, meg a changelogjainak az olvasására.
- A hozzászóláshoz be kell jelentkezni
Asszittem mukodik a swearing szuro ;)
- A hozzászóláshoz be kell jelentkezni
É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?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni