Please create a -current forum

… because of freebsd-update, and not other reasons. …

Thanks. This is surely a key point.

In the absence of a usable freebsd-update: things become significantly more complex.

Significantly more complex for users of:
  • STABLE
– users gain advice, the advice is rarely alarmist, the learning and debates are not detrimental to use of RELEASE.

Significantly more complex for users of STABLE, and where a problem is insurmountable: most people will have a perspective that's rational.
 
I'd recommend for new users to use a supported production release, and not STABLE, only because of freebsd-update, and not for other reasons.
Huh! I use almost exclusively -RELEASE versions, but never used freebsd-update(8). Only building from source, I can have a base system tailored to my needs. Of course, this would change once pkg-base gets somewhere, but right now, building from source is the only way.

Patch-level releases don't change too much; using meta-mode, the builds will be really quick.

IMHO, the one reason to use -RELEASE is, well, it goes through release engineering and is supported, giving you something solid and stable.
 
Just to make it clear: If you're serious about maintaining and testing a port, you need -CURRENT.
I don’t think this is a requirement. A newer kernel supports older userland. Even for ports explicitly marked for -current, a better place would be a relevant mailing list, to reach developers.

A sub forum for -current if any should have a pinned message that provides some guidance on what to do if you want to run -current and point out the dangers of running it but that is about it!
 
bakul, it is a requirement. Every port must build and work on -CURRENT. As a maintainer, it might be fine not to test it yourself, but at least the committer has to do it. If you want to do good work as a maintainer, you test everything upfront, and you need -CURRENT for that.
 
Actually I would say the requirement is in the *opposite* direction in that -current must not not break ports but I grant your point in that the only way to know is to build try build ports on -current. Even so, I would think -ports and -current mailing lists are a better place to talk about any broken ports.
 
the requirement is in the *opposite* direction in that -current must not not break ports
Nope. It's the ports' responsibility to stay compatible with -CURRENT as well, not the other way around.

It's not expected from every maintainer to make sure it works, but it is expected from every committer. As a maintainer who isn't a committer, you can test it yourself, making everyone's lifes easier and speeding up the overall process.

Even so, I would think -ports and -current mailing lists are a better place to talk about any broken ports.
I don't say discussing porting issues would be on-topic in a "-CURRENT" section. I'm just talking about one valid use-case for running a -CURRENT machine that isn't developing or bug-hunting in the system itself.
 
I used to run -current for many years. I never expected ports to always track -current. You can't expect tens of thousands of ports to build every time a new commit is made! However, I would expect ports to work with a new release.

The lists do serve a purpose, but things there are terribly last century. Plain text, denial of attachments, disjointed archiving, and so on.
Even so, that is usually where developers hang out and not on a newbie friendly forum.
 
I don't say discussing porting issues would be on-topic in a "-CURRENT" section.
I think that discussing a given port's breakage in a -current subforum would serve a useful purpose. But like I said earlier in a couple posts effective participation requires an understanding of a topic, and a buy-in to the goals of the conversation. If you're not a good fit to the conversation, you're not welcome to participate, sorry! This is the dynamic under which most workplaces operate, even in "right to work" countries. This ties into my earlier comments about the disconnect between dev hangouts and user hangouts - some of that disconnect may be intentional. As the saying goes, "Birds of a feather flock together". You wanna be a dev - get up to speed on the tools, expectations, interactions, etc. Yeah, that's hard work, and you'll have to take some lumps along the way. 😔
 
I envision -CURRENT subforum as a way for users to have some exposure to the development process. …

For exposure, I occasionally speed through a list of new bugs, clicking only the ones that interest me.

Feeds can be useful, but a little disorderly, for example:

1644088367809.png

I find an Element view of things easier to speed through:

1644088497393.png

YMMV
 
Here's example why topics about current are not welcome.
 
Here's example why topics about current are not welcome.
You posted that about 10 minutes after that thread started. It may be a legitimate example.

From that thread:
Why do you want to use a development version of FreeBSD anyway? Why not just install a supported version?
Simply because FreeBSD 13 on Parallels in M1 (ARM) at the moment I think it have problems due to some system bugs that I don't know: I tried to install it with the "other systems" option (not Linux), in this case it installs but does not goes to the network; then I tried with the "linux" option and in this case it goes into a loop at the installation and restarts after few seconds...

FreeBSD 14 installs without difficulty, even if it then has these drawbacks.
It's relevant for hardware reasons, but the software part isn't. There's some value for the forums as there's hardware that people want to use, and this gives useful information about that.

Knowing about ports and other basic tasks is the least expected for using CURRENT. While it's implied, something like this could be added to the guideline.
 
… Using CURRENT will require more of building your own ports …

STABLE requires more building of ports than RELEASE.

This thread should be done.

Which of these three things might be meant by done?
  1. Begin a parallel topic about creating a sub-forum for STABLE
  2. forever continue to suppress discussion of CURRENT, even when suppression of CURRENT alone becomes irrational
  3. be welcoming and approachable.

Nobody has addressed

Ahem.
 
Compatibility for newer hardware and for new features is my main reason for believing why CURRENT should be discussed here. Another reason, I can think of if is an entity of a CURRENT version is written about in an online journal/magazine or elsewhere, but this wouldn't be for troubleshooting and would be a little more relevant than offtopic already is. It can be discussed, though there will be the constant bringing up the rule. I wish something like this could be added to the guideline, so when the rule is pointed to, those are clear exceptions.

Welcome to the new user, and I'm sure will be a great contributor to the forums. However it was a little inconvenient to see the having to explain about (limitations of) ports and packages in CURRENT. Every new forum user, has had to be corrected on something, even on forum usage, or learned more about the OS they went. The part about hardware is relevant, and as to why they used CURRENT. A lot of potential users want to know about what newer and common hardware works and about new features.

Also, there's some expectation for users to know about using ports and packages, and other basics when using CURRENT. This way, the rule can be posted once, then discussed less afterwards. While a lot of this need may need to be said specifically, there's some implications of this already in the rules:
For the most part, -CURRENT should be considered the playground for FreeBSD developers, and for 'adventurous users' who don't mind that their system breaks. These users typically do not require any help to get their systems back into a working state.
You should really only install -CURRENT if you're prepared to participate in fact-finding and troubleshooting sessions with the FreeBSD developers on the freebsd-current mailing list. The forums lack the knowledge and resources to answer in-depth questions about new developments and their ramifications.
For new hardware and features, a user should also be ready to use the mailing lists anyway, and be able to report back to developers on there.

I don't see the need for a whole forum, but instead for a prefix, which unfortunately can get replaced with a SOLVED prefix. Having a forum of CURRENT, would be comparable to having whole forums dedicated to each major distribution, 13 series and 12 series. An operating system feature is important, and that feature needs to be seen as evolved if applicable to being into STABLE and a production release. A tag can already be used, if these limited discussions about CURRENT are accepted than barely tolerated.
 
it was a little inconvenient to see the having to explain about ports and packages in CURRENT. Every new forum user, has had to be corrected on something, even on forum usage, or learned more about the OS they went.
We have this same problem on Stack Overflow and another forum I used to moderate. No one reads the rules. It's their fault, not the forums, but there it is.

Compatibility for newer hardware and for new features is my main reason for believing why CURRENT should be discussed here.
Except, as stated earlier, newbies shouldn't be using CURRENT and CURRENT isn't designed for users, who this forum is for.
 
I still see the exception, of for a particular piece of newer hardware or a feature, when they know enough of the basics. Also, if someone's expert enough and wants to tell us about it. It's of value to production systems and for users, for when it's asked about or for shortly into the future. There's a lot of asking about newer hardware on FreeBSD. There's a mailing list, some things about hardware/features can be discussed and searched here quicker. They have to be able to use the mailing list anyway. Though, people need to try STABLE first, if they want to experiment with if something works.

When I tried hardware on STABLE or production, I knew I was taking a risk on that hardware not working any time in a few years (or not at all, but less likely).
 
But things in CURRENT might not ever make it into STABLE or RELEASE. Discussing such things now is pointless to users if it never makes it beyond that.
 
We have this same problem on Stack Overflow and another forum I used to moderate. No one reads the rules. It's their fault, not the forums, but there it is.


Except, as stated earlier, newbies shouldn't be using CURRENT and CURRENT isn't designed for users, who this forum is for.
I've seen people who don't post a lot here, but are clearly not newbies when it comes to FreeBSD, and would be comfortable with -current. Those people do seem aware of what they're getting into.
 
But things in CURRENT might not ever make it into STABLE or RELEASE.
I don't want to admit it, but that's a good point. They need to understand that they're taking a risk that support for a hardware may not make it into a STABLE or a RELEASE. Lots of hardware support is expected to stay in, because it's newer hardware that's becoming more common. It should only be for people who know what they're getting to, and readers need to know that a hardware or feature may be dropped.

There was a product I bought was meant for a production system, and it listed FreeBSD on the box. The hardware didn't work, because the FreeBSD I was using was a newer version, and GENERIC only had drivers for newer versions of hardware from that manufacturer. It was a RocketRaid card.

There was a time, where a developer on a mailing list told me something regarding a newer version of Bluetooth worked. This may have caused me confusion, because it may have been in CURRENT or STABLE, and maybe didn't make it to a PRODUCTION version. Either this, or the developer pointing to something preemptively, or something that was in a tree, but not fully functional.

A feature itself, can just as easily be about PORTS, than CURRENT, STABLE or RELEASE: it can also shift between these.

We have DEVELOPMENT in the forums: https://forums.freebsd.org/forums/freebsd-development.34/.

I still think there needs to be considered exceptions for hardware and features of CURRENT, something along the lines of DEVELOPMENT. Obviously, with not as much leeway as for STABLE or RELEASE, and users need to know enough of what they're doing.

But even then, I don't use the latest hardware; I use what's good enough and what's common. The only interest I have in hardware is for a few things, which I wait for it to get into a Production release. I don't use CURRENT and STABLE anyway. I would use STABLE, but I don't feel like doing the install and reinstall, just to learn about that and write about it.
 
And it took 6 pages before sidetone pointed out THAT. Now I feel a little silly, because I haven't connected the dots until now. 😩 A quick look there gives me the impression that a thread about -current would be at home there! It would be a good mental exercise for participants to frame the topic and discussion so that the thread does not become a catch-all for attitudes and politics. 😏
 
Back
Top