Re: What is the status of the FreeBSD development process now?

From: <iio7_at_tutanota.com>
Date: Fri, 04 Nov 2022 22:14:57 UTC
Nov 4, 2022, 01:59 by imp@bsdimp.com:

>> I guess my expectations were too high. Sure, things has improved, but without
>>  a clear set of rules - like ALL commits must be reviewed before going into the
>>  kernel, base, etc. - the same problem can happen again.
>>
>
> Now I know you are trolling...
>
> Nobody that's has done engineering for any length of time would expect reviews to catch all problems. That's at best wishful thinking and at worst a horribly toxic management culture.
>
You're putting words in my mouth. I never said that reviews would catch all problems, what
 I am saying is that we *need* to learn from past mistakes by having fixed rules.

> What has happened is that there is more review, the commits are generally much much smaller and more people are reading the commits after the fact. I half jokingly told a coworker recently the fastest way to find a problem in my code is to commit it since so many people read it, I get feedback right away.
>
> Again, these things are present in the data.  There are way more tests than being committed than before. There is more CI coverage than before. There are efforts to greatly expand that. The layered approach gies a long way towards catching issues like this than before. Thinking promulgating some simplistic rule change is at best overly simplistic think and disingenuous trolling at worst.
>
It's great that things have improved, but without a clear set of rules, such that nothing
gets into the current branch from a committer that hasn't been reviewed by at least
another developer, the problem will just repeat itself. All we need is a "low", people feeling
off, life happening, etc., and reviewing gets slacked.

I would rather say, anyone who has done engineering for any length of time knows that without
clear rules and guidelines and some kind of "safety" system to implement such rules, all guaranties
are out the window.

All it takes is that when someone has made a commit, someone else has to look it through,
provide an "OK", and then it can get into current, without the "OK", it stays out of current.

This is not a guarantee, but at least something like the wireguard problem, would most likely
be prevented in the future.

Since things have improved, it shouldn't be too difficult to make it a condition.

Cheers.