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
signature.asc
Description: This is a digitally signed message part
