Summary.

A brief overview of stability levels and automatic submission limitations.


Ebuild stability (status) levels.

new A newly submitted ebuild. Can be installed/considered by emerge only if --enable-all option is given in command line or Stability_level flag in make.conf is set to All
confirmed This is for ebuilds not reviewed by core group but which have reached certain threshold of positive votes. Is seen by emerge if --enable-confirmed is given or Stability_level=confirmed.
approved ebuilds reviewed and approved by core group (and received sufficient amount of positive votes). Requires Stability_level of "approved" or --enable-approved in command line (last one atypical, as Stability_level wil rarely if ever be set higher).
core System libraries and other crytical packages (likely including portage scripts). Requires core developer attention. No submissions go directly into CVS. Awailable always, as this is maximus stability level that can be specified.
unstable Packages whose average vote dropped below negative threshold value or that were reviewed but not approved by core developers. These packages are effectively banned form consideration by high level tools (think present masked packages). In order to be installed require invocation of low level ebuild utility.
The "new" status actually combines "new", "approved-new" and "core-new" levels. Second is for new core developer submissions and 3rd is for new submissions or updates of core packages.
It may not be necassary to consider such submissions as new but rather to assign them appropriate status immediately. However maintaining overal procedure for developer and core submission (namely vote-count before confirmation) will allow for a more secure distribution if there is a need for such (you don't put the latest two-day old kernel version on a production sever after all. Instead you normally wait some time and observe comments of must-have-latest community. kernel-2.4.15 was a good example of how things can go wrong (even in a stupid way) on just any level).
On the other hand this distinction is largely conceptual and requires special measures (such as core and approved package lists) only on server. User tools only need to know about the "new" status. All the threshold values, urgency and other politics happens on CVS.

It is possible to have an additional Stability_level setting of "unstable" to let high level tools access ebuilds marked "unstable". I don't think this is a good idea though, as certain people won't be able to hold the temptation to break their system :-).
But then rsync_Stability_Level should have such setting available, so that people could see what ebuilds were worked on. Somebody might actually repair it!

Automated submission and server sequrity.


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