From nobody Fri Nov 4 22:14:57 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N3w0j70f4z4gtvx for ; Fri, 4 Nov 2022 22:15:01 +0000 (UTC) (envelope-from iio7@tutanota.com) Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.tutanota.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N3w0h53Gnz3vcq for ; Fri, 4 Nov 2022 22:15:00 +0000 (UTC) (envelope-from iio7@tutanota.com) Received: from tutadb.w10.tutanota.de (unknown [192.168.1.10]) by w1.tutanota.de (Postfix) with ESMTP id D1F89FBF8DA for ; Fri, 4 Nov 2022 22:14:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1667600097; s=s1; d=tutanota.com; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Content-Transfer-Encoding:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender; bh=pVBd5Dqp9kT4Wk8oY8SYebcFfq7XrL5jBYP1YzUThkI=; b=YFLTPNxg7ROBt0sagBRNkrO4Oj4tRTkZYdhajnTXxv15A3k7BAMBvvGtyW7jjY3W pJEiXeiSqnmOWcnUxbjG7alYEprUFDQxkyim/nZ8QfJqcueMlOoL7uzihyuKTzqzEbC PldjmAn9D9AYPytdYMXho/mESwirEGttA2aY9ZptszXYtj0zPEtb43mB3Idi2jQh1k/ IUEfzkmkzM8SVA05+oECaFmjLTVbaL6KMRbxVXOJqNaYZvjWQJPDO+LAmniP1zkwwFz 42GL9I6HyMnjoixn4rY+3CKZFYlcD/3F7QMYHgPwkqXHvXfvMJcgH9AZPv/Z1betVc+ KiDiWVjvKw== Date: Fri, 4 Nov 2022 23:14:57 +0100 (CET) From: iio7@tutanota.com To: Freebsd Hackers Message-ID: In-Reply-To: References: Subject: Re: What is the status of the FreeBSD development process now? List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4N3w0h53Gnz3vcq X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tutanota.com header.s=s1 header.b=YFLTPNxg; dmarc=pass (policy=quarantine) header.from=tutanota.com; spf=pass (mx1.freebsd.org: domain of iio7@tutanota.com designates 81.3.6.162 as permitted sender) smtp.mailfrom=iio7@tutanota.com X-Spamd-Result: default: False [-3.00 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[tutanota.com,quarantine]; R_SPF_ALLOW(-0.20)[+ip4:81.3.6.160/28]; R_DKIM_ALLOW(-0.20)[tutanota.com:s=s1]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:24679, ipnet:81.3.0.0/18, country:DE]; MIME_TRACE(0.00)[0:+]; FROM_NO_DN(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[tutanota.com:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 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.