This lengthy proposal is preceded by a discussion on [gentoo-dev] mailing list. Please see messages:
http://lists.gentoo.org/pipermail/gentoo-dev/2002-March/010028.html
http://lists.gentoo.org/pipermail/gentoo-dev/2002-March/010337.html
http://lists.gentoo.org/pipermail/gentoo-dev/2002-March/010504.html
and their related threads.

Also I would like to thank Benjamin Ritcey and Chris Johnson for their contribution.

I exchanged few private emails with Benjamin. Since I feel that his question may be of interest to other people, I asked him for permission to include our messages here. So, with his blessing, here they are:

Benjamin Ritcey:
OK, read it though; some good ideas, but somethings that I was wondering about -- if a good chunk of people don't run the 'new' ebuilds, how will anything get voted up? If it's just a point-release for something (say, samba_2.2a or whatever), will this still be in the 'new' category?
Otherwise, it sounds like a start - we certainly need something...
-b

My response:
On 28 Mar 2002, Benjamin Ritcey wrote:
> OK, read it though; some good ideas, but somethings that I was
> wondering about -- if a good chunk of people don't run the 'new'
> ebuilds, how will anything get voted up? If it's just a point-release
   I would not worry too much about it, from my experience it is easier to find people who will want to get to even "unstable" stuff, vs the ones who will stick with stable only. Besides rsync_Stability_Level == All will only enable to fetch all packages, emerge will not see them by default, so I expect many users will opt for that. And once they see something interesting some of them won't hold to check it :-).
   Nontheless this is a very valid concern. Notice that I left both these options as possible alternatives (end of Server perspective section). This is where I am most interested in input.
   Also I don't think it is possible to know up front what's gonna be the best solution (this is a dynamic system, depending on initial conditions it can end up in that or other attractor). We might need to try both. It seems that a good starting point would be to implement a mixed case:
  Important packages get approval status manually from core group. If they don't want to approve it (if it's been submitted a new developer) but feel that promotion to confirmed status is necessary they could promote it manually (yea, I feel bad about such possibility, I think if core developer looks at it he should approve it).
   If the package is not that important, then let it rot. Users CAN see its existence. Of course this requires a good doc, so users know where to look (good browsing tools are nice also, it can probably be done within portage2 framework).
   The point is that requirement to have ALL packages confirmed will provide a nice additional layer of security. And yes, I see that this does not seem to be the problem for important packages. The problem is that occasional packages won't get much attention. Well, this is the life. Go to http://www.freshmeat.net. Do you feel comfortable about stability of every one of those apps (analog of having package reach confirmed/approved status)? But they all are accessible/browsable. Compare this with the package which did not make it there - you have to know what are you looking for and quite specifically.

> for something (say, samba_2.2a or whatever), will this still be in the
> 'new' category?
   Yes, that's the idea for this one. It is not critical to the general idea though and can be omitted, but I feel that some people would love to have it that way.

BTW, I was also thinking about setting up some kind of developer rating system, based on how their ebuilds get accepted. Something similar to slashdot, we can use entropy instead (entropy=exp(karma)) :-). I have some thoughts, they did not make it into this write-up yet. I will probably update vote system section sometime. Do you this that would be interesting?

PS
Nonrelated :-), why slashdot got definition of karma the other way around? Everybody who got at least some eastern exposure knows that large karma is BAD and small karma is GOOD.

George

Chris Johnson
Chris proposed an "alternative" route. While maintaining stability levels and votes, he pleaded for simplicity. He also opts for a "passive user - active system" voting scenario. You can find details in his nice write-up here:
http://relentless.org:8000/gentoo/forum/message?message_id=6584&forum_id=6581

You can find my response here.




Few semi-random thoughts.

It just stroke me: the structure of stability levels I propose here nicely mirrors existing mailing lists (and thus gentoo community). We have:

gentoo-core: people with write CVS access
gentoo-dev: people who submit patches and ebuilds and don't mind to get down and dirty
gentoo-user: users - largest part of the community
gentoo-newbies:  this is where new people are supposed to ask questions.

Does this ring a bell yet?
One important aspect here is the fact that this mailing list structure was not created right out of the box, but rather evolved. Looks like evolution tends to dictate some common features as the systems grow!
Also just a common observation, as you start participating in a project and core people start to notice you, they tend to respond faster (to an ebuild submissions for example. And BTW this is not only gentoo, its a common "feature" :-)).Well, this is pretty natural, so why not automate this with a rating system described in a voting section?

Email me, post a message to gentoo-dev mailing list, or use my feedback form.