Megszületett az 1 000 000. commit a KDE subversion tárolójában

KDE

A KDE bejelentette, hogy megszületett az egymilliomodik commit a Subversion verziókezelő rendszerében.

"Csodálatos mérföldkő a KDE számára," mondta Cornelius Schumacher, a KDE e.V. igazgatótanácsának elnöke. "Ez egy nagy, sokszínű és tehetséges csapat által végzett több éves kemény munka eredménye, akik azért jöttek össze a világ minden tájáról, hogy fejlesszék a világ egyik legnagyobb és legátfogóbb szoftvertermékét."

A 500 000. commit 2006. január 19-én, a 750 000. huszonhárom hónappal később, 2007. december 18-án esett. Ezzel szemben az 1 000 000. mérföldkőnek számító commit eléréséhez mindössze további tizenkilenc hónapra volt szükség.

"A KDE-n belül a fejlesztés üteme gyors és egészséges, és az új fejlesztők meghökkentő ütemben csatlakoznak hozzánk," jegyezte meg Schumacher. "Az elmúlt három évben minden hónapban átlagosan több mint húsz új fejlesztő ejtette meg az első commit-jét."

A bejelentés itt olvasható.

( honorshark | 2009. 07. 21., k – 20:32 )

Jo unneples... "As such, parts of KDE development will be migrating to Git.".

...fejlesztés üteme gyors...jegyezte meg Schumacher. Hogyne lenne az? :))

( subchee | 2009. 07. 21., k – 20:39 )

Nem flame-threadet akarok indítani, szigorúan szvsz, de a KDE 4.2.x (és az 4.3 RC builded) óta komolyan gondolkodom, hogy Gnome helyett ez lesz a default DE -m :)
A 3.5.x -höz képest szebb, testre szabhatóbb, stb. (normális gépen normális mennyiségű RAM -mal gyors is)

Én az a vad KDE 3.5 párti voltam, akit emlegettek, de a 4.3-nak a bétájával már elégedett vagyok. A 4.2 is már jó volt, de ott még volt rá okom, hogy ne minden gépen váltsak a 4-es sorozatra, viszont úgy nézem, hogy a 4.3-nál már tényleg nem tudok (komoly) hiányosságot mondani.

---
Nagy Péter

"4.3-nál már tényleg nem tudok (komoly) hiányosságot mondani"

Stabilitás...? Tesztelgetem a jelenlegi rc-t, de állandóan elszállogatnak a komponensek. Nojó, lehet h ez nem a kde-alap problémája, viszont az alkalmazások használhatósága is mércéje a platformnak.

Egyébként én is úgy látom h a 4.3-al kezd "szerethető" formát ölteni a kde4

Szépnek szép.

De én épp downgrade-en gondolkozom.

Ugyanazon a hardware-en lassabb, mint a KDE3.5, és míg a 3.5 kiforrott volt, ebben egy csomó dolog hiányzik.

Funkciók is, beállítási lehetőségek is.

A 3.5 testre szabhatóbb, gyorsabb. A szépség, nekem, másodlagos szempont.

+1
Ami meg a szépséget illeti, nálam KDE 3.5.10-en egy vékony, teljesen átlátszó panelem van fent, csak az óra és pár ikon látszik rajta, AWN van alul, Screenletek az asztalon, az ablakkereteket az Emerald adja, pár hasznos dolgot pedig a Compiz, a KDEmod legacy alap témája pedig szerintem szebb, mint az Oxygen stylus, vagy mi is a neve. Tehát alap kinézetre akár GNOME is lehetne.

Azért kisebb meglepetések még érhetik az embert:)

-----------
If you try using the skulpture theme for kde and apply the same theme for gtk
applications in kde's system-settings, gtk apps stop running. This seems to be a known bug.

Reproducible: Always

Steps to Reproduce:
1.Emerge gtk-engines-qt-1.1 (or -r1)
2.Apply the skulpture theme in kde
3.Try to run firefox or any other gtk app

Actual Results:
The apps fail to start

Expected Results:
To start of course :-)
---------

nekem Fedorán adta elő, pár hete...
Üdv
VJ

( sarkanyolo v | 2009. 07. 21., k – 21:21 )

LEGnagyobb, LEGátfogóbb.
Hááát...

( kelemengabor | 2009. 07. 21., k – 22:31 )

"te elefánt, érzed hogy dübörgünk?" rovatunkban ma: a KDE projekt és az ő fordításfrissítő szkiptjük, meg egy kiragadott példa:

(22.13.00) kelemengabor: http://websvn.kde.org/trunk/l10n-kde4/hu/messages/kdeadmin/knetworkconf…
(22.13.06) kelemengabor: na itt van például ez
(22.13.23) kelemengabor: valaki grepelje meg, hogy hányszor kommitolt bele scripty
(22.15.00) kelemengabor: $ grep -ic scripty knetworkconfmodule.po.html
(22.15.00) kelemengabor: 65
(22.15.00) kelemengabor: gabor@gabor-desktop:/tmp$ grep -ic lengyel knetworkconfmodule.po.html
(22.15.00) kelemengabor: 8
(22.15.03) kelemengabor: muhahah
(22.15.19) kelemengabor: lengyel = Szántó Tamás, karbantartó
(22.15.24) kelemengabor: scripty = bot
(22.15.38) kelemengabor: így könnyű összehozni egy valag kommitot :D

Persze bizonyára dolgozik ott egy rakat valódi ember is, de nem csak ők :P
/troll

Nyilván sok commit-ot csinálnak scriptek, elég csak a merge folyamatokra gondolni.

Másrészt a hivatkozott példában scripty rendszeresen update-eli, hogy az adott nyelvi elem melyik forrásfálj melyik sorában található. Ez fontos egy fordítási projekt esetén, nyilván szükséges hozzá commit, és ettől függetlenül sokan dolgoznak rajta... :)
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

Nem ertek egyet veled. A forditasi fajlokban igenis hasznos dolog, hogy ha megvannak ezek a fajl:sorszam parok, megpedig a megfelelo helyen, ugyanis egy okosabb forditoeszkoz meg tudja ezeket jeleniteni, ha a forras elerheto, es ha peldaul .ui vagy .glade fajlokrol beszelunk, akkor akar maga a form is megjelenhet. Ez azert is jo, mert kontextusaban tudod forditani a szoveget, ami, valljuk be, oriasi elony tud lenni - nalad. Mert a fejlesztoknek aztan baromira nem erdeke, hogy ezek az infok benne legyenek, ez mind-mind a forditok kenyelmet szolgalja.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

hát hmm, erről jutott eszembe, hogy sok helyen a fordítókra néha jobban figyelhetnének. pl. az ilyen "of", "a", "at", "be" szintű string-eknél, amikor rohadtul nem derül ki, hogy mit is akarnának közölni, nagyon hálás dolog :) .ui, .glade fájllal nem nagyon dolgozok, inkább .po, vagy sima php array-ek, de kommentezni ott is lehet, .po-ban van direkt erre külön mező, csak senki nem használja :)

szerintem.

Persze hogy hasznos, nem arról van szó.
Arról van szó, hogy ezt nem kell havonta kommitolni a verziókövetőbe.
Mert nem, ismétlem _nem_ releváns információ.
Releváns az, ha módosul egy fordítás, az verziókövetőbe való.
Ugyanis, mint mondod ez csak a fordító kényelmét szolgálja, igen. A fordítót viszont az érdekli, hogy a ma elérhető forrásban mi van és hol. Ami tegnap vagy egy hónapja volt (a foobar.c 45 sora helyett a 47.-be került egy sztring, hát ezt tényleg meg kell örökíteni svn-ben :P), lényegtelen, a mai forráshoz kell fordítást készíteni. Épp ezért, a ma generált po-val nyugodtan felül lehet írni a tegnap generáltat, semmi lényeges információ nem vész el. És pont ez az, amit a damned-lies csinál - verziókövetőbe mentés nélkül.

Mondjuk az is igaz, hogy így a marketingcsapat nem tud ilyen bombasztikus bullshit híreket generálni.

Ejj... nyilván az új verzió tag vagy merge-elése után kell frissíteni ezeket az információkat, hogy oda-vissza kapcsolat legyen a nyelvi properties és a forrás között. Persze ez az információ nem létfontosságú, de sokat segíthet... :)

A verziókövető pedig pont ilyenre való, hogy bármikor elő lehessen állítani egy tegnapi vagy két hónappal ezelőtti build-et. És ha ráfutnak erre scriptek, amelyek ellenőriznek és számolnak, akkor nem lesz eltérés, ha minden verziókezelt. Persze ez sem létfontosságú, csak sokat segíthet... :)

A Damned Lies (projekt név?) miképp működik? Mutass egy példát, ahol látszik, hogy egy nyelvi property hol és hány helyen jelenik meg a forrásban, érdekelne a működése.
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

SZVSZ ez tenyleg nem a verziokezelobe valo. Ime ketto lehetseges megoldas, nem tudom a gnome melyiket csinalja, vagy egy harmadikat-e:

- van egy szkript ami eloallitja a kivant informaciot, de az nem kerul be a verziokezelobe. Az eredmenye viszont bekerulhet a kiadott .tar.gz-be.

- minden egyes commit elott lefuttatunk egy (masik) szkriptet, ami frissiti a forras <-> nyelvi elemek adatbazist, igy az benne lehet a verziokezeloben, ha tenyleg ez az igeny, de nem kellenek neki kulon commit-tok.

Kicsit kapcsolodik ide, dolgoztam roviden egy olyan projekten, ahol pl. az autoconf altal eloallitott configure szkript is benne volt a verziokezeloben, es a kedves fejlesztok be is kommitteltek ha valtozott. Namost mivel ugye mindeki mas verzioju autoconf-ot hasznalt, a configure szript allandoan valtozott. Baromi rossz volt olyan kommitokat nezegetni, ahol 5 sor valtozott a forrasban meg kb. 5000 a configure szkriptben. De biztos lehetett volna szep statisztikat csinalni, hogy mennyi sok uj kodot irtunk....

Kiadott tar.gz-be egyátalán nem való ez az információ, nem az a célja. A cél gondolom az, hogy egyetlen egy helyen fusson le a script jól meghatározott feltételek alapján triggerelve és _minden_ fejlesztőhöz és _minden_ fordítóhoz eljut az információ. Ha ezt megteszi a fordításhoz használt tool is, akkor nincs baj, de én alapvetően a központi megoldást jobban szeretem, könnyebb módosítani rajta és mégis mindenhova eljut.

Az utolsó példád pedig valóban fejlesztői hülyeség... erre találták ki az ignore-t... :)
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

Na jo, hat akkor nem kell a tar.gz-be tenni. Ettol fuggetlenul mindket vazolt megoldas jobb, SZVSZ. A szkriptet egyebkent persze bele lehet tenni a verziokezelobe, sot, ajanlatos is, legyen a build folyamat resze a lefuttatasa. Igy kozponti, mindenki ugyanazt futtatja, megsincs sok "szemet" commit.

Az utolsó példád pedig valóban fejlesztői hülyeség... erre találták ki az ignore-t... :)

Hat mondtam en nekik, hogy ezt igy ne csinaljuk, de azt hiszed hallgattak ram? Ahhoz meg kis hal voltam, hogy kitoroljem a configure-t.... igazabol azt akartak, hogy ha valaki svn-bol fordit, akkor ne kelljen neki autoconf, automake, libtool, etc. Szerintem meg aki svn-bol akar forditani, az szepen installalja ezeket maganak...

Igen, tényleg ez a neve :). (fejlesztő szerint: There are lies, damned lies, and statistics. Previously, we had statistics, now we have damned lies.)

Itt van pl egy ilyen projekt, hogy alacarte: http://l10n.gnome.org/vertimus/alacarte/master/po/hu
A letöltés ikonok alatt megtalálod az aktuális git forrásból generált pot fájlt és az abba mergelt hu.po-t, illetve a fenti alacarte linken az összes nyelvet és branchet. Ezeket nem tartja gitben, csak az oldalról tölthető le. Figyeli a commit levelezőlistát, és ha valamelyik fájl frissül (a POTFILES.*-ban említett forráskód, vagy fordítás), akkor frissíti ezeket (po esetében persze csak a megfelelő po-t frissíti, a többi nyelvet nem), felülírva a korábban itt lévő fájlokat. Ezeket a fájlokat, ha olyanom van akkor letöltöm, lefordítom, betolom gitbe és kész. Így mindig naprakész hazugságokat kapunk, a nem naprakész meg senkit se érdekel, így nincs is olyan szkript ami ezeket frissítgeti a gitben, az előzmények meg szép olvashatók maradnak :).
Az egyes branchekben, tagek alatt meg szintén ezek a fájlok találhatók, ha naprakészek, ha nem, de ennek igazán nincs is gyakorlati jelentősége: ha a fordító nem frissítette, akkor a generált mo-ban nem lenne több lefordított üzenet, legfeljebb lefordítatlan, a megjegyzés meg eleve bele se kerül: a felhasználó végeredményben ugyanazt látja.
Nem tudom, hogy a KDE esetén mit ellenőriznek és számolnak szkriptek, de itt ilyesmi nincs. Ahogyan nyelvi property-k sem, ezek nálad konkrétan mik?

Lehet, hogy nem értem tisztán a leírtakat, de nem látom azt a feature-t, hogy valami tool összeköti a nyelvi fájlt a forrásfájlokkal - tehát nem látom biztosítottnak a lehetőséget, hogy a fordító (ember) megnézhesse, hogy az adott lefordítandó szöveget a programban hol és milyen kontextusban használják.

Segítenél, hogy ez hogy működik GNOME esetén? A KDE-s példában ez látszik (és a scripty script a megjegyzésekben frissíti a forrásfájlok hivatkozott sorait, mivel a fejlesztés során nyilvánvalóan azok elcsúsznak): 


#: kadddevicecontainer.cpp:142 knetworkconf.cpp:67 knetworkconf.cpp:99
msgid "The format of the specified IP address is not valid."
msgstr "A megadott IP-cím hibás formátumú."

És a kadddevicecontainer.cpp megfelelő sorában ilyesmit látok: 


KMessageBox::error(this,i18n("The format of the specified IP address is not valid."),i18n("Invalid IP Address "));

Ha a fenti msgid kétértelmű lenne, akkor a fordító meg tudja nézni a fent hivatkozott forrásfájlok adott soraiban, hogy milyen kontextusban áll elő az üzenet, és annak megfelelően fordítja le. Ilyenre tudsz példát mondani?
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

A Gnome is ugyanilyen xgettext-tel generált po-kat használ, pl a fenti alacarte po-ja ilyen:

#: ../Alacarte/MainWindow.py:167
msgid "Name"
msgstr "Név"

Aztán a fent vázolt folyamatos frissítés eljárás garantálja, hogy amit a d-l oldaláról letöltesz, az azokra a sorokra hivatkozik, amit a gitweben vagy helyi klónban láthatsz.
(mondjuk, a konkrét példa eltér 4 sorral, ez valami bug lesz, de általában pontos)

És amikor lefordítottad, akkor visszakerül egy olyan a verziókezelőbe, ami módosított nyelvi részeket és forrásfájl hivatkozásokat tartalmaz...

Annyi problémát látok ebben, hogy egy régebbi nyelvi fájl késői kommit művelete a forrásfájl hivatkozások elcsúszását tudja okozni, mivel nem okoz konfliktust script általi és a fordító általi módosítás... ízlések és pofonok... :)
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

Igen, de igazabol a forrasfajl-referencia modositasara jelenleg semmi VCS nem kepes, mert a diff/patch mindig kornyezet alapjan megy, marpedig a msgstr "" es a msgstr "Akármi" tulsagosan is elter. Ezert van az, hogy a meglevo forditasokat mindig szinkronizaljak az adott forrasfahoz.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Szerintem nem mindegy, mi van a verziókezelőben. A commit nem fáj. És inkább legyen több commit, minthogy sérüljön az integritás, akármilyen apró dologról van szó. Ezért nem értem ezt a hatalmas ellenérzést a scriptek által történő commit ellen.

A másik kérdésre visszatérve: volt rá példa, de az már régen volt. Az utóbbi öt évben Java-val foglalkoztam, ott nincs po, ott vannak properties fájlok. :)
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

Nem a commit fáj, hanem az ha egyrészt átláthatatlan hogy mikor mi történt ténylegesen a verziókezelőben, na meg az ha a marketingosztály a kommitok számával büszkélkedik, amiknek meglehetős részéről lehet tudni hogy automata.
Po esetén nem sérül az integritás. Java properties az más, élvezettel szoktam hallgatni illetékeselvtárs rémtörténeteit a Mozilla fordításáról :P

Nem mindegy, mert rengeteg projektnel az aktualis verziokezelos valtozatot forditod. Viszont a fejleszto nem tudhatja, a fordito epp mikor meltoztatja kicheckoutolni a po fajlt - masik oldalrol viszont a fordito van a legjobban felhaborodva, ha egy nem konzisztens nyelvi fajl van a rendszerben.

Szoktam po-t forditani, bar mostanaba egyre kevesebbet. A linguist-hez igazabol egyik forditoprogram sem er fel, a linguist meg nem tud po-t. Inkabb Qt alapu programokat forditok.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Ácsi, ez már a fejlesztőbácsi bűne :).
Igaz, hogy még nem terjedtek el az olyan korszerű po-kezelő rendszerek, mint a Transifex vagy a Launchpad (:P), de string freezelni és levelezőlistára levelezni egy csomó helyen eddig is tudtak, a többiek meg állják csak a kövezést.

Abban igazad van, hogy a mergalasokat egy kommitba is ossze lehetne presszurazni - ha erre az svn lehetoseget adna. Tudtommal azonban csak a gitnel van olyan, hogy squash, ami osszelapitja az egy branch-bol torteno mergeleskor a commitokat egyetlen nagy committa.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Nem ez így nem igaz, de szerintem a gnome-ban nagyon nagyon buta dolgok vannak. Egyszerűen durva véleményt akartam megfogalmazni, csak hogy egy kis kontrasztot adjak arra reflektálva, hogy mennyire hülye a KDE.
Mindegyiknek megvannak a saját hülyeségei, de mivel nem szeretem, ha csak az egyiket szapulják (itt KDE), ezért benyögtem egy gnome ostorozást. :)
Ettől még igazat kell adjak a kommentednek, bár Te szerintem csak szarkasztikus voltál. Hehehe :)

Ha azt veszed, hogy milyen programokat válogatnak bele a DE-be, mint default alkalmazások, akkor nagyon nehéz szeretni. ugye a lényeg a gnome csapat szerint a minimal állíthatóság és minimal feature, hogy a felhasználó ne zavarodjon össze. Ezért olyan karcsú a gnome számomra. Az a másik, hogy éppen ezért kivesznek dolgokat GUI részekből, amik állíthatóak ugyan, de csak a gconf-on keresztül. Ráadásul már a gconf-ot is dobják és helyette egy hasonló, de azért kicsit más gnome-config architektúra lesz benne. De a probléma ezzel az, hogy tulajdonképpen tovább viszik azt, hogy a felhasználó ne tudjon állítani semmit sem a GUI-n, csak a gconf/gnome-configon keresztül, ha expert. Egyébként nekem tetszik a gconf "registry" elgondolás, csak hogy tisztázzuk.
Sajnos a legroszabb tényleg a default alkalmazások:
- brasero (hol van ez egy nero, vagy egy k3b-hez képest)
- eog (ne is beszéljünk róla, mert a win-es képnézegető minimal alkalmazásnál is szegényesebb)
- f-spot (egyetlen előnye a digikam-hoz képest a flickr és picasaweb támogatása volt, ha jól tudom ez már van digikam-ban pluginként)
- totem (jajj, jajj , ajajajaja, hajj, brühühühühü, jajajaja, mást sajnos nehéz róla mondani)

Most csak kimondottan Qt-s KDE-s alkalmazásokkal hasonlítottam össze, de megtehettem volna hasonszőrű GTK-s app-okkal is. Ugyanis azokból is vannak sokkal jobbak, mint a default gnome felhozatal.
Én azt szoktam mondani, hogy a gnome a linux-ok windowsa (csak felületre és állíthatatlanságra gondolva)

hát én nem tudom, gnome-nál mindig ezzel jönnek, nekem még nem volt olyan dolgom, amit akartam volna, de nem tudtam volna beállítani. na nem mintha azzal tölteném a napjaim, hogy "állítgatok".

egyetlen dolog, amivel gondom volt, az a hang. de ez már nem a gnome hibája, szarból nem lehet várat építeni.

az említett példáid nem a legjobbak. mondhatnám, hogy a brasero nekem megfelel a célra, illetve a gtk-s nero is :) a képnézés meg off, mivel semmi nincs linuxwide, ami felér az irfanview-vel. f-spotot sose használtam, így nyilván igényem sincs vele szemben (annyit tudok, hogy valami képbuzeráló). totemet meg idejét se tudom, mikor indítottam, vlc-t használok, ami mellesleg wxgtk-s volt, de nem szoktam szívgörcsöt kapni a qt-s felülettől sem :)

a gconf érdekes, szép meg jó, de megint csak olyan dolog, amit 1x megnéztem, és azóta se érdekel, valamiért nem szokott rámtörni a roham, hogy nekem most valamit állítgatni kell. ez a gnome-config is az újdonság erejével hatott, de valószínűleg annyit fogom használni, mint az elődjét ;)

szerintem.

+1

Utoljara akkor piszkaltam a gconf-ot, amikor a compiz (akkor meg beryl) beallitofelulete bugzott, es nem mentette el a kocka tetejere es aljara teendo kep utvonalat rendesen, kezzel kellett utanaigazgatni. De az mar reg volt, tan igaz se volt.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

-Brasero egyre jobb, már lassan megüti a használható cdíró színvonalát. Igaz, én is k3b-t használok.
-EOG-ot én sem szeretem, gthumb van helyette.
-F-spot, nos, én még mindig nem értem, mire való az az izé...
-a totem viszont jó. szépen fejlesztik, már majd minden formátumot lejátszik, a sok általam nézett softsub-os .mkv miatt nem alapértelmezett lejátszó csak.
Mindazonáltal maga a gnome nekem jobban bejön, mint a kde. Jobban használható számomra, mint a kde, legyen 3.5, vagy 4.3, tökmindegy.

---------------------------------------------------------------------------------
A Linux nem ingyenes. Meg kell fizetni a tanulópénzt.
Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!!

-Brasero egyre jobb, már lassan megüti a használható cdíró színvonalát. << Hehe.. lassan megerjuk hogy kiir egy CD-t ... hmm. Bar a legutobbi meg mindig csak par kidobott lemezt eredmenyezett. GO FOR IT!!! Megtudjak csinalni! Erzem, egyszer, kepes lesz a kolkom CD-t irni vele, s majd meselhetem hogy az en koromban... :)) (Btw en is K3b-val irok mivel nem akarom a kukam etetni)
-F-spot, nos, én még mindig nem értem, mire való az az izé... << +1.
-a totem viszont jó. szépen fejlesztik, már majd minden formátumot lejátszik, a sok általam nézett softsub-os .mkv miatt nem alapértelmezett lejátszó csak. << Hat en hard/soft-subot is nezek de azon nem valtoztat hogy iszonyat buta lejatszo. Kb mint Dragon player. "Lejacca' a filmed, ingye' van, openszorsz, kuss"... maradok SMplayer/VLC/barmi hasznalhato parti.

"mást sajnos nehéz róla mondani"... sz.. ? :))

Nyilvan te vagy az az emberke, akinek a Gnome nem jon be. De ilyenek is kellenek, mert a KDE-nek is fejlodnie kell.

Btw, miert kell mindenkinek ugyanaz tetszen, mint a masiknak? Szivem joga, hogy az Amarok-ot jonak itelem avagy sem, vagy eppen az OpenOffice-t hasznalhatonak tartom, vagy sem. Ezek annyira szubjektiv dolgok, es annyira fuggnek az egyen alapveto beallitottsagatol, hogy szerintem ertelmetlenek ezek a vitak. Ami idot meg energiat elpazarlunk az ilyen vitak soran, abbol mar regen felepult volna az I. Holdbazis.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Nem vitarol van szo, s ez nem is Gnome, hanem az alkalmazasok amik jonnek hozza. Igaz , Gnome-ban nincs "gnome-base", "gnome-workspace", hanem kapsz mindent az arcodba. Jo, van gnome-core, de utana mindent lerant egy csomag csak mert miert ne... 2009-ben legyen mar geped ami viszi. Amarok amugy nem bejovos, OpenOffice-al meg csak annyi a gond hogy tetu.

I. Holdbazis.. hmm.. vegre lehetne bolygok kozt is harcolni, vert ontani nem csak a foldon..mekkora moka.. :)) Emberbol igy is kerul ilyesmire, kerdezz meg par kinait hogy van e kedvuk kimenni ha az eselyuk 1% a tulelesre.. oromtelien elfogadjak szerintem..

Arch-on is lehet plain Gnome-ot felhuzni, s nem huz fuggosegeket. Jo hat Arch mas teszta, Gentoo-sok kozul is rengetegen hasznaljak.

OOo-rol epp ma kerdezett egyik veteran linux/bsd/unixos ismerosom hogy lehet minden formazast leszedni egy adott szovegreszrol. Mondtam masolja ugy hogy elvesszen a formazas. Vegulis mukodik... de megegyeztunk hogy megvennenk az MS office-t linuxra..ha lenne.

"Igaz , Gnome-ban nincs "gnome-base", "gnome-workspace", hanem kapsz mindent az arcodba. Jo, van gnome-core, de utana mindent lerant egy csomag csak mert miert ne..."

ha lövésed sincs róla, akkor lécci ne beszélj már hülyeségeket. az 1 dolog, hogy az x disztró hogy csomagolja. nézz már meg egy garnome-ot, aztán rájössz, hogy szét vannak osztva.

szerintem.

Leggyakoribb script általi commit az automatikus merge.

Sok egyéb script általi commit is lehet, itt arról van szó, hogy egy script rendszeresen összenézi, hogy az adott resource-hivatkozás hol van a forrásban és ez alapján módosítja a nyelvi fájl tartalmát. Tipikus script feladat, felesleges erre emberi erőforrást pazarolni, ám nagyon sokat segít a fordításban.

Leírás miért kellene? Script is ki tudja adni az `svn ci` parancsot, a feladatok pedig projektenként változnak... :)
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

Mondjuk tegyuk hozza, hogy ez ugyan eleg regenyesen hangzik, a valosag azonban sokkal prozaibb: ez a script ket-harom parancsnal tobbet nem ad ki, ezt pedig akar ember is kiadhatna akarmikor - csak ez igy idozitve van, es nincs az emberi feledekenysegre bizva.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Azt hittem (remenykedtem benne), hogy bonyolultabb feladatokat is tudtak automatizalni, es gondoltam szivesen ellesnek toluk par trukkot, ugyanis neha-neha elegge megkeseriti az ember eletet egy merge(akar orakat is elvehet a munkabol).
De ezek szerint megsem talaltak fel a spanyol viaszt :)

------------------
- The Question is: What is mahna mahna?!
- No! The question is: Who Cares!