A millió dolláros kérdés pedig az, hogy melyik környezetbarátabb:
Valóban jó kérdés -- az biztos, hogy az az olcsóbb, ha a folyamat minél korábbi részénél elkapjuk a hibát. Hogy melyik a környezetbarátabb, azt nem tudom.
(nem tudom, hogyan lehet többszintű idézetet készíteni:)
>> végre fel kell ismerni, hogy a CI nem helyettesíti az alapos peer review-t
> No arguments here, de ki mondott ilyet egyáltalán?
Ez nyilvánvaló abból, hogy a github / gitlab WebUI mennyivel gyengébb eszköz a részletes code review-ra, mint a rendes email (git-format-patch, git-send-email). Nagyon hosszú és nagyon részletesen megvizsgált, több projektet érintő workflow váltásban vettem részt; teljesen egyértelmű számomra, hogy a "git forge" módszertan arra helyezi a hangsúlyt, hogy gyorsan olvasszunk be mindent, minél több contributor tudjon minél hamarabb csatlakozni, a code review másodlagos, a tesztek majd megfogják a hibákat. A squash-on-merge ennek tökéletes szimbóluma -- tökéletes jele annak, hogy a "git forge generációnak" nem jelent szinte semmit egy patch series szerkezete, sorrendje, evolúciója több verzión keresztül, illetve az eredményként létrejövő git history alkalmassága a biszekcióra (git-bisect), regresszió esetén. Például (tudtommal) sem a gitlab, sem a github WebUI nem kínál a mai napig a git-range-diff paranccsal összemérhető funkciót (amely egy több patch-ből álló sorozat inkrementális (v1, v2, v3...) bírálatánál kritikus); ennek üzenete egyértelmű.
A "git forge generáció" elsősorban működő(-nek látszó) kódot akar, amit esetleg át lehet nézni.
Az email alapú review-ban hívő generáció elsősorban emberek számára ír olvasható, részletesen dokumentált, minimalizált patch-eket, ahol a vezérelv az, hogy az olvasót (reviewer-t) lépésről-lépesre vezetve okítsuk, mintegy mellesleg felépítve a megoldást. Kódot nem a számítógépnek írunk, hanem a többi programozónak. Amikor a patch-et készítjük, az csak a nulladik rendű kérdés, hogy "hogyan írjam meg". Az első rendű kérdés az, hogy "hogyan értessem meg a reviewer-rel"; ez a fontosabb szervező elv. Egy patch akkor van kész, amikor már nincs mit elvenni belőle.
Nem azt mondom, hogy a "git forge módszertan" teljesen leszámol a review-val, de a hangsúly abszolút máson van. Számomra eltéveszthetetlen a különbség.
Mi köztes megoldásként (a gitlab-ra költözéshez, de a szigorú-gondos review eszközök / workflow megtartásához) külön projektet csináltunk / indítottunk: https://gitlab.com/bichon-project/bichon (ld. különösen a History / Motivation részt).
A code review szükséges, de egyáltalán nem váltja ki az alapos, jól átgondolt teszteket
Egyetértek, csak én úgy érzem, átestünk a ló túloldalára.