Fejlesztési folyamatait érintő állásfoglalást adott ki a FreeBSD projekt

FreeBSD

A Wireguard balhé oly mértékben eszkalálódott, hogy a FreeBSD Core Team jónak látta nyilvánosan megerősíteni, hogy milyen irányelveket követ, illetve fog követni a jövőben a FreeBSD projekt a kódminőség kapcsán:

Code quality is an essential FreeBSD value [...] The recent concerns regarding the WireGuard patches remind us that our development processes must always continue to mature. [...] We were excited to provide a kernel WireGuard implementation in FreeBSD 13.0. Before the if_wg(4) rewrite was committed, several FreeBSD developers proactively worked on fixing bugs and writing tests and documentation for the original implementation. In other words, we had spent time during the release's Q/A period looking for problems, and that unfortunately culminated in if_wg(4) being removed from 13.0 during the release cycle. [...] Over the next month the FreeBSD Core Team will lead a discussion on appropriate pre-commit testing, static analysis, code review, and integration policies to avoid a repeat of this situation and to continue improving FreeBSD's code quality.

Részletek itt. 

( Huncraft v | 2021. 03. 31., sze – 12:38 )

Kicsit jobban örültem volna, ha a tényleges balhéról is lett volna cikk (tudom, nem küldött be senki ilyet, írjam meg én, stb..), mert végigolvasva az Ars Technica cikkét, számos dolog van amiből tényleg lehet tanulni (köztük nem 1 olyan amire eddig azt hittem, hogy csak kis cégek követik el, mert a nagyobbak már rég megtanulták, hogy ilyen hibát nem vétünk). 
Szóval így utólag csak bátorítani tudok mindenkit, hogy olvassa el a forrás anyagot is: https://arstechnica.com/gadgets/2021/03/buffer-overruns-license-violati… 

Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Kicsit jobban örültem volna, ha a tényleges balhéról is lett volna a kommentedben (tudom írjam meg én, stb..), mert végigolvasva az Ars Technica cikkét, számos dolog van amiből tényleg lehet tanulni (köztük nem 1 olyan amire eddig azt hittem, hogy csak kis cégek követik el, mert a nagyobbak már rég megtanulták, hogy ilyen hibát nem vétünk). 
Szóval így utólag csak bátorítani tudok mindenkit, hogy olvassa el a forrás anyagot is: https://arstechnica.com/gadgets/2021/03/buffer-overruns-license-violati… 

trey @ gépház

Kicsit jobban örültem volna, ha a tényleges balhéról is lett volna a kommentedben

Már mint lett volna mi? Szó? Értekezés? ${RANDOM IGE}? Értem én amúgy, hogy trollkodási szándékkal létrehozott copy-paste comment, de legalább tartalmilag legyen értelme már..

Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Én most pont a BSD-s oldalra utaltam inkább.

- Direktben HEAD-re merge-elni kódot (egyáltalán hogy volt erre joga? )
- code review megkövetelésének hiánya (minimum egy +2 valakitől aki még az adott területen illetékes)
- Test case-ek hiánya (és itt még a code coverage-be bele se megyek, bár egy normálisabb code checker a return true jellegű függvényeket nyomban meg kéne fogja)

Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Bocs, félreérthető voltam..

Macy committed his port—largely unreviewed and inadequately tested—directly into the HEAD section of FreeBSD's code repository, where it was scheduled for incorporation into FreeBSD 13.0-RELEASE.

Nálam ez azt jelenti, hogy git push origin HEAD:refs/heads/main-re tolta (vagy releng/13.0 release branchre), ahelyett hogy saját dev branchet használt volna (amit aztán utólag (rebase-elnek és) merge-elnek a main / release branchre).
Amúgy nem tudom, hogy core fejlesztők esetén mi a szokás FreeBSD projectben, de külsős munka esetén még lehet az is opció lett volna, hogy pull requestként kerüljön be a commit..
 

Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

egy developer miert ne mergelhetne kodot? anno en is kozvelten commitoltam a NetBSD kernelbe ;-)

szerk: ja, nem valtozott sokat azota se:

Several FreeBSD community members would only speak off the record. In essence, most seem to agree, you either have a commit bit (enabling you to commit code to FreeBSD's repositories) or you don't. It's hard to find code reviews, and there generally isn't a fixed process ensuring that vitally important code gets reviewed prior to inclusion. This system thus relies heavily on the ability and collegiality of individual code creators.

Ha ez tényleg igaz, akkor csak idézni tudom magamat:

amire eddig azt hittem, hogy csak kis cégek követik el, mert a nagyobbak már rég megtanulták, hogy ilyen hibát nem vétünk

Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

( NagyZ v | 2021. 04. 02., p – 14:24 )

Macy's history as a landlord, unsurprisingly, dogged him professionally—which contributed to his own lack of attention to the doomed WireGuard port.

"I didn't even want to do this work," Macy eventually told us. "I was burned out, spent many months with post-COVID syndrome... I'd suffered through years of verbal abuse from non-doers and semi-non-doers in the project whose one big one up on me is that they aren't felons. I jumped at the opportunity to leave the project in December... I just felt a moral obligation to get [the WireGuard port] over the finish line. So you'll have to forgive me if my final efforts were a bit half-hearted."

de a penz azert jo volt, h csinalja meg, csak aztan fos lett, es hat akkor szarunk bele, ugye?

hogy en mennyire ilyen nyomi fejlesztot latok, elkepeszto

The first step was assessing the current state of the code the previous
developer had dumped into the tree. It was not pretty. I imagined
strange Internet voices jeering, “this is what gives C a bad name!”
There were random sleeps added to “fix” race conditions, validation
functions that just returned true, catastrophic cryptographic
vulnerabilities, whole parts of the protocol unimplemented, kernel
panics, security bypasses, overflows, random printf statements deep in
crypto code, the most spectacular buffer overflows, and the whole litany
of awful things that go wrong when people aren’t careful when they write
C.

ahahahah