Re: [gentoo-user] Gentoo's future directtion ?

[Rich Freeman]

On Sun, Nov 23, 2014 at 5:50 PM, hasufell <hasufell@g.o> wrote:
> On 11/23/2014 12:20 AM, Rich Freeman wrote:
>>
>> You have just as many options under the status quo, and actually more.
>>
>
> Why would that be? We have a centralized _culture_. All this is
> basically about culture, not just about tools.

Gentoo has a fairly decentralized culture.  Heck, we have three
different udev implementations.

You say tomAYto, I say toMAHto.  :)  Let's focus on things that are a
bit less subjective.

>
> 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.

>
> 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.

>
> 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.

>
> 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.

>
>> 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.

>
> 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.

>>
>> If there is somebody blocking progress on something, by all means
>> point it out.  However, it needs to be a case where somebody is
>> actually trying to do something, not just complaints about all the
>> great stuff that could get done if somebody cared enough to even try.
>>
>
> You are being specific again, looking for a person, a project or
> whatever that's not behaving.
>
> I am looking at the contribution culture and our model and see that it's
> not working and it's getting worse.
>
> We are talking about two different things, apparently.

You're trying to argue that no single thing is wrong with Gentoo while
apparently everything is wrong with Gentoo.  If there is SO much wrong
with our culture, surely you can point out a SINGLE EXAMPLE?

You're making very subjective arguments, and it is very hard to
rationally discuss problems in Gentoo when you can't point to anything
specific.  Your only specific example was Nethack, and it is already
obsolete.

Your point is that we have huge problems.  My point is that there
aren't large problems and when they are pointed out they get quickly
fixed.  I can cite examples, like the games project.  If you want to
persuade me that it is worth making some huge change to Gentoo, then
you need to provide specific examples of things that the status quo
hasn't been able to address that a new model would address.

>
>
>> The problem is that most of the overlays don't support everything in
>> the main tree.  For example, right now it is REALLY painful to run qt5
>> on a stable box, because the qt5 overlay just introduced changes
>> making it incompatible with stable qt4.  That sort of thing is likely
>> to get worse rather than better in a distributed model.
>>
>
> Low quality ebuilds, miscommunication and the like happen regularly in
> our current closed-fashion gentoo project. I can only see communication
> improve in a distributed model, because it CANNOT ever work without it
> (cause there are not 200 people with push access, lol).

So, what is stopping you from making it happen?

>
>> 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.

--
Rich