Elkezdtek lemondani az OpenOffice.org Community Council TDF-ben érintett tagja

Pár nappal ezelőtt Louis Suárez-Potts vezetésével arra kérte az OpenOffice.org Community Council azokat a tagjait, akiknek köze van a nemrég megalakult The Document Foundation-höz, hogy mondjanak le az OOo Community Council-ben betöltött pozíciójukról. A felhívásnak elkezdtek eleget tenni az érintettek. Néhány nappal ezelőtt Charles-H. Schulz jelezte, hogy távozik. Szintén lemondott Christoph Noack is. Mindketten a bizottság tagjai voltak. De nem csak bizottsági tagok távoztak. Florian Effenberger, a marketing projekt vezetője is búcsúzott. Szintén lemondott Thorsten Behrens, a Graphic System Layer egyik vezetője. A részletek itt.

Hozzászólások

Csak én látom úgy, hogy a teljes OOo hátország szétesik, és felsorakozik a libre mögött???
--
A linux felhasználóbarát. mindössze megválogatja a barátait...

Most fordítva van. Akik felsorakoztak a Libre mögött, azokat mondatják le.
Az már más kérdés, hogy a maradék mire lesz képes. Illetve az is kérdés, hogy a Libre mögött felsorakozottak mire lesznek képesek.

-----
"Fontosabb egy jó szomszéd, mint egy távoli rokon." (Árvízkárosult, 2010)

Oszd meg és uralkodj... hogy tetszhet ez most a microsoftnak... :(
--
Gábriel Ákos

Érdekes, hogy Louis Suarez-Potts is bedobta ezt a gondolatot, sőt tovább ment, szerinte a Microsoft keze is benne van a dologban. Ez baromság. Ő ugyan veszít, mert nem mondhatja kifelé magáról, hogy egy egységes közösség vezetője, de a projekt nyerni fog ezen. Eddig sem volt egység, és nem volt egyetértés. Most mindenki megy a maga útján, és a LibreOffice kötöttségek nélkül fejlődhet, amerre akar.

Az elmúlt három hétből még nem lehet levonni semmit, nyilván mindenki rávetette magát az újdonságra. Jött egy csomó új fejlesztő, beküldte a patchét, és észlelhette, hogy azonnal befogadták, megköszönték stb. Remélem, közölük sokan maradni fognak, és nemcsak egy fellángolás volt. Most az a legfőbb probléma, hogy olyan feladatokat keressünk a frissen belépő fejlesztőknek, ami nem túl nehéz, de értelmes. Egy csomó ilyen feladat az első három hétben megoldódott.

Megoldódtak olyan dolgok is, ami egy adott közösségnek fontos volt, de az OpenOffice.org-nak nem. Például a horvát és a dán szótárak integrálásával egy több éves várakozás ért véget a LibreOffice-nál azonnal. Sohasem értettem, miért nem lehet valamit azonnal betenni, ami kész és működik, ezért kihasználva commit jogomat, ahogy kérték, betettem a horvát és a dán szótárakat a LibreOffice-ba. Ebből az ottani közösségek látják, hogy ez a projekt figyel rájuk. A horvátnál volt valami licencprobléma, ezt nem úgy oldottam meg, hogy elfektettem a hibát, hogy "vállalati jogászaink majd megvizsgálják", és három évig se kép se hang, hanem elolvastam, hogy minek kell megfelelnie, és átalakítottam, hogy megfeleljen. Az, hogy ezt megtehettem, a LibreOffice-nak köszönhető. A kód integrálását a LibreOffice-nál bárki elvégezheti, aki commit jogot kapott (azért kapott annak idején, mert megbíztak benne), nem csak néhány release engineer, mint az OOo-nál.

Ugyanígy, fordítási javításokat is el fogok fogadni mindaddig, amíg teljesen le nem lesz fagyasztva a kód, sőt a javítókiadásokkal együtt a fordítások is frissülhetnek. Miért is ne? Miért jó az, hogy egy adott nyelvi verzió egy látványos elgépeléssel fél évig égeti magát, míg a javítás 2 perc, és abszolút kockázatmentes (arra szoktak hivatkozni, hogy jajj, akkor most az egészet újra kell tesztelni minden platformon stb. - nem, nem kell az egészet újratesztelni. Ha olyan rossz egy program, hogy egy fordítás javításától elromlik a funkcionalitása, akkor ott már nagy baj van. Ennyire bízni kéne a saját kódunkban.)

Folytatódni fog az erőteljes kódtisztítás, a túlbonyolított build folyamat egyszerűsítése, ezek gyorsulást fognak hozni. A felhasználók számára látható funkciók fejlesztése még nem tudom hogyan lesz, várom, hogy megjelenjen a roadmap.

Az OpenOffice.org-ból minden új kódot át fog venni a LibreOffice, aminek értelmét látja. Tehát nem lesz dupla munka, hála a szabad szoftveres licencnek, a kód szabadon áramolhat a LibreOffice irányába. Fordítva sajnos nem, mert az OpenOffice.org-hoz nem elég az LGPL, egy külön SCA-t is alá kell írni (elfaxolni stb.), hogy a fejlesztő a copyrightot megosztja az Oraclével. Tekintve ezt, hacsak a LibreOffice valamit el nem ront, nem tudom, mi értelme lesz valakinek OpenOffice.org-ot használnia, hiszen a LibreOffice mindent fog tudni, mint az, plusz még azokat is, ami csak a LibreOffice-ban lesz benne.

Én mondjuk még mindig tartok tőle, hogy az Oracle esetleg bezárja a kódot és az erősen visszavetheti a LibreOffice fejlődését is. Azt gondolom megteheti, s pont az SCA miatt. Persze, ha nem így lesz, és az ooo-build-ból lett LibreOffice folytatja azt a hagyományt, hogy mindig az OpenOffice.org előtt jár egy-két lépéssel. Ha ez így lesz, akkor az lesz nekünk a legjobb, mert a hibák gyors javításának lehetősége adott, akár 1-2 hét alatt javítható lesz egy olyan hiba, amire eddig fél évet is várni kellett. Persze kérdés, hogy mikor lesz olyan további új funkció hozzáadva a LibreOffice-hoz, amely tényleg nagy előrelépésnek tekinthető. A mostani folyamatok inkább a kódtisztításnak tekinthető, kommentek lefordítása, halott kódok teljes eltávolítása, felesleges include-ok eltávolítása, leakek felkutatása és eltávolítása. Remélhetőleg csökken majd a kód megváltatásához szükséges tanulási görbe, egyszerűbb lesz majd részt venni. De az OOo nagyon bonyolult, a LibreOffice oldalán egyelőre csak majdnem egy tucat ember van aki mélységében hozzáadhat a kódhoz. Persze idővel ez a szám növekedni fog, ebben biztos vagyok.

KAMI | 神
--
Támogatás | OxygenOffice | Fordításaim és SeaMonkey

Azt hiszem nem fogom hiányolni azokat a remek fejlesztéseket és fergeteges QA munkát, amit pl. az RTF exporttal kapcsolatban követtek el a kedves fejlesztők. Vajna Miklós újraírta a kódot és érdemes megnézni, hogy milyen égbekiáltó hibák voltak ebben a kódrészben.
- Ez ékes bizonyíték arra, hogy a hangoztatott QA bullshit.
- Hogy summer of code keretében kvázi nulláról lehet nagyot alkotni pár hónap alatt (sem a kód ezen részében, sem a specifikációban nem volt jártas Miklós a projekt elején)
- Vajon miért kell kódot tisztítani, ha a QA olyan fantasztikus és olajozott?
- Az ügyfeleim hogyan tudnak L3 bugokat fogni napi használat után, amit anno a go-oo projektben 2(!) nap alatt javítottak, az OOo-ban meg azóta se.

Valóban ennek hiánya miatt aggódunk?

Más a felfogás. Az RTF kódhoz nyilvánvalóan nem nyúltak hozzá 2000 óta, az ok ismeretlen. Azt szokták írni az ilyesmikre, hogy nincs erőforrás rá -> "OOoLater".

Ha viszont valaki nagyobb horderejű változásokat akart, elhajtották, hogy ne legyen, mert épp most van az újraírás alatt, és úgyis ki kéne dobni a munkáját. Pl. phanatic, amikor FSF.hu/Novell ösztöndíjas volt, azt a feladatot kapta, hogy oldja megy a magyar/angol függvénynevek választhatóságát a Calcban, és ezzel a szöveggel koptatták le. Végül Kohei implementálta a funkciót kb. 2 évvel később, persze nem lett upstream.

Igen. Több szem többet lát. Az kód döntő része örökség. Ezt Te is tudod. Ezeket a kódtisztítási feladatokat meglehetett (volna) valósítani egy CWS keretén belül is. Persze örülök, hogy ez a folyamat is elkezdődött.

A QA nem bullshit. Szerintem klassz dolog, ha a támogatott platformokra buildelni kell és ezek tesztelésre kerülnek. Persze ezt célszerű ezt az elvárást buildbotokkal kiszolgálni. Örülök, ha a funkciókhoz súgó is készül. Láttam vmiklos01 problémáját is, melyben azért én inkább a szervezetlenséget és a belső kommunikáció rossz működését feltételezném, mint rosszindulatú hozzáállást. Anno leveleztem a StarDivision mérnökeivel egy-egy probléma megoldásához és számomra segítőkésznek tűntek. Ezért is gondolom a fentieket.

Én azt hiszem, az OOo a lehetőséghez mérten nem fejlődött rosszul, s ha megvalósult volna a nagyobb kódbefogadás a külső kóderektől, akkor nem is lett volna baj. De ezen hibás gyakorlat miatt azért ne savazzuk le az összes fejlesztést, munkát amit hamburgiak végeztek. Nyilván vannak területek, amiket nem láttak fejlesztők évek óta, vannak amelyek jobban előtérben vannak. Az erőforrások végesek. Jómagam RTF fájlokat nem nagyon nyitogatok, s ha valamit elmentek, azt ODF formátumba kerül. Ugyanakkor sokak számára hasznos a jobb RTF export.

Ezúton is gratulálok is Miklósnak, a remek munkájáért.

L3 bugok vannak, lesznek, és nem baj ha a hibákat javítják. Kinek ez, kinek az fáj. Örülök, ha valamit ilyen gyorsan javítanak. Elvégre erre kötöttetek szerződést a Tisztelt Ügyféllel. Ha az Oracle is kötött ilyen támogatási szerződést, és ott is L3-ra futnak, ők is javítják majd. Persze örülök, hogy van LibreOffice nagyobb nyitottság, több szabadúszó (vagy éppen vállalati) fejlesztő.

KAMI | 神
--
Támogatás | OxygenOffice | Fordításaim és SeaMonkey

Örökség? Ki örökölt kitől?
Nagyrészt azok az arcok ülnek ott, akik a StarDivision érában is ott voltak. Vajon mi lehetett az oka, hogy a remek OOo QA nem működött?

A QA bullsit, mindaddig, amíg gátolja a fejlesztést és nem a hibakeresésre koncentrál. Ezt több ponton bebizonyosodott már. Lehet itt még pörögni rajta, de túl sok az egybeesés. Az openSUSE konferencián a LibreOffice napon, nem kevés ilyen példával álltak elő. Ennyi véletlen nincs.

Az, hogy nem használsz RTF-et, az nem ok arra, hogy rossznak kell lennie. És most sem használható az RTF formátum, mert import nélkül ez nem korrekt támogatás.

Csak azt nem értem, hogy ezek után az OOo team miért nem veszi ki az RTF támogatást, hiszen a QA-n biztos nem megy át, ha bármilyen bug alapján ránéznek. Hát itt bukik meg a QA, és innen látszik, hogy csak indok a fejlesztők távol tartására.

L3. Ezzel kapcsolatban azt írtam, csak nem akartad megérteni, hogy egy olyan QA, amelynek ők bemutatják magukat, nem termel ennyi bugot, alapvető funkcióknál (pl. nyomtatás, cellamásolás és még sorolohatnám).

LibreOffice nem ígér ilyen QA-t, hanem gyors reagálást ígér a hibákra. Összevetve az elégtelen QA ás nem reagálunk a hibákra kombóval az előbbire szavazok. Természetesen te szeretheted a tradicionális megoldást.

Amíg nem hibamentes a szoftver (ami viszont nem létezik), a QA szükségszerűen gátolja a fejlesztést. Kérdéses ennek mértéke. Nyilván az OOo modellje túl merev volt sok tekintetben. De ne a múlton merengjünk, hanem a jövőn, ha lehet.

AZ RTF támogatás - néha - még ilyen formában is jól jön. Nyilván nem napi használatról van szó az általam ismert történeteknél, hanem egyedi estekről.

Nekem alapvetően a CWS rendszer tetszett. Noha ennek nagy az overheadje, de egy ilyen komplexitású szoftver esetén talán kifizetődő. Persze mint mindent, ezt is lehet jól és rosszul is csinálni.

Remélem azért tudsz róla, hogy majd' három éve a LibreOffice és elődein dolgozok, mind végfelhasználóként, mind fegyverhordóként?

KAMI | 神
--
Támogatás | OxygenOffice | Fordításaim és SeaMonkey