Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 26 May 2025 22:58:38 +0000
From:      Alastair Hogge <agh@riseup.net>
To:        Tomoaki AOKI <junchoon@dec.sakura.ne.jp>
Cc:        Warner Losh <imp@bsdimp.com>, Dennis Clarke <dclarke@blastwave.org>, freebsd-current@freebsd.org
Subject:   Re: With poudriere how does one create a jail of a slightly older RELEASE ?
Message-ID:  <858a28779b1f95124f8b7bf2f11968ac@riseup.net>
In-Reply-To: <20250527011714.7a525ae96279376ab4dad580@dec.sakura.ne.jp>
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> <20250527011714.7a525ae96279376ab4dad580@dec.sakura.ne.jp>

next in thread | previous in thread | raw e-mail | index | archive | help
On 2025-05-27 00:17, Tomoaki AOKI wrote:
> 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.

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?858a28779b1f95124f8b7bf2f11968ac>