Chris: Thanks for contribution!

First I would like to go over conceptual stuff. I totally agree, that unobscured ebuild flow is central to the success and scalability of the distribution. Your points on what are you looking for in the user feedback (namely reports of what worked and what did not) are very essential. This is a kind of input I was looking for. 

I see now that we are attacking the problem from different sides, you jump right at what you as user would like to see and I was thinking in terms of how to introduce distributed ebuild processing with minimal effort and maximum security. I must say that I generally prefer evolution over revolution :-).

Now to the technical stuff:

 I see that we think about packages in a different way. I opted for every change to any ebuild be specifically visible: every update by original author or anybody willing to contribute goes as a new -rX ebuild. These ebuilds are rated according to voting system. Effectively this is a CVS realisation, however since the needs are quite specific it has to be modified. I think that addresses your concerns to some extent - every attempt is available and successfull ones are better visible. 

I created this design on a presumption (which I did not realise at the time but now see its influence) that as a successful project which finally left tight hacker community for a large world, gentoo has have three categories of users: 1.regular users 2.developers 3.core developers With a popular distribution 1st category will outnumber others (and at some point greatly) and thus provide sufficient testing. It may be essential to have silent votes submitted or it may be better to require users to take an action to submit the vote. We can never know beforehand. That's why I did not just push for a specific voting system but instead tried to quickly compile a few possibilities. I am sure in the end we will settle on initial realisation (probably something mixing both possibilities), as well as I am sure that we will have to readjust it later :-). 

BTW, I am going to rewrite my chapter devoted to voting systems. Right now it is not much more than a few paragraphs of raw thoughts. I also have an idea about developer ratings to complement votes for ebuilds (and make overall voting mechanism more efficient). I will write this down sometime over this coming week. 

Promotion threshold levels: I strongly feel against setting them in stone, whatever stability level structure we will end up with. It WILL have to be readjusted as a userbase will grow.

On a related note. As system grows the more decentralized it gets. However this does not happen in a big crash-event normally. Usually it goes through stages, like benevolent dictatorship -> core group in charge -> delegation of partial processing rights to outsiders -> core group as coordinating center... and for successfull project the transitions are normally pretty smooth. Therefore in my design I try to accomodate all the needs. 

1. We have to provide possibility to keep resultant distribution stable. Therefore I consider my stability levels and requirement for user confirmation of ALL ebuilds essential. I will update this section in the main file (proposal.html) as well. 2. It seems that your stability levels are pretty similar to mine and even overlap somewhere:

 2.1 I think tere is misconception in your text: your "Stable" ebuilds correspond not just to core in mine structure but to core and approved comined. The distinction on my side is purely functional, they both are stable, while core require more specific core developer intervention: they cannot be commited automatically, instead they go through core group. 

Approved CAN be commited automatically, they are accessible, only they reach approved status upon core developer blessing. This is more related to security levels of distribution then to ebuild acessibility.

All other ebuilds do not require core groupintervention al att. Well, technically none require. If ebuild does not get core developer attention it can still reach confirmed status. With many users setting their Stability_Level = confirmed you will effectively get decentralized distribution without central control on majority of packages. No "manual certification" as you mentioned it required. Only on core packages.

 2.2 However there is an additional feature you want represented more specifically, that is to see all successfull and all failed attempts. I do not want to go into voting specifisity at this point. Lets try to keep design modular from the very beginning. So, what about such scenario: All the limitations I imposed in "Server perspective chapter" will require that every modification to any ebuild shell go as a new -r(X+1) ebuild. If original ebuild fails it gets "unstable" and author or interested users are forced to repair it. And all their modifications will stay in the tree - visible. The success of implementation is visible as its aggregate vote. Unsuccessfull are visible if you opt for it (rsync_Stability_Level flag).

The best thing - this info is available locally. nd you do not need to use special tools for it - avoids unnecessary database branching.

Well, actually it may be desirable to have all this data stored remotely. It is possible to do it both ways and write tools that do both. It is possible to keep one database per LAN and sync it to some central depository. As system grows single central depository will become a single point of failure and distributed system similar to DNS or FreeNet can be used (this is already Mega level, when we surpass RedHat, Mandrake and RedFlag combined :-)). Infinite configurability is possible, and this is why I think that with proper care gentoo can become THE unifying (but not limiting) base. All it takes is to follow evolution.

Now back to evolution and design. While we have to strive to keep the system secure and choose the best implementation corresponding to presennt user base (what defines how much centralized it should be kept at the moment) we should not forget the ultimate goal: infinite scalability, evolution is a distributed process. On the other hand while we strive to reach infinite scalability we should not forget issues at hand: keep it secure sequre and appropriate. Ok, I feel like I start to sound political here, thats a sign to stop and put some time in the actual desing :-), and may be start thinking about implementation?

PS I will submit rewised proposal to bugs.gentoo.org in about a week. I think to provide links to both proposals and to this forum. What do you think?