On Fri, 2006-06-09 at 12:20 -0400, Chris Gianelloni wrote: > > 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.
My pleasure. I'd rather see myself as poweruser in this regard since I try not to break too many ebuilds ... > 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. Maybe you don't realize that taking ebuilds for packages that are _not in portage_ and providing them in a nice bundle does not affect every developer? Noone wants to push a new cvs-snapshot of glibc. That so not the point here. But having a controlled managed overlay with ebuilds that are now spread all across bugzilla ... that would be a good service to our users. > This means it *CANNOT* be left up to a small group of developers to > decide without any discussion on the matter. So now we're a democracy where everything needs to be voted upon? *sigh* Let's leave that debate for another day ... > > 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. s/the developer/I/ there are some devs that would prefer this overlay environment. Please don't push your personal preferences as The Right Way (tm) > You also completely gloss over the > ability of a single rogue user to now compromise countless users with a > single commit. And an ebuild on bugzilla has more security? We're just making it easier to use these ebuilds. Also I expect the maintainers to keep a reasonable quality standard. > 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. I am not responsible for ebuilds because I don't trust myself enough :-) That doesn't stop me from giving out access to my server to anyone who has a good reason ... like the Gentoo/HURD repository or the Java overlay. > > 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? We have control over sunrise. And hey, if it sucks kill the project with silver bullets, a stake to the heart and two pounds of garlic. Just don't kill an idea before it is even tested ... > Having an overlay such as this will tarnish Gentoo's reputation. No :-) What reputation are we talking about? The distro that lags in updates behind others? Where you see a problem I see potential: More well-tested ebuilds, recruiting potential developers ... if you don't want that you're an elitist bastard. ;-) > 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? No :-) 1) It doesn't increase your workload - these packages are things that are _not_ in the main tree. No overlap --> no stupid bugs with overwritten ebuilds etc. 2) low-quality? I might mention that I'm hosting some overlays that have non-gentoo contributors (*gasp!*) Why are they hosted on my server? Because the contributors are not (yet) gentoo devs, but provide good to excellent input to the projects. So now you tell me that I'm doing wrong in helping Gentoo development? These people can't contribute to other gentoo-hosted projects, so it is easier to move the repositories to a more liberal server. That tells me that Gentoo development is fundamentally buggy when we complain about a lack of manpower and then say "yeah, but not _that_ kind of manpower" when users try to help. <cynic> And people wonder why usually things get done secretly and then presented as a finished product - no wonder, it seems to be the only way to get _anything_ done. </cynic> > I seriously question your motives towards the Gentoo project. Good. Question them. I'm still doing what I can to help ... doing such silly things as finding new servers for Infra and writing articles for the GWN. If that isn't good enough ... well ... who cares. You invest as much as I do in your own server for Gentoo usage and I'll not question _your_ motives. > > 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. It's all about trust. Those people that suck ebuilds out of bugzilla now will use the overlay. Same potential for damage in a slightly different package ... > 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. Less work --> more time to do interesting things. And just because you don't like overlays doesn't mean we should remove them. Heck, I really really dislike Gnome, but I'm not going to petition for removal just because I don't like it. Remember that "Gentoo is all about choice" discussion that pops up every now and then? If a motivated group of devs wants to try an overlay experiment you should let them try. Worst case it's a failure and gets punted after two months. > 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. You know, I've met you at FOSDEM and I know that you don't mean this as an insult, but it is very easy to misread it as that. Might I suggest that you don't formulate responses in a way that can easily be read as a personal attack? > > > 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? It's easier to manage one big overlay - at least that seems to be the motivation for doing it. And if we're all mistaken we at least learn a valuable lesson. > > 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> It helps if you keep things in context > Oh, right. None. That's why I wrapped it in <opinion></opinion> tags. If we knew the answers we wouldn't need to discuss things ... > > ... 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. And you are trying your best to make me look like an ass. Please stop doing that, it makes discussion really hard. Keep to technical issues. The issue is: This overlay will _not_ contain BreakMyGentoo-style ebuilds of new versions of things in portage. There won't be a glibc cvs snapshot. Just ebuilds that for now live in bugzilla and are hard to find. We wish to provide them in an easy-to-use package to our users. You know ... users. Those people that are not devs. Some of us try to give them the best experience we can, and if there is something like an overlay that even the more n00bish users can use we should try to provide it. > > Could be part of the policy to not touch existing ebuilds. > Actually, it already is, according to jokey. Even better! > > And again, one svn repo vs. 113 hard-to-find bugs ... > Amazing how you pull such numbers out of thin air. It's a special talent. 47 <-- just for you > Which 113 bugs are you talking about, exactly? Try to find the relevant files in the three bugs jakub posted. Now try that for multiple packages ... Most users won't need to harvest 113 bugs, but I'd prefer a "svn up". It's just so much saner and less work that it is hard for me to see how bugzilla even makes sense. > > > 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. That is weird, but you are entitled to your opinion. > 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. That is your opinion. I think it's a good idea with a best-effort execution. And noone is forced to do anything - all that data is in bugzilla already. > 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. Define damage - I see your efforts to keep a motivated group of devs from implementing a new and untested idea as damaging. But I can accept that - you have a different point of view. Would be boring if we all agreed. > > > 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? That process that many people consider too complicated and time-consuming? Not everyone wants to spend 20h a week on Gentoo. Some people just want to maintain their personal app for Gentoo. In some cases we already have proxy-maintainers, so I don't see why we should not try to find more motivated smart users to help. > Also, just because I trust one person, doesn't mean I trust > someone that you trust. Trust is not implicit, it is earned. That's why most Gentoo devs can have an account on my server. Except those that have told me directly that they don't like me :-) > 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. The difference between a random user and a dev often is not much more than an @gentoo.org email adress. I don't consider all users untrustworthy - if they show that they wish to help we should not sabotage them. Maybe you don't remember the time when you were "just" a user? > 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. We support them because a dev or a group of devs decided to do it. As long as Gentoo doesn't have a BDFL this will happen ... and if you don't like it discuss it with the relevant person(s). Maybe they are willing to change things? > > 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. If someone wanted to exploit boxen he'd use a much simpler attack vector ... our rsync mirrors are wide open. No need to secure the little window over there when the front door is open ... > 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. Ok, that seems counterproductive to me, but if you are not willing to compromise it will be hard to have any communication at all. Instead of trying to kill this idea you should try to get it modified into something we all can agree on. take care, Patrick -- Stand still, and let the rest of the universe move
signature.asc
Description: This is a digitally signed message part
