Re: With poudriere how does one create a jail of a slightly older RELEASE ?

From: Rick Macklem <rick.macklem_at_gmail.com>
Date: Tue, 27 May 2025 00:43:43 UTC
On Mon, May 26, 2025 at 7:36 AM 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.
>
> > 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.
I will mention that you forgot the mailing lists. If you post something to
freebsd-current@ most of the developers see it.

Bugzilla is ok for reporting bugs, but not so good when it comes to having
a discussion about it. Same goes for phabricator.

And, yes, I am not a fan of github, but do suffer through it for things
like OpenZFS and Linux kernel patches.

But I'm old school (and old;-), rick

>
> > 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
>