[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Re: Unstable branch proposal - second round
From:       George Shapovalov <georges () its ! caltech ! edu>
Date:       2002-03-30 11:04:59
[Download RAW message or body]

Chris

I cannot post to the forum, all I get in responce is this:

Request Error The server has encountered an internal server error. The error 
has been logged and will be investigated by our system programmers. 
AOLserver/3.3.1+ad13 on http://relentless.org:8000

Therefore I attach my posting here.

PS
Don't you think we should change the topic name? I am afraid this "unstable 
branch" stuff scares @gentoo.org people off :-).
    If you agree please reply off my posting under "distributed ebuild 
processing" or start the new thread.

George


On Friday 29 March 2002 05:10, you wrote:
> George and all,
>
> I'd like to modify/simplify this proposal somewhat. George's proposal is
> complementary and more comprehensive, but I try to cut it down to what I
> think is the minimally sufficient system. I explain further at this
> link:
>
> Background/motivation:
> http://relentless.org:8000/gentoo/
>
> Short proposal plus forum:
> http://relentless.org:8000/gentoo/forum/message?message_id=6584&forum_id=65
>81 Enjoy, and I'm open for comments!
>
> Chris
>
> On Thu, 2002-03-28 at 00:52, George Shapovalov wrote:
> > Thanks!
> >
> > you might be willing then to read my detailed description :-), link to
> > which I just posted on mailing list:
> > http://www.its.caltech.edu/~georges/gentoo/epsp/proposal.html
> >
> > George
> >
> > On Wednesday 27 March 2002 19:22, you wrote:
> > > It sounds like a good idea!

["Chris_forum-1.txt" (text/plain)]

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?



[prev in list] [next in list] [prev in thread] [next in thread]