On Sun, Nov 23, 2014 at 6:45 PM, hasufell <hasuf...@gentoo.org> wrote: >> >> As long as you actually commit to maintaining the Nethack package, you >> can do this. >> > > As above: I think it's wrong. >
Your opinion is noted. Your argument was that policy issues were preventing you from fixing Nethack. Now you're simply choosing not to fix Nethack because you think that the problem was fixed in the wrong way. You're welcome to not fix Nethack if you don't want to fix it. However, it is a bit disingenuous to talk about barriers to fixing things when they're self-imposed. > > I have offered one right now, including > * changes to the project structure (shrinking the amount of devs, > concentrating on the core, base-system, toolchain, PM) Nobody is going to deny devs entry to Gentoo in the absence of a working alternative. That just seems like a non-starter. Create your grand new vision first, then you probably won't have to convince everybody else to abandon the status quo. > * changes to the culture (REVIEWS, not random push access) > * changes to the policies (themes overlays, how to split overlay etc) > * changes to the tools (pointed out some specific things that are > already implemented in paludis) These are all things I support. > It's not just about "then work on it" if it's a cultural, organizational > and technical change at once. Sure it is. That is how things get solved. Your proposal amounts to basically forking the whole distro. You can do that if you want. We're not going to force it to happen by kicking all the current devs out. > The first step is NOT randomly implementing or changing things. The > first step is to discuss, find people who think similar and see if this > is even a thing we CAN move to. No argument, and I fully support that discussion. I just don't care for the "sky is falling" atmosphere. >> >> What is the difference between 1 million repositories on 1 million >> rsync servers and 1 million subdirectories on 1 rsync server? >> Administratively there is a difference, of course, but in terms of >> capability there is actually no difference. They're just different >> namespaces. >> > > Then we should merge all upstream packages automatically into the CVS tree. As I said, administratively there is a difference, and technically there is not (in the sense of technical capability). That is just as true about forking every single upstream project we have and sticking it in CVS. That would actually work just fine technically. It just would be a horrible mess to administer. >> >> It is just incredibly demotivating, and completely unactionable. If >> somebody a month ago gave you some misinformation about Nethack, I >> can't fix that. I gave you the correct information above. >> > > Yes, it IS unactionable, because there is no consensus whatsoever. I > find it funny that people want to push me into the "go open a project > and shut up" direction. > > Don't really expect me to push long for this. I don't need burn-out. > > I am just pointing out the idea and waiting for interesting feedback > (majority wasn't). I'm all for improvements. The part that is demotivating is pointing to past problems that are solved and arguing that we still need to solve them. Then talking about non-specific problems that need solutions, without giving anybody an opportunity to solve it in any other way. It is just unfair to everybody to argue in this way. Suppose I claim that Gentoo has horrible problems, but it will all be fixed if everybody mails me a check for $10k. What are those problems? Well, they are cultural problems. They're really serious. They're making people quit! Who specifically is quitting? You're focusing on specifics, and I'm trying to fix the big problems and not the little instances of it. Just send me that check for $10k. I ask for specifics because as a Council member it is my duty to try to deal with problems. When you claim that there are problems not getting solved, but refuse to provide the necessary information to allow the problems to be solved, then it is basically an argument that I'm not doing my job and you're dissatisfied, but you simply don't trust me to actually fix things. I realize that is personalizing things a bit, but it is demotivating all the same. I fully get that your intentions are good. I'm not disputing that. However, you're proposing revolutionary solutions that are unlikely to be embraced wholesale when having a long-term goal with incremental steps for getting there would be far more constructive. > >>> >>> Again: there are various people who have a different concepts of how >>> games in gentoo should look like. So we can either start breaking tree >>> consistency (and I hope QA will kickban us for doing so, because that's >>> exactly their job) or we just stop doing everything centralized and let >>> things happen... which concept is the most popular one will then turn >>> out by itself! >> >> The council already said that games do not need to be in the games >> herd. It is not within the QA team's discretion to decide otherwise. >> >> BTW, about nethack: you can have a package named nethack2 if you >> want. I can add another one called nethack3. GLEP 39 specifically >> states that projects are allowed to compete. >> > > "The Gentoo Quality Assurance Project aims to keep the portage tree in a > consistent state." > > As I said: I don't think that GLEP makes a lot of sense. And I will > neither introduce competing eclasses, nor break tree consistency > randomly. The user will have major problems finding his way if we have > ~10 ruby eclasses, ~12 python eclasses, ~3 multilib implementations (uh, > we already have) and ~4 games eclasses (and some games not using any of > those). > We already have 2 multilib implementations, and 2 approaches to games. Your proposed distributed model would actually increase the number of alternatives. > >>>> Don't get me wrong, I'm all for more overlay support. I'm all for >>>> reform when there is something to reform. However, in all your >>>> complaints about developers causing conflicts you're actually becoming >>>> part of the problem. You're basically coming across as being >>>> impossible to satisfy, because you bring up vague complaints without >>>> anything that anybody can act upon, and I find it rather frustrating >>>> personally as these sorts of issues are something I'm really committed >>>> to fixing. >>>> >>> >>> Again: you are confusing a specific incident with my proposal of a >>> distributed model. >> >> I FULLY support having more distributed repositories. The part of >> your argument that I object to is your claim that we have these huge >> cultural issues that prevent people from working on things they want >> to work on, or that we shouldn't allow people to work on packages in >> the main tree. >> > > The reason I jumped into this thread is that someone had problems with > the java project. I'm not sure, but maybe something is wrong with my eyes? And my point was that the only problem I see with Java is that nobody is actually working on it. If nobody works on distributed java repositories, it will be just as bad. My specific request was WHO is trying to do something to improve Java and finding a policy that is preventing them from doing so, and WHAT policy is causing the problem? It is easy to talk about vague problems. It is harder to actually pinpoint specific issues that can actually be fixed. Please don't take this as a personal attack - I generally have a lot of respect for you. I just don't think that this is a helpful way of approaching these problems. -- Rich
