Megalakult a Document Foundation

Az elmúlt évtizedben az OpenOffice.org jelentős és fontos nyílt forrású projektté vált, köszönhetően a közösség lelkesedésének és segítségének.

Az OpenOffice.org tizedik születésnapjához közeledve itt az ideje egy fontos lépés megtételének. Az elmúlt tíz év során többször felvetődött egy független OpenOffice.org (pl. alapítvány ötlete), de soha nem valósult meg. Úgy érezzük, itt az ideje, hogy a projekt kezdete óta meglévő terv végre valósággá váljon. Ezért néhányan, akik már régóta hozzájárulunk az OpenOffice.org-hoz, létrehoztunk egy szervezetet, amelynek neve:

The Document Foundation

A következő hónapokban a célunk az OpenOffice.org közösség fejlődésének előmozdítása egy új, nyílt, független, meritokratikus szervezet kifejlődése irányába.

Mivel még nem biztos, hogy az OpenOffice.org védjegyet átengedi-e nekünk az Oracle, egy új márkanevet hoztunk létre. A termék neve ezentúl:

LibreOffice

Tekintettel arra, hogy milyen sokat köszönhetünk az Oracle-nek, meghívtuk őket is, hogy legyenek tagok és partnerek ebben az új vállalkozásban. Reméljük, hogy elfogadják a meghívást a hamburgi fejlesztőcsapattal együtt, és a LibreOffice csak ideiglenes név lesz. Kezdeményezésünket máris széles körben támogatják a vállalatok, például a Google, a Novell és a Red Hat, valamint mellénk álltak barátaink a brazil BrOffice.org közösségből. Mások, akik szintén szimpatizálnak terveinkkel, hamarosan szintén csatlakozhatnak hozzánk.

Jelenleg 25 jól ismert és az OpenOffice.org-hoz hosszú idő óta hozzájáruló közösségi tag vesz részt az alapítvány ügyeiben. Megalakítottuk az ideiglenes Steering Committee-t a további lépések megtétele érdekében.

Igyekszünk megteremteni az infrastrukturális feltételeket, hogy gyorsan tudjunk kommunikálni a közösséggel.

Csatlakozási lehetőségek:

A Document Foundation Steering Commitee nevében:

  • Sophie Gautier (a „francophone” projekt vezetője)
  • Italo Vignoli (az olasz projekt vezetője)
  • Olivier Hallot (a BrOffice.org projekt vezetője)
  • Thorsten Behrens (szoftverfejlesztő a Novellnél)
  • Florian Effenberger (a marketing projekt vezetője)
  • Caolán McNamara (szoftverfejlesztő a Red Hatnél)
  • André Schnabel (a német projekt vezetője)
  • Charles Schulz (a Native-Lang Confederation vezetője)

A hír magyar vonatkozása, hogy az alapítvány tagjai közül 16-an, 2010. szeptember 2-án, az OpenOffice.org konferencia Budapesten fogadták el az alapítvány irányelveit és választották meg a Steering Commitee tagjait. Az itt látható kép ekkor készült.

A LibreOffice köré szeretnénk magyar közösséget építeni, így a projekttel kapcsolatos információk a jövőben az alábbi helyeken követhetők nyomon:

Hozzászólások

Örülnék, ha a név maradna, mert a "LibreOffice" egyáltalán nem tetszik. Plussz, az OpenOffice már a felhasználók között is elég ismert.

Nem feltétlen kell az a Libre sem...

mi lenne ha simán annyi lenne hogy:

Office.org

mellesleg a közösségen kívül a legtöbb felhasználót nem érdekli, hogy a névből kiderül, hogy szabad-e vagy sem... úgyis utána jár.

OpenOffice esetén is mindenki megkérdezte, hogy és mennyibe kerül... meg hogy le lehet-e tölteni szabadon. Szóval a névben szerintem felesleges hangsúlyozni, hogy az most Free Open Libre Szabad vagy bármi...

Ezért lenne jó az Office.org... kár, hogy a domain foglalt.

Eleg szerencsetlen nevvalasztas. DDG-n keresve LibreOffice-ra egy 2002-es elegge elvetemult es idiota project jon be: click.

Google mar okosabb es a megfelelo libreoffice-t teszi elore, de akkor is volt mar ilyen nevvel egy kezdemenyezes, megha elvetelt is. Raadasul sokkal nyelvtorobb, mint OO.o...

Nekem sem tetszik az új név, gondolom a francia, brazil és olasz kollégáknak tetszett, akik többségben vannak a Steering Committee-ben, mert az ő nyelvükön ez egy értelmes kifejezés. Az angolban is elterjedt jövevényszó (lásd FLOSS). Szerintem tökmindegy, hogy 2002-ben egy indiai diák már indított egy ilyen nevű projektet, a kutya sem emlékszik már rá. Ma, amikor már minden értelmes név foglalt (Phoenix, Firebird, git - ezek jutnak most eszembe), nehéz valami újjal előállni. Majd magyarosan ejtjük, akkor nem lesz nyelvtörő. :) Vagy ami még jobb, vissza lesz nevezve OpenOffice.org-ra.

"(...) a francia, brazil és olasz kollégáknak tetszett, akik többségben vannak a Steering Committee-ben, mert az ő nyelvükön ez egy értelmes kifejezés."

vs.

"A következő hónapokban a célunk az OpenOffice.org közösség fejlődésének előmozdítása egy új, nyílt, független, meritokratikus szervezet kifejlődése irányába."

--
NetBSD - Simplicity is prerequisite for reliability

Elmagyarázzam?

új - most alakult
nyílt - bárki csatlakozhat
független - nem egy cég diktál
meritokratikus - annak van nagyobb szava, aki eddig többet tett

Nem tudom, hogy találták ki a nevet, csak tippeltem, hogy talán ezért lett az, ami. Mivel az egészet titokban akarták tartani, nem írtak ki róla népszavazást. Nem látom az ellentmondást, amire rá szerettél volna mutatni (vagy félreértettelek).

egy használható gui kéne, nem haszontalan, céltalan, cselekvőképtelen foundation-ök. (izé)

amíg az office 2010 még egy régifos p4-en is elindul kb. 5 mp alatt, addig openofisszal kb 1 perces vinyókergetés lenne a jutalmam. és akkor a funkcionalitásról még nem esett szó.

igen, a legtöbb hétköznapi feladatot meg lehet (valahogy...) oldani oo-ban is, csak kényelmetlen, lassú és ronda. és amíg nem kopogtat bsa-s személyzet rendőrrel karöltve minden ajtó előtt (eljárási joggal), addig semmi motivációja nem lesz a népnek váltani egy szarabb megoldásra.

a firefox sem azért lett népszerű, mert ingyenes. ez csak egyike volt a sok-sok oknak. az oo esetében viszont ez kb. az egyetlen pozitívum, ami eszembe jut.

szerk: azt még kihagytam, hogy szánalmas, hogy még egy olyan nagy cégnek is, mint a novell, saját branch-et kell karbantartania, annyira szerencsétlen a sun-orekül policy.
szerintem.

Ez a foundation nem egy gittegylet, azért jött létre, hogy cselekedjen.

Az indulási időről kkemenczy küldött be minap egy videót, nem 1 perc. Mire jó ezt mindig valakinek bedobni?! A szutyok P4-emen is 4-5 másodperc alatt indul az OOo.

A fejlesztés üteme fel fog gyorsulni, az idióta, hosszadalmas procedúrák kihagyásával hamar szép és gyors lesz a LibreOffice.

A Novell pedig nem tart fenn már saját branchet, mert ma reggel az egész átneveződött LibreOffice-ra. Mától kezdve az Oracle tart fenn saját branchet. :)

ez eddig ambíciózus, de majd meglátjuk, mi realizálódik belőle.

szerk: ja, ezen átsiklottam: "Az indulási időről kkemenczy küldött be minap egy videót, nem 1 perc. Mire jó ezt mindig valakinek bedobni?! A szutyok P4-emen is 4-5 másodperc alatt indul az OOo." nekem nem. és azért kell bedobni, mert kurvára irritáló.
szerintem.

érdekes amit az fsf-es blog-ban írtál a hosszas patch elfogadási procedúrákról. érthetetlen számomra a dolog.

egy kérdés: gnumeric módjára nem lehetne átírni C-be az office fontosabb részeit? én gnumeric-et használok és k*rva gyors, igaz a tudása nekem elegendő. gondolom a "tiszta" java kódnál kivitelezhető lenne, gui-t meg újra kellene csinálni esetleg? elnézést hogy ilyennel dobálózok, neked mégis mélyebb rálátásod van, érdekelne.

... az Oracle meg hasonloan lelkes lesz a community kapcsan mint az OpenSolaris-nal lattuk?

Ez az alapítvány azt a célt tűzte ki, hogy átvegye az Oracle-tól az OpenOffice.org fejlesztését és ügyeinek intézését?
Ha az Oraclenek ez amúgy is terhes, akkor lehet, hogy könnyedén át is adja.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba és kész!

Még a SUN idejében is az volt az érzésem, hogy ha a SUN kiszáll akkor az OOo fejlesztés nagyot nyeklik, mire talpra áll, mire összeáll az a csapat, aminek megvannak a hozzáértő tagjai és megvannak a pénzzel is támogatni tudó és akaró cégek is hozzá.
Ha jól gondolom, akkor ez az alapítvány pont ezért van, hogy egy esetleges Oracle hmm.., kedvezőtlen lépés következményeit elhárítsa, illetve mint írtad, az Oracle "teszetoszaságát" a nyílt kód fejlesztésben kivédje.
Szurkolok, hogy tényezővé nője ki magát!
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba és kész!

lehet az a megoldás, hogy le kell fordítani magyarra az Office előtti nevet is :D pl:
- SzabadOffice... esetleg: 56Office vagy ÖtvenhatOffice így ÖOo :D
- bár ha már az elejét akkor már a végét is kellene pl "SzabadIroda" :-)

Viccet félretéve nekem még az is tetszik hogy OtthonOffice.. vagy "OperaOffice" hisz kellemes vele dolgozni mint egy könnyed opera. (Operett ha esetleg gáz az "Opera" böngészőnév miatt...)

Még alternatíva az OkosOffice :-)...

Lehet érdemes lenne -ha már community- és az Orakulum nem mondott le az OpenOffice névről egy szavazást csinálni, hogy mindenki ötleteljen névvel kapcsolatban (báár akkor meg sok domain spekuláns regizik domain-t...)

Mikorra varhato lokalizalt, magyar verzio? Tervez-e az fsf.hu egy magyar build-et a jelenlegi beta-bol?

Az fsf.hu eleve ebből a forrásból építkezik jó ideje, így nem sok fennakadást és különbséget fognak tapasztalni a magyar felhasználók. Azt még nem tudom, hogy mikor lesz kiadás ebből a bétából. Ha sokat késlekedem, már nem is ez a béta lesz aktuális. Most jobban leköt a fejlesztés (és más munkák), mint a béta kiadása, de ha találok egy szabad délutánt, akkor nekiállok.

Na ez a beszéd! Nekem spec. a név is tetszik :-)

Tekintve az oracle hozzáállását mi várható?

A legtöbb distro jelenleg az openoffice-t szállítja, már a CD-n hiszen office alkalmazás nélkül a legtöbb user nem bírja ki. Az ubi aktív LTS kiadásában is szereplő OO.o sem bírt meglenni az piros logó nélkül.

A google és a redhat már letette a voksát, ők akarnák. Ugyanakkor a google online office megoldása valamint a RHEL vagy a NOVELL enterprise megoldása is a cég szoftvertermékeinek alternatívái, avagy fordítva. Itt nem annyira egyszerű a helyzet mint bevásárolni a sun-t. Nem beszélve arról sem, hogy a különböző programokban megjelenő logó már maga marketingmegjelenés ( főleg ha azt IT világ hírei között járatlanabb user nézegeti ).

Az OO.o egy olyan különleges helyet foglal el a szabad szoftverek között, amit kevés program mondhat el magáról. A legtöbb usernek KELL. Nincs alternatíva, vagy pont erre épül. Gondolom ez egy cégnek elég sokat ér.

windows-ra lesz x64 verzió?
szerintem.

Én nem találtam erre statisztikát csak egyet (érdekes pl, hogy a böngészős statokban ez az infó nincs benne)...

Based on Steam’s January 2010 information, Windows 7 64-bit is used by 19.50% of all Steam users compared to 9.03% for Windows 7 32-bit. Windows 7 managed to take 28.53% of all users, up +5.47% from last month. Windows XP is still dominant with 42.78%, down 2.63% from last month.

http://www.neowin.net/news/windows-7-64-bit-adoption-rate-higher-than-3…

Nyilván ez nem releváns, csak meglepődtem mennyire nincs ilyen stat.

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

http://techreport.com/discussions.x/19384

tessék :D

szerk: ajj, megelőztek :( de amúgy tökmindegy, komolyan nem kell venni, mivel a kérdés eleve félreértésen alapult :) a lényeg, hogy előbb-utóbb az x64 ideje is eljön. szvsz a következő desktop windows x64-only lesz, winserveren ez ugyebár már megvolt. de pl. az exchange is x64-only már.
szerintem.

mint mondtam, a kérdés félreértésen alapult, szóval fölösleges ezen agyalni. tisztában vagyok vele, hogy a globális penetráció közel nem így fest, meg azzal is, hogy a 64-es xp egy átcímkézett ws2003, hogy elmondhassák, hogy ilyen is van.

de a link poénnak elment :P
szerintem.

Szerintem ha fejlesztésről, fejlesztési tervekről van szó, nem abból kell elsősorban kiindulni, hogy most mi van, hanem azt kell megpróbálni kikövetkeztetni mi lesz 1-2 év múlva, hiszen pár hónapba biztos beletelik egy stabil 64 bites kiadás elkészítése.
Az OpenOfficeban egyre több a kiadványszerkesztést elősegítő fejlesztés jelent meg, ami azt jelenti, hogy az igényes felhasználói réteg kiadványszerkesztésre használja, ahol véleményem szerint már jelen pillanatban is a 64 bites windowsok dominálnak, hiszen 3 GB-nél több memóriát nem támogat a 32 bites OS. A kiadványszerkesztés esetén pedig a gépeken lenni szokott CorelDRAW, Adobe CS, QuarkXPress, stb, amelyek ha win7-en futnak, akkor szűken érik be még 4 GB memóriával is, tehát ebben a felhasználói rétegben szerintem a 6-8 GB memória van elterjedőben, ami alapból feltételezi a 64 bites OS-t és az igényt egy 64 bites LibreOffice-OpenOffce-ra.
De win7 esetén még kispénzű, tiszta szoftos felhasználók esetében is kevés a 3 GB, hiszen számomra elképzelhetetlen, hogy egyszerre 1 darab OO fusson a gépen és semmi más. Komolyabb munka esetén min pár böngésző, pár OO, pár grafikai program fut a gépen és a kihagyhatatlan kommunikációs programok futnak, amelyeknek szintén kell legalább 4 de inkább 6 GB ram.

Akkor egy idő után lesz OpenOffice, meg LibreOffice, és a kettő különböző dolgokat fog tudni?

Eddig nagyobbrészt nem fizetős fejlesztők fejlesztették az OpenOfficet? Azt nem értem, hogy akkor most két része szakadt a fejlesztőcsapat? Egyik rész fejleszti tovább az OpenOfficet, másik a LibreOfficet? Tehát akkor mindkettő fejlesztése lelassul?

Angolul lehet már olvasni jókat a témában (pl. ez), talán készül majd egy magyar összefoglaló cikk is. De a lényeg: a LibreOffice fejlődése nem fog lelassulni, mert mindenhonnan fogad el kódot, az Oracle-től is. Az eddigi Go-OO-hoz képes annyival jobb a LibreOffice, hogy nem egy patch setet kell karbantartani, hanem flat git repositorykat.

Komolyan, egyre jobban az az érzésem, hogy te triggerhappy troll vagy. A cikket el kéne olvasni:

"Kezdeményezésünket máris széles körben támogatják a vállalatok, például a Google, a Novell és a Red Hat, valamint mellénk álltak barátaink a brazil BrOffice.org közösségből."

--
trey @ gépház

Itt most te nézted el. Csigaa nem a *Office-ra gondolt imho, hanem a FLOSS projektekre általában. Attól, hogy valami open még nincs nyert ügye. Kell egy-pár ember aki fő állásban tud vele foglalkozni. Persze egy bizonyos méret alatt nem kell.
---
/* No comment */
Ketchup elementál megidézése a sajt síkra

"The news from the Oracle OpenOffice conference was that there was no news." - nyilatkozta Michael Meeks. Eddig talán dübörgött az upstream fejlesztés? Te látsz itt olyan jelentős újdonságot, amire azt mondod, igen, nem hiába dolgozott rajta fél évig ~50 főállású fejlesztő?

Én ezt nem tudom megítélni, hogy ez sok vagy kevés, de azért voltak fejlesztések:

Megújult nyomtatási párbeszédablak
Jelszóval védett dokumentumok kezelése
Kereső eszköztár
PDF export – betűkészlet beágyazás
Eszköztár-panel, táblázat vezérlőelem

Writer
Kisbetű – nagybetű: új üzemmódok
A szótárak, az elválasztás és a szókincstár újdonságai

Impress
Diaelrendezések és -beszúrás eszköztár-elemek

Chart
További grafikus elemek és szövegek elhelyezése
Hierarchikus tengelyfeliratok
Jobb alapértelmezett értékek

Én azt gondolom azért a QA is rengeteg időt elvitt. Persze kérdés a LibreOffice esetében ez mennyi erőforrást jelent, mennyire hátráltatja a fejlesztést, mennyire veszik komolyan.

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

A tesztelés kérdésben logikusan nem tudok segíteni, mert nem tudom nálad mi a QA process.

windows buildek megjelenése:
OxygenOfice 3.2.1: 2010.06.25. (weboldalról megnézve)
OOo Novel Edition 3.2.1: 2010.07.16. (clarity adatbázisból: emiatt lehet pár nap eltérés, általában +2-10 nap), további hibák miatt a szeptemberben is volt 3.2.1 kiadás. A kérdéses időszakban a bugzilla szerint 3 kritikus és pár további hiba lett javítva.

Most csak az utóbbi megjelenést vizsgáltam, de már egy ideje figyelem a tendenciát és a többi kiadásnál is hasonlókat tapasztaltam. Ezt is csak azért tudom, mert az ügyfeleim rendszeresen kérdezik, hogy a mienk mikor jön mert már minden egyéb verzió megjelent.

De ezzel semmi baj nincs, mindenki akkor készít buildet, amikor akar, pont ez a jó benne.
Csak hát a QA nem illik a képbe nekem, mert ha a régi QA team jól végezte a munkát, akkor a megjelenés után onnan valóban érdemes gyorsan buildelni. Ha viszont a QA nem megfelelő a közösségi megoldásoknál, akkor onnan nem érdemes hamar buildeni, hanem kicsit várni kell.

Ugyanakkor simán lehet, hogy az én eszmefuttatásom a hibás.

A konkrét tesztelés nálam így történik:

Legalább egy hónappal a tervezett OOo kiadás előtt buildelek magamnak egyet és elkezdem napi szinten használni. Ez persze Linuxos környezetben teszem. Amikor eleget teszteltem, készítek előzetes Windowsos buildet és blogomon megkérem a hallgatóságot, hogy teszteljenek. Ezt kiegészítve a Windowsos és Linuxos buildek elkerülnek a barátaimhoz is, akik napi használatban tesztelik. Semmi speciális nincs, nincs tesztelő gurum aki mindent kipróbál. Legutóbb smoketestet is futtattam. Ezek után készülnek el a végleges verziók, amelyet szintén a barátaimnak adok ki tesztelésre. Persze figyelem az egyéb kiadásokat, pl az FSF.hu kiadásait, s megpróbálom az azóta felmerülő problémákat megnyugtató módon orvosolni. Én nem is találkoztam kritikusnak nevezhető problémával az OxygenOffice-szal kapcsolatban, csak talán eggyel, Linuxon – de azt orvosoltam.
Én mondjuk a két megjelenés közötti időszakban nem látok kritikus FIX-et, vagy csak nekem kerülte el a figyelmemet? Persze későbbről van ilyen is, de azt hiszem ezt itthon csak a 3.3.0-ban fixáljuk majd, ha csak váratlan helyzet nem adódik.

Azt gondolom a QA fontos része a munkának, s ugyanakkor itt lehet a leginkább spórolni. A StarDivision patch befogadása tényleg lassú és körülményes volt ( (jaj, fordítás vagy elég vmiklos GSOC upstream ügymenetére gondolni), de a QA szerintem jól működött. Persze itt is túl minden volt bürokratikus, ezen nyilván lehet javítani. Nekem tetszett, hogy a CWS-ek minden platformra megjelentek, feltétele volt a bekerülésnek (már ha nem platfor specifikus dologról volt szó). De pl. az ooo-buildel kapcsolatban bennem is megfogalmazódott, amit Tímár Andris is leírt a blogjában: „Próbálom lefordítani Windowsra az aktuális állapotot, de ez nem egyszerű feladat. A fejlesztők Linuxon dolgoznak. Tapasztalom, hogy ami Linuxon simán lefordul, az Windowson nem mindig. A napokban többször is küldtem build logot azoknak, akiknek a kódja miatt hibára futott a build. Örülnek neki. Én is örülök, hogy ezzel hasznára lehetek a közösségnek, mert egyébként Windowson OOo-t buildelni sokkal rosszabb, mint Linuxon.”

Persze a magyar közösség számára nem sok változás lesz összességében, mert a széles körben alkalmazott hazai változatok eddig az ooo-build-et használták, amelynek leszármazottja a LibreOffice.

Na és persze jó látni a mostani pezsgést a projekt körül.

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

szokásosan kicsit elkalandoztál és mindenki másra terelted a fonalat (pontosan tudom, hogy András mit és hogyan dolgozik, mert a Novell buildszerverén készíti az fsf buildet, ahogy korábban te is használtad), de próbáljunk fókuszt tartani.

röviden:
- nálad nincs igazi QA
- go-oo.org projektben közvetlen nincs QA és nem is várod meg más cég QA folyamatát (pl. Novell)
- szerinted nincs probléma az általad készített szoftver minőséggel, amelynek patch-setje több mint 2000 javítást tartalmaz, ami nem ment át az általad magasztalt QA folyamaton

Szóval egy olyan QA folyamatért aggódsz, amit eddig nem igazán használtál te sem. erre próbáltam rávilágítani.

A jövőben legfeljebb sokkal több alpha és beta lesz, ahogy egy igazi nyílt forrású projektnél illik.

Azt gondolom, hogy a QA esetemben hozzájárulók kérdése. Ha van aki tesztel, azt örömmel veszem, ha nincs egy részét csinálom. De nyilván mindenre nincs erőforrásom.

Mivel a go-oo projektben nincs közvetlenül QA, ahogy írtad, és a hozzájárulók száma reményeink szerint nőni fog, el kell gondolkodni valamilyen megoldáson. Számomra a CWS megoldás szimpatikus, legyen letesztelve a támogatott platformokon a cucc. Valami hasonlót kellene bevezetni. Mondjuk a triviális javítások elkerülhetik ezt az utat, azért triviálisak.

Igazad van, a Novell QA folyamatát nem tartom eléggé erősnek. Ez egy mai jelentésem: https://bugs.freedesktop.org/show_bug.cgi?id=30495

Az OOOP minőségével kapcsolatban rossz tapasztalatokat nem hallottam. Persze egy szoftver soha nem készül el.

Az általam használt patch-készlet nem jutott el a QA-ig. A többségéből szerintem CWS sem lett, s ez nem a QA hibája!

Nem magasztalom, csak szerintem azzal nem volt baj.

Mivel go-oo=oo.o+patchek ezért áttételesen mégis beépült az a QA a termékbe.

Release early, release often... Ha a minőség platformtól függetlenül egységes lesz, lehetőleg magas, az jó.

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

> Azt gondolom, hogy a QA esetemben hozzájárulók kérdése. Ha van aki tesztel, azt örömmel veszem, ha nincs egy részét csinálom. De nyilván mindenre nincs erőforrásom.

Az általad említett QA és az általad végzett ellenőrzés között hatalmas a szakadék.

> Igazad van, a Novell QA folyamatát nem tartom eléggé erősnek. Ez egy mai jelentésem: https://bugs.freedesktop.org/show_bug.cgi?id=30495

Megint terelsz. Kicsit szálljunk már le a földre. Ilyen bugokkal tele van az OOo hibabejelentő-rendszere, csak ott feature-nek minősítik.

Én itt kizárólag P1 bugokról beszélek, amelyre L3 process készül, nem custom animation cuccról. Ilyenkor az ügyfél külön buildet kap a gyors javítás miatt. A kettőt vicc egy lapon említeni.

Mindenesetre lassan megszünnek a profilok és el kell gondolkodni mindenkinek, hogy tovább forgálcsolja-e az erőforrásokat, vgay csatlakozik a LibreOffice-hoz. Ennek megfelelően nagyon bízom benne, hogy megszűnik a fsf build is és sikerül LiberOffice-ban gondolkodni. Te nem tervezel ilyesmit? Kicsit konszlidálná a magyar helyzetet is.

Mivel a forráskódot én is lefogatom ezért az a QA alap szinten, lefordul, megvalósul. Nyilván egy code review sem ártana.

Ebben az esetben az említett köztes időszakban nem volt P1 besorolású bug.

Természetesen, ha megszűnnek a profilok (distro-conf-okra gondolsz?), akkor ezt én is követni fogom. Erről nyilván majd Andrással is egyeztetek. Egyelőre annyira új a dolog, hogy érdemes várni, figyelni fejleményeket és hozzájárulni a forkhoz. Mivel az ooo-buildról, vagy nevezzük go-oo-ról beszélünk - amelyhez András és én is automatikusan betettük azokat a javításokat és fejlesztéseket, melyeket fontosnak gondoltunk - ez a jövőben sem lesz másképp. Ha jól láttam András már be is küldött javítást és én sem maradok tétlen.

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

A forrás lefordulásával semmilyen QA nem valósul meg. Az egyik egy technikai ellenőrzése a kódnak, a másik pedig funkcionális ellenőrzése a programnak.

> Ebben az esetben az említett köztes időszakban nem volt P1 besorolású bug.
mármint a freenodon. A Novell ügyfelei/ügyfél oldali beta teszterei nem ide jelentenek be, a gyors (1 hét) javítás után csak a commit jelenik meg a freenode-on, mert nincs értelme ott is megnyitni majd lezárni egy bugot.

Más köztes tartományt vizsgálva tudom, hogy volt a freenode-on is, ha jól emlékszem a Calc esetében. Egy tendenciáról, amit követsz és csak rámutattam arra, hogy nyilván van oka későbbi build kiadásának, ha valaki (pl. Novell) támogatást ad rá. Andárssal erről többször beszéltünk: káros a felhasználók szempontjából korán stabilnak kikiáltott verziót megjelentetni és nem várni két hetet csak azért, hogy valami előbb legyen kint.

"mármint a freenodon. A Novell ügyfelei/ügyfél oldali beta teszterei nem ide jelentenek be, a gyors (1 hét) javítás után csak a commit jelenik meg a freenode-on, mert nincs értelme ott is megnyitni majd lezárni egy bugot."

Akkor egy lehetőség a fejlődésre: Lehetne az összes commitban jelezni, ha ilyen bugok kerülnek javításra. n#xxxxx vagy bnc#xxxxxx módon legalább. A freenode-on meg szerintem csak IRC van, közvetlenül ott nem jelennek meg bugok. Csak áttételesen - hivatkozva rájuk, vagy commit esetén.

"Más köztes tartományt vizsgálva tudom, hogy volt a freenode-on is, ha jól emlékszem a Calc esetében." - citation needed

Köszi a jelzést, a tapasztalatokat be fogom építeni a kiadási folyamatba.

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

> Akkor egy lehetőség a fejlődésre: Lehetne az összes commitban jelezni, ha ilyen bugok kerülnek javításra. n#xxxxx vagy bnc#xxxxxx módon legalább.

nem tudom mit kezdenél egy L3 process SWAMP ID -jával :)

> freenode-on meg szerintem csak IRC van

igen, freedektopra gondoltam és elirtam, talán ezért értetted félre.

> "Más köztes tartományt vizsgálva tudom, hogy volt a freenode-on is, ha jól emlékszem a Calc esetében." - citation needed

Akkor gondold azt, hogy nincs így, a nyílt forrás erre is felhatalmazást ad, nekem mind1.

> Nem gondolom, hogy nincs így, csak tényleg érdekel.
Mivel ez a te érdeked, akkor talán érdemes utána járni.

A fontosabb észrevételeket megtettem, adtam támpontokat, de végigvinni nem tudlak úton, mert én másfele tartok. Elmondtam, amit gondolok ezzel kapcsolatban és természetesen megteheted, hogy figyelmen kívül hagyod. Sajnos tovább ezzel nem tudok foglalkozni.

Az általad készített verzió olyan, mintha az általam openSUSE-ba készített csomagok kedvéért egy új disztribúciót indítanék és leforkolnék a Factory-ról. Nem tagadom sokszor volt már ilyen gondolatom, de rájöttem, hogy ennek semmi értelme, ráadásul a felhasználói bázist összezavarja a sok verzió, főleg akkor, ha egyedi fejlesztés minimális benne és egyszerű csomagolásról van szó.

Személy szerint a legjobb időpontnak tartom a DF alatt egyesíteni az erőket, hívják akárhogy is az általuk készített Office programot, ahogy azt András meg is lépte és amiért minden elismerésem érte. Ez kritikus időszak a projekt kezdetekor és nagyfokú elkötelezettséget és támogatást jelent egy ilyen elhatározás.

> Van még valami bűnöm?
Ez a kommunikáció, ami alapvetően QA kérdéssel merült fel nagyon tipikusának mondható, amikor is a kényes kérdéseket a válaszra sem méltatod, viszont folyamatosan új frontokat nyitsz az elterelés maximalizálása érdekében. Van aki szereti ezt, sőt mulattatja, de ne haragudj, nekem ez nem jön be.

Köszönöm szépen a segítséget.

Az OxygenOffice-nek történelmi okai is voltak. Egyrészt a karácsonyfa build ötletét karolta fel 2005/6 táján, meg pl. előtesztelési mód volt pl. az FSF.hu build ooo-buildra történő váltásakor. Ezért azt gondolom nem áll a párhuzam az openSUSE hasonlatoddal. Persze az idők változnak és meglehet, hogy a jelenlegi helyzetben már nem jelent pluszt az LibreOffice-hoz képest. Bízom benne András jól döntött, s folytatjuk a munkát együtt.

QA kérdésben leírtam mindent amit kérdeztél, de igen, szeretem az egészt is látni. Meg az apró részleteket is.

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

> pl. előtesztelési mód volt pl. az FSF.hu build ooo-buildra történő váltásakor.

én még nem hallottam olyanról, hogy a buildelés tesztelésére készítettek volna új disztribúciót/forkot. ez nem ok, ez magyarázkodás, illetve önigazolás. A valódi okok nyilván nem ezek. De mint mondtam, az open source szabadsága nem szab jogi vagy technikai korlátokat, ez a gyönyörű benne, hogy a hozzájárulók saját döntései a meghatározók. És azt is megértem, hogy nem érted, nem tetszik, vagy egyszerűen hülyeség amit mondok, természetesen ez is benne van a pakliban.

és ahogy nézem, nem én gondolkodom egyedül így, ma olvastam a listán:

"One thing I would like to see the Document Foundation undertake is to
(or at least try to) organize the other major efforts, like Go-oo,
OxygenOffice and NeoOffice - and maybe now even IBM/Lotus Symphony - to
eliminate duplication of effort and coordinate patch acceptance, etc."

Elgondolkodtató, hogy miért nem említik meg az fsf.hu buildet...

Akkor most a go-oo kódjából fog ez kiindulni, és annál is jobb lesz ez?

A "régi" go-oo (ooo-build) kódtárolók átnevezése és a go-oo foltokat elkezdték belefűzni a különféle modulok tárolóiba. Ezzel egyre inkább különbözni fog az OOO320m7-től amely a legutolsó verzió ami még OOo forrás + go-oo patchek modellre épült. A mostani lépés lényegében beveteti, hogy LibreOffice forrásra épül a termék.

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