I can do a lot from a production release. I used to achieve more. It's partly because there was low hanging fruit to be improved that no one caught for years, but a larger part of it is, because I don't have as much energy and focus.
If and when I learn Python and C, then it would be worth working on CURRENT. Having a system in virtualization for CURRENT would complicated for me as well. I would stick with a production release anyway. I would be on STABLE, but I don't have the energy to be compiling STABLE for every update that comes along.
Documenting on the forums may seem like little, but I learn a lot when writing about it, and it helps others see how things work more clearly. As for CUPS, I used to think it was a mess based on what others said, until I wrote about it, I see how it's very practical, and just needs cleaning up on the side. Actually, a lot around CUPS is a tangled mess, when I tried to print a while ago. It pulled in over 50 dependencies that broke functionality of other ports on my system. However, that mess is the ports tree, not CUPS itself. I thought about how the ports tree could be cleaned up around CUPS and SANE before researching and writing that.
I tried documenting on the Handbook, but it's not practical at all. It's difficult to do yourself. Also, it can change, when each line is referenced from the beginning of the book. I can write improvements to it, but using that system is difficult. When wanting help for getting improvements in, it has happened, that no one is ready at the same time.
The major way a lot of CURRENT users would be on the forum, is for those who use the Desktop. Desktop's problems are largely in ports, rather than in the base system. Still, CURRENT uses the ports tree. What relates to the base system has to do with video drivers. What gets cleaned up for ports in a production release will carry on into CURRENT's use of ports anyway.
All I'm interested in CURRENT is very few things. Video graphics are good enough. Bluetooth or any substitute that allows a usb stick to work with multiple outputs, which is an over all lack from all Opensource desktops, not only FreeBSD. Any capability like this will come from ports first anyway. The only thing, is for HID in base to either take the abilities of uhidd or iichid in ports, or for the ones in ports to be compatible with HID in base. There's not much in CURRENT that I'm interested in anyway. The base has already caught up with a lot of technology.
I'm 50/50 on if CURRENT would be good for here. In a way, it seems like it belongs, even if I won't use it or hardly be able to comment on it. Others on here and I couldn't bring value to a CURRENT section. There could be a lot of people asking about it, and a few people getting frustrated with everyone asking so much. While it seems like it belongs, there could be downsides to having a CURRENT section in the forum. There could be upsides that we haven't realized as well.
Really, there needs to be more people on the mailing lists and on Bugzilla. Going on there, I have to do research before posting. The ports tree has been discouraging for me, when I suggest something that keeps getting ignored, such as to label Doxygen as Doxygen and not as simply Docs, because they have different dependencies. I make up for this in my make.conf for exceptions on those ports. Most of the time, maintainers are responsive, as a month is a good time to get back, and they appreciate suggestions that work.
