View previous topic :: View next topic |
Author |
Message |
node_one Apprentice
Joined: 07 Apr 2008 Posts: 165
|
Posted: Thu Apr 10, 2008 6:03 pm Post subject: Different testing branches |
|
|
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. |
|
Back to top |
|
|
AllenJB Veteran
Joined: 02 Sep 2005 Posts: 1285
|
Posted: Thu Apr 10, 2008 6:41 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
Kollin Veteran
Joined: 25 Feb 2006 Posts: 1139 Location: Sofia/Bulgaria
|
Posted: Thu Apr 10, 2008 6:43 pm Post subject: |
|
|
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..." |
|
Back to top |
|
|
Genone Retired Dev
Joined: 14 Mar 2003 Posts: 9522 Location: beyond the rim
|
Posted: Thu Apr 10, 2008 10:53 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
node_one Apprentice
Joined: 07 Apr 2008 Posts: 165
|
Posted: Fri Apr 11, 2008 5:59 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
Genone Retired Dev
Joined: 14 Mar 2003 Posts: 9522 Location: beyond the rim
|
Posted: Sun Apr 13, 2008 8:34 am Post subject: |
|
|
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. |
|
Back to top |
|
|
timeBandit Bodhisattva
Joined: 31 Dec 2004 Posts: 2719 Location: here, there or in transit
|
Posted: Sun Apr 13, 2008 2:31 pm Post subject: |
|
|
node_one wrote: | 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. |
That sort of information is best obtained from a bugzilla search for the package of interest. _________________ Plants are pithy, brooks tend to babble--I'm content to lie between them.
Super-short f.g.o checklist: Search first, strip comments, mark solved, help others. |
|
Back to top |
|
|
node_one Apprentice
Joined: 07 Apr 2008 Posts: 165
|
Posted: Sun Apr 13, 2008 6:58 pm Post subject: |
|
|
Quote: | 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. |
Maybe you are right. Maybe something like this will not reduce the total amount of time that I or anyone else has to spend masking or keywording packages on the user side (etc/portage) in the long run. If that is the case, then it is truly not worth implementing. I am just too inexperienced to make a judgment one way or the other, yet.
Quote: | That sort of information is best obtained from a bugzilla search for the package of interest. |
True. What about making some of it available from inside emerge or equery? It does not have to be very detailed. At least a bug count and the most recent bug post-date would be better than nothing. Right now these tools seem to be disconnected from what is happening on Bugzilla or there is another tool that I just do not know about. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|