Different testing branches

[node_one]

I have been thinking that it may be beneficial if the testing (~) branch is split into, possibly three (alpha, beta and rc), different branches.

This will allow users to choose, by keywording, what level of instability they are comfortable with. New packages can first be available to all users with, for example, an alpha keyword, instead of everyone who has them keyworded testing. Then if there are no problems with the packages, they can be keyworded beta, rc and then stable.

I am not familiar with portage enough to know if this is possible, or how it can be implemented. I would like to know what more experienced users/developers think about this.

[AllenJB]

But the testing branches aren't based around whether packages are considered alpha/beta/rc upstream or not and introducing more levels of "testing" into Gentoo itself would be unnecessary and create more work for the developers. You can filter by specific versions in /etc/portage/package.* already.

[Kollin]

I don`t think that this is wise, alpha and beta software can do a horrible things on meta distro like gentoo!
Can you imagine alpha-baselayout compiled with alpha-gcc and alpha-glibc!! *shivers*
_________________
"Dear Enemy: may the Lord hate you and all your kind, may you be turned orange in hue, and may your head fall off at an awkward moment."
"Linux is like a wigwam - no windows, no gates, apache inside..."

[Genone]

Well, technically it would almost trivial (as there is no technical relationship between arch and ~arch). But it would just increase complexity without any real benefit, as it would still be up the ebuild/arch maintainers to decide what keywords an ebuild would get. Also there is already package.mask for the problematic stuff, so I don't see any need for another layer.

[node_one]

Yes, I do use package.mask a lot. The names alpha beta and rc were only suggestions and I was not, necessarily, considering upstream when I was suggesting them. Also I suspect packages such as "alpha-baselayout" and "alpha-gcc" would be masked when the alpha is referring to upstream. As far I understand it, masking is independent of the branch. Packages can be masked and be stable.

I guess I am looking for a way to get more information about an ebuild/package, more than emerge -pv, emerge -s or equery list -p, in terms of:

1. How long it has been in testing (the ebuild and the package, if considering upstream, separately)
2. Current/past bugs and their severity

and also to possibly use that information more easily. I was thinking keywording different testing branches would be a very effective way to communicate that to users and at the same time allow users to control the maturity/quality of the packages they emerge, and use, through a more coarse-grain method than packages.mask. I think this would be especially important when doing emerge -(pv)uDN world.

With respect to all developers, I do not think all packages in testing (~) are of equal maturity/quality and there should be an easy way to designate that, for users to get informed about that, and for users to be able to easily act on that information. I think that if this or something similar is handled correctly, there would be less need on the user side to deal with package.mask. In addition, I think this may enable users of different skill levels to more effectively test packages. Right now all users emerge/test from the same testing branch. With multiple branches, more experienced users can work with more "bleeding-edge" software where less experienced users can work with more "beta" software.

Maybe there is just something wrong with my workflow, the way I deal with packages. After all I am just a n00b, too new of a Gentoo user and not a pro developer.

[Genone]

The main problem is that not everyone has the same standards: what one considers stable could be an alpha version for someone else. It's a social problem, and you can rarely solve those by technical means.

[timeBandit]

[node_one]