From nobody Mon May 26 22:58:38 2025 X-Original-To: freebsd-current@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 4b5rm24nRVz5wxC0 for ; Mon, 26 May 2025 22:58:42 +0000 (UTC) (envelope-from agh@riseup.net) Received: from mx0.riseup.net (mx0.riseup.net [198.252.153.6]) (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 "mx0.riseup.net", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b5rm16dMlz3JqQ for ; Mon, 26 May 2025 22:58:41 +0000 (UTC) (envelope-from agh@riseup.net) Authentication-Results: mx1.freebsd.org; none Received: from fews02-sea.riseup.net (fews02-sea-pn.riseup.net [10.0.1.112]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx0.riseup.net (Postfix) with ESMTPS id 4b5rlz5wfgz9vXZ; Mon, 26 May 2025 22:58:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1748300320; bh=V9Oohaby+Lo/TaQj7H4+C+n7WqICUbdB9oHBqGcWZ7E=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=bHgrl2Xehx35DmoI8uMUuQJzyz8z4P9semOaXdOvY31Y4ZqaQLC7ewIoF9AnNNQFE BgcVS6sXozH4nTQhLeY9lecP3eNhd0WxzoOhDEgyxcO5bPb7NIGOnzv5jZdN5m+/AH IY316fa4loK2GVEHpEGoSBIrIJI0oUypBQbr8gyI= X-Riseup-User-ID: 9DB8A387D96BD9433D42D02AB28599DEF95630FBF58ACBB6A1DD56CC7C1B824F Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews02-sea.riseup.net (Postfix) with ESMTPSA id 4b5rlz2yGtzFv8s; Mon, 26 May 2025 22:58:39 +0000 (UTC) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Date: Mon, 26 May 2025 22:58:38 +0000 From: Alastair Hogge To: Tomoaki AOKI Cc: Warner Losh , Dennis Clarke , freebsd-current@freebsd.org Subject: Re: With poudriere how does one create a jail of a slightly older RELEASE ? In-Reply-To: <20250527011714.7a525ae96279376ab4dad580@dec.sakura.ne.jp> References: <20250526151416.68ff7c09.grembo@freebsd.org> <20250527011714.7a525ae96279376ab4dad580@dec.sakura.ne.jp> Message-ID: <858a28779b1f95124f8b7bf2f11968ac@riseup.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4b5rm16dMlz3JqQ X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16652, ipnet:198.252.153.0/24, country:US] X-Spamd-Bar: ---- On 2025-05-27 00:17, Tomoaki AOKI wrote: > On Mon, 26 May 2025 08:36:05 -0600 > Warner Losh wrote: > >> On Mon, May 26, 2025 at 8:14 AM Dennis Clarke wrote: >> > >> > On 5/26/25 09:14, Michael Gmelin wrote: >> > > >> > > >> > > On Mon, 26 May 2025 08:25:50 -0400 >> > > Dennis Clarke wrote: >> > > >> > >> > >> I have no idea what "MFC" is supposed to mean. >> > >> I guess it is a code change that happened somewhere. >> > >> >> > > >> > > Merge From Current = Merging or back-porting a base commit from CURRENT >> > > (main/base/HEAD) to another, usually lower, FreeBSD version branch. >> > > >> > > https://wiki.freebsd.org/Glossary#MFC_--_Merge_From_Current >> > > >> > > -m >> > > >> > >> > So many places with special terms and stuff buried somewhere. In the >> > last week or so I have discovered https://archive.freebsd.org/ and now >> > there is https://wiki.freebsd.org/ which I have not ever seen once in >> > five or six years of trying to use FreeBSD. Maybe a link or something >> > can be put on the "About" page? https://www.freebsd.org/about/ >> >> Yes. We have our own Jargon that has evolved over the years. Many >> of the terms are used so frequently we forget that people new to the >> project might not understand them. > > Something like MFC but a different term, MFS (Merge From Stable) is > used, too. Means mostly like MFC, but from stable branch like stable/14 > to release engineering (releng) branch like releng/14.2. > In most cases, the changes are the same as MFC, so the term MFC is used. > But MFC to stable branch made some modifications, term MFS should be > used instead to clarify the fact (not always, unfortunately). > > >> > Even more crazy is the way in which FreeBSD is changed and/or fixed. >> > There are bug reports of course but it seems everything really happens >> > in a thing called a Phabricator. >> >> Well, it's even more complicated than that... We have Bugzilla to get bug >> reports, which sometimes have patches. Historically, these patches have been >> neglected, in no small part because many of our developers have a hard >> time saying 'no' especially to something that's ambiguously incorrect or >> that touches a complicated-to-fix area of the tree. Next up is Phabricator, >> which developers use to review changes, but sometimes non-developers >> use it, but we have had a hard time managing that process, so changes often >> get lost. Third, we have github pull requests now that I've been trying to >> establish as a better-managed place to go to contribute. > > Bugzilla would be best for non-developers, as it does not require > patch to file bugs. The downside I see is that there's no assistances > for commenting specific part of the patch (if exist) that is uncertain > or need fix. For example, Bug 286705. > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286705 > > Phablicator is the opposite. It (AFAIK) requires codes (patches|diffs) > to review on reporting. But reviewers and/or aubscribers can comment > directly to specific part of codes/diffs, allowing precise discussions > about proposed changes/additions. > > For example, I basically use Bugzilla when I don't have patch > to review (or having patch to upgrade like Bug 287021). > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=287021 > > Once I can create patch, I recently open a review for it > like Differentioal revision D50487. > > https://reviews.freebsd.org/D50487 > > And if the patch is intended NOT to affect users (infrastructial > changes only), I simply open review without filing Bug to Bugzilla > like D50142. > > https://reviews.freebsd.org/D50142 > > And an example of a review with comments to the patch itself. > > https://reviews.freebsd.org/D49982 > > > Currently GitHub pull request is no-go for me, as its accounts are NOT > managed neither by FreeBSD project and/or FreeBSD foundation. GitHub is another Walled Garden. You need an account to read code on it's platform, and they are terrible at providing access to new subscribers. I am on my second account, and none of my up upstream Issues are appearing. A migration to Github will be a direct attack on those who take a principled position against surveillance platforms, and corporate mono-cultures. > If creating github.freebsd.org that its accounts are managed by > FreeBSD project and/or FreeBSD foundation, I'll be happy to register. The great thing about Bugzilla, and Phabricator, one does not need to grasp the git branching dance, and can instead produce git-formatted-patches from a git worktree for submission. This is a lot closer to patches via email, a wonderful process that is losing favor these days. >> > It really is a great UNIX implementation and runs like a charm as a >> > server but the skills required are all over the place and no where and >> > everywhere and yeah ... thanks to this mail list I can at least keep a >> > few things running. To quote a really cool guy that is an expert at such >> > things "If it breaks you can keep both pieces." >> >> We also do try to document everything in the FreeBSD handbook, but >> sometimes it's a bit out of date because there's been lots of change and >> innovation over the years. >> >> Warner