From nobody Fri Nov 04 01:32: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 4N3NRb0DYvz4hJ2S for ; Fri, 4 Nov 2022 01:32:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 4N3NRZ1K6Wz3qbw for ; Fri, 4 Nov 2022 01:32:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ed1-x533.google.com with SMTP id v17so5614635edc.8 for ; Thu, 03 Nov 2022 18:32: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=SUfPh3kpGcQskDO7pXRAJb6VAlZcz9YXD3FiPwmeta0=; b=7T3Ig4zcA1fenWHwrqVqqq8Hs6rIPxrsICzOUxChYdCRBxYGgx07VgEP5H694cyCII nAOAjISiG+M6xsJ1jo12YMLDsa5CQ9wiSuVEfXBEzy57bBJW9Ts0MQqtVzcv0TM8c780 Cm6yOQ+QkFdagOZCiF++xlcm65RDdoQeuiiHtKhLrdAwUmY1LRE5Dbf1giDC0GaXsInV KrTeg76MLPjz1sfkCWda5LE/DYj5TU8CqayPjhcMb6FfO1dQNG3UgJSyeKwIFNF+cE4W 0kcM6piIF75vNGhLmtWunOEIUuLHnEKPArgXQoQgWFsSjFHVkxV2Wo6jiRfF1kmodsFp S+qA== 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=SUfPh3kpGcQskDO7pXRAJb6VAlZcz9YXD3FiPwmeta0=; b=XLfKbn4swPL+muXuezpX3pRhuSWUBLOfBpJj2LSZnvSG+Y1uzjpWBJY9GHSLEZYfo1 82w0ZN/1YH5JOzse2UL+f6HwTICmx2ePtuRWCYZ96ueKL0i3vH89wmQTj+VUp3gOfFj3 YOhnQNWl2XklCDDNCy5R7jyi8QaJsSSGTn5HeKUrzmTMUskVT1+D8L7kHY7wwWEBbxaR vV3SrYkKkINZH9Lhmz3pHRzmWIzY5PalMxNlfb94dZfLUnf/Ih/lONgl9IauQqLsrQjb +lPp0PmnY34CaNOZUrmLurplgpDcXXKpYmv9FIe7idalOfftVaXui/RpLUTwLyYVMFzP WSIw== X-Gm-Message-State: ACrzQf02ZcssQoTjgeyIV6iLm47BNjoty3gE56wvCxQS6YahLFP8wKFa VN3qliXcGqfXUB4exOwAch4fnJTDHHVTEaqfirWdlA== X-Google-Smtp-Source: AMsMyM5y3CYBIGE4aHdOQngaC9/VqF57HrPVVEoRc82EfQg1P8OHcQs3+Zu+WgpYZLKbgB4mPZu2W0XrpZ+FvwJ1fcU= X-Received: by 2002:a05:6402:5c9:b0:446:fb0:56bb with SMTP id n9-20020a05640205c900b004460fb056bbmr33884550edx.173.1667525576666; Thu, 03 Nov 2022 18:32: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:32: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="000000000000a6c6ae05ec9b0da1" X-Rspamd-Queue-Id: 4N3NRZ1K6Wz3qbw X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=7T3Ig4zc; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::533) 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::533: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 --000000000000a6c6ae05ec9b0da1 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 3, 2022 at 6:47 PM wrote: > >> In OpenBSD, AFAIK, absolutely no code goes into the project without > >> at least 1 other people reviewing it and approving it. This can be > >> seen with the "OK" in the commits. > > > This has been shown to be false: > > > > > https://lists.freebsd.org/archives/freebsd-questions/2022-November/002192.html > > I have just replied to that. It's wrong. Take a look at the > OpenBSD commit logs. > Many, but not all, have the OK tag. My quick grep over the last 1000 commits I have in my tree suggests about 50%: % git log -1000 | grep -i ok | wc 524 2048 13689 which is the 1000 commits ending around May 1, 2022 this year (the last time I pulled an OpenBSD tree on the machine I have handy). > We're not talking about ports, the issue is related to the kernel and > base, etc. > Many, but not all, FreeBSD commits have a reviewer these days, and the main exceptions are trivial spelling errors, build botches and other similar things. A quick grep suggests of FreeBSD suggests similar numbers: % git log -1000 | grep 'Review' | wc 555 2163 22658 vs % git log -1000 HEAD~20000 | grep 'Review' | wc 319 1220 10577 which is in the time period a few months before the email in your original email. For both OpenBSD and FreeBSD this undercounts the number of commits that had a review that wasn't documented, or used a non-standard form to document, or (in FreeBSD) submitted by was reviewed by the committer, but no 'Reviewed by' was added to the commit because it was believed to be implicit (it is, but that's hard to grep). So it appears that the numbers are currently about the same and that different methods may give slightly different results because of the inconsistent marking of the tree. Because marking is inconsistent, and some actually reviewed changes go undocumented, it is really hard to say that one project is better than the others. Warner --000000000000a6c6ae05ec9b0da1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Nov 3, 2022 at 6:47 PM <iio7@tutanota.com> wrote:
>> In OpenBSD, AF= AIK, absolutely no code goes into the project without
>> at least 1 other people reviewing it and approving it. This can be=
>> seen with the "OK" in the commits.

> This has been shown to be false:
>
> https://lists.fre= ebsd.org/archives/freebsd-questions/2022-November/002192.html

I have just replied to that. It's wrong. Take a look at the
OpenBSD commit logs.

Many, but not all,= have the OK tag. My quick grep over the last 1000
commits I have= in my tree suggests about 50%:
% git log -1000 | grep -i ok | wc=
=C2=A0 =C2=A0 =C2=A0524 =C2=A0 =C2=A02048 =C2=A0 13689
wh= ich is the 1000 commits ending around May 1, 2022 this year (the
= last time I pulled an OpenBSD tree on the machine I have handy).
= =C2=A0
We're= not talking about ports, the issue is related to the kernel and
base, etc.

Many, but not all, FreeBSD c= ommits have a reviewer these days, and
the main exceptions are tr= ivial spelling errors, build botches and other
similar things.

A quick grep suggests of FreeBSD suggests similar nu= mbers:

% git log -1000 | grep 'Review' | w= c
=C2=A0 =C2=A0 =C2=A0555 =C2=A0 =C2=A02163 =C2=A0 22658
v= s
%=C2=A0 git log -1000 HEAD~20000 | grep 'Review' | wc
=C2=A0 =C2=A0 =C2=A0319 =C2=A0 =C2=A01220 =C2=A0 10577

which i= s in the time period a few months before the email in your original
email.

<= div class=3D"gmail_quote">For both OpenBSD and FreeBSD this undercounts the= number of commits
that had a review that w= asn't documented, or used a non-standard form
to document, or (in FreeBSD) submitted by was reviewed by the commit= ter,
but no 'Reviewed by' was added= to the commit because it was believed to
b= e implicit (it is, but that's hard to grep).

So it appears that the numbers a= re currently about the same and that different
methods may give slightly different results because of the inconsistent= marking
of the tree. Because marking is in= consistent, and some actually reviewed changes
go undocumented, it is really hard to say that one project is better th= an the others.

Warner
--000000000000a6c6ae05ec9b0da1--