From nobody Fri Nov 4 01:59:45 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 4N3P2l15jFz4gcHB for ; Fri, 4 Nov 2022 01:59:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N3P2k1jWMz3vHg for ; Fri, 4 Nov 2022 01:59:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ej1-x636.google.com with SMTP id t25so9832802ejb.8 for ; Thu, 03 Nov 2022 18:59:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=7UPe7N2bnJ4yG4C0ZeYJJZcoK9zGfrvJdbJUskZwH4M=; b=66uV8vdcOqs72po1OUnFeJmidTzMmNOimYfn1GHSaOUxao4BFW4GuEAPIP3Pt0n3yD 49RN5vwnbY3S0/UflDbHxsLo/u9k8/069FTZ64SoflVsc0iT4IMCCXZm7GgY8w8/7Dww B+D7Zs6Km6MnL1bfsicTuzblf3ZIPos4p1U13UUtmLC2G5PD4Q4cZnnJSJvjCMdJNACv rCkrPhQ9TZQFOpLlQL74xsLjyXf8aoTThiOEuKicQfzIfYiY7t2cvyfevWRoZkyKH3Km BS3dnWHua7YugSSRCwJhbCWXhCMWYB+A7f4IpomoF19XP00dvxLqUvNuJUEcKzSLkV9Y ETkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7UPe7N2bnJ4yG4C0ZeYJJZcoK9zGfrvJdbJUskZwH4M=; b=TsO0UaFlY70IGJ5pAJ3ujdvVxG5j37KvSZ8WEo9ajiGprOZ7ROHoMt48kx1Nv5fT/g GIO/bJNfK5kM/RqKKDthKhE0ekE3/evdtj0ImZSMJngWMk3bGJqKeVqidbLO3NPstlJJ Zmv0qxSGDnqjvAIvkrfntsCwiK+OaLVGYzE/Ih9dBwIEGi8QBoTym5JUQvuNfuejZ6ea 7pq4eRXAQUVxi9IoWq617bso8lHn7Hy10d4To26vpvnbVQy8Q3jq38WqPbGEsFMHhs74 YhSaDTDct91lwk68qdmamW/216TLbQN7lTCcMJKS1cWueiuNWzmdbWNI7oWPeYQYYDVy hALg== X-Gm-Message-State: ACrzQf1iJMAMNiWPCSHClfGDAYoH6J8C+dS705eZ8TurGhypvjOiAnbz TsMI5MjX2hFDg/A0LtztFZdMtJyayifd1UHEVVCpUqNfFNQ= X-Google-Smtp-Source: AMsMyM7Vt43QCQ9t1ASTGBQJPRpwMKSgdLAkfqwar7QDA5L4S6W8TOnXwyKK/YUpe4kNw08Rrauhwly0wewNHl449CQ= X-Received: by 2002:a17:907:d02:b0:7a3:de36:b67 with SMTP id gn2-20020a1709070d0200b007a3de360b67mr31384191ejc.451.1667527196899; Thu, 03 Nov 2022 18:59:56 -0700 (PDT) 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 References: In-Reply-To: From: Warner Losh Date: Thu, 3 Nov 2022 19:59:45 -0600 Message-ID: Subject: Re: What is the status of the FreeBSD development process now? To: iio7@tutanota.com Cc: Freebsd Hackers Content-Type: multipart/alternative; boundary="00000000000039915d05ec9b6e98" X-Rspamd-Queue-Id: 4N3P2k1jWMz3vHg X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=66uV8vdc; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::636) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.00 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::636:from]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --00000000000039915d05ec9b6e98 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 3, 2022, 7:39 PM wrote: > Nov 4, 2022, 01:34 by imp@bsdimp.com: > > > According to my data, reviews are up significantly since that email. > > > > I'm guessing you haven't been able to confirm anything has changed > because > > you've not actually looked for data, since it's trivially easy to find > that data. > > > No, I have looked. I never said that I didn't find anything. However, what > I was > suspecting to find was a set of rules put in place to prevent anything > like the > wireguard issue from happening again. > Your expectations are off. You need to look at the data. 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. 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. Warner Kind regards. > > > > > --00000000000039915d05ec9b6e98 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Nov 3, 2022, 7:39 PM <iio7@tutanota.com> wrote:
Nov 4, 2022, 01:34 by imp@bsdimp.com:

> According to my data, reviews are up significantly=C2=A0since that ema= il.
>
> I'm guessing you haven't been able to confirm anything has cha= nged because
> you've not actually looked for data, since it's trivially easy= to find that data.
>
No, I have looked. I never said that I didn't find anything. However, w= hat I was
suspecting to find was a set of rules put in place to prevent anything like= the
wireguard issue from happening again.

Your expectations are off. You need t= o look at the data.

I guess my expectations were too high. Sure, things has improved, but witho= ut
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 t= rolling...

Nobody that&#= 39;s has done engineering for any length of time would expect reviews to ca= tch all problems. That's at best wishful thinking and at worst a horrib= ly toxic management culture.

What has happened is that there is more review, the commits are genera= lly much much smaller and more people are reading the commits after the fac= t. I half jokingly told a coworker recently the fastest way to find a probl= em 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.=C2=A0 There are way more tests than being = committed than before. There is more CI coverage than before. There are eff= orts to greatly expand that. The layered approach gies a long way towards c= atching issues like this than before. Thinking promulgating some simplistic= rule change is at best overly simplistic think and disingenuous trolling a= t worst.

Warner

Kind regards.




--00000000000039915d05ec9b6e98--