Re: [gentoo-dev] Project Sunrise thread -- a try of clarification

[Chris Gianelloni]

On Fri, 2006-06-09 at 10:28 +0200, Patrick Lauer wrote:
> On Thu, 2006-06-08 at 20:06 -0400, Chris Gianelloni wrote:
> > > You don't need a subversion client, you perhaps notice the http in front
> > > of the url.. just open it up in your browser and you get the source
> > > immediately.
> >
> > Umm... so now I need to go and instead of clicking a nice link in
> > bugzilla, trawl through the subversion repository and find what I'm
> > looking for?  How exactly is downloading things via http any different
> > than downloading them from bugzilla, which is also http?
> just my point of view -
>
> bugzilla sucks. Ever had to download 10 attachments for one ebuild?
> It is a good tool for discussion, but I would prefer a simple tool (like
> layman) that can automatically update things. You obviously don't like
> overlays, but that shouldn't be a reason to stop us from using it.

Well, I thank you for your vast experience as an ebuild developer in
this matter.

You do realize that this isn't one of those things where you can say
that if you don't like it you don't have to use it, right?

This *will* affect *every* ebuild developer.

This means it *CANNOT* be left up to a small group of developers to
decide without any discussion on the matter.

> > > Or, if you want some history like sources.g.o, you can do so as well here:
> > > http://overlays.gentoo.org/proj/sunrise/browser/
> >
> > Excellent.  So we're moving the history from being in a single location
> > (the bug) to being in multiple locations.  That will definitely improve
> > the development process.
> Yes, now it is easier to check out the ebuilds. More users ==> better
> testing.

Except that now the developer has to do much more work to get the same
information, making it even less likely that he'll bother to pick up one
of these maintainer-wanted bugs.  You also completely gloss over the
ability of a single rogue user to now compromise countless users with a
single commit.  Please come back once you've firmly grounded yourself in
the reality that we're a pretty popular distribution, and that makes
this project a prime target for malicious abuse.  Perhaps if you were
responsible for some ebuilds, you've be more cognizant of the
implications that a bad commit can cause our users.

> >   No offense, but everything I have seen looks
> > as if it will add even *more* overhead to actually getting packages into
> > the tree.  The only thing this seems to provide is a half-baked
> > repository for the users to get marginally-tested ebuilds for software
> > that wasn't interesting enough for inclusion in the tree.
> That differs from the 20 or so overlays maintained by users how?

Let's see.  They aren't on Gentoo infrastructure, which means they don't
give off any immediate assumption of being "official" or "supported" in
any way.  Hell, go back and look at Peter's response about how he would
use an overlay such as this only *because* it is on Gentoo
infrastructure.

So what exactly was your counter-point again?

> Honestly I'd prefer an overlay where I can marginally trust the content
> over a "foreign" repository maintained by people I don't know.

Having an overlay such as this will tarnish Gentoo's reputation.  We
should not be providing *anything* that is only half-supported or
half-tested.  Anything less than being sully supported via the security
team and QA is a failure on the part of Gentoo.  We have enough *crap*
in the *tree* that is unsupported, which makes us look bad, yet you want
to insist on supporting a project that affects all of the ebuild
developers, which you have not mentioned is a group which you are not a
part of, so can gladly speak of increasing their workload with no
consequences to yourself, and provides an avenue for low-quality or
possibly malicious ebuilds to be distributed to our users, all under a
Gentoo banner?

I seriously question your motives towards the Gentoo project.

> Hmmm ... bugzilla.
> Instead of a simple cvs up; cd /usr/local/portage/category/package I
> need to search for ALL bugs with $name in it, look which one it is,
> curse bugzilla for falling asleep again, see which attachments are
> relevant, download them, curse bugzilla for falling asleep again, copy
> them to my overlay, read the bugcomments to see if any special renaming
> or directory structure is needed ...
>
> Hmmm. I think an overlay does have some advantages there ...

Sure.  Until I sneak in some obfuscated code as a "fix" to a "bug" and
it gets executed on your machine because the actual *developers* that
are used to maintaining this stuff and know what to look for aren't a
part of the process.

Making something easier does not make it better.  I'm sorry, but you've
yet to convince me on how your laziness is supposed to be an improvement
for the development process of Gentoo.

> > Again, read what I wrote.  I said that the developer would see "sunrise"
> > in the PORTDIR_OVERLAY of the user's emerge --info, which you reiterated
> > without considering.  This is a login bug.  At no point did they make
> > mention of having installed pam_skey from this overlay.  This means that
> > I, as the developer getting this bug, am now responsible for looking at
> > *every package* in the sunrise overlay to determine if *any* of them
> > could *possibly* be affecting this package or causing this bug, then
> > asking the user if they have any of them installed.
> This differs from a manually patched ebuild in /usr/portage by virtue of showing you that an overlay is used ...

Wow.  Another one of those "I can't answer your issue, so I'll just try
to divert your attention somewhere else" answers.  Thanks for absolutely
nothing but contributing noise.

> > Wouldn't this process be *infinitely* easier if instead of "sunrise"
> > there was a "pam" overlay with *only* the pam stuff?
> Ooooh, cool. Now I need about 75 overlays to get things done, and of course there will be no bad interaction between them ;-)

As opposed to the free for all that is this overlay?

> Having one overlay with a focus on not-in-portage ebuilds should not
> cause the scenario you described and will most likely cause less weird
> bugs because of intra-overlay dependencies.

What evidence do you have of this?

> </opinion>

Oh, right.  None.

> > That is *exactly* what we get with the other overlays like php and
> > vmware.  I *know* that if I'm looking at a glibc bug and the user has
> > "php" as an overlay, that it isn't going to be a concern.
> ... and if we control the overlay we can exclude things like system
> packages easily.

You really do a good job of making attempts to skirt the issues.  Do me
a favor, if you're just going to use vague references and try to avoid
answering the issues at hand, don't bother wasting everyone's time by
replying.  You're more than welcome to provide some *useful* insight,
but simply stating that something won't be an issue doesn't make it
true.

> Could be part of the policy to not touch existing ebuilds.

Actually, it already is, according to jokey.

> > This is a prime example of totally glossing over any discussion to make
> > it sound promising for you.
> If bugzilla wasn't so sucky people wouldn't try to use other methods of
> communication ;-)

Except this isn't another form of communication, nor is it being
presented as one.  Do you even bother to notice what you're writing?
How exactly is a bunch of ebuilds in an overlay a "method of
communication"?

> And again, one svn repo vs. 113 hard-to-find bugs ...

Amazing how you pull such numbers out of thin air.  Which 113 bugs are
you talking about, exactly?

> >  Even better, if I am the proxy
> > maintainer for a particular set of ebuilds for one or more
> > user/maintainers, why do I need it in your big, bloated, and completely
> > inappropriately-named "sunshine" overlay versus a developer overlay of
> > my own?
> You don't. Please use your developer overlay. Please don't try to take
> away our more open overlay.

Unfortunately, your request for my dropping of this issue will not be
honoured.  This overlay is a bad idea, that is being poorly executed,
and is being *forced* on the developer community at large with
absolutely no for-warning or planning.  It really is a shame that we
don't have any policies that allow for action to be taken against people
who either knowingly, or through actions of ignorance, cause massive
damage to Gentoo such as this.

> > After all, I am the *only* proxy maintainer.  Why should there
> > be the added *insecurity* of allowing any number of people that *I*
> > might not trust complete access to the small number of packages where I
> > am the proxy?
> It's your choice. Either you get mailbombed with each minor version update or you trust them to not screw up with the sunrise overlay.

Isn't that what the process of becoming a developer is supposed to
build?  Also, just because I trust one person, doesn't mean I trust
someone that you trust.  Trust is not implicit, it is earned.  Some
random user having complete access to an area where only people that *I*
trust should really have access is not instilling faith in me of this
project.  However, instead of answering these concerns, you simply brush
them aside as a non-issue, though I am not the only developer that has
spoken out on this *exact* same issue.

> And the users could just create their own overlay, get it added to
> layman and we'd have the same without supervision. From where I'm
> standing it's better to have the possibility to nuke a bad ebuild in the
> overlay instead of asking some random user to change this in that
> overlay because of $problem.

Why exactly are we supporting these overlays via layman anyway?  That
implies a level of trust and support that you admit we do not have.  I
guess I should touch on that subject next, but that doesn't belong in
this discussion.

> Maybe we even find some motivated new ebuild monkeys that have the
> motivation to become devs ... one can always hope :-)

...and maybe we get owned and people quit using Gentoo because a few
developers decided to go against the advice of other developers and
allowed for an easy-access, easily-exploitable way for some malicious
user to own countless Gentoo boxes, and nobody did anything to stop it.

Well, I am going to do everything within my power to stop it.  I will
not back down until this project is dead.  It really is that simple.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux