- A hozzászóláshoz be kell jelentkezni
Hozzászólások
azt hittem visual sourcesafebe (vagy hogy a rákba hívják) nyomják, mi törpént, megvilágosodtak lol...
--
GPLv3-as hozzászólás.
- A hozzászóláshoz be kell jelentkezni
februárban itt is volt róla szó, hogy váltanak
- A hozzászóláshoz be kell jelentkezni
Miért van olyan érzésem, hogy rosszul használnak egy eszközt? :)
- A hozzászóláshoz be kell jelentkezni
Tenyleg, miert? Gondolom a monorepo az, ami neked furcsa -- a Google es a Facebook is monorepoval dolgozik, ugyanugy extra toolingot tettek valami hagyomanyos VCS ala/fole. Valoszinuleg nem teljesen hulyek dolgoznak ezeken a helyeken.
----------------------
while (!sleep) sheep++;
- A hozzászóláshoz be kell jelentkezni
Ahja, a mindent-bele repó az, ami nekem nagyon-nagyon furcsa, nem létezik, hogy az összes projektjük között forrásszintű mozgásra lenne szükség. Az, hogy egy olyan eszközt használnak olyan célra, amire az nem való, mert a teljes repót leszedi minden történésével, majd ezt körbetákolják, hogy egyáltalán működjön, az is furcsa. Nem mondtam, hogy hülyék dolgoznak ott, de nem ez lenne egyiknél se az első hülye döntés... :)
- A hozzászóláshoz be kell jelentkezni
Nem kell leszedni a teljes history-t. https://stackoverflow.com/questions/1209999/using-git-to-get-just-the-l…
- A hozzászóláshoz be kell jelentkezni
Igen, tudom, de ez is egy workaround, ami több problémát hoz be, mint amennyit megold. :)
- A hozzászóláshoz be kell jelentkezni
+1
Teljesen egyetértek. Pont az ellenkező irányba kellene menniük, minél inkább függetleníteni egymástól a projektjeiket.
- A hozzászóláshoz be kell jelentkezni
Akkor ugyanazt a hibát javítgathatják 10X, vagy workaroundolhatják 10 helyen 10 féleképpen.
Rengeteget lehet spórolni vele, ha minden egy verziókezelőben van. Az eszköz nem képes rá? Akkor az eszközt kell megjavítani.
- A hozzászóláshoz be kell jelentkezni
Amit írtam az miért jelentené azt, hogy ugyanazt 10 helyre is kell rakni?
Nem igazán értem a gondolatmenetet. Ha egy valamiben van a hiba, akkor csak egy helyen kell javítani mind a két esetben; ha 10 helyen van hiba, akkor 10 helyen kell javítani mind a két esetben.
- A hozzászóláshoz be kell jelentkezni
Miért van az a forrásrészlet több projektben _másolva_? Ezt a helyzetet nem a verziókezelő tákolásával kell megoldani, ez annál mélyebb probléma, ha ez az oka.
Továbbra se látom annak értelmét, hogy _minden_ egyes projekt egy repóba kerüljön... sarkítva: mi indokolja, hogy egy gépi kódon megírt firmware és egy JavaScript fájl egy repóban legyen?
- A hozzászóláshoz be kell jelentkezni
Csak egy példa:
Continuous Build/Delivery:
Van egy alkalmazásgyűjteményem A,B,C,D komponensekkel, amik ebben a sorrendben függenek egymástól.
Egyik komponensen (legyen B) készítek egy feature branchet. Commit-olok bele.
Mit és mikor build-elek le a teljes rendszer teszteléséhez? (Lehet, hogy ez után a commit után egy másik komponensben is fogok valamit változtatni, pl. API változás miatt.)
Pontosabban melyik komponens melyik branch-ét?
Ha egy repository van, akkor nincs ilyen kérdés, mert a branch az összes komponenst érinti. Ez nagyon kellemes lehet, ha komponenseken átívelő változtatásokat kell eszközölni...
- A hozzászóláshoz be kell jelentkezni
"Van egy alkalmazásgyűjteményem A,B,C,D komponensekkel, amik ebben a sorrendben függenek egymástól."
Azt ne mondd, hogy az összes projekt függ az összes projekttől egy all-in repóban... :)
- A hozzászóláshoz be kell jelentkezni
Nem mondta, hogy "az összes projekt függ az összes projekttől egy all-in repóban".
Idézted mit mondott, olvasd el ujra :)
- A hozzászóláshoz be kell jelentkezni
Én teljes mértékben értem... szóval az egymástól nem függő projektek miért is vannak akkor egy repóban? :)
- A hozzászóláshoz be kell jelentkezni
Épp elég, ha van egy rakás összefüggés mindenütt - ahogy tuti, hogy van. Ha egyben van minden, akkor ezeket az eseteket nagyon jól lehet kezelni minimális erőfeszítéssel. Ha nincsenek, akkor a managerek egyfolytában olyan vitákon ülnek napokat, ahova elhívnak 1-1 fejlesztőt az összes érintett csapatból, és azon vitáznak, hogy melyik csapatnak az infrastruktúráján ki nyithat feature branchet és ki nem.
Ilyeneken olyan megoldások szoktak születni, hogy:
* A csapat kiadja a kódot, miután tesztelte a saját környezetében, és aztán B, C D és E csapatok integrálják. Ha 1 csellentyűcske nem működik, akkor change request, patch version, all hell broke loose
* A csapat csinál egy mirrort magának a B csapat verziókezelőjéből és B csapat csinál egy mirrort A csapat verziókezelőjéből, mert azért bele kell peccselgetniük, de ezt szigorúan nem képesek megosztani egymással valami IT faszkodás miatt.
* A csapat megelégeli a végtelen meetingeket és felteszi a toldacuccot.hu-ra a peccset és magán emilen elküldi a linket a B csapatnak, akik pendrájvon becsempészik a cégbe, mert az IT és a menedzserek hetek óta azon pingpongoznak, hogy hogy kellene megosztani a projektet a két csapat között :-).
- A hozzászóláshoz be kell jelentkezni
Most arról beszélsz, amikor külön repókban vannak, de erős függésben vannak egymással, ahelyett, hogy egy vékony API-n keresztül függenének, és a forrásaiknak semmi közük nem lenne egymáshoz.
Megoldás 1: szüntessük meg az erős függéseket.
Megoldás 2: rakjunk mindent egy repóba (alább írtam, hogy ez miért nem szerencsés).
- A hozzászóláshoz be kell jelentkezni
Szüntessük meg az erős függéseket -> valósítsuk meg ugyanazt 10 helyen. Vékony API legyen -> hónapos meetingsorozat az API-ról, hogy olyan legyen ami mindenkinek elfogadható. Egyetlen új metódus felvétele több hónapig tart a kommunikációs körök és a csapatok beosztási problémái miatt. Addig áll az új funkció fejlesztése.
- A hozzászóláshoz be kell jelentkezni
Szüntessük meg az erős függéseket -> valósítsuk meg ugyanazt 10 helyen.
Ezt még mindig nem értem, hogy ez miért függ össze. Miért kellene ugyanazt 10 helyen megvalósítani, miért nem egy lib-ben, amit 10 helyen is használnak?
Vékony API legyen -> hónapos meetingsorozat az API-ról, hogy olyan legyen ami mindenkinek elfogadható.
Ezt sem igazán értem, hogy a tervezés az miért csapatok közötti, hónapos meetingek sorozata.
Azt sem látom be, hogy tervezés helyett jobb az, ha bárki beírhat bárhová, bármit, mert lehetősége van rá.
- A hozzászóláshoz be kell jelentkezni
Te tényleg így dolgozol? :O
- A hozzászóláshoz be kell jelentkezni
Én nem, de láttam már ilyet.
- A hozzászóláshoz be kell jelentkezni
És ezért az a megoldás^W workaround^W gányolás, hogy mindent egy repóba teszünk? :)
- A hozzászóláshoz be kell jelentkezni
Ha meggondolod, a világ összes kódját is elképzelheted egy nagy repóként, amiben mindenki a saját dolgait hekkeli a saját fejlesztési ágain.
A legjobb az lenne, ha a világ összes kódja egyetlen repó lenne. Igazából az a workaround, hogy sokmindent külön kezelünk.
- A hozzászóláshoz be kell jelentkezni
Miért is lenne jó, ha minden egyben lenne? Miért fontos egy mosógép szivattyújának a vezérléséhez, hogy egy repóban legyen a jQuery első verziójával?
- A hozzászóláshoz be kell jelentkezni
Kerdes, hogy miert lenne kulon. (Valojaban azert szoktunk kulon repokat hasznalni, mert a toolok ugy vannak kialakitva, hogy azt feltetelezik, hogy a repo az egy alkalmazasnak/rendszernek felel meg.)
Nezd meg, hogy pl. a 'go get github.com/user/projekt' hogy mukodik. Kicsit hasonloan, mint a Maven central, csak a github a tarolo. A Maven central-t reponak szokas hivni -- ebben az ertelmezesben a github is egy repo.
Szoval semmi gond azzal, ha 'minden egyben' van, ha van extra struktura.
----------------------
while (!sleep) sheep++;
- A hozzászóláshoz be kell jelentkezni
Ha így értelmezed a monorepót azzal csak az a gond, hogy elveszti az összes jónak gondolt előnyét:
1.) Több eszközzel és egyszerűbben használható, mivel ott van minden egy fájlstruktúrában (pl. grep-es keresés) és nem kell az egyes részek verzióival törődni.
2.) Nem kell verziózni az egyes részeket, minden egy közös verzión van.
3.) Könnyen lehet egyben (egy branchben) kezelni a projekteken átnyúló változtatásokat.
4.) Nem kell foglalkozni a függőségekkel.
Én ezeket egyáltalán nem tartom előnyöknek, lásd a részletes írásomat.
- A hozzászóláshoz be kell jelentkezni
"Valojaban azert szoktunk kulon repokat hasznalni, mert a toolok ugy vannak kialakitva, hogy azt feltetelezik, hogy a repo az egy alkalmazasnak/rendszernek felel meg."
Szerintem azért szoktunk külön repókat használni, mert a mosógép szivattyújának 8 bites processzoron futó vezérlő szoftverének a módosítása feleslegesen lenne a nagy közösben együtt egy changeset alatt a Firefox magyar nyelvű fordításnak javításával. És akkor nem beszéltünk a jogosultságokról és a többi úri huncutságról.
"Nezd meg, hogy pl. a 'go get github.com/user/projekt' hogy mukodik."
Külön-külön projekt külön-külön repóként. Nem tudok egy changeset alatt feltolni két külön projektbe módosításokat. Biztos értjük, hogy mit beszélünk egymással?
"Szoval semmi gond azzal, ha 'minden egyben' van, ha van extra struktura."
Ugye a tárgybeli esetben pont az a helyzet, hogy nincs extra struktúra. Ha full feature Git kell a fejlesztőnél, akkor le kell hozni több száz GB adatot, minden szart, minden befulladt projektet a világ kezdetétől mostanáig, ezért GVFS nélkül egy clone 12 órás művelet volt. 12 órás művelet! Ezt sikerült leszorítani 5 percre GVFS-el. Egy clone-t!
Értem én, hogy ez csodálatos dolog és azt is értem, hogy bele kellett harapni valamelyik ujjukba, mert valószínűleg egy, azaz egy repó hízott meg ennyire hosszú évek és évtizedek alatt, amelyben most már csak kurva keservesen lehetne szétvágni a tekergőző csápokat és erre nincs idő a kiélezett piaci helyzetben... de ettől még ne tegyük a kirakatba úgy, mint ultimate megoldást, amikor ez csak az évek alatt felhalmozott technical debt halomra egy workaround... Ássunk egy gödröt, amibe berakhatjuk azt a földet! :)
- A hozzászóláshoz be kell jelentkezni
"Mit és mikor build-elek le a teljes rendszer teszteléséhez?"
Ehhez azt kell pontosan tudnod, hogy mi éppen a teljes rendszer definíciója, hogy mely bináris artifactokból áll. Csak ez dönti el, hogy mit kell buildelned ahhoz, hogy a teljes rendszer előálljon.
A teljes rendszer definíciója ugyanis megmondja, hogy mely komponensek pontosan melyik verziói alkotják a teljes rendszert.
És ez totálisan független attól, hogy a "teljes rendszer" komponenseit monorepoban vagy nem monorepoban tárolod. Sőt, az se biztos, hogy a "teljes rendszer" minden forráskódját te tárolod, sok esetben csak a bináris artifacthoz férsz csak hozzá. Attól még a teljes rendszer definíciójának meg kell lennie.
- A hozzászóláshoz be kell jelentkezni
Kényelmesnek tűnik, de nem az, ráadásul pont a Continuous Delivery -t lehetetleníti el.
Tegyük fel, hogy van egy A komponensed, amitől függ a B, C, D komponens.
A komponensen API változtatást végzel egy branch-ben, emiatt nem fog fordulni a B, C, D komponensed sem ugyanabban a branchben. Milyen jónak tűnik!
A gond akkor kezdődik, ha a B komponensnél szeretnéd ezt a változást minél gyorsabban lekezelni és kiküldeni (delivery) az új B komponens-t, legyen ez 2 nap. Csakhogy ezt nem tudják megtenni, amíg a C, D komponensekben is át nem vezetik a változást. A C komponensben éppen egy sürgős funkciót raknak, amit egy hét múlva kellene küldeniük.
Ilyenkor az a helyzet áll elő, hogy vagy a C komponens készítők abbahagyják a munkájukat és átvezetik az A változásait 2 nap alatt, hogy kimehessen a B, de akkor két napot csúsznak, vagy megcsinálják a saját funkciójukat, majd aztán vezetik át a változásokat, akkor meg a B fog csúszni egy hetet.
Egy gigászi monorepóban mérhetetlen sok ilyen függőség lesz. Egyik komponens változása magával ragad egy csomó másik komponenst, egyik vár a másikra, majd fél évente, ha minden lecsitul, akkor ki lehet adni minden komponensből egy verziót, ami ezer módosítást tartalmaz.
Ezzel szemben, ha szépen el vannak szeparálva az egyes komponensek, akkor az A változása nincs hatása senkire, akár egyből lehet küldeni. B, az új A alapján átvezetheti a változásait, majd tesztek és build után mehet azonnal ki. Ha bármi probléma van, akkor lehet tudni, hogy mivel van, hiszen csak nagyon kicsi változások után mennek ki az új verziók. Emellett C, D komponensek is élik a saját életüket, nincsenek egymással összekötve. Pl. a B2.4 az A1.3-at használja, majd a B2.5-ben az A2.0-ra állnak át. Semmi más változtatás nincs, mehet ki. Miközben C3.5 már az A1.7-et használja, de az A2.x-re váltás még nem sürgős nekik, előbb a saját szolgáltatásaikon fejlesztenének.
A munka is kevesebb lesz összességében, hiszen A minden egyes változását nem kell átvezetni a B, C, D-n minden egyes alkalommal, nem kell új teszteket írni, a meglevőket futtatni, kézzel tesztelni, kiküldeni. Egy-egy változtatás, mint tudjuk, hibalehetőségeket rejt magában, így az összes tőle függő komponenst (nem csak a közvetlen függőeket) érintheti.
A munka is könnyebb a szeparált esetben, mivel az A komponensnél nem lesznek ott a B, C, D komponens branch-ei, csak a sajátjai.
- A hozzászóláshoz be kell jelentkezni
Tök jó elmélet, de a Google-nel van CD monorepo mellett.
----------------------
while (!sleep) sheep++;
- A hozzászóláshoz be kell jelentkezni
Attól, hogy egy repód van, még megmarad a függőségek kezelésének kényszere, azt ugyanis nem a repók száma, hanem a kód, illetve a megoldandó feladatok komplexitása szüli.
Az egy repóval a függőségkezelés csupán az egyszerű esetekre válik triviálissá (nem kell csinálni semmit), a bonyolult esetekre viszont megnehezül. Vannak más dimenziói is a problémának, pl. első kellemetlen következmény, hogy a "fejlesztői közösség" jórészt nem fog tudomást venni a probléma létezéséről, hiszen az egy repos megoldás elrejti a kérdéskört. Ha sok repod van, akkor nem tudsz meglenni jó API definíciók nélkül, és rá vagy kényszerítve, hogy gondolkodj a függőségeken.
Gondolom a redmondi fiuk végiggondolták a dolgot, (pl. ha sok szarul definiált moduljuk van, öngyilkosság belefojtani a függőségkezelés gyötrelmeibe a fejlesztést), és a számukra optimális verziót választottak.
- A hozzászóláshoz be kell jelentkezni
miért van egy olyan érzésem, hogy ez a monorepo olyan, mint a big data... azaz hánnyunk mindent egybe, aztán nevezzük külön szakterületnek azt, hogy próbáljuk valami értelmesre használni ;)
Mondjuk róluk mondta Barnacules, hogy bár ki kell adni a forrásokat mindenféle nagy kormányok szolgálatainak, de olyan bonyolult buildrendszere van, hogy más úgysem tudja reprodukálni :D
- A hozzászóláshoz be kell jelentkezni
Az is hulyesegnek tunt (nekem) hogy minden adatot egy adatbazisba pakoljanak, aztan megis hogy bejott egyeseknek...
- A hozzászóláshoz be kell jelentkezni
Itt azért felmerül, hogy mit is nevezünk egy adatbázisnak, ahogyan a github-ot is valaki monorepo-nak hívta.
Az internet a világ legnagyobb adatbázisa. Ez beleesik az általad egy adatbázisnak nevezett kategóriába?
Egy két példa jól jönne, hogy mire is gondolsz!
- A hozzászóláshoz be kell jelentkezni
Pl. a nosql adatbazisok, amiknel a tartalma "dokumentum" es nincs feltetlen konkret struktura meghatarozva...
Google fele Bigtable vagy epp egy Key-value database,
Nem, az internet nem egy adatbazis. Semmilyen szemszomgbol.
- A hozzászóláshoz be kell jelentkezni
Nem igazán az adatbázis típusa érdekelt, hiszen akár relációs adatbázisba is bele lehet rakni mindenféle adatot, inkább olyan cégekre, akik minden adatukat egy adatbázisba teszik és sikeresek (legalábbis én így értettem a kijelentésedet).
Nem, az internet nem egy adatbazis. Semmilyen szemszomgbol.
Ez csak attól függ, hogy miként definiálod az adatbázist. Az általam ismert definíciók szerint az.
Wikipedia: Database
The World Wide Web is thus a large distributed hypertext database.
- A hozzászóláshoz be kell jelentkezni
RDBMS alapbol szeirntem sokkal behataroltabb. Eleg kuzdelmes skalazni egy keneralis datastore-hoz kepest. Nem tudom, ki teszi minden adatat egy adatbazisba, gondolom senki? Nem is lenne logikus. Nem is mondta senki, hogy barki ilyet tenne.
Nem ertek egyet a wikipediaval :) Nem gond, ugye?
Gondolnam, hogy az indexeles, kereses, sebesseg, kereszthivatkozasok, adatmennyiseg, egy-egy nagy metaadat eltarolasa annyira nem kedvez sehol, minden adat egybe rakasanak. Nem vagyok adatbazisguru, de nem lennek biztos benne, hogy minden nagy ceg megosztja, mikor mire, mit, mennyi adatot tarol. Igy azert kicsit nehez tippelni, hol tarolnak DB-ben legnagyobb adatot.
- A hozzászóláshoz be kell jelentkezni
Youtube thinks otherwise :)
- A hozzászóláshoz be kell jelentkezni
R mint relációs. Szóval tényleg behatároltabb, mint a reláció nélküli adatbázosok. Avagy mentsünk el mindent, hátha jó lesz valamire és mivel kezdetben nem tudtuk mire, ezért nevezzük el adatbányászatnak a területet, aki utólag rendet próbál teremteni a káoszban :D
- A hozzászóláshoz be kell jelentkezni
Én nem tudok ultimate all-in adatbázisról, melyik az, amelyik _mindenre_ egyformán jó?
- A hozzászóláshoz be kell jelentkezni
Google Bigtable egy proprietary DB, aztan mondjuk jo eg tudja, mi mindent jelent, mi van benne. (key value, nosql, RDBMS, Log) Vegulis, egy adatbazis csak....
- A hozzászóláshoz be kell jelentkezni
A Bigtable egy szimpla NoSQL és azok között se a legokosabb, se a leggyorsabb... mit is akarsz ezzel mondani?
- A hozzászóláshoz be kell jelentkezni
Nem dolgozom a google-nel, innen vettem, amit gondolok: https://en.wikipedia.org/wiki/Bigtable
- A hozzászóláshoz be kell jelentkezni
Oszt: visszaírtál címszavakat vagy kontextusban végig is gondoltad?
- A hozzászóláshoz be kell jelentkezni
Mit szeretnel mondani? Hogy a NoSQL, amit adnak gyenge? Lassu? Vagy hogy megszabjak, mit pakolsz bele? Vagy nincs benne sok adat? En ugy ertelmeztem - a rendelkezesre allo adatokbol - hogy ez egy altalanos, igen nagy adatbazis. Hogy konkretan mi van benne, es mennyi adat, azt csak tippelem, hogy sok. Ennyi, nem tobb.
- A hozzászóláshoz be kell jelentkezni
Innen indultunk: "Én nem tudok ultimate all-in adatbázisról, melyik az, amelyik _mindenre_ egyformán jó?"
A Bigtable messze nem ilyen, vannak olyan esetek, amire kiváló, vannak olyan esetek, amire a kategóriájában vannak jobbak, kategóriáján kívüli feladatokra meg meg alkalmatlan.
- A hozzászóláshoz be kell jelentkezni
Ertem, koszonom fejtagitast.
- A hozzászóláshoz be kell jelentkezni
+1
Talán azért, mert rosszul használják! :-)
- A hozzászóláshoz be kell jelentkezni
Az gondolom fel sem merülhetett, hogy megfontolták, és a hátrányokat is figyelembe véve hoztak racionális döntést.
- A hozzászóláshoz be kell jelentkezni
Hogyne merülne fel, sőt azt gondolom, hogy ez így is történt! Sőt úgy tudom, hogy a Google és a Facebook háza táján is vannak ilyenek.
Évekig, évtizedekig lapátolták össze a kódokat egy hatalmas monolitba, majd, amikor már kezelhetetlen méreteket ölt, akkor választhatnak, hogy vagy évekig bontogatják kisebb részekre, úgy, hogy közben a fejlesztési metodikán is alaposan változtatni kell, ami érint rengeteg dolgozót; vagy pár hónapos, pár fejlesztőt érintő munkával az eszközeiken módosítanak. Logikus, hogy az utóbbi mellett döntenek, de ettől nem lesz jó az, ahogyan csinálják.
Ez csak az én személyes véleményem, aki ennek ellenkezőjét gondolja, azt is tiszteletben tartom!
- A hozzászóláshoz be kell jelentkezni
+1
Az a ronda business reason ... ;)
- A hozzászóláshoz be kell jelentkezni
Az MS-t es a Facebookot nem ismerem ilyen szempontbol, de a Google eseteben cseppet sem arrol van szo, hogy egy nagy monolitjuk van. (Hogyismondjam -- nem vagyok egy Google-fan, finoman szolva, de az o skalajukon abszolut van ertelme pl. a monoreponak, es _nagyon_ jol mukodik a dolog. A monoreponak es a monolitnak semmi koze egymashoz.)
----------------------
while (!sleep) sheep++;
- A hozzászóláshoz be kell jelentkezni
A monoreponak es a monolitnak semmi koze egymashoz.
A mono a monolit (monolithic) rövidítése. (a repo meg a repository-nak)
mono repo === monolithic repo === monolithic repository
- A hozzászóláshoz be kell jelentkezni
Aha. Akkor felreertettelek, monolitnak a nagy, tombszeru appokat szoktak nevezni (vs. microservice)
----------------------
while (!sleep) sheep++;
- A hozzászóláshoz be kell jelentkezni
From Ancient Greek μόνος (mónos, “alone, only, sole, single”)
--
NetBSD - Simplicity is prerequisite for reliability
- A hozzászóláshoz be kell jelentkezni
De ha megsem akkor fujsz ra egy kis windexet azt jovanazugy :D
- A hozzászóláshoz be kell jelentkezni
mono ~ egy
monorepo ~ egy repo
monolit ~ egy kő ~ valami "nagyon" egyben van, nem moduláris
sztem a monorepót nem kell feltétlenül monolitikusként feloldani, megállja a helyét szimplán.
~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack
- A hozzászóláshoz be kell jelentkezni
Ha mar kezelhetetlen, akkor irnak egy verziokezelot ami tudja kezelni:
https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions…
"Google relied on one primary Perforce instance, hosted on a single machine, coupled with custom caching infrastructure1 for more than 10 years prior to the launch of Piper. Continued scaling of the Google repository was the main motivation for developing Piper."
- A hozzászóláshoz be kell jelentkezni
Tokmind1 ... a lenyeg, hogy nekik nagyobb! :P
- A hozzászóláshoz be kell jelentkezni