Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Different testing branches
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
node_one
Apprentice
Apprentice


Joined: 07 Apr 2008
Posts: 165

PostPosted: Thu Apr 10, 2008 6:03 pm    Post subject: Different testing branches Reply with quote

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
View user's profile Send private message
AllenJB
Veteran
Veteran


Joined: 02 Sep 2005
Posts: 1283
Location: Ashford, Kent

PostPosted: Thu Apr 10, 2008 6:41 pm    Post subject: Reply with quote

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.
_________________
http://gentoo-wiki.com :: http://lug.org.uk :: http://www.linux.org/groups/ :: User Blogs
Back to top
View user's profile Send private message
Kollin
Veteran
Veteran


Joined: 25 Feb 2006
Posts: 1099
Location: Sofia/Bulgaria

PostPosted: Thu Apr 10, 2008 6:43 pm    Post subject: Reply with quote

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!! 8O *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
View user's profile Send private message
Genone
Retired Dev
Retired Dev


Joined: 14 Mar 2003
Posts: 9011
Location: beyond the rim

PostPosted: Thu Apr 10, 2008 10:53 pm    Post subject: Reply with quote

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
View user's profile Send private message
node_one
Apprentice
Apprentice


Joined: 07 Apr 2008
Posts: 165

PostPosted: Fri Apr 11, 2008 5:59 pm    Post subject: Reply with quote

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
View user's profile Send private message
Genone
Retired Dev
Retired Dev


Joined: 14 Mar 2003
Posts: 9011
Location: beyond the rim

PostPosted: Sun Apr 13, 2008 8:34 am    Post subject: Reply with 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.
Back to top
View user's profile Send private message
timeBandit
Bodhisattva
Bodhisattva


Joined: 31 Dec 2004
Posts: 2672
Location: here, there or in transit

PostPosted: Sun Apr 13, 2008 2:31 pm    Post subject: Reply with quote

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
View user's profile Send private message
node_one
Apprentice
Apprentice


Joined: 07 Apr 2008
Posts: 165

PostPosted: Sun Apr 13, 2008 6:58 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Page 1 of 1

 
Jump to:  
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