Back to site
Since 2004, our University project has become the Internet's most widespread web hosting directory. Here we like to talk a lot about web servers, web development, networking and security services. It is, after all, our expertise. To make things better we've launched this science section with the free access to educational resources and important scientific material translated to different languages.

Fork ili ne Fork


Fork (“viljuška”) ili ne Fork

Lekcije od Ubuntu-a i Debian-a

Benjamin Mako Hill

Kanonski ograničeno
The Debian GNU/Linux Project
Software in the Public Interest, Inc.

Ovaj materijal je licenciran pod Creative Commons Attribution-Sharealike 2.0 License.

Kanonska lokacija za najnoviju verziju ovog dokumenta je na autorovom web sajtu.

Istorijat revizije
Revizija 0.2 7.avgust 2005.
Ispravka i poboljšanja.
Revizija 0.115.maj 2005.

Prva verzija ovog pisanog rada je napisana za prihvaćeni govor održan na Linuxtag-u 2005. u Karlsruhe-u, Nemačka.


Uvod

Eksplozivni porast slobodnog i open source software-a tokom poslednje decenije se ogledao u podjednako eksplozivnom porastu u ambicioznosti projekata slobodnog software-a u izboru i bavljenjem problemima. Pokret za slobodni software ovim velikim problemima pristupaju sa više koda i širim zajednicama, nego što se to moglo zamisliti prethodne decenije. Primer ovih masivnih projekata uključuje desktop okruženja - kao GNOME i KDE - i distribucije kao Debian, RedHat, i Gentoo.

Ovi projekti usklađuju rad hiljada programera — podjednako volontera i plaćenih — i proizvode milione redova koda. Njihov software se koristi od strane miliona korisnika sa različitim skupinama potreba. Ovaj pisani rad se fokusira na dva glavna efekta ove situacije:

  • Zajednice kojima projekti slobodnog software-a — a naročito veliki projekti — služe, su sve različitije. Za pojedinačni veliki projekat postaje sve teže da izda bilo kakav pojedinačni proizvod koji može da usluži sve njegove potencijalne korisnike.

  • Postaje sve teže reprodukovati ove velike projekte.Dok je reprodukovanje čitavog projekta nemoguće za male grupe hacker-a, često nije moguće ni za male grupe da bar trakiraju održavaju fork (viljuška) velikog projekta tokom vremena.

Uzevši sve zajedno, ove činjenice podrazumevaju sve više realizovanu zajednicu slobodnog software-a iz koje programeri često potiču, ali gde je i tradicionalni forking često neodrživ. "Forks," kako su tradicionalno definisane, moraju biti poboljšane. Zajednice oko velikih projekata slobodnog software-a moraju biti pametnije u vezi procesa derivacije, nego što su to ranije bile.

Mi ovo već vidimo sa GNU/Linux distribucijama. Nove distribucije su danas retko izgrađene iz scratch-a (grebanje). Umesto toga, one su adaptirane iz, i izgrađene na radu postojećih projekata. Kako projekti i baze korisnika rastu, ove izvedene distribucije su sve uobičajenije. Većina onoga što ja opisujem u ovom eseju su alati i iskustva izvedenih distribucija.

Stvaraoci software-a moraju da slede ideju ekosistema projekata i proizvoda slobodnog software-a koje su fork-ovali, ali da održavaju blizak odnos kako rade paralelan i simbiotički razvoj. Da bi to uradili, developeri bi trebalo da:

  • Razlome proces derivacije na skup različitih tipova kustomizacije i derivacije i naprave prioritete metoda derivacije.

  • Kreiraju i podstiču socijalna rešenja za socijalne aspekte problema derivacije.

  • Grade i koriste nove alate specifično dizajnirane za koordinisanje razvoja software-a u kontekstu ekosistema projekata.

  • Distribuiraju i koriste alate kontrole distribuirane verzije sa naglaskom na održavanju razlika tokom vremena.

Ovaj pisani rad je rana analiza ovog skupa problema. Kao takav, izrazito je fokusiran na iskustvo Ubuntu projekta i njegovom postojanje kao izvedene Debian distribucije. Takođe vuče i iz mog iskustva sa Debian-NP i Custom Debian Distribution (CDD) zajednicom. Obzirom da učestvujem podjednako u Ubuntu i CDD projektima, ovo su oblasti o kojima mogu da diskutujem sa nekim nivoom znanja i iskustva.

"Fork" je reč od četiri slova

Čin uzimanja koda za projekat slobodnog software-a i njegovo razdvajanje radi kreiranja novog projekta se zove "forking." Postojale su brojne čuvene forks u istoriji slobodnog software-a. Jedna od najpoznatijih je schism (rascep) koja je odvela do paralelnog razvoja dve verzije Emacs text editor-a: GNU Emacs i XEmacs. Ovaj rascep istrajava do danas.

Neke forks, kao Emacs i XEmacs, su permanentne. Druge su relativno kratkog daha. Primer ovoga je GCC projekat koji je video dve forks — EGCS i PGCC — koje su se obe na kraju ponovo stopile u GCC. Forking se može dogoditi iz bilo kojeg broja razloga. Često developeri na projektu razvijaju političke ili lične razlike koje ih dovraćaju od daljeg zajedničkog rada. U nekim slučajevima, oni koji održavaju postaju oni koji ne odgovaraju, a drugi developeri fork-uju da bi održali software u životu.

Na kraju ipak, većina fork-ova se pojavljuje jer se ljudi ne slažu oko karakteristika, mehanizama, ili tehnologije u jezgru projekta. Ljudi imaju različite ciljeve, različite probleme, i žele različite alate. Često, ovi ciljevi, problemi i alati jesu slični do izvesne tačke pre nego što potreba za razdvajanjem načina postane suštinska.

Fork se pojavljuje na nivou koda, ali fork nije isključivo — ili čak primarno — tehnička. Mnogi projekti kreiraju “grane”. Grane su alternativne verzije dela software-a koje se koriste za eksperimentisanje sa intruzivnim ili nestabilnim karakteristikama i fiksiranim delovima. Forks se razlikuju od grana podjednako u tome što su često značajnija odstupanja od tehničke perspektive (to jest, više redova koda je promenjeno/ili su promene invazivnije ili predstavljaju fundamentalnije razmatranje problema), i u tome što su razdvajanja definisana u socijalnim i političkim pogledima. Grane uključuju pojedinačnog developera ili zajednicu developera — budući da su forks odvojeni projekti.

Forking se istorijski posmatrao kao kao loša stvar u zajednicama slobodnog software-a: njihovo viđenje je da proističu iz nesposobnosti ljudi da rade zajedno i završili su u reprodukciji rada. Kada sam objavio prvu verziju Free Software Project Management HOWTO pre više od četiri godine, uključio sam mali pod-odeljak o forking-u koji je opisao koncept za buduće lidere projekta slobodnog software-a, ovim tekstom:

Kratka verzija odeljka o fork-u je, na radite ih. Forks primoravaju dvelopere da biraju jedan projekat na kome će raditi, zbog političkih podela i preobilnog posla.

U najboljim situacijama, fork znači da dve grupe ljudi treba da krenu sa razvojem karakteristika i obavljanjem posla koji bi normalno radili kao dodatan trakiranju fork-ovanog projekta i obavezi da ručno selektuju i primenjuju karakteristike i fiksne delove njihovoj bazi koda. Ovaj nivo monitoring-a i konstantno poređenje mogu biti izuzetno teški i troše mnogo vremena. Ovoj situaciji nisu suštinski pomogli tradicionalni alati kontrole izvora (source control tools) kao diff, patch, CVS i Subversion koji nisu optimizirani za ovaj zadatak. Gora (i daleko uobičajenija) situacija se pojavljuje kada dve grupe počnu da rade bez, ili sa parcijalnim znanjem o kodu sa druge strane fork-a. Važne karakteristike i fiksni delovi se implementiraju dvaput — različito i nekompatibilno.

Najbitnija svetla strana ovih nedostataka je što su problemi ujedinjeni sa forking-om toliko ozbiljni i grozni da, u većini slučajeva, pretnja od fork-a biva dovoljna da primora one koji održavaju da razrade rešenja koja zadržavaju fork da se dogodi pre svega.

Konačno, vredi ukazati da je fork nešto kao osporavani termin. Iz razloga što definicije fork-a uključuju, u manjem ili većem stepenu, iskaze o političkim, organizacionim, i tehničkim razlikama među projektima, razdvajanja koje mnogi ljudi nazivaju granama ili paralelnim stablima, od strane drugih su opisana kao forks. Nedavno, podstaknuta pojavom sistema kontrole distriburane verzije, definicija toga šta jeste, a šta nije fork je postajala sve manje jasna. Delom zbog istih sistema, prednosti i mane onoga što se sve više problematično nazivalo forking-om, podjednako je sporno.

Studija slučaja

U mom uvodu, opisao sam kako rastući obim projekata slobodnog software-a i rapidno rastuća veličina i raznolikost korisničkih zajednica predvodi potrebom za novim tipom derivacije koja izbegava, što je bolje moguće, nedostatke forking-a. Nigde to nije očiglednije nego u najvećim projektima sa najširim obimom: mala grupa projekata koja uključuje distribucije operativnih sistema.

Debian projekat

Debian projekat je po mnogim proračunima najveća distribucija slobodnog software-a u pogledu koda. Takođe je, verovatno, najveći projekat slobodnog software-a u pogledu broja volontera. Debian uključuje više od 15,000 paketa i rad dobrog broja od preko 1,000 zvaničnih volontera i još mnogo saradnika bez zvaničnog članstva.Projekti bez Debian-ove masovne baze volontera ne mogu ponoviti ono što je debian postigao; mogu se retko nadati da bar održe ono što je Debian proizveo.

U vreme kada je ovaj rad napisan, Distrowatch nabraja 129 distribucija baziranih na Debian-u — većina njih su trenutno aktivne u različitom stepenu. Svaka distribucija predstavlja bar jednu osobu — a u većini slučajeva zajednicu ljudi — koji se nisu složili sa Debian-ovom vizijom ili pravcem dovoljno jako da žele da kreiraju novu distribuciju i koji su imali tehnički kapacitet da proprate ovaj cilj. Uprkos Debian-ovom dugogodišnjem sloganu — "univerzanil operativni sistem" — činjenica da je Debian projekat postao operativni sistem sa najbržim rastom, istovremeno šireći toliko derivata, svedočanstvo je činjenici da, što se software-a tiče, jedna veličina ne može odgovarati svima.

Organizaciono, oni koji potiču od Debian-a, locirani su podjednako unutar i izvan Debian projekta. Grupa onih koji potiču od Debian-a, a koji rade zajedno unutar Debian projekta, označili su sebe kao "Custom Debian Distributions" i kreirali blizu dvanaest projekata prilagođavajući i izvodeći iz Debian-a za određene grupe korisnika uključujući neprofitne organizacije, medicinske zajednice, pravnike, decu i mnoge druge. Ovi projekti grade na jezgru Debian distribucije i Cannonical-ovog arhiva iz unutrašnjosti organizacionih i političkih limita Debian projekta i konstantno se trude da minimiziraju delt-u fokusiranjem na manje invazivne promene i unapređuju kreativne načine građenja sposobnosti za menjanjem jezgra baze Debian koda kroz ustanovljene i politički usaglašene procedure.

Druga grupa Debian customizer-a (oni koji prilagođavaju) uključuje one koji rade izvan Debian projekta, organizaciono. Za zapažanje sa ove liste su (po abecednom redu) Knoppix, Libranet, Linspire (nekada Lindows), Progeny, MEPIS, Ubuntu, Userlinux, i Xandros. Sa svojom jakom tehnološkom bazom, odličnim upravljanjem paketom, širokim izborom paketa za odabir, i jakom posvećenošću slobodi (besplatnom) software-a, što osigurava mogućnost derivacije, Debian obezbeđuje idealnu tačku polaska za kreiranje GNU/Linux distribucije.

Ubuntu

Ubuntu projekat je započeo Mark Shuttleworth u aprilu 2004. i prva verzija je izgrađena gotovo u potpunosti od strane male grupe Debian developera zaposlenih od strane Shuttleworth-ove kompanije Canonical Limited. Puštena je u svet krajem 2004. Druga verzija je izdata šest meseci kasnije u aprilu 2005. Ciljevi Ubuntu-a su da obezbedi distribuciju baziranu na podskupu Debian-a sa:

  • Regularnim i predvidljivim izdanjima — svakih šest meseci sa podrškom za osamnaest meseci.

  • Naglaskom na slobodni software koji će održavati mogućnost derivacije distribucije.

  • Naglaskom na upotrebljivost i konzistentnu viziju desktop-a. Kao primer, ovo je prevedeno u manje pitanja u instaleru i default selekciji i konfiguraciji paketa koji su upotrebljivi za većinu desktop korisnika “out of the box."

Ubuntu projekat obezbeđuje interesantan primer projekta koji za cilj ima da izvodi iz Debian-a u velikom stepenu. Ubuntu je napravio promene na nivou koda do blizu 1300 paketa u Debian-u u vreme kada je ovaj rad napisan i brzina promena se neće smanjiti tokom vremena; ukupan broj promena i ukupna veličina delta-e će rasti. Promene koje Ubuntu pravi su primarno najintruzivnije vrste — promene na samom kodu.

To će reći, Ubuntu projekat je eksplicitan u vezi činjenice da ne bi mogao da postoji bez rada koji je obavio Debian projekat. Još važnije, Ubuntu objašnjava da ne može da nastavi da obezbeđuje kompletan set paketa od kojih njegovi korisnici zavise bez tekućeg rada od strane Debian projekta. Iako je Ubuntu napravio promene do blizu 1300 paketa, ovo je manje od deset procenata ukupnog broja paketa isporučenih u Ubuntu-u i povučenih od Debian-a.

Scott James Remnant, istaknuti Debian developer i hacker na Ubuntu-u koji radi za Canonical Ltd., na ovakav način je opisao situaciju na svom web log-u da bi predstavio metodologiju razvoja Ubuntu-a u nedelji nakon prvog javnog objavljivanja Canonical-a i Ubuntu-a:

Ne mislim da je Ubuntu "fork" Debian-a, sugeriše da u nekom trenutku krećemo odvojenim putem od Debian-a i zatim sa vremena na vreme se stapaju u promenama kako mi nastavljamo sopstvenom putanjom.

Naš model se prilično razlikuje; svakih šest meseci pravimo snimak Debian-ove nestabilne distribucije, primene i izvanrednih patch-ova (“zakrpe”) od našeg poslednjeg izdanja do njega, i provedemo par meseci testirajući ga i sređujući bug-ove.

Jedna stvar koja bi trebalo da je očigledna iz ovoga je da je naš posao mnogo lakši ako Debian uzme sve naše promene. Model nas zapravo podstiče da vratimo Debian-u.

Zbog toga smo od prvog dana počeli da sređujemo bug-ove koje smo krenuli da šaljemo nazad Debian-u kao patches kroz BTS. Ne samo da će to olakšati mnogo naš posao kada dođemo do zmarzavanja za “drevno”, naše sledeće izdanje, već je to upravo ono što bi svaki derivat trebalo da uradi pre svega.

Postoji izvesna debata o tome do kog stepena su Ubuntu developeri uspeli da postignu ciljeve izložena od strane Remnant-a. Ubuntu je fajlovao stotine patch-ova u sistemu trakiranja bug-ova, ali je naleteo i na probleme u odlučivanju šta čini nešto što bi trebalo da je vraćeno debian-u. Mnoge promene prosto nisu relevantne za Debian developere. na primer, oni mogu uključiti promene u paket kao odgovor na drugu promenu urađenu u drugom paketu u ubuntu-u koja neće biti ili nije uzeta od strane Debian-a. U mnogim drugim slučajevima, najbolja akcija u odnosu na određene promene, određeni paket, i određeni upstream,Debian developer je prosto nejasan.

Zapis trakiranja Ubuntu projekta u konstruktivnom radu sa Debian-om je, za sada, izmešan. Dok stalno rastući broj Debian developera održava svoje pakete aktivno unutar oba projekta, mnogi podjednako u Debian-u i Ubuntu-u smatraju da Ubuntu ima zaostalog posla u oživljavanju sopstvenog cilja potpuno izglađenog produktivnog odnosa sa Debian-om.

To će reći, važnost ciljeva opisanih od strane Remnant-a u kontekstu razvojnog modela Ubuntu-a ne može biti preterana. Svaka linija delta-e između Debian-a i Ubuntu-a ima cenu za Ubuntu developere. Tehnologija, društvena prksa, i mudri izbori mogu da redukuju troškove, ali ih ne mogu eliminisati. Resursi koje Ubuntu može doneti da bise nosio sa problemom izgradnje distribucije su ograničeni — daleko ograničeniji od Debian-ovih. Kao rezultat, postoji ograničenje koliko daleko Ubuntu može da odstupi; uvek je u prednosti Ubuntu-a da minimizira delta-u gde je to moguće.

Primenljivost

Ubuntu i Debian su distribucije i — kao takve — operišu na različitom nivou nego velika većina projekata slobodnog software-a. Uključuju više koda i više ljudi. Kao rezultat, postoje pitanja kao što su da lisu iskustva i lekcije naučene iz ovih projekata naročito ptimenljive na iskustva manjih projekata slobodnog software-a.

Jasno, zbog poteškoća sjedinjenih sa ogromnom količinom forking-a koda i problema sjedinjenih sa dupliranjem rada velikih volonterskih baza, distribucije su primorane na nalaženje načina za balansiranjem između koristi i mana forking-a. Međutim, dok je potreba jača i neposrednija u većim projektima, koristi njihovih rešenja će često biti u poptunosti prenosive.

Jasno, mogućnost modifikacije slobodnog software-a da se bolje uklapa sa potrebama svojih korisnika leži u srcu uspeha pokreta slobodnog softwareeđutim, dok modifikacija obično dolazi u formi saradnje na bazi pojedinačnog koda, ovo je funkcija ograničenja u metodologijama razvoja software-a i alata pre nego najbolji odgovor na potrebe ili želje korisnika ili developera.

Verujem da će fundamentalna prednost slobodnog software-a u narednoj deceniji biti u rastućoj sposobnosti da svaki pojedinačni projekat slobodnog software-a budu višestruke stvari za istovremeno višestruke korisnike. Ovo će preću u činjenicu da će, u narednih deset godina, tehnologija i socijalni procesi napredovati, tako da forking postaje manje loša stvar. metodologija razvoja slobodnog software-a će postati manje zavisna od pojedinačnog projekta i počeće da ističe paralelni razvoj unutar ekosistema odnosnih projekata. Rezultat je da će projekti slobodnog software-a dostići kompetitivnu prednost nad vlasničkim software-skim projektima kroz svoju sposobnost da bolje služe sve različitije potrebe sve većih i sve raznovrsnijih baza korisnika. Iako to danas zvuči paradoksalno, nastaće više projekata, a biće napisano manje suvišnog koda.

Projekti koji su više limitirani u kodu i obimu mogu koristiti alate i metode opisane u podsetniku ovog pisanog rada u različitim kombinacijama, na različite načine, i do različitih nivoa nego primeri oko distribucija predstavljenih ovde. Različiti projekti sa različitim potrebama će otkriti da izvesna rešenja funkcionišu bolje od ostalih. Iz razloga što su zajednice veličine Debian-a teške za fork na način koji doprinosi bilo kojoj strani, dešava se da se u ovim zajednicama tehnologija i metodologije razvoja prve pojavljuju. Vremenom, ove strategije i alati će se naći produktivno uposleni u širokom spektru projekata sa širokim spektrom veličina, potreba, obima i opisa.

Balansiranje Forking-a sa saradnjom

Derivacija i analiza problema

Najlakši korak u kreiranju projekta produktivnog derivativnog software-a je razlomiti probleme derivacije na serije različitih klasa modifikacije. Izvesni tipovi modifikacije se lakše urade i suštinski su održiviji.

U kontekstu distribucija, problem derivacije može biti razlomljen na sledeće tipove promena (sortirane grubo prema nepretencioznosti inherentne u rešavanju problema i ozbiljnosti problema dugotrajne održivosti koje oni uvode):

  1. Selekcija individualnih delova software-a;

  2. Promene u načinu na koji su paketi instalirani ili pokrenuti (npr., u okruženju Živog CD tipa ili korišćenje rezličitog instalera);

  3. Konfiguracija različitih delova software-a;

  4. Promene urađene na samom software paketu (urađene na nivou promena na kodu paketa);

Razbijanjem problema na ovaj način, Debian derivati su bili u stanju da pristupe derivaciji na načine koji fokusiraju energiju na manje pretenciozne probleme pre svega.

Prva oblast na koju se Ubuntu fokusirao bila je selektovanje podskupa paketa koje bi Ubuntu podržao. Ubuntu je selektovao i podržava približno 2,000 paketa. Oni su postali glavna komponenta u Ubuntu-u. Drugi paketi u Debian-u su bili uključeni u odvojeni odeljak Ubuntu arhive zvane universe, ali nisu imali garanciju da će biti podržani fiksnim delovima za bug-ove ili bezbednost. Fokusiranjem na mali podskup paketa, Ubuntu tim je mogao da slektuje održivi pod-odeljak Debian arhive koju su mogli da održavaju tokom vremena.

Najjednostavnije izvedene distribucije su— koje često rade unutar Debian projekta kao CDD, ali takođe uključuju projekte kao Userlinux — isključivo liste paketa i ne rade ništa van selekcije paketa. instalacija lista paketa i održavanje ovih lista tokom vremena se može pomoći kroz kreiranje onoga što zovu meta-paketima: prazni paketi sa dugim listama "zavisnih delova."

Druga stavka, promene konfiguracije, takođe je od manjeg uticaja. Fokusiranje na izmeštanje što je moguće više promena u oblast promena konfiguracije je održiva strategija koju su oni koji rade derivaciju, a rade na cilju Debian projekta na bazi pojedinačnog koda, aktivno sledili. Njihova ideja je da radije nego da fork-uju deo koda zbog neslaganja u tome kako bi program trebalo da radi, mogu ostaviti kod netaknut, ali dodati mogućnost rada na drugačiji način za software. Ova promenjena funkcionalnost je učinjena priključnom kroz promenu konfiguracije na isti način na koji su aplikacije konfigurisane kroz pitanja postavljena u vreme instalacije. Pošto Debian projekat ima unificirano spakovani framework konfiguracije zvani Debconf, oni koji rade derivaciju mogu da konfigurišu čitav sistem na izrazito centralizovani način. Ovo se ne razlikuje od RedHat-ovog Kickstart-a, iako je naglasak na održavanju tih promena konfiguracije tokom života i napretka paketa; Kickstart je isključivo fokusiran na instalaciju paketa.

Treći tip konfiguracije je ograničen na promene u okruženju kroz koje se sistem pokreće ili instalira. Jedan od primera je Progeny-ev na Anaconda-i baziran Debian instaler koji obezbeđuje promenjeni instaler, ali rezultira u identičnom sistemu. Još jedan primer je Knoppix projekat koji je čuven po svojim "Live CD" okruženjima. Dok Knoppix čini širok opseg invazivnih promena koje prebacuju sve stavke u moju gore pomenutu listu, drugi Live CD projekti, uključujući Ubuntu-ov "Casper" projekat, mnogo su bliži izmenjenom shell-u kroz koji se pokreće isti kod.

Iz razloga što su ove tri metode relativno ne-invazivne, razumne su strategije za male timove i pojedince koji rade na kreiranju izvedene distribucije. međutim, mnoge poželjne promene — i u slučaju nekih izvedenih distribucija, najpoželjnije promene — traže invazivnije tehnike. Poslednji i najinvazivniji tip promene — promene u kodu — jeste najteži, ali takođe najviše obećava i najmoćniji je ako se to može uraditi održivo. Promene ovog tipa uključuju račvanje baze koda i biće tema podsetnika ovog pisanog rada.

Distribuirana source (izvor) kontrola

Jedna obećavajuća metoda održavanja delta-i u fork-ovanim ili granskim (branched) projektima leži u distribuiranim sistemima kontrole verzije (version control systems (VCS)). Tradicionalni VCS sistemi rade na visoko centralizovani način. CVS, arhetipski slobodni software VCS i osnove mnogih drugih, baziran je oko modela pojedinačnog centralizovanog servera. Svako ko želi da se obaveže projektu mora se obavezati centralizovanom skladištu (repository). Dok CVS dopušta korisnicima da kreiraju grane, svako sa obavezujućim pravim ima pristup čitavom skladištu. Alati za pravljenje grana i stapanje vremenom postaju ne naročito dobri.

Model grananja je prvenstveno usmeren ka sistemu gde je razvoj razdvojen, a zatim grana u potpunosti ponovo stopljena u glavno stablo. Normalna upotreba grane bi mogla da uključi kreiranje razvoja grana, pravljenje serija razvojnih izdanja, dok se za to vreme održavaju i sređuju važni bug-ovi na primarnoj stabilnoj grani, a onda na kraju zameni stabilno izdanje sa razvojnim izdanjem. CVS model nije usmeren ka sistemu gde se proizvoljna delta, ili skupovi delta-i, održavaju tokom vremena.

Distribuirana kontrola verzije ima za cilj da rešava brojne probleme uvedene od strane CVS-a koji aludira na gore navedeno tako što:

  • Dopušta ljudima da rade međusobno nepovezani i bez međusobne sinhronizacije, potpuno ili delimično, na proizvoljni i ad-hoc način.

  • Dopušta delta-ama da budu održavane tokom vremena.

Na kraju krajeva, ovo traži alate koji su bolji kod stapanja promena i koji ne stapaju izvesne promene kada je to željeno ponašanje. To takođe vodi do alata sposobnih za stapanje osetljivo na istoriju.

Najpoznatije prebacivanje na distribuirani VCS model iz centralizovanog VCS modela bio je potez Linux kernel razvojne zajednice na vlasničkom sistemu kontrole distribuirane verzije BitKeeper-u. U njegovoj nedavnoj objavi odluke da se odvoji od BitKeeper-a, Linus Torvalds je rekao:

Ustvari, uticaj koji je BK imao je da nas suštinski natera (a naročito mene) da promenimo način na koji radimo stvari. To obuhvata oblasti od trakiranja najsitnijih skupina promena do prostog načina na koji sam ja završio verujući pod-održavaocima sa mnogo većim stvarima, a da više nisam morao da radim na patch (“zakrpa”) po patch.

U vreme prebacivanja, slobodni alati kontrole distribuirane verzije su bili manje napredni nego danas. U ovom trenutku, nedovršena lista VCS alata slobodnog software-a uključuje GNU Arch, Bazaar, Bazaar-NG, Darcs, Monotone, SVK (baziran na Subversion-u), GIT (sistem razvijen od strane Linus-a Torvalds-a kao zamena za BitKeeper) i druge.

Svaki od ovih alata, bar nakon što dostignu izvestan nivo zrelosti, omogućavaju ili će omogućavati korisnicima da razvijaju software na distribuirani način i da, vremenom, porede svoj software i vuku promene iz drugih značajno lakše nego što bi to drugačije mogli. Ideja o paralelnom razvoju leži u srcu modela. Alati za stapanje i rešavanje konflikata tokom vremena, i sposobnost za “biranjem” izvesnim patch-ova ili promena od paralelnog developera, svaki čini ovaj tip razvoja značajno korisnijim nego što je to bilo u prošlosti.

VCS-i u potpunosti rade na nivou koda. Zbog prirode tipova promena koje Ubuntu projekat pravi na Debian kodu, Ubuntu se prvenstveno fokusirao na ovaj model i Canonical trenutno zasniva dva glavna proizvoda distribuirane kontrole — Bazaar i Bazaar-NG projekte.

Na mnogo načina, upošljavanje kontrole distribuirane verzije efektivno, daleko je lakši problem za rešavanje za male, tradicionalnije, projekte razvoja slobodnog software-a, nego što je to za GNU/Linux distribucije. Iz razloga što su problemi udruženi sa održavanjem paralelnog razvoja pojedinačnog dela software-a u skupu odnosnih distribuiranih skladišta primarni slučaj upotrebe za sisteme kontrole distribuirane verzije, sam distribuirani VCS može biti tehničko rešenje za izvesne tipove paralelnog razvoja. Kako alati i društveni procesi za distribuirani VCS napreduju, postaće sve važniji alati u načinu na koji se slobodni software razvija.

Iz razloga što su problemi opsega udruženi sa izgradnjom čitave derivativne distribucije komplikovaniji od onih udruženih sa radom sa pojedinačnim "upstream" projektom, kontrola distribuirane verzije se samo aktivno raspoređuje u Ubuntu projekat. Radeći to, projekat se fokusira na njihovo integrisanje u specifične alate za problem, izgrađene na kontroli distribuirane verzije.

Specifični alati za problem

Još jedna tehnika na kojoj Canonical Ltd. eksperimentiše je kreiranje alata visokog nivoa izgrađenih na alatima kontrole distribuirane verzije posebno dizajniranih za održavanje razlike među paketima. Iz razloga što se ovi paketi obično distribuiraju kao source fajl sa kolekcijom od jednog ili više patch-ova, ovo uvodi jedinstvenu mogućnost kreiranja VCS sistema visokog nivoa baziranog na ovoj činjenici.

U slučaju Ubuntu-a i Debian-a, ideaan alat kreira jednu granu po patch-u ili karakteristiku i koristi heuristiku za analiziranje patch fajlova i inteligentno kreiranje ovih grana. Odeljak o izgradnji paketa ukupnog patch-a se takođe može držati kao odvojena grana. Canonical-ov alat, zvani Hypothetical Changeset Tool (HCT) (iako više nije hipotetički), jeste eksperimentalni način za kreiranje veoma jednostavnog, veoma aerodinamičnog interface-a za bavljenje određenim tipom source-a koji je kreiran i distribuiran na poseban način sa posebnim tipom promene.

Dok HCT obećava da će biti veoma koristan za ljude koji prave izvedene distribucije bazirane na Debian-u, njegova primena van onih koji rade distribucije će biti, po svemu sudeći, ograničena. To će reći, on daje primer načina na koji problem i kontekstualno specifični alati mogu odigrati suštinsku ulogu u održavanju izvedenog koda, uopštenije.

Društvena rešenja

Rečeno je da je opšta glupost od “tehnofila” da pokuša da uposli tehnička rešenja za rešavanje društvenih problema. Problem derivacije software-a je podjednako tehnički i društveni problem i shodno tome ukazuje da veći problemi traže pristupe koji uzimaju u razmatranje oba tipa rešenja.

Scott James Remnant poredi odnos između distribucija i izvedenih distribucija kao slične odnosu između distribucija i uostream održavalaca:

Ne mislim da se to mnogo razlikuje od toga kako Debian održavaoci međusobno deluju sa svojim upstream-ovima. Kao Debian održavaoci, uzimamo i pakujemo upstream software ,a zatim delujemo kao izlaz iz bug-ova i problema. Prilično često sređujemo bug-ove sami i primenjujemo patch na paket i šaljemo ga upstream. Ponekad upstream ne uključuje u sebe taj patch i mi se moramo uveriti da ga slučajno ne ispustimo kod svakog izdanja koje sledi, pa daleko više volimo ako ih oni uzmu, ali se ne ljutimo ako se to ne desi.

Ovako ja vidim odnos između Ubuntu-a i Debian-a, više nismo fork Debian-a, nego je Debian paket fork svog upstream-a.

Scott aludira na činjenicu da je, bar u svetu distribucija, paralelni razvoj već jedan način gledanja na modus operandi postojećih GNU/Linux distribucija. Odnos između onoga ko radi derivaciju i derivee-a na nivou distribucije odražava odnos između distribucije i "upstream" autora paketa koji sastavljaju distribuciju. Ovi odnosi su retko bazirani na tehnološkim alatima, ali su u poptunosti u oblasti društvenih rešenja.

Ubuntu je sledio brojne različite inicijative u tom smislu. Prva od njih bila je regularni fajlovanje bug-ova u Debian sistemu trakiranja bug-ova, kada se bug-ovi koji postoje u Debian-u sređuju u Ubuntu-u. I dok ovo može biti delimično automatizovano, izbor za automatizacijom ovoga i način na koji je ovo podešeno je čisto sociološki.

Međutim, pošto sam aludirao na gore navedeno, Ubuntu je još uvek ostavljen sa pitanjima u vezi promena koje su napravljene na paketima koje ne sređuju bug-ove obavezno ili koji sređuju bug-ove koji ne postoje u Debian-u, već se mogu pojaviti u budućnosti. Neki Debian developeri žele da čuju o punom obimu promena učinjenih na njihovom software-u u Ubuntu-u, dok drugi ne žele da im se dosađuje. Ubuntu bi trebalo da nastavi da radi sa Debian-om da pronađe načine da omogući developerima da ostanu sinhronizovani.

Postoji takođe nekoliko inicijativa od strane developera u Debian-u, Ubuntu-u, i drugim derivacijama za stvaranje jačeg odnosa između Debian projekta i njegovog ekosistema onih koji rade derivaciju i naročito između Ubuntu-a i Debian-a. Iako je forma koju će na kraju ovo imati nejasna, projekti koji postoje unutar ekosistema bi trebalo da istražuju oblast odgovarajućih društvenih odnosa koji će osigurati da mogu da rade zajedno i budu informisani o međusobnom radu bez pribegavanja “spam-ovanja” jedni drugima sa nebitnim ili bespotrebnim informacijama.

Još jedno pitanje koje je nedavno odigralo važnu ulogu u Debian/Ubuntu odnosu je važnost podjednako davanja adekvatnog poverenja autorima ili upstream održavaocima software-a bez nagoveštaja da drugi rade za, podržavaju, ili su povezani sa projektima derivacije sa kojima, iz bilo kog razloga, "upstream" autor možda ne želi da bude udružen.

U slučaju Debian-a i Ubuntu-a, ovo je rezultiralo u isticanju zadržavanja ili uvoza changelog unosa kada se uvoze promene i u opštijem notiranju “pedigrea” promena. O tome se takođe nedavno diskutovalo u smislu polja “održavaoca” u svakom paketu u Ubuntu-u. Ubuntu želi da izbegne pravljenje promena na svakom ne-modifikovanom source paketu (i uvođenje bespotrebne delta-e), ali ne želi da pruži utisak da je održavalac paketa neko ne-udružen sa Ubuntu-om. I dok nije odlučeno ni o jednom rešenju u vreme pisanja, jedna ideja je uključila markiranje održavaoca paketa eksplicitno kao Debian održavalac u vreme kada su izgrađeni binarni paketi na Ubuntu mašinama za izgradnju.

Isticanje drušzvenih rešenja je takođe suštinsko kada koristimo distribuiranu VCS tehnologiju. Kao što je Linus Torvalds aludirao u navodima gore, važnost tehnoloških promena na distribuiranu VCS tehnologiju oseća se samo kada ljudi počnu da rade na različiti način — kada počnu da upošljavaju različite društvene modele interakcije developera.

Dok Ubuntu-ovo iskustvo može da pruži dobar model za rešavanje nekih od ovih pitanja kontrole source-a, može da posluži samo kao model, a ne kao čvrsti odgovor. Društvena rešenja moraju biti odgovarajuća za dati društveni odnos. Čak i u situacijama gde je paket “razgranat” (branched) zbog društvenih neslaganja, izvesni nivo saradnje na društvenom nivou biće suštinski za dugotrajnu sprovodljivost derivativa.

Zaključci

Kako tehnike opisane u ovom pisanom radu napreduju, uloga koju one imaju u razvoju slobodnog software-a postaje sve uglednija i sve važnija. One koje će im se pridružiti biće druge tehnike i modeli koje nisam opisao i ne mogu da predvidim. Zbog veličine i korisnosti njihovog koda i veličine njihovih razvojnih zajednica, veliki projekti kao Debian i Ubuntu bili su primorani na sukobljavanje i pokušaj posredovanja u problemima nasleđenim u forking-u i derivaciji. Međutim, pošto se o ovim problemima pregovara i alati i procesi napreduju ka rešenju, projekti slobodnog software-a svih veličina će moći da ponude korisnicima upravo ono što žele sa minimalnom suvišnošću i malo duplikata u radu. Radeći to, slobodni software će spregnuti moć sa kojom vlasnički modeli ne mogu da se takmiče. Oni će povećati svoj kapacitet da produciraju bolje proizvode i bolje procese. Na kraju, to će pomoći da slobodni software privuče više korisnika, dovede više developera, i proizvede slobodniji software višeg kvaliteta.


Published (Last edited): 18-06-2013 , source: http://mako.cc/writing/to_fork_or_not_to_fork.html