Continuing the discussion from Qubes OS 4.2 Signed Weekly Builds:
@Insurgo raised a good point about the testing category.
What are your thoughts on how this category can better serve its members?
Is this a case of a downward spiral of inactivity? (Less posts, then less engagement, etc.?) Do you prefer opening issues directly in the tracker? Etc. (Feedback welcome 
).
Well, to me it starts from building some testing gidelines and applying crosslinking processes.
I think a good start is https://forum.qubes-os.org/t/what-to-test-where-to-get-what-to-test-where-to-report-testing-results
Actually, this is the 4.2 testing category. We’re posting in it right now.
Here’s the link: 4.2 Testing - Qubes OS Forum
Maybe it’s a case of “out of sight, out of mind.” Can you have it shown in the left side bar by default for members of the testing team?
Could be. I will play around with it. But I am not sure I can make apply it only to some users. Especially because everyone can see it but not all can post to it.
Weirdly enough, I was not seeing it 
only the first referred post telling users to post to an e-mail address to create new topics, which also was a post for 4.1 reused for 4.2 which is why I got confused and asked if there was actually testing happening on 4.2 from the 30 testers in this forum.
I’ve seen some issue about 4.2, but ye i can fix the most of it, so i dont see anything need to be discuss? feel free to ask.
(moved this to the Forum Feedback category so others who are not in the testing category can also chime in if they have any thoughts)
I’m going to be proposing here a radical solution. And I wanted to hear other’s thoughts, particularly @unman’s who currently manages memberships of the team.
Currently the testing team requires that people apply. Could it be that by making this a non-exclusive category would actually share testing results?
It’s of little point having one category where there are very few posts. Given that in the past, in the testing team mailing list it wasn’t much active either, this could potentially be a better situation. But idk, could also be that people are just not interesting in sharing here findings before opening bugs upstream.
It could also be indeed a lack of visibility.
How to bring more attention and participation to 4.2 Testing Category
Thanks for open ability to write about testing. My message (modified a bit) from other thread:
Maybe people are reluctant to participate in testing of upcoming releases on a beta stage due to being afraid that something will be broken and not fixed for a long time. And it happens, unfortunately. It happened to me with R4.1 and keyboard layouts. Something should be done to address at least the most painful regressions.
To me it can explain why testing of R4.2 is not going so well. E.g. I would love to install R4.2rc1 on a laptop for testing, but I am still not able to fix my main issues on R4.1, I do not want to make it worse.
Maybe the development process should be leaned a bit from adding new break-existing things towards making stable pivot releases with improvements and new features, so it can be advertised/recommended to other people to work in a stable way for at least 1-2 years. Something about priorities of existing issues and something like that. Thanks again.
I’m reluctant to try 4.2 RC yet because there is no upgrade path from 4.1, and it’s not clear if it will be possible to update from the RC to the release properly.
The upgrade path MUST be tested, it should really be part of the RC itself IMO.
I also worry about the documentation, 4.2 changed a lot, and the website documentation only contain doc for the stable version, are there waiting-to-be-merged PR for 4.2 or will the doc be obsolete for a few months once 4.2 is obsolete?
4.2-rc2 is coming out very soon, and it includes the in-place upgrade tool.
Both. You can see some waiting PRs here, but the reality is that the documentation is mostly a volunteer effort, so it mostly just gets updated as people find the time and inclination to contribute updated content.
It could be level 2 access, like “All around Qubes”.
I expect many users to struggle with the iptables → nft change when reading the documentation
I suggest to make the documentation of such important changes part of the release cycle.
And about mans, do they reflect calling changes in qvm-* and qubes* tools?
Acknowledged. Thank you for the suggestion!
You mean in the OS rather than on the website? (My comment above was about qubes-doc, not in-OS documentation like man pages.) That I’m not sure about, but you can probably check in the appropriate repos on GitHub. If the devs have forgotten to update them, please feel free to open an issue (if one is not already open) and/or submit a PR to update the man pages.
Oh the tool command line interfaces are changing?
Where can I find out about this? Changes not known about will absolutely bite me (and probably many others) in the butt when I go to upgrade since I use a LOT of scripts to regenerate VMs. (And hopefully salt will know what to do internally, too.)
Some people enjoy keep documentation up to date (i know some), and some people not (its me).
For me and for now, writing a good documentation still hard, it maybe too technical for novice user.
Well, I think almost no, it stays the same.
But maybe qubesctl in R4.2 will have some options that are absent in my installation of R4.1. I saw something about this change when I was developing qubes completion (bash completion) for all qvm- and qubes* commands.
Note that qubesctl has no complete documentation anyway, its man page is lacking basic information about arguments. So, maybe I am wrong and nothing changed, I do not remember the details.