- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Kicsit furcsa volt, hogy meg sem nezte mit fogad el.
- A hozzászóláshoz be kell jelentkezni
Nekem ez nem fura :)
--
HUPbeszolas FF extension
- A hozzászóláshoz be kell jelentkezni
:)
- A hozzászóláshoz be kell jelentkezni
Ez kesz, nem tudok oltozkodni a rohogestol :)
- A hozzászóláshoz be kell jelentkezni
ezek mar azok a levelek, amiket "tag"-eltek, hogy mehet a stabilba.
a felado is o maga volt, ha figyelted
--
Live free, or I f'ing kill you.
- A hozzászóláshoz be kell jelentkezni
Ennyire reszleteiben nem kovettem, hogy mi a helyzet, nyilvan ez elsosorban egy kicsit "tooling" bemutato. De jo lett volna az elfogadas lepeseit is latni.
- A hozzászóláshoz be kell jelentkezni
azt megbeszelik a listan
--
Live free, or I f'ing kill you.
- A hozzászóláshoz be kell jelentkezni
A listában To alatt ő szerepel, ez logikus, hisz ő kapta a levelet, de a levél kinyitásakor a From mezőben meg nem őt láttam, már ha jó helyen néztem. Hol láttad, hogy ő a feladó?
"Belépés díjtalan, kilépés bizonytalan."
- A hozzászóláshoz be kell jelentkezni
Úgy látom, hogy a befektetett munkának jelentős része olyanokból áll, mint pl. a Subject: sorok manuális szerkesztése. Ha én csinálnám (SOHA!), akkor biztos, hogy inkább automatizálnám vagy másokkal csináltatnám meg ezeket a kozmetikázós részeket :-p
- A hozzászóláshoz be kell jelentkezni
Valószínűleg azt pont nem lehet automatizálni, hiszen emberek írják. De azt hiszem nem ez a jelentős része a munkának, hanem a patch tartalmának átnézése, amit ha jól tudom mind a mai napig Linus csinál egyedül. Ilyen szempontból Greg Kroah-Hartman a "más valaki", aki az unalmasabb részét csinálja :)
- A hozzászóláshoz be kell jelentkezni
az általa karbantartott -stable kernelfákba.
Szerintem Linus nem csinál stable-t.. :P
- A hozzászóláshoz be kell jelentkezni
Vicces lenne, ha minden pöcsöt ő nézne át "személyesen". :)
Nem követem a kernelfejlesztést, de amit eddig videón Linustól hallottam, az alapján általában legalább van még egy szint alatta, amin keresztül mennek a pöcsök (alrendszer karbantartók). Mindenhez nem ért, ideje sincs mindennel foglalkozni - ezért vannak alatta olyan emberek, akiknek a döntésében megbízik.
- A hozzászóláshoz be kell jelentkezni
A patch-et az adott alrendszer karbantartója nézi át alaposabban. Ez után merge-eli Linus, de nem hiszem, hogy megnézi, max elolvassa, hogy mire vonatkozik a patch.
--
CyclonePHP
- A hozzászóláshoz be kell jelentkezni
Akkor ezt mi a francert nem lehet automatizalni? Ennyire olcso Linus ideje?
- A hozzászóláshoz be kell jelentkezni
Nem, hanem hanem neki is van egy vetojoga. Lehet olyan patch, ami esetleg neki lesz gyanus, es visszakuldi.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
- A hozzászóláshoz be kell jelentkezni
Komolyan ilyen eszközöket használ 2012-ben? Nem vagyok ellensége terminának és a szöveges alapú progiknak, de ami itt történt, az kicsit meglepett. A hasonló jellegű munkafolyamat nálunk kicsit másképpen zajlik, jóval kevesebb billentyűleütéssel (és egérkattintással) - kissé hatékonyabb szoftvereket használunk.
- A hozzászóláshoz be kell jelentkezni
Ilyen egy profi. Aki még ennél is jobb, az közvetlen a binárisban javít hexa patch alapján.
"Belépés díjtalan, kilépés bizonytalan."
- A hozzászóláshoz be kell jelentkezni
+1, kozepkor
--
NetBSD - Simplicity is prerequisite for reliability
- A hozzászóláshoz be kell jelentkezni
++
- A hozzászóláshoz be kell jelentkezni
Mindkettőtöktől kérdezem, mi jelenleg a state of the art hasonló feladatra? Pl. ha kapok valakitől patcheket a projektemhez emailben, és szeretném azokat megnézni (mármint a kész, patchelt kódot), elfogadni, aláírni, stb.?
Szerk. Pl. NetBSD-nél hogy megy át a patch az emailből a CVS-be?
- A hozzászóláshoz be kell jelentkezni
"NetBSD-nél hogy megy át a patch az emailből a CVS-be?"
:D
--
zsebHUP-ot használok!
- A hozzászóláshoz be kell jelentkezni
A micsodából micsodába?
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
1, Ne email-ben küldje, hanem rögtön verziókezelőben, ha ez még se megy, akkor egy automatikus script azonnal tolja be verziókezelőbe az érkező levelek tartalmát és készítsen belőle task-ot egy issue kezelő rendszerben, ennek a számát írja bele a commit üzenetbe.
2, Ezek után léteznek tök jó code-review eszközök, amelyek kellően vizuálisak és intuitívak, hogy a kód áttekintését kényelmesen és gyorsan lehessen elvégezni, beleértve a visszadobás és az elfogadás workflow-t is, így rögtön meg tud jelenni egy issue kezelő rendszerben a visszadobott vagy elfogadott patch -- és persze lehet rögtön ütemezni, hogy melyik release során adjuk ki.
3, A merge előtti kódon a tesztek automatikus futtatása, kód metrikák automatikus kiértékelése, mint a merge feltétele.
4, A sikeres tesztek és review után a merge lehet automatikus, ha nincs conflict.
Nem túl összetett folyamat, amúgy nem zavar, ha valaki jól érzi magát automatizálható feladat elvégzése közben, csak ne propagálja, hogy ez egy követendő példa.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
- A hozzászóláshoz be kell jelentkezni
Hat igen, en el tudnek kepzelni egy gerrit.kernel.org -ot.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
- A hozzászóláshoz be kell jelentkezni
Azért a gerrit-nél vannak kifinomultabb eszközök is:
https://www.youtube.com/watch?v=fFQ4MWQTO4Q
https://www.youtube.com/watch?v=tOFOtpCycz4
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
- A hozzászóláshoz be kell jelentkezni
Es ugye a linkelt cucc opensource? Merthogy ugyebar Linux kernel fejlesztesrol beszelgetunk. Azt mar meg se merem kerdezni, hogy GPL v2 vagy v3 kompatibilis-e a licence, mert van egy tippem a valaszra. A Gerrit viszont az ilyen kovetelmenyeket is rohogve teljesiti.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
- A hozzászóláshoz be kell jelentkezni
Opensource. És opensource fejlesztésekhez ingyenes... :)
"A Gerrit viszont az ilyen kovetelmenyeket is rohogve teljesiti."
Nagyszerű... csak a licencelésről viszont nem lesz egy eszköz kényelmesen használható. :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
- A hozzászóláshoz be kell jelentkezni
Ebben igazad van, csakhogy ha figyelemmel kovetted a Linux kernel fejleszteset, akkor tudod, hogy Linus, ahol csak lehet, igyekszik GPL eszkozoket hasznalni a fejlesztes soran, es ennek csak az egyik oka az, hogy o az egyik vezeralakja a licenc elkotelezett hiveinek. A masik viszont az, hogy igy szabadon tudja modositani a forrast az o igenyeinek megfeleloen, es vissza is tudja kuldeni azt az eredeti csapatnak.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
- A hozzászóláshoz be kell jelentkezni
Ez a GPL-t leszámítva mind igaz Atlassian termékek esetén. :)
Ha a Red Hat-nak megfelelő a Jira (https://issues.jboss.org/secure/Dashboard.jspa). Az Oracle-nek megfelelő a Jira (http://mail.openjdk.java.net/pipermail/announce/2011-October/000112.html). Sok más Open Source cégnek megfelelő az Atlassian termékpaletta, mert egyszerűen sokkal produktívabb lesz tőle a fejlesztés, akkor miért pont a Linux kernel környékén kell sznob hozzáállás miatt komoly embernapokat azzal tölteni, hogy az előző évszázadból származó eszközökkel oldják meg például a patch-ek kezelését és a code-review-t?
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
- A hozzászóláshoz be kell jelentkezni
Az atlassian termekek nem telejsen nyilt forrasuak, forrasuk nem toltheto le szabadon, amennyire tudom. Levelezni/kerni kell toluk, es "majd elbiralljak".
Nezd, ezeket a szabalyokat nem en talalom ki. Tessek felvenni Linus-sal a kapcsolatot, es erdemben leirni, hogy ez nekik miert jo/nem jo.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
- A hozzászóláshoz be kell jelentkezni
"Az atlassian termekek nem telejsen nyilt forrasuak, forrasuk nem toltheto le szabadon, amennyire tudom. Levelezni/kerni kell toluk, es "majd elbiralljak"."
Nem bírálnak el semmit. Élő licenc mellé jár a forrás, egyszerűen minimalizálják az élő munkát, előtérbe helyezve a kreativitást a gépies tevékenységekkel.
"Nezd, ezeket a szabalyokat nem en talalom ki. Tessek felvenni Linus-sal a kapcsolatot, es erdemben leirni, hogy ez nekik miert jo/nem jo."
Tiszteletben tartom a döntéseiket, nyilván futottak pár kört, de a szál onnan indult, hogy "amúgy nem zavar, ha valaki jól érzi magát automatizálható feladat elvégzése közben, csak ne propagálja, hogy ez egy követendő példa."
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
- A hozzászóláshoz be kell jelentkezni
"Élő licenc mellé jár a forrás"
Vagyis nem teljesen open source
Egyebkent pedig itt propagalasrol szo sem volt. Egy insider videot lattunk, nem tobbet.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
- A hozzászóláshoz be kell jelentkezni
De, teljesen Open Source. Viszont nem FLOSS.
- A hozzászóláshoz be kell jelentkezni
Mintha hallottunk volna már olyanról, hogy a Linux kernel fejlesztése nem FLOSS cuccban történt volna.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Igen, egy ideig asszem BitKeeper-t (vagymit) hasznaltak, de aztan amint lett elheto alternativa, valtottak is - gitre.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
- A hozzászóláshoz be kell jelentkezni
Na azért nem egészen. A BitKeeper szerzője berágott egy visszafejtés miatt, ami megkönnyítette a Linux fejlesztők életét, és úgy döntött, hogy akkor nem adja ingyen a BitKeepert. Ekkor írta meg Linus pár nap alatt a git első verzióját.
- A hozzászóláshoz be kell jelentkezni
"Vagyis nem teljesen open source"
Ok. Akkor hogy nevezzük azt pénzért megvehető szoftvert, aminél a bináris mellé a forrás is jár?
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
- A hozzászóláshoz be kell jelentkezni
hat ez a jira hol free? meg hol opensource? de lehet en vagyok vak...
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
Open Source, például az alábbi módon tudsz egy Confluence-t magadnak lefordítani:
https://developer.atlassian.com/display/CONFDEV/Building+Confluence+Fro…
És Open Source projektekhez free:
http://www.atlassian.com/software/views/open-source-license-request
És nem csak az Atlassian közvetlen termékei ingyenesek OS használathoz, hanem az _összes_ plugin... azok is, amelyeket vendor-ok készítenek.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
- A hozzászóláshoz be kell jelentkezni
"Source code access is available for commercial license holders" :(
Egy kis fejleszto cegnek meg a $1200 egy kicsit sor elsore... (a 25-fos licensevel, mivel pl van 5 dev, 3 "mindenfele" manager, 2 sysop, X reporter).. sajna marad a gerrit :(
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
Egy 25 fos ceg nem kicsi, ha fejlesztocegrol van szo. 25 ember mar csodat tud muvelni. Kisebb
"Egy kis fejleszto cegnek meg a $1200 egy kicsit sor elsore"
25 embernek 1 fo felhavi fizeteserol beszelunk. Nehogymar sok legyen. A JIRA es a tobbi Atlassian termek nagyon megeri az arat. Kisebb cegeknek, startupoknak meg ott a 10 dollaros licenc. Ket mozijegy ara.
Aki meg nem tudja kigazdalkodni ezt sem, az inkabb zarja be a boltot.
- A hozzászóláshoz be kell jelentkezni
"Source code access is available for commercial license holders" :("
Open Source licenchez is jár a forrás, én is letöltöttem, mert például plugin fejlesztéshez nagyon hasznos segédeszköz a host forrása.
"Egy kis fejleszto cegnek meg a $1200 egy kicsit sor elsore... (a 25-fos licensevel, mivel pl van 5 dev, 3 "mindenfele" manager, 2 sysop, X reporter).. sajna marad a gerrit :("
10 fős licenc 10 dollár évente. Ennél több nem kell szerintem code-review feladatra kis cégnél. Ha kell a 25 felhasználós licenc -- ami ugye havi $4 felhasználónként és nem fillérekbe kerülő fejlesztőkről beszélünk :), akkor már kigazdálkodható az 1200 dollár is abból a pénzből, amit a gerrit és a crucible használata közben megtakarított embernapokból kijön, pláne ha hozzávesszük a többi Atlassian terméket, amelyekkel nagyon sok manuális munka automatizálható és nem esik le az asztalról semmi, ami beérkezett, mindennek megvan a helye a workflow-ban...
Napi szinten használom ezeket az eszközöket és próbáltam jó pár egyéb eszközt, sajnos nincs jó ingyenes alternatíva (az alapötlet általában egyszerű és könnyen leprogramozható, de normális és használható webes felület nem szokott előfordulni ingyenes eszközöknél), mert hiába ingyenes, ha közben több embernapot elveszt a cég azon, hogy nem használhatók hatékonyan.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
- A hozzászóláshoz be kell jelentkezni
Na akkor most gyorsan tegyunk tisztaba dolgokat.
Eloszor is, a sztori onnan indult, hogy kokori eszkozoket hasznalnak a kernel fejlesztese soran. En vetettem fel azt, hogy ezeknel az eszozoknel (ezekhez kepest) egy Gerrit is hatalmas elorelepes lenne. A Gerrit tehat igy kerult a kepbe, en nem mondtma, hogy a Gerrit egy uberalles-fasza rendszer, csak viszonyitottam hozza.
Aztan, ne keverjuk ossze a Linux kernel fejleszteset egy fizetos termekeket fejleszto cegevel. Amennyire tudom, a Linux kernel fejlesztese - legalabbis nevleg - non-profit dolog, a fejlesztok kozvetlenul a Linux kernelen vegzett munkajukert nem kapnak penzt (az mas kerdes, hogy olyan cegek alkalmazasaban allnak, ahol a feladatuk a Linux kernel fejlesztese (is), de ezert, mint allasert kapnak penzt, nem pedig mint pl. a Google fizeti az Android fejlesztoket, vagy a RedHat az OVirt fejlesztoit). Tehat a Linux kernel a sajat fejlesztesere nem termel penzt, a legtobb cuccuk - amennyire tudom - vagy adomany, vagy adott ceg bocsatotta rendelkezesukre.
Ilyetekeppen tehat arrol beszelgetni, hogy a Linux kernel mit tud maganak kitermelni a fejleszteshez, nos ez nem vezetne sehova sem. Itt alapitvanyok vannak meg lelkes kontributorok, de a Linux kernel mogott nincs egy konkret ceg, akit meg lehetne nevezni, mint kvazi "tulajdonost".
Linus is csak koordinalja a fejlesztest, de meg csak az o tulajdonaban sincs a Linux kernel.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
- A hozzászóláshoz be kell jelentkezni
Leírom lassan: az összes Atlassian termék ingyenes open source fejlesztésekhez...
"akit meg lehetne nevezni, mint kvazi "tulajdonost"."
A kernel.org-ot például ki tartja fenn? :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
- A hozzászóláshoz be kell jelentkezni
Valamelyik alapitvany fizeti a domaint, a hosting gep vagy adomany, vagy valaki szivessegbol hostolja.
Amugy az Atlassian mi alapjan donti el, hogy mi szamit opensource fejlesztesnek?
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
- A hozzászóláshoz be kell jelentkezni
"Valamelyik alapitvany fizeti a domaint, a hosting gep vagy adomany, vagy valaki szivessegbol hostolja."
Tehát mégis csak van pénz valahol, ha minden kötél szakad... :)
"Amugy az Atlassian mi alapjan donti el, hogy mi szamit opensource fejlesztesnek?"
Nagyjából az a határ, hogy a termék felhasználója számára általános esetben automatikusan elérhető-e a termék forráskódja.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
- A hozzászóláshoz be kell jelentkezni
"Amugy az Atlassian mi alapjan donti el, hogy mi szamit opensource fejlesztesnek?"
Nagyjából az a határ, hogy a termék felhasználója számára általános esetben automatikusan elérhető-e a termék forráskódja.
Fun fact: mivel az Atlassian termékei opensource szoftverek, ezért azokat az Atlassian termékeinek fejlesztéséhez ingyenesen felhasználhatja az Atlassian. :)
- A hozzászóláshoz be kell jelentkezni
A Linux kernel fejlesztesehez az osszes Atlassian termek ingyen lenne, ugyanugy, mint a Gerrit.
Epp ezert hiaba nagy elorelepes mar a Gerrit is, meg annal is van jobb, ugyanannyi dollarert.
Csak eppen mivel nem FLOSS (de a licencelok szamara, igy a kernel.org-osok szamara is elerheto a forras), ezert nem hasznaljak. A licenchuszarkodassal egyaltalan nem vedheto a kokori minoseg/release management. Mindenesetre ha tenyleg csak a licenc miatt nem hasznalnak korszeru eszkozoket, akkor ne csodalkozzon senki, hogy mindig lesznek regressziok, 1-1 bug kezeleset nem lehet kovetni a forraskodhoz kepest konnyen - nem, a Bugzilla erre nem alkalmas. Az egy rettenetes eszkoz, hasznaltam JIRA utan, mert egy masik cegnel az volt a policy. Hat, JIRA-hoz kepest remalom.
- A hozzászóláshoz be kell jelentkezni
Ez kicsit mellékszál, de tapasztalatom szerint a regressziók ellen nem megoldás semmilyen forráskód menedzsment eszköz. Azokhoz teszteket kell írni.
- A hozzászóláshoz be kell jelentkezni
Na igen, es ez egy kernelhez nem is mindig trivialis feladat...
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
- A hozzászóláshoz be kell jelentkezni
Monolitikus rendszerek ftw.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Nem feltetlen csak ezert. Egy QLA 8521-es kartya driverehez pl. hogy irsz tesztet? (nem feltetlen van ilyen kartya, ez most csak pelda). Vagy mondjuk egy wifi driverhez?
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Itt csak USB-ről van szó (meg az ígéretről, hogy egyszer majd lesz firewire és ethernet csatlakozókhoz is).
- A hozzászóláshoz be kell jelentkezni
Van meg ott mas technologia is: http://msdn.microsoft.com/en-us/windows/hardware/gg487310.aspx meg ugy a DDK kornyeken erdemes korulnezni.
Masreszt tenyleg, egy 20+ eve fejlesztett kernelnel meg mindig ott tartunk, hogy "hogyan lehet ezt tesztelni?" Elvileg a vilag legjobb szoftvermernokei dolgoznak rajta, nem pedig hobbikoderek. Sot, sokan fizetest is kapnak azert, hogy kernelt fejlesszenek.
- A hozzászóláshoz be kell jelentkezni
Az érdekelne, hogy mennyi lehet a code coverage a Linux kernelnél, illetve statikus kódelemzésnek mi lenne az eredménye... :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
- A hozzászóláshoz be kell jelentkezni
Van ugyebar egy ilyen: http://ltp.sourceforge.net, de a Wiki alapjan rengeteg funkciohoz nem letezik teszteset.
A kernel kb. 15M sor kodbol all, ehhez az LTP ad kb. 3000 tesztesetet. Azert nem rossz, atlagosan minden otezredik sor van letesztelve :)
- A hozzászóláshoz be kell jelentkezni
1) tudjuk hogyan mukodik a kartya
2) tudjuk mi a driver interfaceja kernel oldalrol
3) tudjuk azt is, hogy hogyan kellene mukodnie a drivernek, milyen teszt esetek vannak, stb.
Ezek jo resze automatizalhato a kernel tobbi resze nelkul is. Attol, hogy ez egy kernel, nem kellene kulonboznie egy modularizalt, tesztelheto sw-nel.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Úgy hívják a technológiát, hogy mocking vagy mock testing... munkaigényesebb, mintha nincs teszt, de nem lehetetlen dolog egy hardverszimulátort megírni, amivel tesztelhető a driver, lévén a driver írásához ismerni kell a hardver működését.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
- A hozzászóláshoz be kell jelentkezni
Egyetértek. Az átnézés ok, mehet tőlem vi-ben, de ezeket az apró kozmetikai korrekciókat már réges régen egy script-nek kellene végeznie.
Ez így leginkább netto energia és idő pocséklás.
Mindezzel persze egyáltalán nem becsmérlem a munkájukat.
-----------------------------------------------------
MacBook Pro - Mac Pro - PowerMac G4 - Hackintosh
- A hozzászóláshoz be kell jelentkezni
Van valakinek ötlete, hogy mivel jelenítette (milyen programmal) a billentyűkombinációkat?
- A hozzászóláshoz be kell jelentkezni
Ez engem is érdekelne.
♲♻♲
- A hozzászóláshoz be kell jelentkezni
a metodikát leírja a google+ oldalán, lásd a linket ytb videó alatt:
"f you have any questions about how I made the screencast, please see:
https://plus.google.com/u/0/111049168280159033135/posts/8Ra2uhYCgGm"
egyébként meg: screenkey.
- A hozzászóláshoz be kell jelentkezni
Kössz.
♲♻♲
- A hozzászóláshoz be kell jelentkezni
dup
♲♻♲
- A hozzászóláshoz be kell jelentkezni
erre mondaná ezt az egyik jó barátom, hogy "hatékonytalan".
- A hozzászóláshoz be kell jelentkezni