[gentoo-user] Gentoo's future directtion ?

[gentoo-user] Gentoo's future directtion ?

[James]

Here's one, very, very interesting proposals, under
serious consideration:

https://wiki.gentoo.org/wiki/Distributed_Gentoo


I'd be curious what the fine and wonderful folks at
gentoo_user think of this proposal. Old farts are
welcome to comment, even encourage to "constructively rant"....


excellent topic,
nowz ur chance to be heard!


hth,
James

:----->
I'm not sure if Tequila and Rum make me a better dancer, or just
makes me think that 'taking a risk or 2 on the dance floor'
is a good thing. Therefore, I need, yet another Caribbean 
Vacation so I can collect more data, and learn of new
ways to analyze that data    >---3

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

[Michael Brinkman]

[-- Attachment #1: Type: text/plain, Size: 1220 bytes --]

I may be misunderstanding, but isn't this cutting back the centralized
development and a pushing for more extensive use of overlays?

To me overlays cause a problem with packages overlapping each other too
much because its the way their maintainers' ebuilds are written.

If anything, I'd suggest continued gentoo centralized development with an
AUR type system that is accessible to gentoo unstable users over the top if
we are just throwing ideas around.

On Fri, Nov 21, 2014 at 11:34 AM, James <wireless@tampabay.rr.com> wrote:

>
> Here's one, very, very interesting proposals, under
> serious consideration:
>
> https://wiki.gentoo.org/wiki/Distributed_Gentoo
>
>
> I'd be curious what the fine and wonderful folks at
> gentoo_user think of this proposal. Old farts are
> welcome to comment, even encourage to "constructively rant"....
>
>
> excellent topic,
> nowz ur chance to be heard!
>
>
> hth,
> James
>
> :----->
> I'm not sure if Tequila and Rum make me a better dancer, or just
> makes me think that 'taking a risk or 2 on the dance floor'
> is a good thing. Therefore, I need, yet another Caribbean
> Vacation so I can collect more data, and learn of new
> ways to analyze that data    >---3
>
>
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 1800 bytes --]

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

[Rich Freeman]

On Fri, Nov 21, 2014 at 12:34 PM, James <wireless@tampabay.rr.com> wrote:
>
> Here's one, very, very interesting proposals, under
> serious consideration:
>
> https://wiki.gentoo.org/wiki/Distributed_Gentoo
>
>
> I'd be curious what the fine and wonderful folks at
> gentoo_user think of this proposal. Old farts are
> welcome to comment, even encourage to "constructively rant"....

Honestly, I think it is a bit optimistic, though something I'd love to
see.  I'm more of a fan of getting the new working before dismantling
the old, and I'm not keen on proposals that start out with gutting
what we already have before there is anything new to replace it.
Burning bridges usually isn't wise.

The optimistic bit is that the proposal is that the only part of
Gentoo that would actually be developed centrally are the parts that
almost nobody is working on today.  That basically amounts to just
having all the developers quit, and hoping that they all move on to
work on overlays instead of moving on to something else.

There are a lot of technical challenges in such an approach -
supporting overlays isn't all that unlike trying to provide kernel
internal API stability.  I think it could be done better, but it would
be a big change.  IMHO it makes far more sense to make those changes
and use them for our own internal benefit in the main repository, and
THEN think about whether the main repository is still needed.

--
Rich

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

[Paige Thompson]

On 11/21/14 18:14, Rich Freeman wrote:
> On Fri, Nov 21, 2014 at 12:34 PM, James <wireless@tampabay.rr.com> wrote:
>> Here's one, very, very interesting proposals, under
>> serious consideration:
>>
>> https://wiki.gentoo.org/wiki/Distributed_Gentoo
>>
>>
>> I'd be curious what the fine and wonderful folks at
>> gentoo_user think of this proposal. Old farts are
>> welcome to comment, even encourage to "constructively rant"....
> Honestly, I think it is a bit optimistic, though something I'd love to
> see.  I'm more of a fan of getting the new working before dismantling
> the old, and I'm not keen on proposals that start out with gutting
> what we already have before there is anything new to replace it.
> Burning bridges usually isn't wise.
>
> The optimistic bit is that the proposal is that the only part of
> Gentoo that would actually be developed centrally are the parts that
> almost nobody is working on today.  That basically amounts to just
> having all the developers quit, and hoping that they all move on to
> work on overlays instead of moving on to something else.
>
> There are a lot of technical challenges in such an approach -
> supporting overlays isn't all that unlike trying to provide kernel
> internal API stability.  I think it could be done better, but it would
> be a big change.  IMHO it makes far more sense to make those changes
> and use them for our own internal benefit in the main repository, and
> THEN think about whether the main repository is still needed.
>
> --
> Rich
>
With regards to distributed gentoo;

to me this sounds like gentoo already. Overlays / layman repositories. I
even have my own overlay that is listed publicly for anybody to add:
https://github.com/paigeadele/netcrave

Which goes to say, the obvious should be assumed since anybody can have
their own publicly listed overlay, you should know what's in it before
you add it--it's a fairly autonomous system but you have to ask to get
publicly to get your repo publicly list and If it were any easier, it
would probably get abused.

Technically you can even use git to manage your entire / filesystem if
you want but it would be more productive to write your .gitignore to
ignore all, then conditionally "un-ignore" things that need to be
tracked thereafter. I did this but only for /etc because I've gotten
tired of hunting down HOWTOs and more often than not a simple example is
more than what I need to get stuff done:

https://github.com/paigeadele/laptop.paigeat.info_etc/blob/master/.gitignore

Honestly though I kinda wish I had done this from the top most
directory, there are things here and there outside of /etc that I'd like
to keep for reference or whatever reason.

You can pretty much do whatever you want with gentoo, its up to you to
decide whether or not to.

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

[Rich Freeman]

On Fri, Nov 21, 2014 at 5:40 PM,  <wireless@tampabay.rr.com> wrote:
> Interesting perspective that I had not considered... still, I think there is
> more at play here. It sounds as if a few "chosen" old guard
> are going to kick out more of the progressive and newer devs
> so that  these few. control the core distro. That way they can agree
> and do what they want.

Where are you getting this stuff?  People seem to talk about "old
guard" Gentoo devs blocking contributions, but the very few times
anything remotely resembling this gets pointed out the Council has
stepped in to remove obstructions.

There are of course a few long-running personality conflicts that
flare up from time to time, and attempts at obstructionism, but they
tend to get shot down which is as it should be.

If somebody feels otherwise then they really need to step up and call
attention to it.  Simply complaining about being oppressed is really
just being part of the problem.

--
Rich

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

[wireless]

On 11/21/14 14:00, Paige Thompson wrote:
>
> On 11/21/14 18:14, Rich Freeman wrote:
>> On Fri, Nov 21, 2014 at 12:34 PM, James <wireless@tampabay.rr.com> wrote:
>>> Here's one, very, very interesting proposals, under
>>> serious consideration:
>>>
>>> https://wiki.gentoo.org/wiki/Distributed_Gentoo
>>>
>>>
>>> I'd be curious what the fine and wonderful folks at
>>> gentoo_user think of this proposal. Old farts are
>>> welcome to comment, even encourage to "constructively rant"....
>> Honestly, I think it is a bit optimistic, though something I'd love to
>> see.  I'm more of a fan of getting the new working before dismantling
>> the old, and I'm not keen on proposals that start out with gutting
>> what we already have before there is anything new to replace it.
>> Burning bridges usually isn't wise.
>>
>> The optimistic bit is that the proposal is that the only part of
>> Gentoo that would actually be developed centrally are the parts that
>> almost nobody is working on today.  That basically amounts to just
>> having all the developers quit, and hoping that they all move on to
>> work on overlays instead of moving on to something else.

Interesting perspective that I had not considered... still, I think 
there is more at play here. It sounds as if a few "chosen" old guard
are going to kick out more of the progressive and newer devs
so that  these few. control the core distro. That way they can agree
and do what they want.


>> There are a lot of technical challenges in such an approach -
>> supporting overlays isn't all that unlike trying to provide kernel
>> internal API stability.  I think it could be done better, but it would
>> be a big change.  IMHO it makes far more sense to make those changes
>> and use them for our own internal benefit in the main repository, and
>> THEN think about whether the main repository is still needed.

Agreeded. In fact if one reads the threads on gentoo-dev that lead to 
this document, one get's a bit more of the picture that is going to be
a very large undertaking, and many, more robust tools will need to be 
developed, to support this (2 tier) system proposal. aka, actually
until gentoo current is mature and stablized, it's a very, very bad
idea, imho.

>>
>> --
>> Rich
>>
> With regards to distributed gentoo;
>
> to me this sounds like gentoo already. Overlays / layman repositories. I
> even have my own overlay that is listed publicly for anybody to add:
> https://github.com/paigeadele/netcrave

On the surface, yes. The way it will work out, no; hell no. There will 
be no new devs moving into the core, unless the "few" bless them and 
they will be clones of the existing dev mentalities that have been the 
source of gentoo limitations, imho.  The question is this: Is gentoo
a "boys club" or an open source evolving/morphing/multi-faceted 
jaugernaut we all know and love.   This porposal has good intentions, 
but is "barking up the wrong tree".


> Which goes to say, the obvious should be assumed since anybody can have
> their own publicly listed overlay, you should know what's in it before
> you add it--it's a fairly autonomous system but you have to ask to get
> publicly to get your repo publicly list and If it were any easier, it
> would probably get abused.

True, very true, but trivial in the deeper context of who and how the 
future of gentoo is steered, imho. i.e. what you are pointing out merely
today's noise.


> Technically you can even use git to manage your entire / filesystem if
> you want but it would be more productive to write your .gitignore to
> ignore all, then conditionally "un-ignore" things that need to be
> tracked thereafter. I did this but only for /etc because I've gotten
> tired of hunting down HOWTOs and more often than not a simple example is
> more than what I need to get stuff done:
>
> https://github.com/paigeadele/laptop.paigeat.info_etc/blob/master/.gitignore
>
> Honestly though I kinda wish I had done this from the top most
> directory, there are things here and there outside of /etc that I'd like
> to keep for reference or whatever reason.

More truth, but it misses what is really at play here.


> You can pretty much do whatever you want with gentoo, its up to you to
> decide whether or not to.

TRUE, but it becomes a power struggle, just like what is occurring 
presently with openrc vs systemd.

Take the JAVA example. Java a core, fundamental technology in many linux 
distros, Android probably being the most visiable (my def of linux
is if you use the linux kernel, it's linux, forget everthing else), ymmv.

Java over the years has never risen to the level of respect and support 
it deserves in gentoo, because of a few core gentoo_master that hate 
Java. I hate oracle too, but not java. Please do not think what I'm 
about to say about gentoo or Java, is in any way a slight against those 
devs that support java or any other gentoo dev. It's just a common 
prejudice (lack of respect) against java for a very wide variety of 
reasons.  So if a motivated group, comes together, we fix up java and 
create many, many tool and packages that are wonderful, powerful and 
popular with a very wide variety of linux users, then gentoo will 
explode and the Java team will be the most visually powerful group of 
devs to the masses of gentoo users. (surely under current gentoo 
circumstances a slim prospect but very viable, imho).


The 'good old boys club' now being demoted to "second base", in the eyes
of the new gentoo users, are very unhappy. If you look at what 
innovating on the net, JAVA is king, imho; Python is strong, but a 
distant second. Haskell and Scala are the future of linux greatness, but 
they have a ways to go.  Java bridges to both Scala and
Haskel very, very visibly, imho.


So again, booting out all the new/lesser/younger devs from the core (of 
gentoo) and making them second class (user) citizens is all a power 
struggle ploy, being pitched as elevating overlays and the gentoo 
citizen.  Why should their work not be included into the core? Why 
should Java (OpenJDK and Icedtea and such) be given a path to the core, 
if not becoming a critical language to the core of gentoo? 
(philisopically not presently) It is a "wolf in sheep's clothing". It is 
the very poorest of ideas. I think we need 800 or 1,000 active gentoo 
devs all competing for the the title of council elder or "grand poubah" 
to make gentoo stronger and more attractive to the masses.   I think one 
day that python will be replace by another "better" language. I think 
the core power_brokers do not like that possibility because they become, 
second class devs and that they *might* be treated like they treat other 
newer devs now.


What happens if one of the new brilliant mathematical/physics minds, 
with deep admin experiences comes to gentoo and starts using haskel and 
scala codes and sets the linux world on fire with innovation? Will that
person find a warm and cozy home at Gentoo?  (ok quite down the 
laughter). In 1990 I strated one of the first ISP in America. I 
convinced SURAnet (who was the internet in 1990) to allow us to connect
to to MAE-EAST and sell TCP/IP connections to the general population.
First one to do it in American and probable in the world. It was only
possible, because we recruited a young mathematican out of England to
write the code. Many were farting around with ppp over serial links,
but this was the first stack that work reliable and was to become open 
sources. (I do not want to "get into it" as many old farts have their 
own perspective and I have zero desire to argue or elaborate). And no
we did not get rich. cheated is more likely the single word for "the 
rest of the story."  I merely point out this industry changing event, so 
that you realize *ONE* mathematician can change the world. Forget 
computer science, forget admins. Forget loosers like LINEART. Math is 
and always shall be king, imho.

Would the gentoo elders make room for such a person, if the core is 
controlled by the few?   doubtless. One of the groups being moved to the
"Overlay fringe" is science/math. Clever, will robinson, clever, 
deceitful and stupid all in one proposal. Wonder where Java ends up?
"out of the core" is my guess.

In fact I'd go so far as to say that "term limits" on the council is a 
better starting point than enshrining the current few, imho. Please 
understand, I'm a huge fan a few of the council members; but power 
corrupts your vision and absolute power will certainly corrupt your 
database that you draw conclusions from.


I sure hope I am wrong, but, then again, I do love a good conspiracy 
theory? Am I a troll?  Nope, I'm older, experience and have seen shit
you would not believe. I first proposed carbon sequestration as a young 
engineer in the 1980 at Prudoe Bay Alaska. I use to sit in a pickup 
truck and watch dozens of Jet engines put massive amounts of CO2 into 
the air. May particular resposibility was to ensure that those dozens
of "gas injection wells" did not experience a loss in integrity, cause 
the massive explosion would set Prudohe Bay on fire; necessitating that
the 2.2 millions barrels of oil we were producing a day, would have to 
be "shut down for repairs". Surely that would have made headlines, 
worldwide.  I proposed for my graduate work to capture the turbine 
emissions (primarily CO2) and inject them into those gas injections 
well. Carbon sequestration was not even an issue at the time. CO2 was
and is the best source of "surfactant flooding" to enhance oil recovery.
I also propose to been the massive energy creation up to a satelitte 
system, run by the military and use a diffuse beam to bounce the energy
down to chicago for usage.  Funny, my professor thought that a bad idea
and wanted me to work with them on converting natural gas into methanol,
so it could be pumped with the crude oil to the Alaskan pipleline and to 
market. Today, still there are laws to prevent methane being converted 
to methanol; but is is ok to convert corn and other food sources to 
methanol or ethanol.

I *was* a young math wize. Now, I'm mostly apathetic, but, I can sniff 
out pooh with the best of them and this idea is *pooh*, at best, imho.


apologies well in advance of any pain anyone feels,
But, I have been using Gentoo, since early 2004,


thoughts?
James

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

[wireless]

On 11/21/14 17:10, Rich Freeman wrote:
> On Fri, Nov 21, 2014 at 5:40 PM,  <wireless@tampabay.rr.com> wrote:
>> Interesting perspective that I had not considered... still, I think there is
>> more at play here. It sounds as if a few "chosen" old guard
>> are going to kick out more of the progressive and newer devs
>> so that  these few. control the core distro. That way they can agree
>> and do what they want.
>
> Where are you getting this stuff?  People seem to talk about "old
> guard" Gentoo devs blocking contributions, but the very few times
> anything remotely resembling this gets pointed out the Council has
> stepped in to remove obstructions.
>
> There are of course a few long-running personality conflicts that
> flare up from time to time, and attempts at obstructionism, but they
> tend to get shot down which is as it should be.
>
> If somebody feels otherwise then they really need to step up and call
> attention to it.  Simply complaining about being oppressed is really
> just being part of the problem.
>
> --
> Rich
>


I have repetitively ask why java is treated like a second class citizen 
here at gentoo. Is anyone close any of those old deprecated java bugs?

I just wonder why the rank and file devs do not like java?
Why the devs do not celebrate Java?

Here's an old rah rah from a council member that is perfect:

http://dberkholz.com/2013/03/14/opportunities-for-gentoo/


But since clustering is now java centric, it seems to be unimportant?
Cluster codes are put in the "science" project now? Apathy runs deep
with anything that touches java, here at Gentoo.

Sure there is sys-cluster, but it is dying on gentoo; very little activity.

For me, and many others, clustering is the future not only
of linux, but computing, personal devices and everything.
Clouds are merely a contract cluster. A clustering is far more important 
that the linux kernel, imho. In a few years everyone will
run on a cluster (systems they control) or on the cloud (a cluster
brought to you by a global conglomerate), and the linux kernel will
be but one mechanism to plug into your cluster. Winblos will have
their path, as will apple, android, samsung, qualcomm, ibm, verizon, 
AT&T etc etc. Booting will be multi-variant. Once you ethernet is live,
you plug into your cluster and the cluster masters your hardware. That 
is how cell phones work today. What you run on your "screen" will be
what you want, or what vendors insist you run. Most will be 
OS/bios/kernel agnostic.


But hey, we don't do java here at Gentoo. Let's move it to an overlay
and be done with it?   That and let's move science to an overlay,
is what I see in this proposal. It's what the end result of gentoo
policy is and for me, science and java are the future for Gentoo, if it 
is to be robustly embraced. I could think of some things to move to 
overlays that would surely upset others that seem them as "core".
Systemd will no doubt be (eventually) very successful at collapsing
many if not most linux distros, imho.


I just like to wrap all of this in a conspiracy flavouring; hopefully 
some devs will jump into java, fix it up and let's give it a proper 
place in the gentoo structure? What if somebody wants to develop a PM or 
PMS using java on gentoo. You think that person would receive a 'warm 
welcome' as in lots of help, code snippets and partners among the gentoo 
elites?

How does your council feel about that? How many council member have 
added java packages or closed java bugs? Sure they have work on other 
things they do not like, but hell no to java?  How about a 'java week" 
where the brightest java devs devote just one week to java? (gnashing of 
teeth?).

I visible proposed just flushing several hundred of the old java bugs,
because their issues, or the related codes are deprecated. I got nothing
back from anyone but silence. The java leadership even admitted that
there is nobody, that currently 'gives a shit' enough to close java 
bugs. How about authorizing a few dozen folks to close java bugs. Why
do you have to be a dev to close bugs in BGO? Surely since java is not 
in the main stream I can close a few java bugs?  Please give me one week 
to close java bugs, and clean up java in BGO. It'll be less than one 
hundred left, I promise you. Piss on that arcane crap criteria impose on 
this effort, by folks that care nothing about java. Just give me the 
torch, and I'll clear a path forward for java; but I am going to ignore 
most of the "crap burden" you have to wade through on BGO to close only 
java bugs.If you do not like what I close, keep a copy and bring them 
back? Surely one or 2 other folks care about those 5+ year old java 
bugs? After all, if they are valid, they get posted again, with 
information from as least the current decade. What do I have to do, beg?

It sure looks like  a duck, quacks like a duck, smells like a duck
and I believe I hear quacking from this latest wacky (dev) idea to move 
most devs and most packages to second class status; as pure  quackery. 
Medically, from a medical dictionary that is about 50 years old, the
most correct diagnostic is "imbecilic".

I think that java and clustering on gentoo are dying, because the 
leadership environment makes it difficult for them to proper. How many 
java bugs have you close, during 2014?




curiously,
James

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

[Rich Freeman]

On Fri, Nov 21, 2014 at 7:13 PM,  <wireless@tampabay.rr.com> wrote:
> On 11/21/14 17:10, Rich Freeman wrote:
>>
>> On Fri, Nov 21, 2014 at 5:40 PM,  <wireless@tampabay.rr.com> wrote:
>>>
>>> Interesting perspective that I had not considered... still, I think there
>>> is
>>> more at play here. It sounds as if a few "chosen" old guard
>>> are going to kick out more of the progressive and newer devs
>>> so that  these few. control the core distro. That way they can agree
>>> and do what they want.
>>
>>
>> Where are you getting this stuff?  People seem to talk about "old
>> guard" Gentoo devs blocking contributions, but the very few times
>> anything remotely resembling this gets pointed out the Council has
>> stepped in to remove obstructions.
>>
>
> I have repetitively ask why java is treated like a second class citizen here
> at gentoo. Is anyone close any of those old deprecated java bugs?
>
> I just wonder why the rank and file devs do not like java?
> Why the devs do not celebrate Java?

If nobody is maintaining Java it is because nobody wants to maintain
Java.  You suggested that established developers were preventing new
ones from doing some things.  The problem with Java is that there
simply aren't that many developers interested in it at all.

Gentoo devs work on whatever they want to work on.  They aren't paid employees.


> I just like to wrap all of this in a conspiracy flavouring; hopefully some
> devs will jump into java, fix it up and let's give it a proper place in the
> gentoo structure? What if somebody wants to develop a PM or PMS using java
> on gentoo. You think that person would receive a 'warm welcome' as in lots
> of help, code snippets and partners among the gentoo elites?

If you want to write a java PM just do it.  You seem to be complaining
that nobody is writing one for you.  I'm sure there are plenty of
Gentoo devs and non-devs who would be happy to talk to you about
writing one if you're willing to pay them for their time.  Otherwise,
this is a volunteer effort and people work on what they want to work
on.

That isn't some kind of evil conspiracy.  Nobody is going to prevent a
Gentoo developer from putting a java-based package manager in the tree
as long as it doesn't contain security bugs/etc.  They may or may not
get any help with doing it, and that just reflects that people work on
what they want to.

>
> How does your council feel about that? How many council member have added
> java packages or closed java bugs? Sure they have work on other things they
> do not like, but hell no to java?  How about a 'java week" where the
> brightest java devs devote just one week to java? (gnashing of teeth?).

Well, I can speak only for myself (as a Council member).  I've never
worked on java packages or closed java bugs (well, maybe I've done a
stable request or two as part of an arch team, but that isn't really
what you're talking about).

Like most other devs I work on the things that interest me or which I
care about.  For the most part, java is not among them, though I do
maintain the android sdk which is java-based.

> How about authorizing a few dozen folks to close java bugs. Why
> do you have to be a dev to close bugs in BGO?

So, first you'll need to find a few dozen folks who are interested in
closing java bugs.  Second, you don't have to be a dev to close bugs
in BGO, but you do need to be given access, and that does mean that
you'll have to work with somebody with some kind of guidelines around
what you'll be doing.  Arch testers have editbugs privs and they
aren't devs, for example, but they follow rules like everybody else.

> It sure looks like  a duck, quacks like a duck, smells like a duck
> and I believe I hear quacking from this latest wacky (dev) idea to move most
> devs and most packages to second class status; as pure  quackery. Medically,
> from a medical dictionary that is about 50 years old, the
> most correct diagnostic is "imbecilic".

Well, go take that up with the dev proposing this.  I'm not suggesting
that anything should be excluded from the main tree, and so far I've
only seen a single Gentoo dev suggest that.  I do support making it
easier to maintain stuff outside the tree.

Devs are allowed to post on the lists.  When one dev posts an idea
that doesn't mean that the entire distribution is going to reverse
directions.

>
> I think that java and clustering on gentoo are dying, because the leadership
> environment makes it difficult for them to proper. How many java bugs have
> you close, during 2014?

Zero.  That's about as many as I'm likely to close in 2015.  Nobody in
the Gentoo leadership is keeping anybody from closing Java bugs.
There just aren't that many devs interested in working on them.

If you want to work on them, you might consider becoming a dev, or
working on them in an overlay (which is a good way to become a dev,
actually).

You seem to be under the impression that Gentoo devs work on things
that the Gentoo leadership tells them to work on.  That is hardly the
case, many of our most important packages are also the least
maintained, because devs work on what they work on, and not on the
stuff the leadership considers important.  If a Gentoo developer
wanted to work on Java the leadership wouldn't interfere with that
just as they didn't interfere with a couple of devs deciding to fork
udev.

--
Rich

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

[Rich Freeman]

On Sat, Nov 22, 2014 at 1:12 PM,  <wireless@tampabay.rr.com> wrote:
>
> The first 100 or so I looked at, are deprecated. They just need somebody
> to 'remove them' the BGO java backlog is being artificially used to
> prevent java work on gentoo. Somebody of authority needs to open
> up java for other folks to work on. Close the 100 oldest bugs
> is a no brainer and a good start, yet nobody will do that, and nobody
> else is allowed to close them. *CONVENIENT* if you hate java and are
> in control.

How are open bugs artificially preventing java work?  If you want to
work on Java, then work on it.  You don't even need to look at
Bugzilla to work on something.  Just do it.

> This policy, whether part of a grand conspiracy, or due to apathetic
> leadership, has the net effect to run off potential new devs to gentoo
> and who like java.

What policy are you talking about?  ANY Gentoo dev can work on or
close java bugs, as long as they're maintaining the packages in
question. THAT is Gentoo policy.  If some dev feels that somebody is
preventing this from happening all they have to do is speak up and it
will be taken care of.  Squatting is not allowed in Gentoo.

I think the real problem is that there aren't many devs who care about
Java in the first place.  That isn't a policy problem - it is a
manpower problem.

>
> Rich, I actually appreciate you help. But somebody of authority is going to
> have to step into this java on gentoo mess and clean house,
> provide leadership and encourage (hell, just remove the roadblocks)
> from java on gentoo.

Show me somebody willing to do the work who is being prevented from
doing the work, and we can figure out how to fix things.

Like most FOSS projects Gentoo is a "do-ocracy."  The leaders are the
people who DO things, not the people who get elected.  For the most
part the people who are elected try to keep obstacles out of the way
of those who do things, and generally provide basic rules so that we
can all live together.

As a Gentoo user and leader, there really wouldn't be that much
personal impact to me if Java disappeared from the tree.  That doesn't
mean that I want to see it go, or that I won't do what I can to enable
people to care for it.  However, most FOSS projects are driven by
people who are scratching their own itches.  The only way Java will
have a good experience on Gentoo is if lots of people who use Java
step up and make it that way.  You can't look to a bunch of people who
don't care about Java and try to get them to care, whether they're
leaders or not.  If you told me that a million more people would use
Gentoo if only we spent an extra couple of hours working on Java, I'd
ask why I should care if a million more people use Gentoo?  :)  I want
people to use Gentoo because it is the right solution for them, and I
want them to contribute back.  If they'd be happier elsewhere, then
more power to them.  Most Gentoo devs aren't out to maximize our
market share or anything like that.

Please don't take this as some kind of rejection.  I'd love to see
Gentoo have great Java support.  However, I doubt it matters as much
to me as it does to you, so you're the one with the incentive to make
it happen.  That's how just about everything that exists in Gentoo got
the way it is - somebody cared and made it happen.

--
Rich

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

[wireless]

On 11/22/14 01:20, Rich Freeman wrote:
> On Fri, Nov 21, 2014 at 7:13 PM,  <wireless@tampabay.rr.com> wrote:
>> On 11/21/14 17:10, Rich Freeman wrote:

> If you want to work on them, you might consider becoming a dev, or
> working on them in an overlay (which is a good way to become a dev,
> actually).

Exactly, I agree. That is why the idea to have a small core of Gentoo
elites (the chosen devs) and move everyone else into overlays, is a
very bad idea.

> You seem to be under the impression that Gentoo devs work on things
> that the Gentoo leadership tells them to work on.  That is hardly the
> case, many of our most important packages are also the least
> maintained, because devs work on what they work on, and not on the
> stuff the leadership considers important.  If a Gentoo developer
> wanted to work on Java the leadership wouldn't interfere with that
> just as they didn't interfere with a couple of devs deciding to fork
> udev.

> Rich


Not really. I think you misss my points and intentions exactly. Java is
critical and growing. Folks are constantly knocking on the gentoo door
with technologies, that are java centric. Here is the latest one, just
posted to gentoo-dev:


https://wiki.gentoo.org/wiki/Project:Android


I tried to participate with the java herd/project. Few have the 
authority to close old java bugs. The few that do, are apathetic,
absent or just do not 'give a shit'. I was told to go work
on java bugs, maybe somebody will notice. Really.

The first 100 or so I looked at, are deprecated. They just need somebody
to 'remove them' the BGO java backlog is being artificially used to
prevent java work on gentoo. Somebody of authority needs to open
up java for other folks to work on. Close the 100 oldest bugs
is a no brainer and a good start, yet nobody will do that, and nobody
else is allowed to close them. *CONVENIENT* if you hate java and are
in control.

If this is not true, the the council should open up java bug cleaning.
Worst case scenario, these hundreds of old bugs will have to be 
re-filed, with updated data from this decade..... (actually a very 
excellent idea in and of itself).

This policy, whether part of a grand conspiracy, or due to apathetic 
leadership, has the net effect to run off potential new devs to gentoo
and who like java.

PS. sorry about forking to new threads, my access is now nntp 
(earlybird) and it just down not follow the thread correctly.


Rich, I actually appreciate you help. But somebody of authority is going 
to have to step into this java on gentoo mess and clean house,
provide leadership and encourage (hell, just remove the roadblocks)
from java on gentoo.

OK?


sincerely,
James

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

[hasufell]

On 11/22/2014 07:12 PM, wireless@tampabay.rr.com wrote:
> On 11/22/14 01:20, Rich Freeman wrote:
>> On Fri, Nov 21, 2014 at 7:13 PM,  <wireless@tampabay.rr.com> wrote:
>>> On 11/21/14 17:10, Rich Freeman wrote:
> 
>> If you want to work on them, you might consider becoming a dev, or
>> working on them in an overlay (which is a good way to become a dev,
>> actually).
> 
> Exactly, I agree. That is why the idea to have a small core of Gentoo
> elites (the chosen devs) and move everyone else into overlays, is a
> very bad idea.
> 

I don't see the argument here. It depends very much on what that
actually means.

>> You seem to be under the impression that Gentoo devs work on things
>> that the Gentoo leadership tells them to work on.  That is hardly the
>> case, many of our most important packages are also the least
>> maintained, because devs work on what they work on, and not on the
>> stuff the leadership considers important.  If a Gentoo developer
>> wanted to work on Java the leadership wouldn't interfere with that
>> just as they didn't interfere with a couple of devs deciding to fork
>> udev.
> 
>> Rich
> 
> 
> Not really. I think you misss my points and intentions exactly. Java is
> critical and growing. Folks are constantly knocking on the gentoo door
> with technologies, that are java centric. Here is the latest one, just
> posted to gentoo-dev:
> 
> 
> https://wiki.gentoo.org/wiki/Project:Android
> 
> 
> I tried to participate with the java herd/project. Few have the
> authority to close old java bugs. The few that do, are apathetic,
> absent or just do not 'give a shit'. I was told to go work
> on java bugs, maybe somebody will notice. Really.
> 
> The first 100 or so I looked at, are deprecated. They just need somebody
> to 'remove them' the BGO java backlog is being artificially used to
> prevent java work on gentoo. Somebody of authority needs to open
> up java for other folks to work on. Close the 100 oldest bugs
> is a no brainer and a good start, yet nobody will do that, and nobody
> else is allowed to close them. *CONVENIENT* if you hate java and are
> in control.
> 
> If this is not true, the the council should open up java bug cleaning.
> Worst case scenario, these hundreds of old bugs will have to be
> re-filed, with updated data from this decade..... (actually a very
> excellent idea in and of itself).
> 
> This policy, whether part of a grand conspiracy, or due to apathetic
> leadership, has the net effect to run off potential new devs to gentoo
> and who like java.
> 
> PS. sorry about forking to new threads, my access is now nntp
> (earlybird) and it just down not follow the thread correctly.
> 
> 
> Rich, I actually appreciate you help. But somebody of authority is going
> to have to step into this java on gentoo mess and clean house,
> provide leadership and encourage (hell, just remove the roadblocks)
> from java on gentoo.
> 
> OK?
> 
> 

Gentoo has a lot of organizational, technical and social problems. Some
of them would just stop existing if we'd move to a more distributed
model, because you'd be able to regroup more easily and work on the
things you care about without stepping on each others toes.

No one would care in such a distributed model if there is one person
blocking progress somewhere. They would just move on, regroup around a
new overlay and start working there and let that guy/project rot forever.

Users would easily be able to pick up what the most community-driven and
collaborative overlays are and would support those instead of some idle,
stubborn or hard-to-work-with overlay maintainers.

In that sense, there wouldn't be a single java ebuild in the core tree.
That would totally be a community effort and you wouldn't have to vent
that much here, but would be working on java ebuilds instead.

Hell, you could even easily fork the WHOLE base-system and toolchain
without forking the whole rest of the distro.

We don't need more authority, we need less... and we need more actual
opensource workflow. Our tools, our organizational model and our
workflow are ALL ancient. And they don't seem to work very well, do they?

Also see: https://wiki.gentoo.org/wiki/Distributed_Gentoo

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

[wireless]

On 11/22/14 13:00, Rich Freeman wrote:
> On Sat, Nov 22, 2014 at 1:12 PM,  <wireless@tampabay.rr.com> wrote:
>>
>> The first 100 or so I looked at, are deprecated. They just need somebody
>> to 'remove them' the BGO java backlog is being artificially used to
>> prevent java work on gentoo. Somebody of authority needs to open
>> up java for other folks to work on. Close the 100 oldest bugs
>> is a no brainer and a good start, yet nobody will do that, and nobody
>> else is allowed to close them. *CONVENIENT* if you hate java and are
>> in control.

> Please don't take this as some kind of rejection.  I'd love to see
> Gentoo have great Java support.  However, I doubt it matters as much
> to me as it does to you, so you're the one with the incentive to make
> it happen.  That's how just about everything that exists in Gentoo got
> the way it is - somebody cared and made it happen.
>
> --
> Rich
>

Exactly. So we agree; that is the reason the original post on the idea
to move everything external to gentoo core, is a very bad one. Java 
exists and prospers on Gentoo, mostly in overlays. Formalizing that
(original) proposal will only serve to further enshrine the fact that 
java on gentoo, get's little love and no java-centric developer will
every get close to the "core" or gentoo.


I'm using java as an example; the science herd and the clustering herd
(projects if you like) are in the same boat. I do appreciate your candid
and clear responses.


James

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

[Volker Armin Hemmann]

Am 22.11.2014 um 20:59 schrieb wireless@tampabay.rr.com:
> On 11/22/14 13:00, Rich Freeman wrote:
>> On Sat, Nov 22, 2014 at 1:12 PM,  <wireless@tampabay.rr.com> wrote:
>>>
>>> The first 100 or so I looked at, are deprecated. They just need
>>> somebody
>>> to 'remove them' the BGO java backlog is being artificially used to
>>> prevent java work on gentoo. Somebody of authority needs to open
>>> up java for other folks to work on. Close the 100 oldest bugs
>>> is a no brainer and a good start, yet nobody will do that, and nobody
>>> else is allowed to close them. *CONVENIENT* if you hate java and are
>>> in control.
>
>> Please don't take this as some kind of rejection.  I'd love to see
>> Gentoo have great Java support.  However, I doubt it matters as much
>> to me as it does to you, so you're the one with the incentive to make
>> it happen.  That's how just about everything that exists in Gentoo got
>> the way it is - somebody cared and made it happen.
>>
>> -- 
>> Rich
>>
>
> Exactly. So we agree; that is the reason the original post on the idea
> to move everything external to gentoo core, is a very bad one. Java
> exists and prospers on Gentoo, mostly in overlays. Formalizing that
> (original) proposal will only serve to further enshrine the fact that
> java on gentoo, get's little love and no java-centric developer will
> every get close to the "core" or gentoo.
>
>
> I'm using java as an example; the science herd and the clustering herd
> (projects if you like) are in the same boat. I do appreciate your candid
> and clear responses.
>
>
> James
>
> .
>

please stop this nonesense.

And I don't mean what you are talking about. Learn to thread. Seriously.
Your emails popping up everywhere, instead of one, nice thread. If you
are using a broken mail client, get another one. If it is your own
fault: stop it.

I don't give a shit about java or whatever you are talking about. But I
am so fed up with seeing your emails everywhere. Threading. Keeps people
sane.

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

[Rich Freeman]

On Sat, Nov 22, 2014 at 1:54 PM, hasufell <hasufell@gentoo.org> wrote:
>
> No one would care in such a distributed model if there is one person
> blocking progress somewhere. They would just move on, regroup around a
> new overlay and start working there and let that guy/project rot forever.
>

Nobody can block progress under the current model.  If you feel
otherwise, please point them out so that they can be dealt with.

I'm fine with having more support for overlays/etc, but I don't think
it is as easy as you're making it out to be.

>
> We don't need more authority, we need less... and we need more actual
> opensource workflow. Our tools, our organizational model and our
> workflow are ALL ancient. And they don't seem to work very well, do they?

Gentoo is already fairly non-authoritative where the main tree is
concerned.  I'm all for more overlay support, but I doubt it is going
to fix the kinds of issues you're bringing up.

The problem with java is that nobody wants to work on it.  Lots of
people want to talk about working on it, but nobody is writing
ebuilds.

The problem with games is that nobody wants to work on those either.
Lots of people like to talk about the games project blocking progress,
but now that this has been eliminated, there isn't some flood of new
games ebuilds.

People love to talk about elitist old-timers blocking progress, but it
seems to me that many of the old-timers don't do a whole lot of
anything.  I think the complaint is really that other people aren't
doing the work we want them to do.

--
Rich

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

[hasufell]

On 11/22/2014 11:20 PM, Rich Freeman wrote:
> On Sat, Nov 22, 2014 at 1:54 PM, hasufell <hasufell@gentoo.org> wrote:
>>
>> No one would care in such a distributed model if there is one person
>> blocking progress somewhere. They would just move on, regroup around a
>> new overlay and start working there and let that guy/project rot forever.
>>
> 
> Nobody can block progress under the current model.  If you feel
> otherwise, please point them out so that they can be dealt with.
> 

They can block progress and they do. And by saying we allow conflicting
ideas in one repository we are even making it worse.

The council is a workaround to make the broken project structure not
look too bad.

>>
>> We don't need more authority, we need less... and we need more actual
>> opensource workflow. Our tools, our organizational model and our
>> workflow are ALL ancient. And they don't seem to work very well, do they?
> 
> Gentoo is already fairly non-authoritative where the main tree is
> concerned.  I'm all for more overlay support, but I doubt it is going
> to fix the kinds of issues you're bringing up.
> 
> The problem with java is that nobody wants to work on it.  Lots of
> people want to talk about working on it, but nobody is writing
> ebuilds.
> 
> The problem with games is that nobody wants to work on those either.
> Lots of people like to talk about the games project blocking progress,
> but now that this has been eliminated, there isn't some flood of new
> games ebuilds.
> 

I strongly disagree. I know a fair amount of games overlays where people
do work on games ebuilds. They just don't give a sh*t anymore to try to
get that stuff into the main tree, because they were alienated long ago.

The image of the games team is so bad, that not even gentoo devs bother
anymore (except me, uh). Yet neither the council, nor comrel has done
anything radical, except giving recommendations, asking for them to
elect a new lead, blah blah.

In a distributed model this project would just have been abandoned by
the community 8 years ago and people would have started a new fresh
overlay. Currently this all sucks, because it will conflict with in-tree
ebuilds and because we don't have good enough tools for this kind of model.

> People love to talk about elitist old-timers blocking progress, but it
> seems to me that many of the old-timers don't do a whole lot of
> anything.  I think the complaint is really that other people aren't
> doing the work we want them to do.
> 

It's not about elitist old-timers, it's about a more dynamic model that
has low tolerance for
* bugs being open since 8+ years, because no one bothers to
review/change stuff (check nethack bug)
* territorial behaviour
* slacking devs slacking so hard, but not stepping down

In addition, this model requires a workflow that is long overdue,
including proper VCS like git or mercurial and a review culture. None of
this happens on a larger scale. Instead we are stuck with tools like
bugzilla for ebuild reviews and push our happy ebuilds to the CVS
repository.

So now guess again why people don't bother, because:
* have to become gentoo devs over a period of 6 months or so, then
realize they are stuck with territorial crap, people ignoring each other
and have to appeal to the council, comrel or whoever multiple times
before something happens?
* or they have to write bugs reports on bugzilla, attach ebuilds
manually, get a partly review in a timeframe of 9 months if they are
lucky, re-push attachments, start again
* or they can try to contribute to sunrise which may be simirlarly slow
(mind you, I've been a sunrise dev, so we can talk about that if you like)
* or they just start their own overlay and stop caring to collaborate
with gentoo devs
* If they are very lucky, then their favorite project already uses an
overlay-workflow (e.g. haskell, science). And those projects usually are
so slow with moving their overlay ebuilds into the tree, that it's
almost useless doing so. They should just stop and focus on their overlays.

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

[Rich Freeman]

On Sat, Nov 22, 2014 at 5:44 PM, hasufell <hasufell@gentoo.org> wrote:
> On 11/22/2014 11:20 PM, Rich Freeman wrote:
>>
>> Nobody can block progress under the current model.  If you feel
>> otherwise, please point them out so that they can be dealt with.
>>
>
> They can block progress and they do. And by saying we allow conflicting
> ideas in one repository we are even making it worse.
>
> The council is a workaround to make the broken project structure not
> look too bad.

What do you do if somebody blocks progress in your overlay structure?
You start another one.

What do you do if somebody blocks progress in the current Gentoo
project structure?  You either ask the Council for help, or start
another project.

You have just as many options under the status quo, and actually more.

Now, what you would get is the ability to have more variety in quality
standards, since general QA/etc would not apply.

>
> I strongly disagree. I know a fair amount of games overlays where people
> do work on games ebuilds. They just don't give a sh*t anymore to try to
> get that stuff into the main tree, because they were alienated long ago.

Well, then by your argument there is nothing wrong, since they're
already in the distributed model.  There is nothing I can do about
people feeling alienated.

If you want to contribute to Gentoo, then do it.  If somebody blocks
your progress then ask for help.

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.

>
> The image of the games team is so bad, that not even gentoo devs bother
> anymore (except me, uh). Yet neither the council, nor comrel has done
> anything radical, except giving recommendations, asking for them to
> elect a new lead, blah blah.

The games team has ZERO power over any dev doing anything to any
package in the tree.  That was the outcome of the most recent Council
decision.  We didn't disband the team because we thought that having a
team focused on games wasn't a bad idea, but so far nobody else seems
all that interested so it seems as likely as not that there won't be a
games team in the future.

How is that not doing something radical?  What more do you want us to do?

>
> It's not about elitist old-timers, it's about a more dynamic model that
> has low tolerance for
> * bugs being open since 8+ years, because no one bothers to
> review/change stuff (check nethack bug)
> * territorial behaviour
> * slacking devs slacking so hard, but not stepping down

The reason the nethack bug is still open is because nobody cares
enough to fix it.  ANYBODY can make themselves a maintainer of Nethack
right now and fix the bug.  The reason that the Nethack bug is still
open is because you apparently care enough about it to post about it,
but not enough to fix it.  I'm not going to fix it, because I don't
use Nethack.

The issues you bring up were an issue in the past, and nobody really
has any tolerance for it these days.  You keep bringing up past issues
that have been fixed, which really sounds to me like a demonstration
that we're running out of real current issues to fix.

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.

>
> In addition, this model requires a workflow that is long overdue,
> including proper VCS like git or mercurial and a review culture. None of
> this happens on a larger scale. Instead we are stuck with tools like
> bugzilla for ebuild reviews and push our happy ebuilds to the CVS
> repository.

Sounds great.  Looking forward to your contributions to the git
migration, which by all indications is just about done.  Maybe you
could get started on a gerrit front-end or something.

>
> So now guess again why people don't bother, because:
> * have to become gentoo devs over a period of 6 months or so, then
> realize they are stuck with territorial crap, people ignoring each other
> and have to appeal to the council, comrel or whoever multiple times
> before something happens?

Most of this stuff is fixed, and every issue that has come up in the
last year has been resolved in the course of a single Council meeting.
Please cite an example to the contrary.  Having attended just about
every Council meeting in the last year I can cite plenty of cases
where stuff like this was fixed.

> * or they have to write bugs reports on bugzilla, attach ebuilds
> manually, get a partly review in a timeframe of 9 months if they are
> lucky, re-push attachments, start again
> * or they can try to contribute to sunrise which may be simirlarly slow
> (mind you, I've been a sunrise dev, so we can talk about that if you like)
> * or they just start their own overlay and stop caring to collaborate
> with gentoo devs

You realize that the last point is basically your proposed solution.
If they don't want to do this today, why would they want to do it
tomorrow?  They're not going to be collaborating with Gentoo devs
under your model, since there won't be all that many of them to
collaborate with.

> * If they are very lucky, then their favorite project already uses an
> overlay-workflow (e.g. haskell, science). And those projects usually are
> so slow with moving their overlay ebuilds into the tree, that it's
> almost useless doing so. They should just stop and focus on their overlays.
>

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.

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.

--
Rich

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

[Nicolas Sebrecht]

On Sat, Nov 22, 2014 at 06:20:01PM -0500, Rich Freeman wrote:

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

I'd say the problem is not about the devs themselves causing conflicts
but the environment and frame devs are working in the current workflow.
Everybody look baffled with the current way of doing things in Gentoo.

I agree with hasukel that the "distributed Gentoo" as proposed today is
a wrong answer.  Not that the issues raised are not valid. They do.

Also, I agree with hasukel that the main problem is about having a
correct distributed model. Posting on bugzilla for ebuilds updates or
new ebuilds is seriously damaging when almost every where else it is
just about sending your git patches. Becoming an official Gentoo dev is
not a solution either due to the recruiting process.

As you say, official devs can work on whatever they like and their
contributions will likely hit the users at some point while at the same
time occasional devs are asked to work with old tools like bugzilla. So
yes, the whole review process is broken and the contribution process is
broken too.

About that, there's no other way than break the whole recruiting process
and change of tools. Have your core team handle git repositories and let
others request pull or send patches like almost all the other open
source softwares in the world. Let's exploit the anarchy and openness
instead of partitionning things into devs/non-devs or main-tree/overlays.


Back to the original request. Here is how starts the "distributed
Gentoo" model:

  Imagine you would say "I like gentoo, but I don't like the way the
  toolchain is handled, so I want to do it differently". Currently, your
  only way is to fork the whole distro or do dangerous stuff with
  overlays.
  
  Imagine gentoo would actually be a small repository of core packages
  with lots of optional user contributed extenions of all kinds. You'd
  only need to fork the core and add those extensions you like.
  
  Similarly... you don't like the way ruby is handled? Well, apart from
  dev-lang/ruby maybe, there'd be no ruby gems in the tree anyway. So
  there can be different approaches of packaging ruby gems and you choose
  which to use or if you want to do it completely different. And there
  would be no complicated configuration required to prevent in-tree ruby
  packages getting pulled in, because there are none.

Isn't this all stuff about handling some kind of pointers? Don't like
the toolchain? Point to another one. Don't like the way ruby is handled?
Point to another one.

So, is it about overlays? No. I'd say overlays are some kind of poor
pointers for many reasons.

Hence, why not adding the pointers we are all missing and rethinking the
other pointers?

-- 
Nicolas Sebrecht

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

[Volker Armin Hemmann]

Am 23.11.2014 um 16:18 schrieb Nicolas Sebrecht:
> On Sat, Nov 22, 2014 at 06:20:01PM -0500, Rich Freeman wrote:
>
>> 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.  
> I'd say the problem is not about the devs themselves causing conflicts
> but the environment and frame devs are working in the current workflow.
> Everybody look baffled with the current way of doing things in Gentoo.
>
> I agree with hasukel that the "distributed Gentoo" as proposed today is
> a wrong answer.  Not that the issues raised are not valid. They do.
>
> Also, I agree with hasukel that the main problem is about having a
> correct distributed model. Posting on bugzilla for ebuilds updates or
> new ebuilds is seriously damaging when almost every where else it is
> just about sending your git patches. Becoming an official Gentoo dev is
> not a solution either due to the recruiting process.
>
> As you say, official devs can work on whatever they like and their
> contributions will likely hit the users at some point while at the same
> time occasional devs are asked to work with old tools like bugzilla. So
> yes, the whole review process is broken and the contribution process is
> broken too.
>
> About that, there's no other way than break the whole recruiting process
> and change of tools. Have your core team handle git repositories and let
> others request pull or send patches like almost all the other open
> source softwares in the world. Let's exploit the anarchy and openness
> instead of partitionning things into devs/non-devs or main-tree/overlays.
>
>
> Back to the original request. Here is how starts the "distributed
> Gentoo" model:
>
>   Imagine you would say "I like gentoo, but I don't like the way the
>   toolchain is handled, so I want to do it differently". Currently, your
>   only way is to fork the whole distro or do dangerous stuff with
>   overlays.
>   
>   Imagine gentoo would actually be a small repository of core packages
>   with lots of optional user contributed extenions of all kinds. You'd
>   only need to fork the core and add those extensions you like.
>   
>   Similarly... you don't like the way ruby is handled? Well, apart from
>   dev-lang/ruby maybe, there'd be no ruby gems in the tree anyway. So
>   there can be different approaches of packaging ruby gems and you choose
>   which to use or if you want to do it completely different. And there
>   would be no complicated configuration required to prevent in-tree ruby
>   packages getting pulled in, because there are none.
>
> Isn't this all stuff about handling some kind of pointers? Don't like
> the toolchain? Point to another one. Don't like the way ruby is handled?
> Point to another one.
>
> So, is it about overlays? No. I'd say overlays are some kind of poor
> pointers for many reasons.
>
> Hence, why not adding the pointers we are all missing and rethinking the
> other pointers?
>

am I the only one who thinks that this way leads to madness?

Version conflicts are bad enough. No multiply that with a bunch of
overlays, all having their own libXY with just some tiny, tiny
differences, and another bunch of overlays who want libXY from certain
others....

if that does not give you nightmares, I don't know what.

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

[Nicolas Sebrecht]

On Sun, Nov 23, 2014 at 04:31:45PM +0100, Volker Armin Hemmann wrote:

> am I the only one who thinks that this way leads to madness?
> 
> Version conflicts are bad enough.

First, version conflicts have their roots in the support for versions of
libraries in softwares. This is the best place to fix that when
possible.

When it comes to ebuilds maintainers, version conflicts are about all
about DECLARATIONS. If software A need Y-v1..12, we should have a way
for the maintainers to declare that A relies on Y-v1..12 and let the
dependency softwares to the hard job and admin/users handle them the way
they want.
Today, this is badly managed with implicit expectations everywhere.

Also, there are ways to overcome version conflicts. Slots are one of
them.

>                                   No multiply that with a bunch of
> overlays, all having their own libXY with just some tiny, tiny
> differences, and another bunch of overlays who want libXY from certain
> others....

That's a reason why I said that overlays are a poor kind of pointers.

For overlay maintainers today, if the main portage tree does not offer
what they expect, the only option they have is to rewrite their own
"static" dependency tree with their own ebuilds. That sucks.

Portage should support a way to expose ALL the conditions for a software
to work and update installed libraries to match the requirements.

-- 
Nicolas Sebrecht

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

[Volker Armin Hemmann]

Am 23.11.2014 um 18:33 schrieb Nicolas Sebrecht:
> On Sun, Nov 23, 2014 at 04:31:45PM +0100, Volker Armin Hemmann wrote:
>
>> am I the only one who thinks that this way leads to madness?
>>
>> Version conflicts are bad enough.
> First, version conflicts have their roots in the support for versions of
> libraries in softwares. This is the best place to fix that when
> possible.
>
> When it comes to ebuilds maintainers, version conflicts are about all
> about DECLARATIONS. If software A need Y-v1..12, we should have a way
> for the maintainers to declare that A relies on Y-v1..12 and let the
> dependency softwares to the hard job and admin/users handle them the way
> they want.
> Today, this is badly managed with implicit expectations everywhere.
>
> Also, there are ways to overcome version conflicts. Slots are one of
> them.
>
>>                                   No multiply that with a bunch of
>> overlays, all having their own libXY with just some tiny, tiny
>> differences, and another bunch of overlays who want libXY from certain
>> others....
> That's a reason why I said that overlays are a poor kind of pointers.
>
> For overlay maintainers today, if the main portage tree does not offer
> what they expect, the only option they have is to rewrite their own
> "static" dependency tree with their own ebuilds. That sucks.
>
> Portage should support a way to expose ALL the conditions for a software
> to work and update installed libraries to match the requirements.
>

and you want portage to finish on this site of eternity when looking for
dependency resolution?

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

[Nicolas Sebrecht]

On Sun, Nov 23, 2014 at 07:25:26PM +0100, Volker Armin Hemmann wrote:

> and you want portage to finish on this site of eternity when looking for
> dependency resolution?

I don't think having exposed requirements would explode the time needed
to calculate the dependency tree because this does not add paths to the
tree. It only validates or invalidates paths.

And if time for dependency resolution would become a real problem, there
are ways to solve that. One could be making pre-calcultated caches of
parts of tree/paths.

-- 
Nicolas Sebrecht

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

[Volker Armin Hemmann]

Am 23.11.2014 um 19:54 schrieb Nicolas Sebrecht:
> On Sun, Nov 23, 2014 at 07:25:26PM +0100, Volker Armin Hemmann wrote:
>
>> and you want portage to finish on this site of eternity when looking for
>> dependency resolution?
> I don't think having exposed requirements would explode the time needed
> to calculate the dependency tree because this does not add paths to the
> tree. It only validates or invalidates paths.
>
> And if time for dependency resolution would become a real problem, there
> are ways to solve that. One could be making pre-calcultated caches of
> parts of tree/paths.
>

which works so well with different useflags.

portage is already almost unbearable slow. The 'distributed model' would
add so much complexity, we can forget USE.

For what gains?

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

[Rich Freeman]

On Sun, Nov 23, 2014 at 12:33 PM, Nicolas Sebrecht
<nicolas.s-dev@laposte.net> wrote:
> Portage should support a way to expose ALL the conditions for a software
> to work and update installed libraries to match the requirements.
>

This sounds nice in principle, but making it work is not trivial.

Suppose my package works with gcc-1.2.3.4 with a list of 14 specific
patches and no others, and glibc-1.2.3.4 with another list of 14
patches and no others.  Now suppose 300 other packages have similar
requirements.

First, expressing that without losing your mind is going to be VERY
painful.  You basically end up having to use content-hashed packages
or something like that.  You also end up with 300 copies of glibc in
RAM and so on.

Second, good luck dealing with security patches and bugfixes.  You now
have 300 copies of glibc to update, and since your list of
dependencies stated that you have 14 patches and no others you now
need to update the 300 other packages to use the newer version of
glibc.

The current Gentoo way is far more limiting, but by having a single
version of glibc with a single policy around versioning/etc packages
don't have to micromanage what they depend on.

If NixOS/etc have found a better solution I'm all ears, but it is hard
to tell based on the info on their website.  It seems hard to me to
allow so much diversity in dependencies without basically having every
package on your system running in its own container (thus consuming a
lot more RAM), and while managing security updates in a sane way.

--
Rich

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

[Nicolas Sebrecht]

On Sun, Nov 23, 2014 at 02:30:12PM -0500, Rich Freeman wrote:
> On Sun, Nov 23, 2014 at 12:33 PM, Nicolas Sebrecht
> <nicolas.s-dev@laposte.net> wrote:
> > Portage should support a way to expose ALL the conditions for a software
> > to work and update installed libraries to match the requirements.
> 
> This sounds nice in principle, but making it work is not trivial.
> 
> Suppose my package works with gcc-1.2.3.4 with a list of 14 specific
> patches and no others, and glibc-1.2.3.4 with another list of 14
> patches and no others.  Now suppose 300 other packages have similar
> requirements.

To make it simple, this is almost irrelevant IMHO. It won't happen
because we are talking about patches required as dependency excluding
other patches required as dependency on the same sources.

IOW, we must notice that we would need multiple *installed* versions
ONLY IF a dependency requirement is not met AND that this requirement is
*excluding* one of the current gcc requirements. So, when they are
non-compatible themselves in some way at the source level.

On top of that, this would have to be an issue that has to be handled by
the software devs.

> Second, good luck dealing with security patches and bugfixes.  You now
> have 300 copies of glibc to update, and since your list of
> dependencies stated that you have 14 patches and no others you now
> need to update the 300 other packages to use the newer version of
> glibc.
> 
> The current Gentoo way is far more limiting, but by having a single
> version of glibc with a single policy around versioning/etc packages
> don't have to micromanage what they depend on.

Well, I wouldn't worry about that because having 300 versions of gcc (or
any other package) is not the purpose. But it is a very good thing to
restart the thread from patches handling like you did since it is the
basis of software updates.

When it comes to building a real and flexible meta-distribution (after
all, this thread is all this issue), it is nice to have the packages
management tools working for you.

Also, it is good to keep in mind that everybody in the chain from the
software developers to the users including fork developers,
package-distro maintainers, sysadmin and the final users might want to
tune their systems at some point. They are all some kind of "forkers"
with the current Gentoo.

Starting from there, the tools should not only allow them to do what
they want but also help them in that task WHITOUT forking. If it's not
the case, you end up with overlays or similar technics whose come which
much more damaging problems in practice.


All distributions manage vanilla sources + patches (including security
patches and bugfixes). We start from vanilla with compilation options.
Each one is declared so they are enabled/disabled easily (use flags...).
Would it be that hard to declare if the patch add/remove/change a
dependency? I don't think so.

Now comes the series of patches management. Would it be hard to have the
tools allowing to tune the series of patches that are going to be
applied? I don't think so, either.

Would it be hard to have the tools allow each role to tune/configure the
system for both useflags and series of patches? Neither, we know how to
do that kind of things since decades.

So, when there are security fixes or bugfixes we don't need anything
much crazy to handle them: the management of series of patches is
already supported of the tools.


Today, ebuilds don't even let a chance for an admin to apply a series of
patches to the vanilla/distro-maintainer sources without having to
rewrite/fork the ebuild. Whatever it is critical for them. The lone
option is to fork+overlay. This is a serious issue FMPOV.

> If NixOS/etc have found a better solution I'm all ears, but it is hard
> to tell based on the info on their website.  It seems hard to me to
> allow so much diversity in dependencies without basically having every
> package on your system running in its own container (thus consuming a
> lot more RAM), and while managing security updates in a sane way.

I don't know about NixOS/etc. I'll look at that.

About containers, they are usefull for solving other problems like
testing, deployement or required isolation, IMO.

-- 
Nicolas Sebrecht

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

[Nicolas Sebrecht]

On Sun, Nov 23, 2014 at 08:15:26PM +0100, Volker Armin Hemmann wrote:

> which works so well with different useflags.

Yes, things need improvements.

-- 
Nicolas Sebrecht

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

[Volker Armin Hemmann]

Am 23.11.2014 um 21:54 schrieb Nicolas Sebrecht:
>
> Today, ebuilds don't even let a chance for an admin to apply a series of
> patches to the vanilla/distro-maintainer sources without having to
> rewrite/fork the ebuild. Whatever it is critical for them. The lone
> option is to fork+overlay. This is a serious issue FMPOV.

that is not true.

the rest: too long for me to read on a sunday night.

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

[Alan McKinnon]

On 23/11/2014 22:54, Nicolas Sebrecht wrote:
> On Sun, Nov 23, 2014 at 02:30:12PM -0500, Rich Freeman wrote:
>> On Sun, Nov 23, 2014 at 12:33 PM, Nicolas Sebrecht
>> <nicolas.s-dev@laposte.net> wrote:
>>> Portage should support a way to expose ALL the conditions for a software
>>> to work and update installed libraries to match the requirements.
>>
>> This sounds nice in principle, but making it work is not trivial.
>>
>> Suppose my package works with gcc-1.2.3.4 with a list of 14 specific
>> patches and no others, and glibc-1.2.3.4 with another list of 14
>> patches and no others.  Now suppose 300 other packages have similar
>> requirements.
> 
> To make it simple, this is almost irrelevant IMHO.


I'll tell you what I'm seeing.

I'm seeing a theoretical description of magic software that mathematics
predicts can exist. I don't see running software.

How about you write running software that does what you describe, then
we can talk more, m'kay?




-- 
Alan McKinnon
alan.mckinnon@gmail.com

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

[hasufell]

On 11/23/2014 12:20 AM, Rich Freeman wrote:
> On Sat, Nov 22, 2014 at 5:44 PM, hasufell <hasufell@gentoo.org> wrote:
>> On 11/22/2014 11:20 PM, Rich Freeman wrote:
>>>
>>> Nobody can block progress under the current model.  If you feel
>>> otherwise, please point them out so that they can be dealt with.
>>>
>>
>> They can block progress and they do. And by saying we allow conflicting
>> ideas in one repository we are even making it worse.
>>
>> The council is a workaround to make the broken project structure not
>> look too bad.
> 
> What do you do if somebody blocks progress in your overlay structure?
> You start another one.
> 
> What do you do if somebody blocks progress in the current Gentoo
> project structure?  You either ask the Council for help, or start
> another project.
> 
> 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.

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.

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)

>>
>> I strongly disagree. I know a fair amount of games overlays where people
>> do work on games ebuilds. They just don't give a sh*t anymore to try to
>> get that stuff into the main tree, because they were alienated long ago.
> 
> Well, then by your argument there is nothing wrong, since they're
> already in the distributed model.  There is nothing I can do about
> people feeling alienated.
> 

First of all they are not really in a properly designed distributed
model as I described just because they run an overlay. Most of them end
with ::mynick, are randomly themed and not reviewed.

Again: this is a culture thing and we have to make ourselves some
policies on how this can work well.

Random overlay != distributed model.

Second thing: sure can we do something about people feeling alienated. A
lot. We can:
* abandon CVS finally
* have proper contribution channels (NOT bugzilla)
* kickban major assholes from the community, no matter how efficient
they are
* 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)
* have a _working_ comrel project
* fix project internal communication... it's unbelievably bad
* stop the way we are recruiting, it's utterly tedious
* ...

> If you want to contribute to Gentoo, then do it.  If somebody blocks
> your progress then ask for help.
> 

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

>>
>> The image of the games team is so bad, that not even gentoo devs bother
>> anymore (except me, uh). Yet neither the council, nor comrel has done
>> anything radical, except giving recommendations, asking for them to
>> elect a new lead, blah blah.
> 
> The games team has ZERO power over any dev doing anything to any
> package in the tree.  That was the outcome of the most recent Council
> decision.  We didn't disband the team because we thought that having a
> team focused on games wasn't a bad idea, but so far nobody else seems
> all that interested so it seems as likely as not that there won't be a
> games team in the future.
> 
> How is that not doing something radical?  What more do you want us to do?
> 

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!

That's how opensource works. Writing stuff modular, so that people don't
have to fork the kernel, just because they don't like the icon theme.

>>
>> It's not about elitist old-timers, it's about a more dynamic model that
>> has low tolerance for
>> * bugs being open since 8+ years, because no one bothers to
>> review/change stuff (check nethack bug)
>> * territorial behaviour
>> * slacking devs slacking so hard, but not stepping down
> 
> The reason the nethack bug is still open is because nobody cares
> enough to fix it.  ANYBODY can make themselves a maintainer of Nethack
> right now and fix the bug.  The reason that the Nethack bug is still
> open is because you apparently care enough about it to post about it,
> but not enough to fix it.  I'm not going to fix it, because I don't
> use Nethack.
> 
> The issues you bring up were an issue in the past, and nobody really
> has any tolerance for it these days.  You keep bringing up past issues
> that have been fixed, which really sounds to me like a demonstration
> that we're running out of real current issues to fix.
> 
> 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.


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

> 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 was just bringing it up as an _additional_ argument
why I find the distributed approach more interesting... because it makes
it easier to regroup and abandon toxic people without having to fight
them for years.

Nothing of what I say is vague. It is already implemented and I pointed
it out. If you refuse to look at it or recognize it, then that's not my
fault.

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

[Volker Armin Hemmann]

Am 23.11.2014 um 22:14 schrieb Alan McKinnon:
> On 23/11/2014 22:54, Nicolas Sebrecht wrote:
>> On Sun, Nov 23, 2014 at 02:30:12PM -0500, Rich Freeman wrote:
>>> On Sun, Nov 23, 2014 at 12:33 PM, Nicolas Sebrecht
>>> <nicolas.s-dev@laposte.net> wrote:
>>>> Portage should support a way to expose ALL the conditions for a software
>>>> to work and update installed libraries to match the requirements.
>>> This sounds nice in principle, but making it work is not trivial.
>>>
>>> Suppose my package works with gcc-1.2.3.4 with a list of 14 specific
>>> patches and no others, and glibc-1.2.3.4 with another list of 14
>>> patches and no others.  Now suppose 300 other packages have similar
>>> requirements.
>> To make it simple, this is almost irrelevant IMHO.
>
> I'll tell you what I'm seeing.
>
> I'm seeing a theoretical description of magic software that mathematics
> predicts can exist. I don't see running software.
>
> How about you write running software that does what you describe, then
> we can talk more, m'kay?
>
>
>
>
oh, the magical cantation known as 'write the code or shut up' ...

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

[Rich Freeman]

On Sun, Nov 23, 2014 at 5:50 PM, hasufell <hasufell@gentoo.org> 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

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

[hasufell]

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?

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

[Rich Freeman]

On Sun, Nov 23, 2014 at 6:45 PM, hasufell <hasufell@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

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

[hasufell]

On 11/24/2014 12:24 AM, Rich Freeman wrote:
>> * 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.
> 

That's actually an argument FOR my proposal of being more distributed
and shrinking the dev community.

In such a scenario we would not need 200 "gentoo developers" anymore.

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

[Rich Freeman]

On Sun, Nov 23, 2014 at 7:12 PM, hasufell <hasufell@gentoo.org> wrote:
> On 11/24/2014 12:24 AM, Rich Freeman wrote:
>>> * 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.
>>
>
> That's actually an argument FOR my proposal of being more distributed
> and shrinking the dev community.
>
> In such a scenario we would not need 200 "gentoo developers" anymore.
>

Sure, but my point is that the way to fix this is:
1.  Set up new distributed model.
2.  Work in the new model successfully for a while.
3.  Retire developers who are no longer needed since they won't be
doing anything anyway.

And not:
1.  Stop recruiting new devs.
2.  Watch attrition get rid of existing devs.
3.  Work on new distributed model that may or may not ever take off.
4.  Hope that Gentoo doesn't die in the meantime.

--
Rich

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

[Sid S]

[-- Attachment #1: Type: text/plain, Size: 3275 bytes --]

>We didn't disband the team because we thought that having a
>team focused on games wasn't a bad idea, but so far nobody else seems
>all that interested so it seems as likely as not that there won't be a
>games team in the future.

Probably a chicken-and-egg thing. I want to play games on my Gentoo, or a
vm hosted by Gentoo, but doing so can be a pain. Is there any reason to
cater to this demographic specifically? Well, no, but making it less hard
would require solving some nontrivial problems others might benefit from.
Which is the purpose of Gentoo, right?

As for Java, I've not encountered any major bugs. This might be why nobody
is talking about Java bugs. If there are any bugs with the introduction of
Java 1.8, again, there's no reason to cater to the demographic that wants
Java 8, but it will likely solve hard problems. Java is something I should
be able to use by accident. It is almost entirely self-contained.

Solving these hard problems is likely to help in other areas. For example,
let me refer to another portion of the conversation below:

>The current Gentoo way is far more limiting, but by having a single
>version of glibc with a single policy around versioning/etc packages
>don't have to micromanage what they depend on.

I actually think this is wrong. The Gentoo way might be limiting in some
respects, but the reality seems to be it is limited by the software it is
working with more than the other way around.

So... what's a better way to do things? NI,SF. Do-autocracy suffers from
the challenging problem of challenging problems being avoided.

>On top of that, this would have to be an issue that has to be handled by
>the software devs.

If only the universe were ebuilds and not turtles.

>Today, ebuilds don't even let a chance for an admin to apply a series of
>patches to the vanilla/distro-maintainer sources without having to
>rewrite/fork the ebuild.

There isn't a way to specify ebuild properties in a way like command line
arguments? Where you can explicitly silence options by specifying them
later, etc?

On Sun, Nov 23, 2014 at 6:30 PM, Rich Freeman <rich0@gentoo.org> wrote:

> On Sun, Nov 23, 2014 at 7:12 PM, hasufell <hasufell@gentoo.org> wrote:
> > On 11/24/2014 12:24 AM, Rich Freeman wrote:
> >>> * 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.
> >>
> >
> > That's actually an argument FOR my proposal of being more distributed
> > and shrinking the dev community.
> >
> > In such a scenario we would not need 200 "gentoo developers" anymore.
> >
>
> Sure, but my point is that the way to fix this is:
> 1.  Set up new distributed model.
> 2.  Work in the new model successfully for a while.
> 3.  Retire developers who are no longer needed since they won't be
> doing anything anyway.
>
> And not:
> 1.  Stop recruiting new devs.
> 2.  Watch attrition get rid of existing devs.
> 3.  Work on new distributed model that may or may not ever take off.
> 4.  Hope that Gentoo doesn't die in the meantime.
>
> --
> Rich
>
>

[-- Attachment #2: Type: text/html, Size: 4040 bytes --]

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

[Rich Freeman]

On Mon, Nov 24, 2014 at 3:20 AM, Sid S <r030t1@gmail.com> wrote:
>
>>Today, ebuilds don't even let a chance for an admin to apply a series of
>>patches to the vanilla/distro-maintainer sources without having to
>>rewrite/fork the ebuild.
>
> There isn't a way to specify ebuild properties in a way like command line
> arguments? Where you can explicitly silence options by specifying them
> later, etc?
>

Any environment-level property can be overridden at the command line,
though this does not include patching.

However, the original claim is still wrong - you just stick the
patches in /etc/portage/patches.  This only works for ebuilds that
call epatch_user right now, but for EAPI6 it will work for all
packages.

--
Rich

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

[Sid S]

[-- Attachment #1: Type: text/plain, Size: 919 bytes --]

Oh. I've had to use that, even. I was thinking patches of ebuilds. (???)

On Mon, Nov 24, 2014 at 6:41 AM, Rich Freeman <rich0@gentoo.org> wrote:

> On Mon, Nov 24, 2014 at 3:20 AM, Sid S <r030t1@gmail.com> wrote:
> >
> >>Today, ebuilds don't even let a chance for an admin to apply a series of
> >>patches to the vanilla/distro-maintainer sources without having to
> >>rewrite/fork the ebuild.
> >
> > There isn't a way to specify ebuild properties in a way like command line
> > arguments? Where you can explicitly silence options by specifying them
> > later, etc?
> >
>
> Any environment-level property can be overridden at the command line,
> though this does not include patching.
>
> However, the original claim is still wrong - you just stick the
> patches in /etc/portage/patches.  This only works for ebuilds that
> call epatch_user right now, but for EAPI6 it will work for all
> packages.
>
> --
> Rich
>
>

[-- Attachment #2: Type: text/html, Size: 1397 bytes --]

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

[James]

Rich Freeman <rich0 <at> gentoo.org> writes:


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


Your eyes are fine. Gmane's web interface was hosed. I tried to use
nntp (earlybird) but that interface does not consistently respond 
to the thread, so hacking at the settings and posting(tests) seems
to upset some.....

I appreciate your ideas, I mostly like the ideas of distributed development
for non "core" modules. I also believe and Rich as articulated, that 
we mostly have thing now. Where I diagree with Rich is this. Sure,
If somebody has been a gentoo dev for years, has push access
then they can get coding completed.  If you are new to the depths
of what gentoo devs do, then it is opaque as to which docs to read,
dealing with the technical details that are currently used and which
are either not documented or poorly documented, etc etc. It's not
that any of the devs have a desire to keep folks from becoming deeply
capable devs such as themselves, it that these "elites" spend very
little time, paving a path for others "fledgling devs"; so the
the cost barrier to gaining inside (current) knowledge is very him,
imho. Most will just drift to anothe distro where that sort of help
is more redily available.  Thank god for SVEN. But, he cannot clean
up the myriad of docs that need tlc. What you do not seem to "comprehend"
Rich, is what most non super_devs want is some help, imho. Just look
back at your harsh postings on java. It's rather crushing for folks
that want to use Java. Quite simply, I'm developing the skills to
use java on gentoo. Those keen developers within the java team, are
spread very thin; just look at what they are recruiting for:


http://wiki.gentoo.org/wiki/Project:Gentoo/Staffing_Needs


So I understand that you are not interested in Java. So, how do
we find or develop a "gentoo-inner-circle-java-interested" dev?
With out that java does not have a chance to gain traction within
gentoo, imho. OK, so dont beat me up for being lazy (stupid as
volker points out routinely) just *help me* via private email
who at Gentoo is the java wizard?  I'll do tons of grunt work
to make then happy.?  OK?

Oh shit: problem one. Go clean up BGO's java bugs. I cant because
it has become a circular cluster_F!.  Too many old blocking bugs;
nobody (who gives a shit) with the authority to purge java bugs.



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

Rich, there are billions of Java codes, available in source form
that can easily have ebuilds created. But we have poor support 
for maven, etc. So they go nowhere. (I believe a gentoo-dev for 
maven is the blocker here. I know that Maven is not easy. I am
not (yet) close to being qualified to work on deep maven issues
withing gentoo.


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

see details above?



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


Ah, I think Hasufell has very good intentions and some keen ideas.
My fear is java is getting not love from the gentoo innner circle.
So we reduce the innner circle dev count, move java to the perimeter
(where nobody cares that is remotely connected to the inner-circle)
and java get's better?  I've seen this sort of thing thousands of
times in my life. Java will just be purged from Gentoo, reticent on
your previous postings about your feelings towards Java.


Another council member in 2013 was all encouraging about gentoo-clustering.
But now that clustering is mostly java centric (imho), few at 
Gentoo care about cluster on gentoo. Convenient. Sad. Not really
encourage to the fledgling community that are willing to work on
java, but need leadership.


I put (2) ebuilds into BGO. apache-mesos and apache-spark. 
bugs 510912 and 523412. There they languish.

Following the outside overlay semantic guidance, newer versions are here,
thanks to Alec:

https://github.com/trozamon/overlay/tree/master/sys-cluster

So as you point out, go and work on what you want. Really? You think
they'll get move to the gentoo tree any time soon? I'm mostly  looking
for help, encouragement and guidance. I am not looking for harsh
reponses that are discouraging. I am not trying to harash you, I appreciate
what you do for Gentoo, very much. I get you are not interested in
anything remotely connected to java. I would appreciated your keen
insight into finding us a java leader that is not burnt to a crisp
by the gentoo-stress-burnout syndrome that seems to surging, again.


If you want java to prosper at Gentoo, it's gonna take an "inner-circle"
gentoo-dev to at least cheerlead for java within gentoo, imho.


hth,
James

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

[Andreas K. Huettel]

Am Montag 24 November 2014, 18:13:56 schrieb James:

> 
> If you want java to prosper at Gentoo, it's gonna take an "inner-circle"
> gentoo-dev to at least cheerlead for java within gentoo, imho.
> 

I'm not really sure what this "inner-circle" stuff is supposed to mean. 

You need a gentoo-dev who is interested and willing to talk to and to listen 
to the existing java team members, and willing to invest quite some time and 
effort.

I have absolutely no clue about the state of java in Gentoo, but for the sake 
of the argument let's assume that the team is understaffed and the ebuild 
architecture is in need of a general overhaul. 

Then what one would have to do is understand how things are done now and why 
(listening helps sometimes more than talking talking talking). Java has some 
pretty complex eclasses, so it'll take some time until you understand them. 
First start with small improvements and then with bigger steps. At some point 
you get along with the existing team and plan the big reforms with them.

This may need dedication and patience, and is not always best served by the 
CADT phenomenon. It definitely does not get better by forking the code into N 
random overlays. And proposing a Java revolution because the existing team 
does not immediately jubilate at your extensive reform proposals is also not 
necessarily the best idea.

ok now I just have to go to Starbucks.

-- 
Andreas K. Huettel
Gentoo Linux developer
kde, council

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

[thegeezer]

On 2014-11-22 18:12, wireless@tampabay.rr.com wrote:

> The first 100 or so I looked at, are deprecated. They just need 
> somebody
> to 'remove them' the BGO java backlog is being artificially used to
> prevent java work on gentoo. Somebody of authority needs to open
> up java for other folks to work on. Close the 100 oldest bugs
> is a no brainer and a good start, yet nobody will do that, and nobody
> else is allowed to close them.

As i've been reading this thread it appears to be more and more that 
there is a large feeling of a commune.  It's not so much the hippy free 
living and off grid everyone helping each other that most imagine it to 
be but more an argument over who is going to buy the toilet paper this 
week.

I've been using gentoo a while now and it was the incredible 
documentation that turned me on to it, and these days if i need help 
with something i'll go via man page, then the originator website and 
eventually i might go to gentoo forums or look at the source code.

we are all in this together and our love of freedom, choice combined 
with our collective sheer bloody minded-ness means we are unlikely to 
drop gentoo for anything else.

now, we are all flying from the seat of our pants, and there are a few 
saying "how do i help gentoo". i understand the confusion with this 
question because i've kind of looked myself and not really got past the 
first step. there was even a thread in this mailing list nearly a year 
and a half ago asking the same thing [1]

all of gentoo council meetings happen on irc if i remember right so it's 
not like there is an elite group deciding fate they are just sorting 
things that need to be sorted.

do we really need a "mark shuttleworth" to start a rallying cry saying 
"this way" and drawing a line in the sand we must hop over?
maybe it's just a shepherd to be more active in the recruitment and then 
its a case of -- where to start collecting people?
perhaps in the staffing requirements there should be a gentoo marketeer 
to push more information out to planet gentoo [2] ? there was another 
discussion about "the end of herds" and this kind of thing really needs 
to be voiced louder to maintain transparency, though it doesn't affect 
me directly.

i think i need to get in touch with the project:documentation team and 
see if i can help as there exists a java project page [3]  but this is 
not mentioned in the wiki for an example [4] of what adds to confusion

maybe what we need is a gentoo "unifier" to ensure that all content is 
unified across all information channels (old and new wikis, mailing 
lists, forums). good luck with that role...and finally i leave you with 
[5] a link to soylentnews with the kind of openness and transparency 
that it would be incredible to see from gentoo.org. i appreciate a news 
site that spawned because of hatred of slashdot's beta program is not 
the same thing as a linux meta-distribution however, there are anonymous 
contributors, folks responsible for things and yet someone who is 
actively involving the website's readers/members. i don't know if anyone 
is familiar with soylentnews' startup process but there were daily 
posts, invitations to irc where things were genuinely involving everyone 
all the way up from domain name _ownership_ and seeking help with 
hosting payments.  i try to help with gentoo here on the mailing list 
when i can and on the forums too but i know very little of the gentoo 
foundation [6]
getting in touch with the documenation team [7] i think will be my first 
step; now to allocate the time (!)

[1] http://thread.gmane.org/gmane.linux.gentoo.user/267858
[2] http://planet.gentoo.org/
[3] http://www.gentoo.org/proj/en/java/index.xml
[4] https://wiki.gentoo.org/wiki/Category:Projects
[5] http://soylentnews.org/article.pl?sid=14/09/15/1857254
[6] https://www.gentoo.org/foundation/en/
[7] https://wiki.gentoo.org/wiki/Project:Documentation

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

[Rich Freeman]

On Wed, Nov 26, 2014 at 10:21 AM,  <thegeezer@thegeezer.net> wrote:
>
> all of gentoo council meetings happen on irc if i remember right so it's not
> like there is an elite group deciding fate they are just sorting things that
> need to be sorted.
>

Per Gentoo's social contract [1] we try to be open about everything.
Very little of what happens in Gentoo is behind closed doors.

Council and Trustee meetings are held publicly on IRC.  Meeting logs
can be found at [2].  Every Council meeting concludes with an open
floor, though issues really aren't likely to actually get immediate
action if they weren't on the agenda (we like to allow the whole
community to participate in list discussion before we just go vote on
something).

For the most part, Gentoo is what we make of it.  There has been a
desire for a long time to try to make it easier to contribute, but in
the end people have to step up to make that happen.  Those who are
most passionate about it are of course the best candidates to try to
drive change.


1 - http://www.gentoo.org/main/en/contract.xml
2 - http://wiki.gentoo.org/wiki/Project:Council

--
Rich

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

[hasufell]

Rich Freeman:
> There has been a
> desire for a long time to try to make it easier to contribute, but in
> the end people have to step up to make that happen.  Those who are
> most passionate about it are of course the best candidates to try to
> drive change.
> 

That's a common misconception in gentoo. Someone has an idea and no one
cares until he "makes it happen". A lot of ideas are not so trivial that
you can just "make it happen". You need consensus, a shift of thinking,
workflow and maybe even that people work TOGETHER on that idea.

But no, you keep saying "make it happen" and "by all means, start
working on it", completely ignoring the nature of the issues brought up.

I don't know of literally any big project except gentoo that still does
not _require_ a review workflow. Git would be the perfect excuse to
"make it happen", but that's something people have to agree on.

Instead we are worrying about stuff like repeated rebases, push
conflicts, push rate etc... so we will just end up using it wrong.

I don't think there is any hope left that this will become sane.

A review workflow (e.g. with appropriate high-level tools and maybe
paired with a distributed approach) will just make all your questions
about "how to contribute" go away.

But I'm sorry, this is probably too vague and I should instead go away
and "make it happen".

Sometimes it is NOT enough to try to improve things. Sometimes you have
to break with concepts. The last guy who tried to do that on a purely
technical level was ferringb and he ragequitted for good. The only
reason he could even come up with all those GLEPs (he wrote a LOT) was
because he got paid by google.

So, having 200+ core developers with push access is not just completely
wrong from the workflow perspective... it also makes it nearly
impossible to break with more fundamental concepts that are not
appropriate anymore.

So, to reiterate: if you want to change more fundamental concepts in
gentoo, you need a job at google and be resistant to burn-out. And now
you are telling me nothing is wrong with our contribution culture?
lol.

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

[Rich Freeman]

On Wed, Nov 26, 2014 at 12:29 PM, hasufell <hasufell@gentoo.org> wrote:
>
> That's a common misconception in gentoo. Someone has an idea and no one
> cares until he "makes it happen". A lot of ideas are not so trivial that
> you can just "make it happen". You need consensus, a shift of thinking,
> workflow and maybe even that people work TOGETHER on that idea.
>
> But no, you keep saying "make it happen" and "by all means, start
> working on it", completely ignoring the nature of the issues brought up.

I think the issue is that 99% of the developer community doesn't think
that there is anything seriously wrong.

If you're waiting for a large mass of developers to decide to make a
huge change, then you're just going to wait forever.  All the packages
I use work fine, and if one doesn't work I can fix it.  For most
Gentoo devs, that's all they're really expecting to get out of the
distro.

If you want to change the mindset, then you're going to have to do
more than just talk about it on the lists.  Historically things change
in Gentoo when somebody builds something that is so obviously useful
that just about everybody adopts it.  For years we argued about why
anybody should bother moving beyond EAPI0.  Now it seems like the
majority of the tree is EAPI5.  That wasn't a policy change.  It
wasn't begging and pleading.  It was the fact that slot operator
dependencies happened and everybody saw the benefits to themselves of
updating.

>
> I don't know of literally any big project except gentoo that still does
> not _require_ a review workflow. Git would be the perfect excuse to
> "make it happen", but that's something people have to agree on.
>

Gentoo is a release-less distro.  First, most projects that aren't
distros aren't really comparable to a linux distro because most
projects represent something unified in design, while distros tend to
be diverse collections.  Distros that involve releases naturally
involve review/testing/etc, as there is the concept that the release
should be fairly free of bugs.  In Gentoo there is no expectation that
the distro is ever free of bugs - there is just WAY too much churn and
there is never some kind of concept of overall quality.

The other problem with a reviewer workflow is that most Gentoo devs
don't want to be or deal with reviewers.  It is hard enough to get
maintainers to just not block collaboration entirely.

If you want to do THAT big of a cultural change, you'd probably be
better off just forking the distro, as you'll end up having to ditch
almost all the current devs anyway.

>
> I don't think there is any hope left that this will become sane.

If your vision of sanity is a world where all devs do nothing but
review pull requests all day, I wouldn't have too much hope.  I think
it is a nice concept, but I just don't see it happening here.  I
wouldn't mind participating in it, but you're not going to get much
support for banning the current way of doing things.

The thing is, you don't have to ban direct commits to adopt a reviewer
workflow.  Just add the review-oriented workflow as an alternative to
direct commits, and encourage its use.  By all means try to recruit
devs who will use the new workflow.  If it is competitive it will
flourish and nobody will mind its existence.  Killing the status quo
just makes it hard to go back if the new way doesn't work out, which
makes it extremely risky.

>
> So, having 200+ core developers with push access is not just completely
> wrong from the workflow perspective... it also makes it nearly
> impossible to break with more fundamental concepts that are not
> appropriate anymore.

Hardly.  You can let those 200+ core developers keep doing what
they're doing, while you add your 20 more developers who can do the
work of 500 developers using your new workflow.  Time will clearly
demonstrate which way works better.

>
> So, to reiterate: if you want to change more fundamental concepts in
> gentoo, you need a job at google and be resistant to burn-out. And now
> you are telling me nothing is wrong with our contribution culture?

I think you need to think about why you contribute to Gentoo in the first place.

If your goal of contributing is to get everybody else to do something
differently then that is a MAJOR recipe for burnout.

If your goal of contributing is to make somebody that nobody else is
working on work better, then you're positioned to succeed.  You can do
that in whatever way you want, including getting others to contribute
while you review the code, etc.  You need to start small, and entice
others to join you.

--
Rich

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

[hasufell]

I still don't see a good argument why we made our system so inflexible,
that obviously needed change needs such high amount of work, PR and proof.

Trying to improve gaming in gentoo took me 2 years full of work just to
realize it is a dead end and I am doing most of the work alone.
The necessity was obvious.

Trying to improve a tiny fraction about gentoo workflow (including your
attempts) already took more than 4(?) years with never ending excuses.
The necessity was more than obvious.

Now I could talk about similarly obvious things. Sure, not all issues
are obvious and those shouldn't be easy to push through.

You can draw your conclusions about this. I drew mine: small changes
will not get us out of here.


Have fun, if you can.

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

[konsolebox]

On Thu, Nov 27, 2014 at 2:04 AM, Rich Freeman <rich0@gentoo.org> wrote:
> On Wed, Nov 26, 2014 at 12:29 PM, hasufell <hasufell@gentoo.org> wrote:
>> I don't know of literally any big project except gentoo that still does
>> not _require_ a review workflow. Git would be the perfect excuse to
>> "make it happen", but that's something people have to agree on.
>>
>
> Gentoo is a release-less distro.  First, most projects that aren't
> distros aren't really comparable to a linux distro because most
> projects represent something unified in design, while distros tend to
> be diverse collections.  Distros that involve releases naturally
> involve review/testing/etc, as there is the concept that the release
> should be fairly free of bugs.  In Gentoo there is no expectation that
> the distro is ever free of bugs - there is just WAY too much churn and
> there is never some kind of concept of overall quality.
>
> The other problem with a reviewer workflow is that most Gentoo devs
> don't want to be or deal with reviewers.  It is hard enough to get
> maintainers to just not block collaboration entirely.
>
> If you want to do THAT big of a cultural change, you'd probably be
> better off just forking the distro, as you'll end up having to ditch
> almost all the current devs anyway.

Hi, just an ordinary 9-years user here.  I hope you don't mind my asking.

Is it really official that most significant people on Gentoo don't like the
change from CVS to Git?  Has there been a general discussion about it, and
what is basically everyone's general argument to it?  Just in case attempts
to change were already made, what were technically the biggest things that
prevented it?

And I also once thought that having a decentralized Gentoo would be good
(yes, even more than just being distributed), but perhaps it would be just
too risky to implemented right away in Gentoo.  Perhaps having an
experimental fork were devs in Gentoo would give support would be nice and
consider merging it back later if it's already mature enough.

Nevertheless I don't think using Git itself is exactly being decentralized,
and probably a more flexible and distributed version of the current Gentoo.
If it's concerns about reviews that people may or may not want, I think
there are still some other good benefits of using Git besides it.

And I'm one who considered sharing some of the ebuilds I made for myself,
but I really dislike personally contacting the developer in charged, or
posting over-formal reports in bugzilla.

Directly giving a pull request to a developer's repository in Github should
be easiest and of great convenience.  It also gives me the confidence that
my report would surely be noticed and noticed right away.

The ebuilds I shared would also need not to be merged.  People can just
look at the forks of an official repository and see of those would be a
fitting solution for them.  I wouldn't need a mentor for it.

About using Github by the way, I just mentioned it because I prefer it and
it would not need to be the official repository.  The official repository
can still reside in Gentoo's servers but mirrors can be placed in Github
for the sake of better collaboration.  Of course I'm not suggesting that
every mirror needs to have the whole portage tree.

Cheers,
konsolebox

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

[Rich Freeman]

On Wed, Nov 26, 2014 at 3:28 PM, konsolebox <konsolebox@gmail.com> wrote:
>
> Is it really official that most significant people on Gentoo don't like the
> change from CVS to Git?  Has there been a general discussion about it, and
> what is basically everyone's general argument to it?  Just in case attempts
> to change were already made, what were technically the biggest things that
> prevented it?

Most devs can't wait to switch to git.  There are a few who might
prefer to stick with cvs but overall I don't think that is preventing
us from switching at all.

Right now the main blocker to switching over to git is that infra
wants to host it on new servers and they're still trying to get them
set up.  I believe that is in the works though.  The hope was that
we'd be up by Dec 1st but that seems to be slipping a bit.

Once the servers are running the plan is to get everybody to pound on
them and work out the workflows.

>
> About using Github by the way, I just mentioned it because I prefer it and
> it would not need to be the official repository.  The official repository
> can still reside in Gentoo's servers but mirrors can be placed in Github
> for the sake of better collaboration.  Of course I'm not suggesting that
> every mirror needs to have the whole portage tree.

That is definitely the plan.  Many devs would prefer to use Github in
their workflow.

--
Rich

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

[Stefan G. Weichinger]

Am 26.11.2014 um 21:39 schrieb Rich Freeman:

> Most devs can't wait to switch to git.  There are a few who might
> prefer to stick with cvs but overall I don't think that is preventing
> us from switching at all.

(without having read the whole thread, sorry)

my *personal opinion* is that git brings a lot of advantages to software
development.

I am still no programmer and maybe will never be .... but I use git for
some of my projects and customer-related stuff ...

It's clever and complex and simple at the same time somehow.

Sometimes I wonder why syncing portage isn't yet available via git ;-)

Maybe it isn't because more clever devs have decided it is not clever at
all :-)

S

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

[Rich Freeman]

On Wed, Nov 26, 2014 at 4:58 PM, Stefan G. Weichinger <lists@xunil.at> wrote:
>
> Sometimes I wonder why syncing portage isn't yet available via git ;-)
>

Well, right now it is because it is too much of a pain to try to keep
cvs and git in sync.

However, the plan for the future is to have a master repo (where the
pushes go to), a git sync repo, and an rsync repo.  The middle option
is likely going to interest you.

--
Rich

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

[Paige Thompson]

you might check out webrsync fwiw

On 11/26/14 23:43, Rich Freeman wrote:
> On Wed, Nov 26, 2014 at 4:58 PM, Stefan G. Weichinger <lists@xunil.at> wrote:
>> Sometimes I wonder why syncing portage isn't yet available via git ;-)
>>
> Well, right now it is because it is too much of a pain to try to keep
> cvs and git in sync.
>
> However, the plan for the future is to have a master repo (where the
> pushes go to), a git sync repo, and an rsync repo.  The middle option
> is likely going to interest you.
>
> --
> Rich
>

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

[Rich Freeman]

On Wed, Nov 26, 2014 at 8:51 PM, Paige Thompson <erratic@yourstruly.sx> wrote:
> you might check out webrsync fwiw
>

Webrsync is great, of course, but not really the same thing as git.

Changelogs will also go away when we move to git.

--
Rich

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

[Paige Thompson]

You know I don't think thats going to happen because if you look at
layman its not as if they didn't think of using git for package trees;
all of them do use git.

A good example of why I don't think they will be using git for portage:
``git clone https://git.kernel.org'

This takes a very long time and a lot of bandwidth and a lot of space.
Why move data that isn't going to be used? With rsync I believe you can
exclude categories:
http://www.gentoo-wiki.info/TIP_Exclude_categories_from_emerge_sync

If they were gonna do that with git every category would have to be a
submodule. I could be wrong but I just want to believe it hasn't been
made available despite being supported for a good reason.

On 11/27/14 02:03, Rich Freeman wrote:
> On Wed, Nov 26, 2014 at 8:51 PM, Paige Thompson <erratic@yourstruly.sx> wrote:
>> you might check out webrsync fwiw
>>
> Webrsync is great, of course, but not really the same thing as git.
>
> Changelogs will also go away when we move to git.
>
> --
> Rich
>

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

[Paige Thompson]

Have a look at this

http://stackoverflow.com/questions/2935899/is-there-any-git-repository-with-official-daily-updated-gentoo-portage

On 11/27/14 02:03, Rich Freeman wrote:
> On Wed, Nov 26, 2014 at 8:51 PM, Paige Thompson <erratic@yourstruly.sx> wrote:
>> you might check out webrsync fwiw
>>
> Webrsync is great, of course, but not really the same thing as git.
>
> Changelogs will also go away when we move to git.
>
> --
> Rich
>

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

[Rich Freeman]

On Wed, Nov 26, 2014 at 9:17 PM, Paige Thompson <erratic@yourstruly.sx> wrote:
> A good example of why I don't think they will be using git for portage:
> ``git clone https://git.kernel.org'
>
> This takes a very long time and a lot of bandwidth and a lot of space.
> Why move data that isn't going to be used? With rsync I believe you can
> exclude categories:
> http://www.gentoo-wiki.info/TIP_Exclude_categories_from_emerge_sync

Anybody who wants to use rsync can still do so after the migration.

Git is a LOT faster at syncing than cvs, which is what we're all stuck
with right now.

The whole gentoo repository with history takes about 2GB, but we will
be separating history from the current tree so initially the
repository will be quite small.

For anybody who does want the history git is very efficient at
syncing.  You would need to store the whole repository, but the
bandwidth needed for syncs is very low.

>
> If they were gonna do that with git every category would have to be a
> submodule. I could be wrong but I just want to believe it hasn't been
> made available despite being supported for a good reason.

There are a bunch of reasons that it hasn't happened.  You can read
the tracker bug to get a sense of the past roadblocks.  At this point
the biggest item left is getting the new infra set up, which is
underway.

--
Rich

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

[hasufell]

Paige Thompson:
> You know I don't think thats going to happen because if you look at
> layman its not as if they didn't think of using git for package trees;
> all of them do use git.
> 
> A good example of why I don't think they will be using git for portage:
> ``git clone https://git.kernel.org'
> 
> This takes a very long time and a lot of bandwidth and a lot of space.
> Why move data that isn't going to be used? With rsync I believe you can
> exclude categories:
> http://www.gentoo-wiki.info/TIP_Exclude_categories_from_emerge_sync
> 

That is uninformed.

check the --depth option of git. You can even clone specific tags with
--depth=1.

Shallow clones are fully supported and you can push from them.

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

[Martin Vaeth]

hasufell <hasufell@gentoo.org> wrote:
>> With rsync I believe you can exclude categories:
>> http://www.gentoo-wiki.info/TIP_Exclude_categories_from_emerge_sync
>
> That is uninformed.

I think he is right.

> check the --depth option of git. You can even clone specific tags with
> --depth=1.

Every tag will still contain all categories:
AFAIK, with git, it is not possible to update everyting but e.g. *access*
*kde* *i10n* *gnome* if you know that you will never install an
ebuild from these categories.

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

[James]

hasufell <hasufell <at> gentoo.org> writes:


> I still don't see a good argument why we made our system so inflexible,
> that obviously needed change needs such high amount of work, PR and proof.

I think that most folks appreciate your efforts and insightful ideas
on how to open up development, particularly in non-critical (non-core)
areas. The quesiton is how do we get from where we are to where we
want to be. I find most of what I'm interested in already in Arch Linux. I
wonder why it is so much easier for Arch users to create pkgbuilds (like
gentoo's ebuilds) and find a dev to adopt the package? Surely someone has 
some insight on this differences, or do I miss something that creats the
difference? [1]  I also find the Arch documentation to be of the finest
quality of any and all linux distros, close to gentoo. ymmv.


> Trying to improve a tiny fraction about gentoo workflow (including your
> attempts) already took more than 4(?) years with never ending excuses.
> The necessity was more than obvious.
> Now I could talk about similarly obvious things. Sure, not all issues
> are obvious and those shouldn't be easy to push through.


Everyone understands small changes and all changes take time for the
majority of members to digest, imho. Not everyone has your keen insight into
 the problem/opportunity. So your patience in explanation, encouragement and
solicitation, is very important, if your idea is to be
implemented and tested. Naturally, Rich and other deeply involved devs, with
addtional responsibilities exude caution, to keep the gentoo stable.
They will not be the source of "team building" for your idea, imho.


> You can draw your conclusions about this. I drew mine: small changes
> will not get us out of here.


I think the jury is still out. So, why can't we test a transient plan
where we take something very broken areas at Gentoo (games or java or
sys-cluster) and test out your hypothesis for package development expansion?

In fact, I've been looking over quite a few ebuilds and pkgbuilds at (Arch
linux). [2] I see quite a lot of commonality. So, why can we not "modify"
this aforementioned "inflexible" system on gentoo to allow for Arch Linux
pkgbuilds to be routinely compiled and installed on gentoo?

Maybe limit the test to /usr/local/portage or /usr/local/portage/test/ so
folks can participate or purge the experiment? Maybe find some Arch linux
devs keen on the idea of developing/evolving package management so that 
the two distros can readiy (or more easily) convert packages between
Arch and Gentoo?   Is it possible?  Could your plan be modified to
include a variety of Arch developers? Surely you have a collection
of devs ready to implement your keen ideas? I, for one realize something
fundamental has to change with Gentoo, after pushing a few months
on java and cluster codes.... Also, there is a vast array of software,
of various quality, among the overlay repositories to use as test-packages?


The biggest thing I seen wrong with Arch is they have forced systemd
onto their users, and all of the arch users I know, are not very
happy about that. So if you approach this correctly, I'm sure quite a
few Arch linux folks would also test your offerings.

> Have fun, if you can.


Always we should have fun. That is why we should deeply discuss these
issues to find common ground. Maybe fixing this inflexible system should
involve a survey of those distros closest to gentoo, for ideas, particulary
several (structured) methods to install packages, provide choices for the
init system, and strongly advocate package development within the
ranks of the user base. Clear and concise documentation, concurrent with
this effort is probably your single greatest alley, should your idea
and leadership prove successful.


hth,
James


[1] http://www.volkerschatz.com/unix/ebuilds/ebuilds.html

[2] https://aur.archlinux.org/packages/sl/slurm-llnl/PKGBUILD

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

[hasufell]

Martin Vaeth:
> hasufell <hasufell@gentoo.org> wrote:
>>> With rsync I believe you can exclude categories:
>>> http://www.gentoo-wiki.info/TIP_Exclude_categories_from_emerge_sync
>>
>> That is uninformed.
> 
> I think he is right.
> 
>> check the --depth option of git. You can even clone specific tags with
>> --depth=1.
> 
> Every tag will still contain all categories:
> AFAIK, with git, it is not possible to update everyting but e.g. *access*
> *kde* *i10n* *gnome* if you know that you will never install an
> ebuild from these categories.
> 
> 

My max DL rate is ~700KiB/s and is the limiting factor.

# time git clone --depth=1 --branch=v3.1
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
real	2m56.615s
user	0m5.802s
sys	0m0.578s

So the initial comment

> A good example of why I don't think they will be using git for portage:
> ``git clone https://git.kernel.org'

doesn't make much sense, because it isn't the recommended way to clone
the kernel tree.

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

[hasufell]

James:
> hasufell <hasufell <at> gentoo.org> writes:
> 
> 
>> I still don't see a good argument why we made our system so inflexible,
>> that obviously needed change needs such high amount of work, PR and proof.
> 
> I think that most folks appreciate your efforts and insightful ideas
> on how to open up development, particularly in non-critical (non-core)
> areas. The quesiton is how do we get from where we are to where we
> want to be. I find most of what I'm interested in already in Arch Linux. I
> wonder why it is so much easier for Arch users to create pkgbuilds (like
> gentoo's ebuilds) and find a dev to adopt the package? Surely someone has 
> some insight on this differences, or do I miss something that creats the
> difference? [1]  I also find the Arch documentation to be of the finest
> quality of any and all linux distros, close to gentoo. ymmv.
> 
> 

Arch has done it wrong, IMO. Sure, their PKGBUILDs are easier to write,
but their quality is also worse. I know how to write them and have
written and looked at a lot of them.

People went the easy way and didn't really care much about review
workflow, so they ended up with AUR where everyone can upload random
stuff, including dangerous and wrong code.

>> Trying to improve a tiny fraction about gentoo workflow (including your
>> attempts) already took more than 4(?) years with never ending excuses.
>> The necessity was more than obvious.
>> Now I could talk about similarly obvious things. Sure, not all issues
>> are obvious and those shouldn't be easy to push through.
> 
> 
> Everyone understands small changes and all changes take time for the
> majority of members to digest, imho. Not everyone has your keen insight into
>  the problem/opportunity. So your patience in explanation, encouragement and
> solicitation, is very important, if your idea is to be
> implemented and tested. Naturally, Rich and other deeply involved devs, with
> addtional responsibilities exude caution, to keep the gentoo stable.
> They will not be the source of "team building" for your idea, imho.
> 

Gentoo isn't even particularly stable anymore. It's a mess to maintain
with a confused PM, toolchain hackery and random conflicting ideas in
one repository (e.g. multilib clashing with crossdev).

The distro can only be as stable as the PM and the PM depends on the
input. The input depends on quality ebuilds. Quality ebuilds depend on a
proper spec, but there is no proper spec... PMS team itself says it
started as a collection of ancient portage behavior and then grew with
time, so there was no real design behind it. Quality ebuilds also depend
on review-workflow. Review-workflow needs proper tools.

We don't even have the last one. Long way to go. Good luck.


 >> You can draw your conclusions about this. I drew mine: small changes
>> will not get us out of here.
> 
> 
> I think the jury is still out. So, why can't we test a transient plan
> where we take something very broken areas at Gentoo (games or java or
> sys-cluster) and test out your hypothesis for package development expansion?
> 

Already doing so
https://github.com/hasufell/games-overlay

and that's where I will update ebuilds, not in the tree. And I don't
care to get any of that into the tree.

> In fact, I've been looking over quite a few ebuilds and pkgbuilds at (Arch
> linux). [2] I see quite a lot of commonality. So, why can we not "modify"
> this aforementioned "inflexible" system on gentoo to allow for Arch Linux
> pkgbuilds to be routinely compiled and installed on gentoo?
> 
> Maybe limit the test to /usr/local/portage or /usr/local/portage/test/ so
> folks can participate or purge the experiment? Maybe find some Arch linux
> devs keen on the idea of developing/evolving package management so that 
> the two distros can readiy (or more easily) convert packages between
> Arch and Gentoo?   Is it possible?  Could your plan be modified to
> include a variety of Arch developers? Surely you have a collection
> of devs ready to implement your keen ideas? I, for one realize something
> fundamental has to change with Gentoo, after pushing a few months
> on java and cluster codes.... Also, there is a vast array of software,
> of various quality, among the overlay repositories to use as test-packages?
> 
> 
> The biggest thing I seen wrong with Arch is they have forced systemd
> onto their users, and all of the arch users I know, are not very
> happy about that. So if you approach this correctly, I'm sure quite a
> few Arch linux folks would also test your offerings.
> 
>> Have fun, if you can.
> 
> 
> Always we should have fun. That is why we should deeply discuss these
> issues to find common ground. Maybe fixing this inflexible system should
> involve a survey of those distros closest to gentoo, for ideas, particulary
> several (structured) methods to install packages, provide choices for the
> init system, and strongly advocate package development within the
> ranks of the user base. Clear and concise documentation, concurrent with
> this effort is probably your single greatest alley, should your idea
> and leadership prove successful.
> 
> 

People are scared of other gentoo-like distros/PMs. Exherbo is evil,
paludis is evil, sabayoon is evil, ...

I've already tried contributing to exherbo. They are technically ahead
of us in some non-trivial areas, but I don't think they have solved the
contribution problem. Sure, they are more distributed and have gerrit
etc, but their review workflow goes more the way "make a high-quality
user-overlay and then we will review it once and add it to our page".

They don't care too much about themed and clearly scoped overlays and
about the difference of 'modular' and 'fragmented'.

200 guys pushing into 200 repositories without _regular_ reviews (not
just a "gentoo dev" or "high quality" overlay badge) is not much
different to what gentoo does.

Arch is neither interesting from the technical nor from the workflow
standpoint, IMO.

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

[James]

hasufell <hasufell <at> gentoo.org> writes:



> Already doing so  https://github.com/hasufell/games-overlay
> and that's where I will update ebuilds, not in the tree. And I don't
> care to get any of that into the tree.

OK.


> People are scared of other gentoo-like distros/PMs. Exherbo is evil,
> paludis is evil, sabayoon is evil, ...

I agree, there is much resistence and calcification deep in the ranks
of gentoo.


> I've already tried contributing to exherbo. They are technically ahead
> of us in some non-trivial areas, but I don't think they have solved the
> contribution problem. Sure, they are more distributed and have gerrit
> etc, but their review workflow goes more the way "make a high-quality
> user-overlay and then we will review it once and add it to our page".


As a young distro, maybe that's all the man_hours they have for
outside packages right now?


> They don't care too much about themed and clearly scoped overlays and
> about the difference of 'modular' and 'fragmented'.
> 200 guys pushing into 200 repositories without _regular_ reviews (not
> just a "gentoo dev" or "high quality" overlay badge) is not much
> different to what gentoo does.

Is this (above) aimed at Exherbo or Arch?


> Arch is neither interesting from the technical nor from the workflow
> standpoint, IMO.

It has been around for a while.



OK so keep in mind if you are successful at what you set up (your overlay
++) with gentoo, I'd be interested to know the details and maybe I'll move
my codes to a similar structure; mostly java and science/math codes....

Drop me private email, or keep me informed whatever your chosen information
dispersement is (a blog? etc)  as your code development mechanisms evolve.


sincerely,
James

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

[Martin Vaeth]

hasufell <hasufell@gentoo.org> wrote:
> Martin Vaeth:
>> hasufell <hasufell@gentoo.org> wrote:
>>>> With rsync I believe you can exclude categories:
>>>> http://www.gentoo-wiki.info/TIP_Exclude_categories_from_emerge_sync
>>>
>>> That is uninformed.
>> 
>> I think he is right.
>> 
>>> check the --depth option of git. You can even clone specific tags with
>>> --depth=1.
>> 
>> Every tag will still contain all categories:
>> AFAIK, with git, it is not possible to update everyting but e.g. *access*
>> *kde* *i10n* *gnome* if you know that you will never install an
>> ebuild from these categories.
>
> My max DL rate is ~700KiB/s and is the limiting factor.

My concern is not the time but the total volume (there are still
often limitations involved), and perhaps even more important,
the disk usage, especially compared with methods like squashfs(+aufs).
It simply is a fact that with git you have to download and store a
lot of unnecessary information (if you are not a developer and do
not use a heavy system): not only git metadata but also
unneeded categories.
So for non-developers, downloading with git does not necessarily
make sense.

That being said, please do not consider this as an argument against
a change to git: For developers it has only advantages, and AFAIK,
it is not planned to cancel other download methods anyway.

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

[Nicolas Sebrecht]

On Sat, Nov 29, 2014 at 07:09:07AM +0000, Martin Vaeth wrote:

> So for non-developers, downloading with git does not necessarily
> make sense.
>
> That being said, please do not consider this as an argument against
> a change to git: For developers it has only advantages, and AFAIK,
> it is not planned to cancel other download methods anyway.

Of course. This is not going to be a requirement. Non-developers should
stick with rsync. No one meant to replace rsync with Git. It is about
replacing CVS with Git.

-- 
Nicolas Sebrecht

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

[Alan Mackenzie]

Hello, everybody.

On Sat, Nov 29, 2014 at 07:09:07AM +0000, Martin Vaeth wrote:
> hasufell <hasufell@gentoo.org> wrote:
> > Martin Vaeth:
> >> hasufell <hasufell@gentoo.org> wrote:
> >>>> With rsync I believe you can exclude categories:
> >>>> http://www.gentoo-wiki.info/TIP_Exclude_categories_from_emerge_sync

> >>> That is uninformed.

> >> I think he is right.

> >>> check the --depth option of git. You can even clone specific tags with
> >>> --depth=1.

> >> Every tag will still contain all categories:
> >> AFAIK, with git, it is not possible to update everyting but e.g. *access*
> >> *kde* *i10n* *gnome* if you know that you will never install an
> >> ebuild from these categories.

> > My max DL rate is ~700KiB/s and is the limiting factor.

> My concern is not the time but the total volume (there are still
> often limitations involved), and perhaps even more important,
> the disk usage, especially compared with methods like squashfs(+aufs).
> It simply is a fact that with git you have to download and store a
> lot of unnecessary information (if you are not a developer and do
> not use a heavy system): not only git metadata but also
> unneeded categories.
> So for non-developers, downloading with git does not necessarily
> make sense.

> That being said, please do not consider this as an argument against
> a change to git: For developers it has only advantages, and AFAIK,
> it is not planned to cancel other download methods anyway.

Speaking as a developer in a project which has just converted to git, I
can assure you that git has tremendous disadvantages, even compared with
cvs.

Principally, git does not have a high level model of version control
concepts, so that using git is somewhat analogous to programming in
assembler.  Both give you tremendous control and the ability to do
practically anything, including shooting yourself in the foot.  So that
instead of conceptualising a "branch" (as you would do with Mercurial,
Bazaar, Subversion, or even CVS), you need to think about "commits
reachable from a certain head (excluding commits reachable from some
other head)".

git is very difficult to learn, compared with, say Mercurial.  To
compare, if you do $ git help branch, you get a man page ~180 lines long
dumped on you, and that's taking up the full width of my 240 character
wide screen.  If you do $ hg help branch, you get a 27 line concise
summary, max. ~80 characters wide, which nonetheless is pretty much
complete.

git has become very popular (much as systemd has), possibly because
programmers are frustrated at not being able to write in assembler any
more.  (At least, that's my theory).  Like systemd, it has established a
stranglehold on its domain.  But severe disadvantages it most definitely
has.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[konsolebox]

On Sat, Nov 29, 2014 at 10:28 PM, Alan Mackenzie <acm@muc.de> wrote:
> Hello, everybody.

Good day.

> instead of conceptualising a "branch" (as you would do with Mercurial,
> Bazaar, Subversion, or even CVS), you need to think about "commits
> reachable from a certain head (excluding commits reachable from some
> other head)".

I actually see that as a more flexible approach.  git is designed to be
distributed and that's what everyone loves about it.

For everything:

http://stackoverflow.com/questions/802573/difference-between-git-and-cvs
http://eclipsesource.com/blogs/2011/06/09/git-lessons-learned/

Cheers,
konsolebox

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

[Alan Mackenzie]

Hello, konsolebox.

On Sat, Nov 29, 2014 at 11:18:49PM +0800, konsolebox wrote:
> On Sat, Nov 29, 2014 at 10:28 PM, Alan Mackenzie <acm@muc.de> wrote:
> > Hello, everybody.

> Good day.

> > instead of conceptualising a "branch" (as you would do with Mercurial,
> > Bazaar, Subversion, or even CVS), you need to think about "commits
> > reachable from a certain head (excluding commits reachable from some
> > other head)".

> I actually see that as a more flexible approach.  git is designed to be
> distributed and that's what everyone loves about it.

We're in violent agreement, it seems.  git is very flexible, just like
programming in assembler is.  git is certainly a distributed system,
just like Mercurial, Bazaar, etc., but seems to be the only one of its
kind that imposes this degree of flexibility on its users.  Hence the
multi-hundred line man pages for each of git's 155 sub-commands.
Mercurial has a mere 50 sub-commands (plus, to be fair, a few one's
going to need which are classified as extensions), and a single, very
readable, man page ~8000 lines long.

> For everything:

> http://stackoverflow.com/questions/802573/difference-between-git-and-cvs
> http://eclipsesource.com/blogs/2011/06/09/git-lessons-learned/

> Cheers,
> konsolebox

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Alec Ten Harmsel]

On 11/29/2014 09:28 AM, Alan Mackenzie wrote:
> Speaking as a developer in a project which has just converted to git, I
> can assure you that git has tremendous disadvantages, even compared with
> cvs.

It depends; they do different things. Depending on what I'm working on,
I use either subversion or git; neither is inherently better all the time.

>
> Principally, git does not have a high level model of version control
> concepts, so that using git is somewhat analogous to programming in
> assembler.  Both give you tremendous control and the ability to do
> practically anything, including shooting yourself in the foot.  So that
> instead of conceptualising a "branch" (as you would do with Mercurial,
> Bazaar, Subversion, or even CVS), you need to think about "commits
> reachable from a certain head (excluding commits reachable from some
> other head)".

As far as I can tell, git has a very clear concept of branching. Fast
branching was one of the biggest design points in git[1], and they did
it by merely making branches pointers to avoid unnecessary copying. So
yes, a branch is "commits reachable from a certain HEAD", but
conceptually this is the same as other branching models even though it
may not be implemented the same way.

> git is very difficult to learn, compared with, say Mercurial.  To
> compare, if you do $ git help branch, you get a man page ~180 lines long
> dumped on you, and that's taking up the full width of my 240 character
> wide screen.  If you do $ hg help branch, you get a 27 line concise
> summary, max. ~80 characters wide, which nonetheless is pretty much
> complete.
>
> git has become very popular (much as systemd has), possibly because
> programmers are frustrated at not being able to write in assembler any
> more.  (At least, that's my theory).  Like systemd, it has established a
> stranglehold on its domain.  But severe disadvantages it most definitely
> has.
>

git is extremely popular, which could be a factor in its difficulty; I'm
guessing it's had a lot more development hours (and more obscure
features) put into it.

git is popular because it solved (and still solves) a problem
(distributed, parallel development) that at the time was not solved by
any other open source DVCS except Mercurial. Both projects started
around the same time, and I would imagine that having the Linux kernel
team backing git was a compelling reason to choose git over Mercurial.
Early on, iirc git was also faster since mercurial uses diffing, not
snapshots, and is written in Python.

I highly recommend Scott Chacon's "Pro Git": http://git-scm.com/book/en/v2

Alec

[1] http://git-scm.com/book/en/v2/Getting-Started-A-Short-History-of-Git

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

[hasufell]

Alan Mackenzie:
> So that
> instead of conceptualising a "branch" (as you would do with Mercurial,
> Bazaar, Subversion, or even CVS), you need to think about "commits
> reachable from a certain head (excluding commits reachable from some
> other head)".

[snipping everything that is not technical]

How exactly is that a disadvantage? You are just complaining about the
way a concept is presented without saying what actual limitations that
implies (if any).

If you like mercurial better, use that. Speaking about "disadvantages"
however requires a bit more than "I like that way better".

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

[Sid S]

[-- Attachment #1: Type: text/plain, Size: 784 bytes --]

Hasufell, what are you referring to by attempts to make Gentoo more
friendly to gaming?

On Sat, Nov 29, 2014 at 1:38 PM, hasufell <hasufell@gentoo.org> wrote:

> Alan Mackenzie:
> > So that
> > instead of conceptualising a "branch" (as you would do with Mercurial,
> > Bazaar, Subversion, or even CVS), you need to think about "commits
> > reachable from a certain head (excluding commits reachable from some
> > other head)".
>
> [snipping everything that is not technical]
>
> How exactly is that a disadvantage? You are just complaining about the
> way a concept is presented without saying what actual limitations that
> implies (if any).
>
> If you like mercurial better, use that. Speaking about "disadvantages"
> however requires a bit more than "I like that way better".
>
>

[-- Attachment #2: Type: text/html, Size: 1209 bytes --]

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

[Rich Freeman]

On Tue, Dec 2, 2014 at 4:03 PM, Sid S <r030t1@gmail.com> wrote:
> Hasufell, what are you referring to by attempts to make Gentoo more friendly
> to gaming?

You quoted an email that didn't refer to "attempts to make Gentoo more
friendly to gaming."

The reason that you should respond below quotes is so that readers can
review the discussion in context.  Your question is out of context,
and top-quoted besides.  You should also trim quotes that aren't
relevant.

Just a friendly request to try to bottom-quote in the future, and this
is part of why.  Obviously replying to the correct email is better,
though bottom-quoting would help call your attention to the fact that
this mistake was made.

--
Rich

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

[Sid S]

[-- Attachment #1: Type: text/plain, Size: 224 bytes --]

Ah, I apologize. I did not mean to quote anything (it happens
automatically; I will start paying more attention to it). I was hoping he
would remember his additions to the conversation at hand and could
extrapolate on them.

[-- Attachment #2: Type: text/html, Size: 249 bytes --]

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

[Tom Wijsman]

On Sat, 22 Nov 2014 12:56:36 -0500
Rich Freeman <rich0@gentoo.org> wrote:

> I think the real problem is that there aren't many devs who care about
> Java in the first place.  That isn't a policy problem - it is a
> manpower problem.

+1

In the past two years, I've committed much to the Java categories. That
grows an idea of Java's size, the manpower and what can('t) be done ...

There are BARELY policies, roadblocks or whatsoever in the way; Java is
just a HUGE amount of packages and the manpower they have for it is TINY.

If people want to guarantee a future for Java, it is a matter of
multiple people stepping up to assure it. Because the one frequent
committer and the multiple infrequent committers that are left, might
keep a small part alive of it for as long as they can make it last.

They'll probably continue to support famous apps with Java components;
but to be attractive to much more apps and areas like Java development
in general, they will need much more people to make it alive 'n kicking.

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

[Tom Wijsman]

On Sat, 22 Nov 2014 18:20:01 -0500
Rich Freeman <rich0@gentoo.org> wrote:

> What do you do if somebody blocks progress in your overlay structure?
> You start another one.

Sounds like something that can work, survival of the [insert anything].
 
> What do you do if somebody blocks progress in the current Gentoo
> project structure?  You either ask the Council for help, or start
> another project.

Survival of the Council once the amount of projects gets nears infinity.
 
> You have just as many options under the status quo, and actually more.
> 
> Now, what you would get is the ability to have more variety in quality
> standards, since general QA/etc would not apply.

Quantity and Quality rarely go together; consider how we're investing in
Quality in a time we might benefit more from Quantity, also vice versa.

> Well, then by your argument there is nothing wrong, since they're
> already in the distributed model.  There is nothing I can do about
> people feeling alienated.

We can bring attention to the overlays; eg. summarize them on the wiki.

> If you want to contribute to Gentoo, then do it.  If somebody blocks
> your progress then ask for help.
> 
> 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.

Get born, make mistakes, learn from them, improve the future, die happy.

> The games team has ZERO power over any dev doing anything to any
> package in the tree.  That was the outcome of the most recent Council
> decision.  We didn't disband the team because we thought that having a
> team focused on games wasn't a bad idea, but so far nobody else seems
> all that interested so it seems as likely as not that there won't be a
> games team in the future.
> 
> How is that not doing something radical?  What more do you want us to
> do?

Preparations for the (un)expected future we're about to experience.

> > It's not about elitist old-timers, it's about a more dynamic model
> > that has low tolerance for
> > * bugs being open since 8+ years, because no one bothers to
> > review/change stuff (check nethack bug)
> > * territorial behaviour
> > * slacking devs slacking so hard, but not stepping down
> 
> The reason the nethack bug is still open is because nobody cares
> enough to fix it.  ANYBODY can make themselves a maintainer of Nethack
> right now and fix the bug.  The reason that the Nethack bug is still
> open is because you apparently care enough about it to post about it,
> but not enough to fix it.  I'm not going to fix it, because I don't
> use Nethack.
>
> The issues you bring up were an issue in the past, and nobody really
> has any tolerance for it these days.  You keep bringing up past issues
> that have been fixed, which really sounds to me like a demonstration
> that we're running out of real current issues to fix.
> 
> 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.

This emphasizes on a bad example from a collection of vague statements;
while we ignore that, what does it have to do with the dynamic model?

> [...] You're basically coming across as being impossible to satisfy,
> because you bring up vague complaints without anything that anybody
> can act upon, [...]

Content on gentoo-user is more likely to be demand than it is supply.

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

[Tom Wijsman]

On Sun, 23 Nov 2014 23:50:48 +0100
hasufell <hasufell@gentoo.org> wrote:

> Again: you are confusing a specific incident with my proposal of a
> distributed model. I was just bringing it up as an _additional_
> argument why I find the distributed approach more interesting...
> because it makes it easier to regroup and abandon toxic people
> without having to fight them for years.
> 
> Nothing of what I say is vague. It is already implemented and I
> pointed it out. If you refuse to look at it or recognize it, then
> that's not my fault.

Snow is so nice, but I stay home 'cause snow is so cold; not my fault.

As an outsider to this new distributed Gentoo discussion happening here;
I would be much more interested in a distributed Gentoo if it was fully
committed to, rather than seeing you try to convince the inconvincible.

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

[Tom Wijsman]

On Tue, 25 Nov 2014 20:29:28 +0100
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:

> And proposing a Java revolution because the existing team 
> does not immediately jubilate at your extensive reform proposals is
> also not necessarily the best idea.

For those that disagree, start overlay java2015 and prove him wrong. ^_^