Bug 1523 – [IDEA] Offload work by distributing trivial ebuild maintenance to users, introduce a simple stability voting system and have a core team approve them to the Portage tree.

• Status: RESOLVED OBSOLETE
• Product: Gentoo Linux

[Description George Shapovalov (RETIRED) 2002-04-04 04:56:18 UTC]

Please take a look at 
http://www.its.caltech.edu/~georges/gentoo/epsp/proposal.html
for an outline of changes to portage that will help to offload non-crytical
stress off core developer team and delegate ebuild review to the users in a
secure and scalable manner. 


This submission is a continuation of a topic first raised few weeks ago under
the "unstable branch" name on gentoo-dev. I reopened the topic under a slightly
modified name and produced this proposal. This version is an update to the
write-up I announced week ago on gentoo-dev, it incorporates some feedback I
collected.

Chris Johnson proposed slightly modified version of such system. You can find
details on it here:
http://relentless.org:8000/gentoo/forum/message?message_id=6584&forum_id=6581.


I am looking forward to the core group comments!

[Comment 1 Daniel Robbins (RETIRED) 2002-04-04 20:08:21 UTC]

Some neat ideas, and I get the idea of what you were trying to say.  I think you
summed up the problems well; still mulling potential solutions over in my head...

[Comment 2 George Shapovalov (RETIRED) 2002-05-13 22:24:25 UTC]

I have actually started some work on adding meet to the proposal.
Please take a look at:
http://www.its.caltech.edu/~georges/gentoo/epsp/update1.html
for an update. I have abandoned the idea to mangle the ebuild names (to add a
new aprt to it basically). Now the status information is supposed to be reside
in a separate file. Generally much more flexible approach and easier to code as
well :). 
Some code is supplied also. Please note that the code is in the *very* early
stage, more in the proof of concept area (and not yet finished). Submitting this
now to contribute to the discussion on the relevant topic on developer mailing list.

George

[Comment 3 George Shapovalov (RETIRED) 2002-05-21 18:40:26 UTC]

This is a code update.

I completed the part responsible for stability levels in portage. Attached are:
new version of estatus.py - the file that "does the job"
patch to portage.py against cvs version 1.149, (committed May 16, seems there
were no commits since then).
In case patch does not apply cleanly (against your version of portage.py) the
only significant chunk of additions should go to portagetree.domask

Changes:
I changed StabilityLevel var to be STABILITY_LEVEL to match make.* style. This
var should be set in make.globals and overriden in make.conf as usual. The
proper setting should be "new" until we add Status files to all packages in
portage tree.

George

[Comment 4 George Shapovalov (RETIRED) 2002-05-21 18:42:47 UTC]

Created attachment 1086 [details]
estatus.py - module providing ebuild status treatment

[Comment 5 George Shapovalov (RETIRED) 2002-05-21 18:43:47 UTC]

Created attachment 1087 [details, diff]
patch to portage.py to make use of estatus.py

[Comment 6 George Shapovalov (RETIRED) 2002-05-21 18:47:49 UTC]

I am using exceptions in this code. It just makes no sence not to inherit
estatus exceptions from PortageError! 
Thus this bug depends on #2328 and I mark the proper dependency here.

[Comment 7 George Shapovalov (RETIRED) 2002-05-21 19:03:06 UTC]

Created attachment 1088 [details]
sample Status file

to have the full set of relevant files I include sample Status file (should
probably end up under /usr/portage)

[Comment 8 Brandon Low (RETIRED) 2002-05-24 02:08:40 UTC]

This is great work!  Just want to chalk my number up in favor of this getting included in the next MAJOR portage release!

[Comment 9 George Shapovalov (RETIRED) 2002-05-24 03:00:29 UTC]

Thanks a lot!

But did you test the code? ;)
Please, please! :)
This is really small chank of code and a quick test.


Just in case, I'll repeat instructions which I posted to mailing lists here:

The code consists of:
estatus.py module that does most of the work
and patch to portage.py - portage.py.diff
Additionally, since the code uses exceptions for error handling and since 
portage_exceptions.py was not incorporated yet you will need that module too 
(portage_exceptions.py is in #2328 on which this bug depends).

portage.py resides in /usr/lib/python2.2/site-packages/, you should apply the 
supplied patch against it (should apply cleanly against portage.py-1.149 in cvs
and portage-1.9.12/13). Other two python modules should go into the same 
dir (or somewhere else where python can find them). File Status.skel contains 
explanation of the (very easy) Status file format.

After you did this you are ready to use new feature. Few words first though:
Since none of your packages have Status file available all your ebuilds will 
default to "new" status. Default setting for STABILITY_LEVEL is "approved", 
thus emerge will not see any ebuilds! To circumvent this you should set 
STABILITY_LEVEL="new" in your make.conf or make.globals (don't forget what 
you modify!). This should bring emerge functionality back to normal (all your 
ebuilds are "new" and you instructed portage to allow all ebuilds that are 
"new" or more stable). 

Now you can create Status file for some certain package and play with it by 
setting different combinations of flags described in Status.skel (and 
comments to the code). You can use this as an alternative to profiles, masking 
and even to create a sub-distribution, however the intended use is somewhat
different. 


George

[Comment 10 Brandon Low (RETIRED) 2002-05-24 07:42:37 UTC]

leaving for weekend trip to MarCon but I managed to do a brief look at the code
and some simple tests, looks nice... it would be nice if the words used in the
Status file matched more closely with what you say in make.conf
ie. 
perl-5.6.1-r4.ebuild confirmed new
perl-5.6.1-r3.ebuild confirmed approved

or somethign (just my 2 cents after 3 hours of sleep ;-))

[Comment 11 George Shapovalov (RETIRED) 2002-05-24 14:38:27 UTC]

Short note on the status switches.

They are different because, well, they are :). 
The setting in make.conf is an "aggregate" ebuild stability level, one of:
["unstable","new","confirmed","appr-new","core-new","approved","core"].
This is in a sense an "abstracted" stability level setting.

The Status file on the contrary contains more direct entries. At present it has
two columns to reflect two categories of users: general users and core
developers. This might be changed subject to appearance of compelling reasons to
do such a change.

Consequitevly setting in each columnt follows more direct and simple model:
every group can mark package as:
unstable, new (no), checked (yes) or core (this setting is reserved for
developers at present but it is trivial to modify code to make it available in
the second column).

How did I come up with yes/no? These follow naturally if you try to answer the
question "was the ebuild checked by that group?". I.e. filling the following table:

ebuild_name    Confirmed?   Approved?
PV-PR          yes          no            (for example)

Its just that yes/no seemed natural in that context. This is not a biggie, it
can be changed to be checked/new for example (for a full set of
[unstable,new,checked,core]). I would like to avoid using different identifiers
for the same settings in different columns (i.e. confirmed vs approved, I used
"ckecked" in both instead), this will make the code more complex for no good reason.
Please tell me what do you think?

Also I noticed you put full ebuild name in your example. Does this seem more
natural than ${PVR} part only? (I like to *not* duplicate information if that
can be avoided, - much harder to miss something in case of format change or some
other modification). Again, that would be a trivial change to the code. 

Thanks for taking your time to check this out ! ;)

George

[Comment 12 George Shapovalov (RETIRED) 2002-05-25 05:13:43 UTC]

Created attachment 1134 [details]
sample Status file (update)

updated Status.skel: added two lines of actual sample
(so its 99% comments instead of 100% now :)).

Note: Status file will most often contain only a few descriptive lines,
generally no more than there are ebuilds in the package dir.

[Comment 13 Markus Krainer 2002-05-26 03:36:50 UTC]

Hi!

As the original intention of this bug was to simply transfer testing of new
packages from the gentoo core team to the users, I think this could be
achieved much simpler.

Why not have a second file like package.mask e.g. package.new that lists all
new versions of an ebuild. Example content:

net-news/leafnode: 1.9.22 1.9.23
sys-devel/gcc: >=3.1

Now "emerge -u pkg" will treat this package versions the same way as if they
are masked (i.e. ignore them) but the user can force installation with 
"emerge --test -u pkg"

We can than encourage the user to "vote" for the ebuild (display a message when
using --test) or to make a bugreport if the ebuild fails. If there are enough
positive votes or no bugreports within a reasonable time, the package is simply
removed from package.new thus integrating it into the "stable branch".

  -Markus-

[Comment 14 Paul de Vrieze (RETIRED) 2002-06-10 03:53:10 UTC]

The status file is a good idea, I do see problems with old ebuilds though. What
does the system do when soneone doesn't do emerge rsync --clean, but just emerge
rsync an has a "stable" ebuild laying around that is removed from the status file?

A solution I see could be to use a removal delay, that is, a version approval
status is only removed after a certain time (say half a year). Another solution
would be to maintain a full list somewhere on the net and allow for on-demand
checking of versions older than the oldest ebuild in the status file. (Such way
no big load should be created)

[Comment 15 George Shapovalov (RETIRED) 2003-05-11 17:38:10 UTC]

Its still some time before herds proposal gets settled and implemented, nonetheless trying to keep this bug alive :).

An ineresting project came around, mentioned on gentoo-dev mailing list. See thread Ebuild Janitor project, by May 11, 2003.
Looks like it can fit nicely with overal idea of this proposal (naturally if it sustains, otherwise something like that can be set up when time is right..), throwing in my remark, so that it doesn't get lost.

In short, these are the forums set up for the discusion of user-submitted and user-maintained (until they get accepted) ebuilds. This should serve as a nice complementary to gentoo-stats/stable improving overal level of user-submitted ebuilds..

From the email:
" The way I see it, distributed ebuild processing requires:
1. some central depository with automated submission system doing at least 
some basic checks (multiple access/stability levels are already in portage, 
but that might need some further ratification)
2. strong voting/feedback system (think gentoo-stable/stats), looped back to 
ebuild level adjutment (some automatic some manual).
3.(new!) the way for users to be getting feedback on their ebuilds and be able 
to discuss related stuf with each other. Apparently best done in user-land, 
by the project such as the one you initiated. Should really do a lot in terms 
of increasing overall quality of submitted ebuilds."

George

[Comment 16 George Shapovalov (RETIRED) 2004-01-31 11:33:42 UTC]

A short note/update.

Recent VCS discussion on -dev made me notice and read an overview of version control systems on o'reilly. One of the systems - Aegis, seems to perfectly fit the bill for the "automatic processing of outside submissions" (well, apparently it was designed for a similar purpose) as it
"
. Manages automated tests, prevents check-ins that do not pass the previous tests, and requires developers to add new tests.

. Manages reviews of code. Check-ins must pass the review of a reviewer to get into the main line of development.
"

Plus this (from aegis site) might indicate scalability (the review article did not address scalability at all):
"Aegis supports large teams and large projects."

The review article is here:
http://www.onlamp.com/pub/a/onlamp/2004/01/29/scm_overview.html
osnews comments (mentioning few more systems) are here:
http://www.osnews.com/comment.php?news_id=5858&limit=no
and the Aegis project is here:
http://aegis.sourceforge.net/

[Comment 17 Brian Harring (RETIRED) 2005-02-27 21:27:45 UTC]

This should be glep'd and posted to -dev, and let them hash it out.
Pretty much, modding portage to identify the 'status' of the ebuild, 'k, doable.

The value of doing this, the resultant effects on QA, etc?  Well, not portage dev's decision.  So... bounce it to -dev, iron it out there (if they go for it), and then poke us with reqs if people agree to it.  Re-open based upon the results from -dev please- marking it WONTFIX now though, since like I said above, the changes required to the tree are a community decision, not portage-devs.

[Comment 18 George Shapovalov (RETIRED) 2005-02-28 00:15:11 UTC]

WTF was it closed while having a developer responsible for it by a dev not really related to the bug? 

Oh, btw, this has been discussed on -dev maany times, even few times on -core. Its been relatively quiet lately (well, like about another half year at this point), but we are not really there yet anyways. Gentoo-stats are lacking and any other voting system could not be agreed upon in prior discussions, infra involvement is not clear yet either, although the rest of the requested features are more or less there, with some tuning they should be useable for this purpose. But then, every half a year or so there is a blurb on -dev on how we or users could speed-up new submissions/bug squashing processing, etc; this bug is brought up and enough people seem to be interested in the idea.
So, in short, now it does not seem like a right time to push on the thing but I keep the bug as a reminder of the idea. This thing *will* go through redesine, discussions, glepping and further discussions when the time is right. Meanwhile if the portage team does not want to see the bug please just remove the alias from CC.
Reopening the thing.

George

[Comment 19 Alec Warner (RETIRED) 2006-03-10 10:52:58 UTC]

Removing portage as requested.  When this gets approved ( preferably as a GLEP ) please re-add us for implementation.

[Comment 20 Jakub Moc (RETIRED) 2006-03-10 11:55:08 UTC]

Bug wranglers are not interested in such stuff. Take this to mailing list.

[Comment 21 George Shapovalov (RETIRED) 2006-03-10 12:02:23 UTC]

Ugh, upstream is me, an active Gentoo developer, and I indicated that I would just like to hang on to this bug as a reminder. Why not reassign it back to me, instead of throwing it out to bug-wranglers? Now I have to reopen and reassign it. I'll post a reply to comment #19 in the reassignment action..

George

[Comment 22 George Shapovalov (RETIRED) 2006-03-10 12:03:38 UTC]

In reply to comment #19.

So, this circled around and finally got thrown out to bug-wranglers. What was the point in taking it from me in the first place? 
Well, admittedly I was almost tempted to have a fuzzy feeling when it got assigned to portage team :), but (sadly) I of course knew nothing would come out of it at this time, since, as I indicated, we are way off of making any practical use of this idea. Meanwhile I would just like to hang on to this bug as a reminder.. 
I added a tag to the subject to make the status of this bug (more) obvious.

>When this gets approved ( preferably as a GLEP ) please re-add us for >implementation.
First this has to be redesigned. A lot has changed since the original idea and brainstorming..

George 

[Comment 23 George Shapovalov (RETIRED) 2006-03-10 12:06:25 UTC]

Oh, forgot to add tags during this all bug bouncing. Adding now..

[Comment 24 George Shapovalov (RETIRED) 2006-03-20 16:24:13 UTC]

The original (updated) proposal has migrated to dev.gentoo.org (as proper).Please see this link instead of the one listed in original post:
http://dev.gentoo.org/~george/epsp/proposal.html

George

[Comment 25 George Shapovalov (RETIRED) 2006-03-20 16:40:28 UTC]

(In reply to comment #2)
> http://www.its.caltech.edu/~georges/gentoo/epsp/update1.html
has relocated to 
http://dev.gentoo.org/~george/epsp/update1.html

In general just substitute 
http://dev.gentoo.org/~george
instead of
http://www.its.caltech.edu/~georges/gentoo
to get to the relevant files..

George

[Comment 26 Tom Wijsman (TomWij) (RETIRED) 2013-03-15 12:35:20 UTC]

Do the problems stated in this proposal still apply today?

Does it refer to actual practical problems we still have?

I think not.

> Limited set of people are responsible for ebuild review. ... it breaks when the system becomes large and/or ebuild submission rate grows above some limit

Only a limited set of people have the necessary knowledge to bring an ebuild up to Portage standards; widening up this scope to much more people is a bad idea since they will suggest hacks and approve ebuilds (we see this happen on #gentoo-dev-help, for instance) that aren't up to Portage standards. Furthermore, adding more non knowledgeable people will also just stall it more; see The Mythical Man-Month about this.

But we don't actually need to refer to such thing: Has the Portage ever failed us in this way with the amount of ebuild requests we have after this many years? I think not. If we're going to increase the rate at which they enter the Portage tree without increasing the rate at which we recruit Gentoo developers, this will just introduce breakage in the Portage tree; better have a maintainable tree, than having to deal with all the not maintainable stuff that enters it.

I don't see this as a problem.

> That same limited set of people has an absolute authority over ebuild processing. ... However in order to alleviate previous problem and keep the same system structure it becomes necessary to involve more and more people into the core group and at some point it becomes unmanageable (as core developers have to be extensively "trained").

They are educated for this purpose, why not? In a similar vein, the council has an absolute authority to vote on matters as well, because they are the most eligible to know what is good for Gentoo and what not.

This isn't really a problem statement, it broadly uses the terms "system structure" and "unmanagable" but doesn't go into details of it; and seeing how well the training went, I don't think there's too much effort to that.

However, the next sentence does have a better point which points out "trained manpower" sounds like a bottleneck:

> Strict centrally controlled structure works nice for small system but does not scale when system grows.

But, for the large scale of users compared to Gentoo developers, I think the sunrise project already really solves this well. It serves as a mass training of users, ebuilds that are up to standards and can be merged into the Portage tree once they are reasonable; so, I don't see how this proposal is currently still addressing a current actual practical problem.

Therefore, I suggest this proposal to be revised or this bug to be closed; if nobody has a reasonable objection, I'll ping the ML in two weeks from now about it for input and if there is again no reasonable objection we can then close the bug two weeks after that.

For those who wish to revise it, please clearly state...

1. ... which current actual practical problem this proposal is addressing.

2. ... why the sunrise, ebuild janitor and other projects don't solve this.

3. ... a practical abstract idea that could possibly resolve this.

Without a concrete proposal that doesn't reflect the current day, I don't see why we should keep this bug around for much longer...

[Comment 27 Pacho Ramos 2016-05-21 15:59:47 UTC]

this mess of random ideas is probably obsolete now and, for pending stuff, it should be reported in one bug per issue and assigned to the people willing to do the work