Date: Tue, 27 May 2025 01:17:14 +0900 From: Tomoaki AOKI <junchoon@dec.sakura.ne.jp> To: Warner Losh <imp@bsdimp.com>, Dennis Clarke <dclarke@blastwave.org> Cc: freebsd-current@freebsd.org Subject: Re: With poudriere how does one create a jail of a slightly older RELEASE ? Message-ID: <20250527011714.7a525ae96279376ab4dad580@dec.sakura.ne.jp> In-Reply-To: <CANCZdfqQwsBaM8X-VhqZnQ%2BfrfrW%2BpMGKBsgaKR%2BP8UQwCpsgg@mail.gmail.com> References: <F52C672E-DD47-4347-87C3-3D39ADB717AD.ref@yahoo.com> <F52C672E-DD47-4347-87C3-3D39ADB717AD@yahoo.com> <e2fe2e32-ac7c-4185-8c97-47838b62a22b@blastwave.org> <20250526151416.68ff7c09.grembo@freebsd.org> <e0cc3bf8-aaa8-444a-bb9a-64f7bc047d17@blastwave.org> <CANCZdfqQwsBaM8X-VhqZnQ%2BfrfrW%2BpMGKBsgaKR%2BP8UQwCpsgg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 26 May 2025 08:36:05 -0600 Warner Losh <imp@bsdimp.com> wrote: > On Mon, May 26, 2025 at 8:14 AM Dennis Clarke <dclarke@blastwave.org> wrote: > > > > On 5/26/25 09:14, Michael Gmelin wrote: > > > > > > > > > On Mon, 26 May 2025 08:25:50 -0400 > > > Dennis Clarke <dclarke@blastwave.org> 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. If creating github.freebsd.org that its accounts are managed by FreeBSD project and/or FreeBSD foundation, I'll be happy to register. > > 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 -- Tomoaki AOKI <junchoon@dec.sakura.ne.jp>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20250527011714.7a525ae96279376ab4dad580>