Re: [gentoo-dev] A heretical thought? Blessing project sunrise as an almost-fork.

[George Shapovalov]

I don't think this (the general idea) is a heretical thought, in fact it was 
around for quite some time. See #1523 for example, which actually came out of 
a similar thread back ?5? years ago.
(There were no GLEPs back then, for those of you who will wan't to go "why 
this isn't it glepped?" :). There were no overlays, even no KEYWORDS back 
then either, so be carefull if you read it - it is quite outdated (half of 
what is discussed there is already implemented in fact) and uses old 
terminology.)
But then I agree about many issues raised regarding the Sunrise project. The 
way it is pushed will not offload anything off the developers and is quite 
likely to do quite the contrary..

The main issue:
to make it fly and really make something useable (supported by users, *not* 
taking devs out of the loop and *not* loading them any more) one (at least) 
ingridient is missing IMNSHO. That is: some ranking system - for the ebuilds 
*and* for the users. It was referenced as voting system in that bug, we also 
had gentoo-stats project (now like what, 4 years ago?) which was not quite 
the same but addressing similar and more immediate issue.

This part of the process (the rankings), taken as an "entity in itself",  is 
not that straightforward (meaning a significant tossing of the design ideas 
would be necessary) and the benefits are not that vital. I think these were 
the main reasons it did not take off as a standalone project (e.g. 
gentoo-stats was restarted a few times, but eventually died). While it is 
nice to have some idea of package usage (which was the main goal of 
gentoo-stats) or get some fuzzy feeling on "I (user) rated holier than thou 
because of my superior ebuilding skills" (voting process in that bug), these 
are clearly not enough to create something sustained. And I am not talking 
about ethics here (this is re: ratings for users - this was actually 
mentioned a few times, so I'll address it right now). A general rule - if 
something is perceived worthy it will be done, no matter how unethical. Even 
if we (the devs) would ban this, nothing stopped the users to create 
something similar on their own (who knows, based around BMG, forums or 
whatever). The fact that this did not happen IMHO illustrates pretty well 
that this is a no-fly thing on its own.

On the other hand I think that just opening up the barrier and allowing users 
to easily bring stuff in is just the same no-fly-by-itself thingy. The 
reason: you have to provide some control over quality or you will get another 
BMG, and my understanding is (the Sunrise thread was pretty long, so I cannot 
be totally sure :)) that that was generally accepted. Now, we have two ways 
to add control:

1. Involve devs, directly or indirectly - this is what Sunrise is proposing 
and many devs strongly object. 

2. Involve users and leave it on their side. There were a few words said about 
how users would take care of it all, but I did not get a clear idea of a 
workflow..

First on #1. 
Sunrise proponents basically say: "we will take care of it all, nobody needs 
to care". Many devs object: "as long as it has anything-gentoo in its 
name/affiliations we *will* feel the consequences and *will* have to care". 
(and now Sunrise poeple basically said that without gentoo in affiliatio it 
is pointless). 
To that I'll add that in any case, bacause of the scale, there is just no way 
Sunrise people themselves are going to be able to keep up. Even if their 
involvement is reduced to the very basic stuff. (This was implied or shortly 
noted in some replies, but I wanted to clearly restate it now..)
But then, involving users without clear workflow and QC will just create 
another mess - "just another BMG" as some people called it.

So, here we go, its number 2 and it requires some structure.
The most fluid one I can think of is a rankings system. For the packages 
(based on reviews of the code, emerge success, usage testing. Can be a 
compound parameter or multidimentional. That bug has some details, but not 
much of those - needs serious redesign I'd say to bring it to present from 
the past..)
and for the submitters/editors - based on the ratings of their submissions 
perhaps (the most straightforwards one), possibly on a few more factors.



So, to summarise:
1. I do agree that in general that (ease of user-side care) is a good thing, 
however this requires (quite) a bit more work than just setting up an 
overlay..

2. (at least) two things - the ease of submission/access to packages and 
QC/ratings are quite tied together and have to be designed/implemented at the 
same time. (And there is some empirical evidence to back this up - BMG and 
gentoo-stats for one) .

George

вівторок, 13. червень 2006 18:10, Grant Goodyear Ви написали:
> Over the years we've had a fairly consistent stream of suggestions that
> we should open up the e-build maintaining process to users instead of
> just devs.  The main arguments against it are the security issues and an
> expectation that it would add to developer workloads.  The former is
> certainly a real problem, although signing (assuming a reasonable
> web-of-trust) could mitigate that some (at least we'd know who to
> blame).  The latter, however, is conjecture, and the only good way to
> verify it would be to actually try it and see what happens.  Oh, and
> there's also a very real fear that if things go horribly wrong, that
> Gentoo's reputation would suffer quite badly.  Perhaps I'm naive, but I
> tend to think that if we were to advertise project sunrise as
> experimental, temporary, use-at-your-own-risk, and
> might-break-your-system, and even put it on hardware without a
> gentoo.org address and add a portage hook that warns whenever the
> project sunrise overlay is used, then our reputation isn't really likely
> to suffer even if it's a complete disaster.
>
> So, Chris, what have I failed to address that would make this a really
> bad idea?
>
> -g2boojum-

-- 
gentoo-dev@g.o mailing list