Re: With poudriere how does one create a jail of a slightly older RELEASE ?
- In reply to: Warner Losh : "Re: With poudriere how does one create a jail of a slightly older RELEASE ?"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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 >