Since I found OpenRC to contain at least one critical bug within the last 3 minor (0.x) releases, I would prefer if it would get some beta testing, before releasing it to the general public.
What I propose is that each new minor release is added to the tree p-masked and the beta testers are informed via email or bugzilla (CC) of this new release, so they can try (i.e. unmask) it and report all issues they find. The best candidates for beta testers would probably be those users who already found a lot of bugs - e.g. because they have odd setups.
I hereby volunteer to be an OpenRC beta tester.
How about beta testers running 9999 and updating often and reporting
bugs they find to us?
Several of us on the team booted our systems with 9999 several times
before the release and did not have issues; otherwise the release
wouldn't have happened.
Or maybe we just add things without keywords at first the way 9999 is;
that is another option.
The reason I suggested having people test with 9999 first is the
fixes could be quicker and we wouldn't have to spin a release for each
Off the top of my head, here are my thoughts.
1. Let's open up an openrc-dev mailing list. That way, anyone who wants
to follow all of this can subscribe there.
2. When a new release is pending, an announcement will be made there.
3. At that point, anyone who wants to test can emerge openrc-9999 and
let us know if they have issues.
4. Also this list will include discussions of changes for OpenRC.
(In reply to comment #0)
> Since I found OpenRC to contain at least one critical bug within the last 3
> minor (0.x) releases, I would prefer if it would get some beta testing,
> before releasing it to the general public.
After speaking with Dennis on IRC for a while about this, we both agreed that p.masking is not really the answer for this issue because that involves a lot of work on all sides.
I'm considering using no keywords to mean masked the way we do for the live ebuild.
Also, I'm considering making the beta ebuilds pull from a specific commit in the repository so that we don't have to keep beta tarballs around indefinitely.
All anyone would have to do to test then is add a line to package.accept_keywords to accept beta versions.
Since keywording still involves the same work to unmask on the tester's ends, another proposal was made: An overlay with regular keyworded ebuilds in it should be provided. Testing volunteers could just "layman -a openrc" and test the newest versions of OpenRC before they hit the tree.
As side-questions we discussed how to version the ebuilds, and William preferred releasing 0.x_beta* first, and once the ebuilds hit the tree start naming them 0.x.y. The exact naming was not really important to the people proposing the beta testing project, though.
adding myself as CC for the purposes of any announcement re openrc-dev mailing list.
best .. khay
(In reply to comment #7)
> Since keywording still involves the same work to unmask on the tester's
> ends, another proposal was made: An overlay with regular keyworded ebuilds
> in it should be provided. Testing volunteers could just "layman -a openrc"
> and test the newest versions of OpenRC before they hit the tree.
> As side-questions we discussed how to version the ebuilds, and William
> preferred releasing 0.x_beta* first, and once the ebuilds hit the tree start
> naming them 0.x.y. The exact naming was not really important to the people
> proposing the beta testing project, though.
For the record, the idea of an overlay was proposed. However,myself and the gentoo qa lead both have extremely strong reservations about using one, especially since it is easy to configure your system to pull directly from OpenRC's git.
The whole argument for releases was based on the idea that you need a fixed point in development for QA. That can be provided with the live ebuild.
You can set openrc_LIVE_COMMIT="1234567" in make.conf to pull a specific commit.
You can also unmask the live ebuild easily.
Once you are through testing or to downgrade, you can just re-mask the live ebuild.
I do not use OpenRC anymore. If you still do and are interested in beta testing, please (request to) reopen.