From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id B2AAE138A1A for ; Sun, 23 Nov 2014 23:45:51 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 939D2E0AEB; Sun, 23 Nov 2014 23:45:45 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 37282E078A for ; Sun, 23 Nov 2014 23:45:44 +0000 (UTC) Received: from [192.168.4.5] (blfd-4d08245d.pool.mediaWays.net [77.8.36.93]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: hasufell) by smtp.gentoo.org (Postfix) with ESMTPSA id E2F38340486 for ; Sun, 23 Nov 2014 23:45:42 +0000 (UTC) Message-ID: <547271A2.1060003@gentoo.org> Date: Mon, 24 Nov 2014 00:45:38 +0100 From: hasufell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.8.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Gentoo's future directtion ? References: <5470D229.7000806@tampabay.rr.com> <5470DBF5.1060304@gentoo.org> <547111B5.2030909@gentoo.org> <547264C8.7030704@gentoo.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: 0fa864db-9c5b-4f56-988c-a0b9904e7d30 X-Archives-Hash: 5f3327ed35193ba91d252e8603e0bd6f On 11/24/2014 12:24 AM, Rich Freeman wrote: >> >> So regrouping is not as easy as you make it sound. Totally not. I don't >> like ruby eclasses and their virtuals. What can I do? Fix them? No, I >> cannot. Stop saying I can fix everything I please. That is incorrect and >> our model makes it even more complicated, because all that stuff is part >> of the tree. > > What would you do under your proposal? You'd start a new repository > with your own set of ruby packages. > > What would you do under the current state? You'd fork the ruby eclass > and all the ruby packages. > > Yes, you're allowed to do that. The thing that keeps you from doing > it is the same thing that will keep you from starting a new ruby > repository - it is a lot of work. > No, I am not doing it because I think it is utterly wrong to introduce two competing concepts in one repository, _especially_ on eclass level. That's bad for QA, bad for consistency and bad for the user. It's a completely different thing for a package like udev and totally unrelated... those are forked UPSTREAM. >> >> You say I can fix the nethack bug? Well, I talked with various people on >> how to do that, the basic idea was to stop using the games eclass. That >> is NOT possible unless you suggest we break QA standards and cause major >> inconsistencies in our tree. (the other possible fix just slipped my >> radar and will probably happen soon) > > Just stop using the eclass. Cite the QA standards that this would > violate. The council ruled a month ago that games are free to use the > eclass or not as they wish. > > As long as you actually commit to maintaining the Nethack package, you > can do this. > As above: I think it's wrong. >> >> Again: this is a culture thing and we have to make ourselves some >> policies on how this can work well. > > The policies ALREADY allow you to do all this stuff. What policy > specifically needs to be changed? > >> * abandon CVS finally > > Already underway. > >> * have proper contribution channels (NOT bugzilla) > > By all means create it. Lots of us are interested in this. > >> * kickban major assholes from the community, no matter how efficient >> they are > > Proposals welcome. Hint, things will go much better if you volunteer > to do the work the assholes are doing... It isn't like we aren't all > tired of this stuff, but if we go booting half the devs then the > distro will basically die. > >> * kickban people from IRC channels that make fun of your first ebuild >> (that's my first experience with gentoo btw... that guy is now a gentoo >> dev as well) > > Flag down a mod when this happens. If you can't find any, then > volunteer to be a mod. IRC is a realtime medium, so it is very > manpower-intensive. > >> * have a _working_ comrel project > > Again, proposals welcome. Half the problem with comrel is that > everybody gets so sick of all the second-guessing that they give up. > People would rather work on stuff that is interesting and not deal > with infighting. When we tried to institute the proctors we managed > to drive them away in a day. > > Everybody wants a working comrel, which generally means they want to > get rid of all the people they don't like, and not have any > restrictions on their own behavior. > >> * fix project internal communication... it's unbelievably bad > > What is wrong with it, specifically? > >> * stop the way we are recruiting, it's utterly tedious > > Well, then don't participate in it. By all means offer improvements. > 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) * 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) I feel like I am repeating myself over and over again. It's not just about "then work on it" if it's a cultural, organizational and technical change at once. 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. Everything else (like improving our overlay tools) is really minor compared to that. Saying I can go working on that right away is just a polite/smart way to say "shut up". >> >> You don't understand. It's not just about blocking progress, it is about >> _diverging_ ideas that cannot sanely be given as alternatives in a >> SINGLE REPOSITORY. > > 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. >> >>> What I can't stand is people moping about their feelings being hurt >>> from umpteen years ago. I can't go back and fix the past. Get over >>> it - contribute or don't. >>> >> >> This is rude. Please stick to the topic, it's not about my feelings. > > It wasn't directed at you specifically. I also didn't criticize > anybody for having feelings. I criticized people for moping about > them. > > 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). >> >> 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). Good job killing the tree. >>> 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?