Harmadszorra is megválasztották Debian projektvezetőnek Stefano Zacchiroli-t

 ( trey | 2012. április 15., vasárnap - 18:06 )

Március közepén volt szó arról, hogy az idei Debian Project Leader (Debian projektvezető) választáson magyar jelölt is indul Nagy Gergely személyében. A szavazás lezárult és Kurt Roeckx, a Debian projekt titkára kihirdette az eredményt. A választást Stefano Zacchiroli nyerte, aki idén harmadik DPL periódusát kezdheti meg. A régi-új DPL új ciklusa 2012. április 17-én kezdődik.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Talán hozzá lehet(ett volna) írni hogy Stefano az első aki harmadszorra is megnyerte a DPL-t egymás után. Elsöprő többséggel, több mint 80%-al. Viszont bejelentette hogy jövőre biztosan nem jelölteti magát.

Hozzairnank, ha a debian nem egy lassu haldoklasnak tuno allapotban lenne epp. De ez nyilvan velemeny, en Stefano programjabol alapvetoen a status quo fenntartasat olvastam ki, es ugy latszik, ezzel a meg ott levo emberek elegedettek. Remeljuk, az ottlevo userek is.

> ha a debian nem egy lassu haldoklasnak tuno allapotban lenne epp

Ez honnan jott le neked?

--
|8]

Én sem értelek teljesen. Miért gondolod, hogy haldoklik? Nekem, mint Debian user tökéletesen megfelel a 2 évenkénti release. Sőt, részemről akár lehetne ritkább is, vagy legalábbis még tovább támogatott az oldstable. Mint pl. Red Hat esetén. Tényleg, szerinted a Red Hat is haldoklik?

----
"Mert nincs különbség: mindenki vétkezett, és híjával van az Isten dicsőségének. Ezért Isten ingyen igazítja meg őket kegyelméből, miután megváltotta őket a Krisztus Jézus által." (Róma 3.22-24)

Nyilvan vannak, akik igy gondoljak, vannak, akik nem.

Nekem szemely szerint a 2 evenkenti release nem felel meg: egyszeruen a fejlesztoeszkozeim gyorsabban valtoznak, tulajdonkeppen a rendszernek vagy minden reszet forrasbol forditom, vagy nem debiant hasznalok.

Sajna az ubuntu se megoldas, mert az meg mostoha modon kezeli a szerveroldalt.

Itt azert nem pusztan az en velemenyem ez, hanem a kornyezetem velemenye is sokszor; igaz, mi nem enterprise dolgokat fejlesztunk, hanem igyekszunk olyan megoldasokat hasznalni, amik csak 1-2 eve vannak a piacon.

A RedHattel (centos) -sel is volt olyan bajom, hogy a friss kiadas az SVN egyik masfel eve bent levo, sokszor kiprobalt, emiatt stabilnak es a ceg altal hasznalhatonak velt feature-et nem tamogatta, emiatt szabalyosan deployolni se tudtam a kodot.

Mit értesz fejlesztőeszköz alatt?

Mondjuk az egyszeru szerveroldali webfejlesztesnel maradva: nodejs, mindenfele python wsgi-k, rails, php modulok.

Ekkor meg nem huztunk be mondjuk couchdb-t, esetleg mongodb-t, redis-t, es nem hisztiztunk amiatt, hogy nem nginx a webszerver, csak a nyelvi futtatorendszert szeretnenk hasznalni, mondjuk egy egy-masfel eves, kiprobalt, stabilnak mondott valtozatot aminek ismertek a hibai is.

Hal' egnek a kiegeszito eszkozok nagy resze vagy ezekben, vagy javaban vannak irva (jenkins es egyeb CI rendszerek, stilusellenorzok, automatizalast es automatizalt tesztelest segito eszkozok), igy ha egyszer sikerul a C-ben levo alapdolgokat valami kevesbe oskovuleti valtozatra hozni backportsbol vagy forditasbol (ismetlem: nem bleeding edge szoftverekrol beszelunk, hanem 1-masfel eves kiadasokrol), akkor mar menni szoktak a dolgok.

Miért nem próbálsz ki egy másik disztribúciót, vagy esetleg FreeBSD-t?

--
Java apps are nothing more than sophisticated XML-to-exception converters.

Oh, na azt a sz.past amit ez szokott jelenteni (FreeBSD) te se akarnad magadnak.

Mondjuk ugy, hogy egy-ket evente megprobalkozok vele en is meg masok is, es mindig azzal terunk vissza, hogy dehat ez horror.

Nem a FreeBSD-vel van onmagaval baj, hanem azzal, hogy mindenkinek linuxa van, es nincs jol kitesztelve az adott cucc FreeBSD-s portja.

FYI, pont ezen problemaidra a testing kivalo megoldas. Talan a railsre nem, de arra keves disztribucional van epelmeju megoldas eleve.

--
|8]

A testing hozza a sajat szivasait rendszerint, akkor mar inkabb felpakolom a fel vilagot forrasbol.

Pont abbol a szempontbol nem stabil, amiben kene, nevezetesen hogy az alaplibeket siman kicserelhetik alolad. Tehat nem feltetlen munka-stabilitassal lesz gondod, hanem nyomsz egy apt-get upgrade-et es hirtelen semmi nem az ami volt.

Egy feleves ciklusu szerver-os kene inkabb (az ubuntu nem ez).

Erre a testing kivaloan alkalmas lehet, ha csak felevente upgradeled (ill. kozben szelektiven, hogy a security frissitesek azert atjojjenek).

Igaz, ez tobb munka, de megoldhato. ;)

--
|8]

Gondoltam, hogy erre gondolsz, de a Debian ettől még nem halott. Neked (és még sokaknak) nem felel meg.

----
"Mert nincs különbség: mindenki vétkezett, és híjával van az Isten dicsőségének. Ezért Isten ingyen igazítja meg őket kegyelméből, miután megváltotta őket a Krisztus Jézus által." (Róma 3.22-24)

> egyszeruen a fejlesztoeszkozeim gyorsabban valtoznak

Erre valo a testing, vagy ha az is keves, az unstable (+ esetenkent experimental). Nyilvan ezzel felad az ember par dolgot, dehat a bleeding edgenek vannak ilyen mellekhatasai. (Ettol fuggetlenul, az unstable neve ellenere meglepoen stabil)

--
|8]

"Ettol fuggetlenul, az unstable neve ellenere meglepoen stabil"

Ja, egy kis dependency hell az semmiség. :)

Nem talalkoztam olyannal. Nem tobbel, mint upstream csomagok eseten.

--
|8]