Administrace komentářů

Kód jde přeložit a nepadají testy, ale nejde věci přidávat do košíku (protože se celá funkcionalita mění a znamená to několik dní či týdnů práce).

To je špatně. Pokud šlo do košíku přidávat před tím, musí tam jít přidávat i po tom, jinak nebudou fungovat testy na přidávání do košíku.

Zkuste ten příklad naformulovat jinak, takhle se totiž vracíme k systému práce franta si 2 týdny pižlá košík nemluvte na něj.

Je vidět, že jste nikdy nepracoval na větším projektu.

Co je to podle vás větší projekt? Uveďte konkrétní příklad a zkušenosti...

Jeden konflikt za půlden mi dává 40 konfliktů za měsíc. Jeden konflikt za čtrnáct dní mi dává 2 konflikty za měsíc. Co je míň?

Jeden konflikt za půlden, kterej řeším 5 minut, mi dá 40*5 minut (=asi 3,5 hod) měsíčně. Pokud nechám těch 28 konfliktních změn za 14 dnů řešit jen jednou za 14 dnů, tak to budu řešit minimálně den, takže celkem 2 dny měsíčně.

Je to proto, že velikost změny + stáří změny a čas strávený její diagnózou nejsou v přímé úměře.

Příkladně, když vím že před 5 minutama všechny testy chodily, a teď nechodí, tak stačí, když budu řešit posledních 5 minut změn, což mám ještě v hlavě a bude mi leckdy stačit se podívat na chybovou hlášku. Pokud budu pracovat celý den a na konci dne mi něco nepůjde, tak budu debugovat a hledat a strávím tím spoustu času navíc. Myslím že každý z nás už tuhle zkušenost prodělal.

Vyvíjím novou funkci, předpokládám, že tam budu potřebovat dva další parametry navíc. Přidám je do rozhraní, všichni refaktorují. Za pár dní zjistím, že se jeden parametr vůbec nepoužívá, tak ho vyhodím. Všichni refaktorují...

Ten příklad jak jsem ho popsal já se ale liší v podstatné věci. Než vyhodím parametr, tak už budu mít k dispozici kód od "všichni", a refaktoruju ho já. "Všichni" se tím nemusí vůbec zabývat. A to je důležité. A je to možné jen tehdy, když "všichni" publikují svůj kód pravidelně a často.

Ale ten časový plán nepočítá s tím, že se ucelené změny v kódu zvládnou během půl dne. Naopak, vývoj jádra je postaven na tom, že se pracuje paralelně ve spoustě větví, a do master větve se kód dává až po funkčních celcích.

Pokud vím, tak linux-next se merguje z branchí vývojářů podsystémů každej den. Jak často tam oni publikují, to je jejich věc. Každopádně pochopte, že i když kernel má třeba release cyklus jednou za 3 měsíce, tak prostě přes to vlak nejede, a co se za 3 měsíce nestihne, tak musí až do další verze. Takže to není tak, že kernel čeká až bude hotové cosi velkého, ale naopak že přispěvatelé si kouskují práci tak, aby do každého okna něco přicmrndli. Tenhle princip lze aplikovat na libovolný časový úsek.

A že by Linus musel neustále řešit nějaké hrozné konflikty při mergování, to se mi nezdá.

Ne, to samozřejmě neřeší, řeší to ti přispěvatelé. Proto pravidlo, první patch se aplikuje čistě a ostatní mergují proti tomu. Opět lze praktikovat v libovolné frekvenci.