[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

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

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.

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.