Jaderné noviny – 12. 6. 2014: Co bude v Linuxu 3.16 (diskuse)

[pavlix]

Nebylo by tedy lepší používat procesy ze softwarového inženýrství namísto akademického peer review jako vzor pro náš proces revidování kódu?

Jenom to ne :D.

[Petr Tomášek]

Nebylo by tedy lepší používat procesy ze softwarového inženýrství namísto akademického peer review jako vzor pro náš proces revidování kódu?

Jasně příjde nějaký korporátnický manažér a svoboda bude fpiči... :-/

[Michal Kubeček]

Občas neškodí podívat se na kontext, než začnete bít na poplach. Konkrétně šlo o tohle:

IMO, every reviewer has their own developement environment and they should be at least testing that the change they are reviewing doesn't cause problems in that environment, just like they do for their own code before they post it for review.

Let me ask you this. In the scientific community, when someone posts a research project and asks their peers to review their work. Are all those reviewers required to test out that paper? Or are they to review it, check the math, look for cases that are missed, see common errors, and other checks? I'm sure some reviewers may do various tests, but others will just check the logic. I'm having a very hard time seeing where Reviewed-by means tested-by. I see those as two completely different tags.

We are not conducting a scientific research experiment here. We are conduting a very large software engineering project here.

So perhaps we should be using robust software engineering processes rather than academic peer review as the model for our code review process?

Nepopírám, že ta myšlenka je kontroverzní a že za otestování na zjevné regrese by měl být v první řadě zodpovědný autor patche, ale ať to čtu, jak to čtu, nějak v tom ne a ne vidět to omezování svobody ze strany korporátnického manažera.

[Petr Tomášek]

Nepopírám, že ta myšlenka je kontroverzní a že za otestování na zjevné regrese by měl být v první řadě zodpovědný autor patche, ale ať to čtu, jak to čtu, nějak v tom ne a ne vidět to omezování svobody ze strany korporátnického manažera.

Však to přijde, až přijdou ty tzv. „robust software engineering processes“...

[koudy]

Mě to přijde jako docela samozřejmost, otestovat si program který píšu (v tom se asi se mnou nebude přít nikdo, kromě nadřízených/prodejců :D ) a nebo po někom kód kontroluju. (tady je to závislé případ od případu)

 

Chápu, že patch pro nějaký hack pro síťování s ARM procesorem, si každý doma na své x86 neozkouší.

Na druhou stranu bych čekal, že když už děláte "Reviewed-by:", tak vlastníte železo, na kterém to zkoušíte.

[Michal Kubeček]

Už takhle je mi záhadou, jak někteří maintaineři zvládají ten provoz. Pokud by měli ještě navíc pro každý patch provádět nějakou sadu základních regresních testů (jak navrhuje Dave Chinner), znamenalo by to enormní nárůst práce. Vaše představa, že by měli testovat funkčnost každého patche, je zcela mimo realitu.

[koudy]

Měl jsem na mysli spíš jednou za x dní si sesumírovat všechny patche a otestovat to jako celek.

Možnost, že by se to mělo dělat hned po přietí patche a hned to zkoušet, mi ani nepřišla na mysl. Bylo by to totiž ŠÍLENÝ něco takovýho chtít po vývojářích :)

Na druhou stranu, by jistě šlo velké množství těchto testů zautomatizovat a provádět je například po zkompilování jádra (třeba "make zImage_test" - což by spustilo virtuální PC..., ne dobře to je příliš velké sci-fi, ale asi chápete kam tím mířím)

[David Heidelberg]

Na druhou stranu bych čekal, že když už děláte "Reviewed-by:", tak vlastníte železo, na kterém to zkoušíte.

Reviewed-by nemá s testováním nic společného. Znamená to, že sis kód přečetl a připadá Ti v pořádku. Samozřejmě se předpokládá dostatečná znalost kontextu.

Naproti tomu Tested-by znamená, že nemusíš rozumět kódu, ale že si to ozkoušel a funguje to.