Date: Fri, 4 Nov 2022 23:14:57 +0100 (CET) From: iio7@tutanota.com To: Freebsd Hackers <freebsd-hackers@freebsd.org> Subject: Re: What is the status of the FreeBSD development process now? Message-ID: <NG3hX4e--3-9@tutanota.com> In-Reply-To: <CANCZdfoS0=FRL_BXfUaauEs5AM8CPNhwe0wSM8FjXjaBDH%2BWzA@mail.gmail.com> References: <NG-5mKi--3-9@tutanota.com> <CACcTwYnDD86etzZhsW64t9fGnL%2Br2BXwZ=RDXGiJ7RP54mWfmw@mail.gmail.com> <NG-G41y--3-9@tutanota.com> <CANCZdfquUTHsCUwBttwCvzHO4Ght0-sNHrONmrse4Ug-Z-CZ5g@mail.gmail.com> <NG-HjAl--3-9@tutanota.com> <CANCZdfoS0=FRL_BXfUaauEs5AM8CPNhwe0wSM8FjXjaBDH%2BWzA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Nov 4, 2022, 01:59 by imp@bsdimp.com: >> I guess my expectations were too high. Sure, things has improved, but wi= thout >> a clear set of rules - like ALL commits must be reviewed before going i= nto 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 re= views 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 rig= ht away. > > Again, these things are present in the data.=C2=A0 There are way more tes= ts 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 s= ome simplistic rule change is at best overly simplistic think and disingenu= ous trolling at worst. > It's great that things have improved, but without a clear set of rules, suc= h 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 "l= ow", 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 su= ch rules, all guaranties are out the window. All it takes is that when someone has made a commit, someone else has to lo= ok it through, provide an "OK", and then it can get into current, without the "OK", it sta= ys 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 cond= ition. Cheers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?NG3hX4e--3-9>