Vlákno názorů k článku
Wine zkouší GitLab od to_je_jedno - njn, obcas se najde i projekt, ktery zamrznul...

njn, obcas se najde i projekt, ktery zamrznul ve stredoveku (a je tak obtizne do nej prispet kdyz clovek neni dinosaurus).

Muj nazor tu asi nebude popularni, ale myslim si, ze podstatne vice rizeny vyvoj (takovy ten ktery pochazi z komerce) muze mit svuj smysl, a muze byt dokonce mnohem efektivnejsi (a neni to primarne o nastroji, zda se posilaji patche, nebo merguji nejake repozitare - to je technikalie). Chci tim rict, ze mnohdy vyvoj posune kupredu jeden clovek, ktery ma nejakou vizi, a v podstate "komunitni vyvoj" muze byt pak spis pritezi. Jako dobry priklad bych videl treba Win32 API, ktere je myslim na svou dobu celkem dobre navrzene, ale doprasila to "komunita" vyvojaru z MS pote, co zrejme ztratili vliv duleziti lide.

Mozna to je o nejake rovnovaze. A mozna to vysvetluje duvod, proc se Linux z meho pohledu do znacne miry potaci v takovem neprilis inovativnim bahynku.

Nechapu co se muze zmenit k negativnimu:
puvodne: voser se zasilanim patchu, zavislost na jednom konkretnim cloveku
nove: standardizovany nastroj pro vytvareni merge requestu, schvalovani MR treba 2 ze 3 lidi z urcite uzke skupiny.

"v komerci" standardne pouzivame gitlab/BB/git­hub/takovyto-cosi-od-MS a fakt si nemyslim, ze to je neco co by bylo proti prospechu projektu.

Drobnosti ako su komentovanie riadkov v patchi ktore vsetci vidia, automaticke kontroly pred zaradenim patchu (od kompilacie az po linting), ... zjednodusenie a zostandardizovanie prispevkov, to nemoze uskodit nicomu.

Jak už napsali ostatní, ta role jednoho člověka s vizí může fungovat stejně na githubu/gitlabu jako fungovala na mailing listu. Prostě policy a flow zůstane zachované, jen to pojede v nástrojích, které na to tyhle vývojové platformy roky vytvářely a tím pádem to bude mnohem efektivnější.

Leda že by tedy ten maník byl extrémně efektivní v čtení a aplikovaní patchů přes mailing list vs pull request workflow v gitlabu :-). Jako lidé jsou všelijací zvlášť dnes to člověk občas zírá, ale i tak ho k tomu časem nějaká komunita nebo přímo někdo z CrossOver dotlačí.

Spis je to tak, ze lidi jsou "lini" ucit se neco noveho a pouziti nove technologie, kterou clovek nezna muze ze zacatku cely proces vyrazne zpomalit. Ale jestli je v dnesni dobe vyvojar co neumi delat s git resp. gitlabem githubem atp. tak ma celkem velky technologicky dluh.

To co jsem popsal je vlastne z velke casti https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar ; moje myslenka, kterou jsem nedokazal prilis dostat do slov bylo to, ze nektere nastroje (gitlab konkretne hloubeji neznam) smeruji spis k tomu Bazaaru (trzisti), resp. jsou na nej vice stavene.

Mozna to je i nejakou moji neznalosti, ale ten dojem z toho mam. Jsem rad, ze tyhle problemy nemusim resit.

V praci tyhle nastroje na mergovani patchu/verzovani nepouzivame. Misto toho mame rozdelene projekty tak, aby byla vzdycky nekde odpovednost, a kdyz potrebuju neco zanest do zdrojaku "ktery mi nepatri", tak si pujcim .cpp, udelam pseudokod, navrhnu prototypy fci, atd. a nekdo jiny to za mne dodela.

Jak muzete mit nazor na neco, co neznate?

V githubu/gitlabu o prijeti a neprijeti zmen rozhoduje vlastnik repozitare. Pokud si nenechate zmenu predem schvalit v issue, nemuzete ocekavat, ze bude prijata.

No tak to jste progresivni no... teda v kontextu minuleho stoleti. V kontextu dneska totalne neefektivni.

Ono prave i s tim githubem/gitla­bem/BB existuje vec ktere se rika fork a pak je neco cemu se rika pull/merge request - takze muzes udelat praci komplet, dat tomu odpovednemu cloveku vec opravdu pripravenou. on sice bude odpovedny protoze bude jediny mit prava mergnout, ale porad bude videt, ze jsi to udelal ty. Ale jo, tak hlavne, ze jste ten korporat no s jasnou odpovednosti :-)