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’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.
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.
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.
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.)
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.