From nobody Mon Nov 28 03:12:08 2022 X-Original-To: freebsd-arch@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 4NL9W83WWPz4hkBT for ; Mon, 28 Nov 2022 03:12:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (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 4NL9W70HR8z44tg for ; Mon, 28 Nov 2022 03:12:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=ph5VIsZF; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::632) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-ej1-x632.google.com with SMTP id gu23so4437869ejb.10 for ; Sun, 27 Nov 2022 19:12:18 -0800 (PST) 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=0fjmwPWoEmdXNq5TLT2ppioMkqssQXiQ3js/DXNG3Jk=; b=ph5VIsZFRWEBEwIWDb5qtf9BEdyKyHb5h4dQMolBfpgA55JL5ab57fh9OqjNmsCSiw WOBj9Gq8XLptgjotrh0HJF8IF+vS8g2YWRFWxVFCr+AnHeFs1+vptxFvh1m/9RAR7sM9 C25qBZdH7IiDgfu6XjqrIeWGYwrCVRfcxgBtlgzJB2Tx6YgD/qOVGbxqQ20vA3P8evT5 ozGfvSy7TxIughx55DaeG2rS1vpj7vu2ulHiPJebSvtwkKQN7u5erOeXTGN/oTuNdFwx gJUs622iWEzHTfWoFm6gFYm7mqG9gfVqkY04FzMGasSVx6863sh18uPv3KFCXrf7/Ng1 c6JQ== 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=0fjmwPWoEmdXNq5TLT2ppioMkqssQXiQ3js/DXNG3Jk=; b=SfSA15DJ06D2LZOxc4L7zI0MbnzJIw+PFu7rDO5nUVDDJr5Lkt0wOZ/WtQhdE+cvuX MyNkstBY46JWHK8LyKoSj5ccDb7kdXTxI055L6mrHQhyO6wdWXxGQehxE+zshJcmWEl7 9V+CwMkgg+l/687bYVsixMutd+9btmJhsSfYvZUm7jwZ3uT7wNxIEiTdy2XmLbtDJ5u6 KO8Vzb5UOgZGES2mcfI/PNCQzBRrsUig1Y2O6tU6QVnktE7GXMD5hNPLTrv8zcYnI00F Nq22jS150+3u953smXdeW2DtcLNjUJo3lYX5+Ecd4VqGkE/71im86QpDzZ3wH9iEjZNV k5Jg== X-Gm-Message-State: ANoB5plcvlmUWQcvrFAklt5kZ1ixbcW8nIAW7h75d9/6wYLo5dP7uOSr LhtbHEiTO44Xiol35WHH6gkVWHnCDMZqJWMNLuhsqygaUzo= X-Google-Smtp-Source: AA0mqf6Gp/VYo/k82TKdpK+rVW1Mu7gnoKmklLTv9dH4Uxo3LmcQt+fPL5SP/tRk6f8giMBVHfHXGipggB4IEs2gKMI= X-Received: by 2002:a17:906:684a:b0:7bc:73e6:b2c3 with SMTP id a10-20020a170906684a00b007bc73e6b2c3mr11754277ejs.451.1669605136313; Sun, 27 Nov 2022 19:12:16 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: <202211250923.2AP9NakT073087@gitrepo.freebsd.org> <20221127223531.Horde.3qMyxtWhJEa3tXdg500ge5g@webmail.leidinger.net> In-Reply-To: From: Warner Losh Date: Sun, 27 Nov 2022 20:12:08 -0700 Message-ID: Subject: Re: How much to remove from UPDATING (was: Re: git: ff0c7816db69 - main - Remove UPDATING entries from old branches.) To: Alexander Leidinger Cc: freebsd-arch@freebsd.org Content-Type: multipart/alternative; boundary="00000000000010c4a005ee7f3dbf" X-Spamd-Result: default: False [-2.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.991]; 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-arch@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::632:from]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-Rspamd-Queue-Id: 4NL9W70HR8z44tg X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --00000000000010c4a005ee7f3dbf Content-Type: text/plain; charset="UTF-8" On Sun, Nov 27, 2022 at 7:17 PM Warner Losh wrote: > > > On Sun, Nov 27, 2022 at 2:35 PM Alexander Leidinger > wrote: > >> Quoting Warner Losh (from Fri, 25 Nov 2022 09:41:28 >> -0700): >> >> > Please revert this. We keep older updating entries on purpose. You >> purged >> > way too much. Let's chat about how much to remove in arch@. They are >> for >> > more than just source updates, so your reasoning is wrong. They are also >> > there for users updating their products which can have a larger leap in >> > time. We've traditionally kept closer to 5-10 years here for that >> reason. >> >> Reverted. >> >> UPDATING as far back as stable/10 (= 4 major updates) is a little bit >> excessive (more than 9 years of development work so far), isn't it? >> > > Yes. It's about one release too old, maybe two. More on one or two in a > bit. > > >> I don't get the "more than just src updates" part. If we don't talk >> about the source code, isn't src/UPATING not the wrong place to store >> it? >> > > More than just 'make buildworld updating' or ''updating a system from src' > is what I mean. > > >> In terms of updating products, I understand that updating them every 2 >> years may be a little bit expensive/excessive for some vendors, but >> taking every UPDATING from every stable branch in-between doesn't look >> too much time consuming to me. And compared to the huge amount of >> changes between N-2 and N... taking UPDATING from all stable branches >> in-beteen is nothing. Nevertheless, 4-5 years I consider OK-ish, >> nearly 10 years is ... ugh ... a life-time or two in the computer >> world. If we look e.g. at the PlayStation (yes, just one of the >> products which has FreeBSD inside, but personally I consider it one of >> the more stable ones than some network products which have a shorter >> shelf-time than the PS-line from an OS-version-tracking point of >> view), there are around 6 years in-between models, and they surely >> haven't started developing a month before the release date. >> > > So, let's look at what it's used for to see how much we need. If you > look at it that way, you'll see that we're not crazy lagging. > > >> So where do we draw the line for UPDATING, 2 major versions (~4 >> years), 3 major versions (~6 years)? ~10 years (~5 major versions) >> looks overly excessive to me. That's not something you want to try to >> catch up, that's rather a new development than a catch-up > > > OK. Traditionally we've lagged a major release or two from what's > officially supported by the project. Right now the 10.x stuff is definitely > too old. The 11.x stuff is borderline (but likely relevant), the 12.x stuff > is still quite relevant. > > We need to look at who is updating. Many people have only recently > updated from 11. Almost everybody has updated from 10 by now. Lots > of people are using 12 and it's still supported. > > Most of the folks that have source products with lots of changes have > updated to at least 12 as far as I've been able to tell. But many haven't > jumped to 13 or current yet. > > There are many people still updating their VMs from 11. Traditionally, they > wait until after 11.x goes unsupported before they update. It's only been > unsupported for just over 1 year. In the past, this is where upgrading is > hitting full speed (I've received feedback in the past at conferences that > people often put it off for up to 18 months)... 10.x has been unsupported > for more than 3 years, so historically everybody has moved on. So the > I can't do math.... More than 4 years... > 10.x entries are definitely stale... The 11 entries are on the edge... I'd > normally have removed the 10.x entries when 13 was branched, but > I was asleep at the wheel this time.... Though looking at the logs, I've > been not so great about this. Better at some times, worse at others.... > So in my opinion, 10.x entries should have already been gone. 11.x > entries are likely useful enough to keep, but they are waning fast. 12.x > entries are likely being used all the time by people upgrading from > still-supported > releases. We've traditionally weighted towards retention because the > cost of retention has been super low. > > This suggests we delete up to the 11 branch point now, and to the 12 > branch point when 14 branches in 6 months or so... > 13.x was branched about 6.5 years ago. When 14 is branched, it will be 7 years and we'll removing the to the 12 branch point which will be four and half years. This seems like a good range to oscillate between. Warner --00000000000010c4a005ee7f3dbf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Nov 27, 2022 at 7:17 PM Warne= r Losh <imp@bsdimp.com> wrote:<= br>


On Sun, Nov 27, 2022 at 2:35 PM Alexander Leidinger &= lt;netchild@freeb= sd.org> wrote:
Quoting Warner Losh <imp@bsdimp.com> (from Fri, 25 Nov 2022 09:41:28 -0700):

> Please revert this. We keep older updating entries on purpose. You pur= ged
> way too much. Let's chat about how much to remove in arch@. They a= re for
> more than just source updates, so your reasoning is wrong. They are al= so
> there for users updating their products which can have a larger leap i= n
> time. We've traditionally kept closer to 5-10 years here for that = reason.

Reverted.

UPDATING as far back as stable/10 (=3D 4 major updates) is a little bit=C2= =A0
excessive (more than 9 years of development work so far), isn't it?
=

Yes. It's about one release too old, m= aybe two. More on one or two in a bit.
=C2=A0
I don't get the "more than just src updates" part. If we don&= #39;t talk=C2=A0
about the source code, isn't src/UPATING not the wrong place to store= =C2=A0
it?

More than just 'make buildworld= updating' or ''updating a system from src'
is wh= at I mean.
=C2=A0
In terms of updating products, I understand that updating them every 2=C2= =A0
years may be a little bit expensive/excessive for some vendors, but=C2=A0 <= br> taking every UPDATING from every stable branch in-between doesn't look= =C2=A0
too much time consuming to me. And compared to the huge amount of=C2=A0 changes between N-2 and N... taking UPDATING from all stable branches=C2=A0=
in-beteen is nothing. Nevertheless, 4-5 years I consider OK-ish,=C2=A0
nearly 10 years is ... ugh ... a life-time or two in the computer=C2=A0 world. If we look e.g. at the PlayStation (yes, just one of the=C2=A0
products which has FreeBSD inside, but personally I consider it one of=C2= =A0
the more stable ones than some network products which have a shorter=C2=A0 =
shelf-time than the PS-line from an OS-version-tracking point of=C2=A0
view), there are around 6 years in-between models, and they surely=C2=A0 haven't started developing a month before the release date.

So, let's look at what it's used for to se= e how much we need. If you
look at it that way, you'll see th= at we're not crazy lagging.
=C2=A0
So where do we draw the line for UPDATING, 2 major versions (~4=C2=A0
years), 3 major versions (~6 years)? ~10 years (~5 major versions)=C2=A0 looks overly excessive to me. That's not something you want to try to= =C2=A0
catch up, that's rather a new development than a catch-up
<= div>
OK. Traditionally we've lagged a major release or tw= o from what's
officially supported by the project. Right now = the 10.x stuff is definitely
too old. The 11.x stuff is borderlin= e (but likely relevant), the 12.x stuff
is still quite relevant.<= br>

We need to look at who is updating. Many peopl= e have only recently
updated from 11. Almost everybody has update= d from 10 by now. Lots
of people are using 12 and it's still = supported.

Most of the folks that have source prod= ucts with lots of changes have
updated to at least 12 as far as I= 've been able to tell. But many haven't
jumped to 13 or c= urrent yet.

There are many people still updating t= heir VMs from 11. Traditionally, they
wait until after 11.x goes = unsupported before they update. It's only been
unsupported fo= r just over 1 year. In the past, this is where upgrading is
hitti= ng full speed (I've received feedback in the past at conferences that
people often put it off for up to 18 months)... 10.x has been unsu= pported
for more than 3 years, so historically everybody has move= d on. So the

I can't = do math.... More than 4 years...
=C2=A0
<= div>10.x entries are definitely stale... The 11 entries are on the edge...= =C2=A0 I'd
normally have removed the 10.x entries when 13 was= branched, but
I was asleep at the wheel this time.... Though loo= king at the logs, I've
been not so great about this. Better a= t some times, worse at others....

So in my opinion, 10.x entries should have alre= ady been gone. 11.x
entries are likely useful enough to keep, but= they are waning fast. 12.x
entries are likely being used all the= time by people upgrading from still-supported
releases. We'v= e traditionally weighted towards retention because the
cost of re= tention has been super low.

This suggests we delet= e up to the 11 branch point now, and to the 12
branch point when = 14 branches in 6 months or=C2=A0so...
13.x was branched about 6.5 years ago. When 14 is branched, it= will be
7 years and we'll removing the to the 12 branch poin= t which will be
four and half years. This seems like a good range= to oscillate between.

Warner
--00000000000010c4a005ee7f3dbf--