First off, I would like to apologize to everyone who has to read this thread. I know that it is long. I know that it can be frustrating. That being said, I also ask for your patience in this matter, as I am not going to back down on this. I will not roll over and let something I see as this damaging to Gentoo simply happen.
Also, since it is obvious that some people are trying to deflect attention away from the actual issues, I will likely not respond to any points that I don't consider to be relevant. I'm not wasting my time, nor yours, with this garbage. Some people seem to not understand that this is not *only* a technical problem, and therefore cannot be discussed on a purely technical level. Some people also think that by comparing someone to a certain ex-developer, that they're going to either win some traction or cause their opposing side to give up. This is not the truth, at all. If it has done anything, it has *fueled* me to fight this "project" even more. On Fri, 2006-06-09 at 23:54 +0200, Patrick Lauer wrote: > On Fri, 2006-06-09 at 16:14 -0400, Chris Gianelloni wrote: > > > Since when was overlays.gentoo.org supposed to even be a service to our > > users? As I understand it, the goal was to ease development, not to > > provide an easy method for half-working ebuilds to make it to our user's > > machines. > > What's the point of development if not to help users? Umm... perhaps to create a *product* that gives usable software to users? How about a little history lesson? Not so many moons ago, new ebuilds were submitted to bugzilla. The bug wranglers would assign the bugs to the team most likely to end up as the maintainers, and new ebuilds either made it into the tree, or sat in bugzilla until the interest was there for it to be added, if ever. Some people felt that this process left lots of packages in bugzilla, with no one to watch over them. Because of this, the maintainer-wanted, and maintainer-needed bugzilla accounts were created to assist in tracking these bugs/packages. This was a good idea at the time, and worked fairly well so long as there were developers going through and actively searching for bugs, that were no longer assigned to the relevant teams, but instead, assigned into some big dumping ground for new package requests. This process failed, as visibility for new packages was reduced to the teams that would likely be doing the actual work. Now, instead of reverting a broken and failed process, a new project is being created in an attempt to fix the problem. Unfortunately, it has been pointed out that this will introduce an even larger set of problems, but that is not being addressed very well. > Everything we do should be done to help users (and worst case we help > that small group of users that are devs). I would have to absolutely disagree here. Gentoo's resources should be spent helping developers do their work more efficiently. This provides a positive end result of users getting more and better software. If we simply did everything for the users, then we would have every single kernel source tree done by a few guys with little understanding of kernel internals, we'd only ship a stage1 tarball, and reiser4 would be our default file-system, stability be damned. > > > > 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? > > > > Anything this abhorrently stupid doesn't need a vote. > Bullshit. > If you need to resort to insults you failed to show on a technical level > why it is bad. I have already shown that this is a piss poor idea on a technical level. I don't think I need to reiterate this again and again, but just for you, since you're not catching on, I'll do it one more time. This is an attempt to fix what is a social problem with a technical solution, where one doesn't fit. What problem is this project trying to resolve, exactly? How will creating a secondary "official" (hey, it's on *.gentoo.org) portage tree help in creating a higher-quality primary portage tree? How will a small team maintain the security and reliability that Gentoo has come to be known for in a secondary portage tree without the support of a security team, or the architecture teams? Why was this not discussed on the developer mailing list before being publicly announced to the world as if it were a complete and working service, with all of the issues worked out? Now, (sorry Flameeyes) let's look at another scenario. A new user to Gentoo decides that he absolutely *must* have package foo. He reads on the forums that package foo is in the Sunrise overlay, so he uses layman and syncs up the overlay. Three weeks later, he decides that he wants pam_skey. He does a search, and there it is! He installs it. This user is not even *aware* that the package came from the overlay. He has a problem. He files a bug. Guess who gets it? Remember, that he isn't likely to mention project Sunrise, or pam_skey, since he doesn't think it is relevant. The bug wranglers will see Sunrise in his overlays on emerge --info, but will have *no clue* what packages he has installed from this overlay. How is this helpful again? > Either it stands on its own or it dies from lack of interest. You completely avoid the point where it is possibly damaging to Gentoo's reputation and community. > I think what is more damaging to the reputation of Gentoo is the > incessant discussion of ideas before they are even tried, killing many > good things before they even have a chance on a technical level. You cannot band-aid a social problem (the lack of developers/interest) with a technical solution. > > Yes, we are *so* lagged behind everyone else. Where do you come up with > > these "facts" anyway? I'd like to visit this mythical land. > Like, gcc 4 ? Gentoo is lagging behind most others (because our QA has grown > from non-existant to really really good) Let's see. We have GCC 3.4 stable and 4.1 in testing. How about some other guys? Red Hat Enterprise Linux: GCC 3.4 (No testing branch) Slackware: GCC 3.3.6 (3.4 in testing) Debian: 3.3.5 (4.0 in testing) Suse Linux Enterprise Server 9: 3.3.3 (No testing branch) Suse Linux 10.1: 4.1 (No testing branch) Ubuntu: 4.0.3 Fedora Core 5: 4.1 Mandriva: 4.0.1 (4.0.2 in beta) Linspire: 3.4.3 Now, I don't see a whole lot of GCC 4.1 in people's stable trees. I guess that makes us pretty much on-par with some of the other guys, doesn't it? Please, if you're going to use something as an argument in your favor, check the facts, first. > It's called diplomacy, it's the thing you usually do instead of bombing > countries back into the stone age. (A side bit of humor...) I'm an American. We don't *do* that. ;] > > Like the hardware I've donated on multiple occasions? > Good to hear. Don't turn it into a pissing contest, I'm just a poor > student, so you can outspend me any day of the week. You're right. This doesn't need to become a pissing contest. My only question is this. Why in the hell did you mention how you spend money for this sort of thing if you didn't want it discussed? It's one of those things that really shows you don't want to have a discussion, but instead are trying to redirect away from the issues at hand. > > Spending a few dollars doesn't make you anything more than a monetary > > contributor. It doesn't buy you any respect. It doesn't buy you > > anything. > Except that all of Gentoo Infra is donated. Are you saying that we don't > need any of these donations? Hey, tell OSU that we don't need their > support. Again, stop with putting words in my mouth. It really makes you look like an asshole. > > How exactly is it easier to manage a large number of ebuilds versus a > > small number? > It is easier to manage one large overlay than managing 35 small overlays. > Communication overhead, duplication of effort, ... Is this not *exactly* why there is a project for managing these overlays? > > Huh? You mean the ones that expect us, as developers, to have their > > best interests in mind and to not allow poor-quality and potentially > > hazardous ebuilds to hit their machines? The same ones that trust us > > with the stability of their machines? The same ones that choose Gentoo > > because we're the best, not because we have some dumping ground of > > barely-wanted packages? Yeah, those users... > You might want to differentiate between user groups ... some want breakage. > Must be some special masochism, but they are using CFLAGS and overlays that > are really whacky. But if that's what they want to do I'm not going to stop > them. > I'll try to convinve them that what they do is not right, their problem > if they don't listen. No offense, but of course you aren't going to stop them. You are not an ebuild developer. You don't have access to the portage tree, and you don't actually support the users. You aren't a bug wrangler. You aren't responsible for working through bugs in *any* way. I tend to think that Gentoo, as a whole, is trying its damnedest to move away from the ricer reputation that we had of old. We don't *want* breakage in our tree. We are no longer a toy for a bunch of developers. We are a serious distribution, capable of being used in the enterprise. Adding additional overhead to get in the way of real development and causing more breakage than we already have is *not* a way to grow our distribution or make it better, it is a way to stifle it and kill it. > No, it is you doing a ciaranm on me by trying to force me to discuss > tangential issues, wrap me in two layers of confusion and then you do what > you wanted to do from the beginning anyway. Ahh, yes, the ciaranm defense. What next, the Chewbacca defense? > I think it was jokey who pasted an email from a user who just wanted to > maintain his two packages without the full become-a-dev stuff, including > reading huge flamewars on mailinglists and other non-productive issues. ...and? You haven't proven any points here. You've merely restated something that was said before. How will this help the individual in question maintain his package in the portage tree, or get it included in the portage tree? Will it not still require a proxy maintainer to take interest in the package and actually commit it to the tree? Will this proxy maintainer not need to be notified when new versions of the package/ebuild are created? How is getting an email stating to "go check out the subversion tree for a new version" end up being that much quicker than an email that says "attached is a new version of the package"? Either way, the communication must happen. > > > > 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 :-) > > > > Again, you decide to point out something that is only somewhat related > > and try to use it as a proving point for your position, when it really > > bares no real relevance. > It does. Excellent counter argument. Let me try. "It doesn't." Bravo! Go me! Now, how about I try it for real. I have faith in the Gentoo recruitment process to try to weed out some of the less than skilled users, who would like to contribute, but either don't know how or simply don't have the necessary skills to do so. While I might trust a small subset of users that I personally have spoken with, or one of my trusted associates has spoken with, I do not inherently trust every user who has submitted an ebuild to have access to make changes to a repository where my trusted users are working. Remember now, I trust the recruitment process to weed these people out. What will *this* project do to provide the same level of trust? -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux
signature.asc
Description: This is a digitally signed message part
