[gentoo-user] The end of "Herds"

[gentoo-user] The end of "Herds"

[James]

Hello,


If you follog gentoo-dev you can see Rich's summary
interpretation (which I do agree with) posted at the
bottom of this thread.


Recently I was asked to help clean up some of the Java
bugs. OK, as a non-maintainer I agreed. I went through
over 100 java bugs, mostly pre 2010, as to make a dent
in the backlog of ~500 java bugs that would probably
be the easiest to clean up. Sure enough, there were
only a few that were still relevant (Hmmmmmmmmmmmmmmmmm)


So I proposed, to one of the Java Herd members we blast out 
a few emails notifying everyone that if folks did not
"reaffrim" these (very old) java bugs, they would be mass-closed.
If you look at those (old bugs) most would agree with my
assessment. However, I listed a few as blatant examples
that needed to be closed. It seems there is no "closer" for
java bugs. Nobody around with the authority (will?) to close
any old Java bugs. The herd is descimated, on furlog or just
burnt out and non-responsive. So all of my work and 
effort was for nothing. Over the years, I have made
at least 3 attemps to use java on gentoo; all resulted in
using other linix distros. For me, java is a reality
that cannot be wished away. What I have learn in the last few
months is that Java on Gentoo is alive and properous; folks with
Java ebuilds just do not bother with getting them into Gentoo
because of the morass of apathy the gentoo java hers has become.

So now is the time for folks to read and post to gentoo-dev on 
thread: :" Deprecating and killing the concept of herds" if
you have any issues with herds being removed from Gentoo.
Ideas on how to best organize bug_cleaning is also welcome.
I think there will be an uptake in proxy-maintainers, if the 
gentoo-dev club is sincere about treating these proxy maintainers
with respect and mutual professionalism.

I think the concept of "Projects" will persist, but herds have
to become active and request to become "Projects" as defined
on the gentoo wiki or they will be erased. Like many others, 
I have been burned in the past with trying to get directly involved 
with Gentoo (been here since 2004). That's all water under the bridge.
So I am "tip_toeing" behind the scenes willing to be a grunt
and clean up some of the java mess, participate in clustering and 
contribute to the science project. We'll see just how long it lasts 
before I get "bitch_slapped" like  my previous attempts........


That's why I named by current /usr/local/portage "jackslap".
We shall see what happens.


I see the enabling of user patches directly into ebuilds in the tree
(EAPI 6) and the cleansing of the irresponsible amongst the herds
with exclusive control over bugs  as a very positive sign that the gentoo
dev community is one again dedicated to making Gentoo an excellent platform.
Whatever your experiences have been, I hope you read, post 
and give direct participation in Gentoo your deepest consideration.


James


<snip>
My (rich) proposal:

For the steady state:

1. For the maintainer tag in metadata, have a type attribute that can
be developer, project, or proxy.

2. Add a contacts tag in metadata that takes an email.

3. Package without maintainers (individuals or projects - regardless
of presence of aliases) get assigned to maintainer-needed and get
treecleaned as usual.

I'm also fine with normalizing this and just switching to a contact
tag that can have a type of developer, project, proxy, or contact.
That is a bigger change.  However, it would probably simplify
scripting and be a bit cleaner for the long-term.


For the transition to the steady state:

a. We generate a list of all current herds and email their aliases to
see if they want to be converted to a non-maintainer alias, or be
disbanded entirely.  One reply to the email is enough to keep the
alias around, no replies means retirement.

b. Anybody in Gentoo can start a project already by following GLEP 39.
It is encouraged for these projects to take over existing aliases
where they feel it is appropriate.  There is no need for all aliases
to have a project - just ones that want some kind of structure (ie
this is strictly voluntary).  When this is done the project will
remove the herd from metadata and add the project alias as a
maintainer with the agreed-upon tagging.

c. We generate a list of all current packages that do not have a
maintainer (either one or more individuals or projects (NOT herds)).
That gets posted so that individuals can claim them.  I suggest not
doing the usual treecleaning email since there could be a LOT of them.
Or we could do it herd-by-herd over time to ease the load.

d. We remove all herds from the existing packages.  Where aliases were
kept in (a) above they are converted to aliases with appropriate
tagging.  If no maintainer exists the package is handled per the
result of (c).


Comments, alternatives, etc?

Re: [gentoo-user] The end of "Herds"

[Michael Orlitzky]

On 11/04/2014 03:13 PM, James wrote:
> Hello,
> 
> 
> If you follog gentoo-dev you can see Rich's summary
> interpretation (which I do agree with) posted at the
> bottom of this thread.
> 
> 
> Recently I was asked to help clean up some of the Java
> bugs. 
> 
> ...
> So I proposed, to one of the Java Herd members we blast out 
> a few emails notifying everyone that if folks did not
> "reaffrim" these (very old) java bugs, they would be mass-closed.
> If you look at those (old bugs) most would agree with my
> assessment. However, I listed a few as blatant examples
> that needed to be closed. It seems there is no "closer" for
> java bugs. Nobody around with the authority (will?) to close
> any old Java bugs. The herd is descimated, on furlog or just
> burnt out and non-responsive. So all of my work and 
> effort was for nothing.

This is exactly the problem we're trying to solve (and I'm sorry to hear
it, many of us have been in a similar position).

Herds as a group of developers have always been very poorly-defined. As
I've heard it repeated, originally packages were supposed to belong to
herds, and developers were supposed to belong to projects. But herds
almost always had an associated email address, so people who cared about
groups of packages would add themselves to the herd to get on the email
alias. But projects were there all along, too, and we wound up with a
bunch of people in herds who were never going to fix bugs and some
smaller number of people in projects (who might fix bugs) that weren't
in the herds. It was all very confusing, so the council is voting to
replace them with something that makes sense.

Basically we want to fix the situation we have right now where it's
impossible to tell who is actually working on Java packages. Once herds
are replaced, you should be able to get an accurate reading out of
metadata.xml and/or the wiki page. (And I'm sure anyone actually working
on Java would appreciate your help.)

For you personally, I would try to find one or two people on the Java
project (actually working on Java right now) and explain to them that
you'd like to help close old bugs. Then you can CC or reassign the Java
bugs to those people. When bug mail gets sent to a herd or project, it's
too easy to say "screw it, someone else will deal with it." Bugs
addressed to me personally get attention much sooner, even if only for
psychological reasons. So reassigning those to a single person might
prompt action sooner than you'd get otherwise.

[gentoo-user] Re: The end of

[James]

Michael Orlitzky <mjo <at> gentoo.org> writes:


> This is exactly the problem we're trying to solve (and I'm sorry to hear
> it, many of us have been in a similar position).

Yep.
The point is not to "bemoan" the issue, but steer gentoo into a direction
where those who are not devs (for whatever reason) can easily contribute
to creating and maintaining a richer diversity of (ebuild) sofware
packages on Gentoo. Nothing is this movement prevents the good_old_dev
club from propering; it just allows the user community to build out
their systems, as they like. Devs can help, or stand aside, but
blocking (Gentoo) users form making their systems what they want
should be "celebrated" because that is the essential core value
of Gentoo, imho.


> Herds as a group of developers have always been very poorly-defined. As
> I've heard it repeated, originally packages were supposed to belong to
> herds, and developers were supposed to belong to projects. But herds
> almost always had an associated email address, so people who cared about
> groups of packages would add themselves to the herd to get on the email
> alias. But projects were there all along, too, and we wound up with a
> bunch of people in herds who were never going to fix bugs and some
> smaller number of people in projects (who might fix bugs) that weren't
> in the herds. It was all very confusing, so the council is voting to
> replace them with something that makes sense.

Finally.  I understand that herds and projects, although not completely
the same thing, have so much overlap that both are not needed. Cleaning
out the cruft {} is a major step in revitalizing the Gentoo distro, imho.


> Basically we want to fix the situation we have right now where it's
> impossible to tell who is actually working on Java packages. Once herds
> are replaced, you should be able to get an accurate reading out of
> metadata.xml and/or the wiki page. (And I'm sure anyone actually working
> on Java would appreciate your help.)

One problem I see is there is not a "one to one" mapping of the herds
to projects. There is a clustering herd and some are still active devs, 
but the herd has no balls (a bunch of steers?). I proposed that that
group be migrated to a project and was told that somebody in the cluster
herd (a dev) would have to make that effort (sending a one sentence email).

If they are not interested, how do a group of users become the cluster project?


Right now, most cluster related codes are worked on by the science herd/project.


 
> For you personally, I would try to find one or two people on the Java
> project (actually working on Java right now) and explain to them that
> you'd like to help close old bugs. Then you can CC or reassign the Java
> bugs to those people. When bug mail gets sent to a herd or project, it's
> too easy to say "screw it, someone else will deal with it." Bugs
> addressed to me personally get attention much sooner, even if only for
> psychological reasons. So reassigning those to a single person might
> prompt action sooner than you'd get otherwise.


Can you send me their gentoo mail addresses, privately?

I understand that we are all a bunch of volunteers. I get it, having
bootstrapped 6 companies myself over the years. I appreciate all
of the former and current devs. I do not wish to be a burden on anyone.
That said, I'm a team builder and would prefer to get users to do the
vast majority of the work, with me. If folks (kids) want to become
a gentoo dev, *thats great*; I just want a gentoo distro where *I* can
get done what I want and a dev community that either supports my vision(s)
or builds the core tools, systems and infrastructure that makes my
efforts and the efforts of other users, an enjoyable experience with Gentoo.


Sure some will migrate to the gentoo dev status, that's great. For me
I'd have to *see the changes* before going down that road again. Just look
at those old bugs for Java, You can "flush" them all older that 2010
without issue, in one blasted email, deprecation define stroke. I'm
not waisting any more time on that crap. If you doubt this, start searching
out those old bugs and find me one from pre-2010 that is still relevant;
also report how many you looked at before you found one that is still
relevant?

Facilitating an easy, straightforward, with plenty of examples for user
to patch  (gentoo-tree) ebuilds on their systems, to setup there own, git
hub repository and clearly document examples of how to hack ebuilds, would
go a long way to making the user base very happy, imho. There are efforts,
but they are mostly "piece_meal", imho. If this finally emerges, you have
too many (qualified) applicants for gentoo dev and you'll have a very happy
user base; which will grow the gentoo adoptions vastly around the net.

Crib to Palace (or as the brothers would say, Mom's crib to my crib
aka crib-2-crib). But I'm not convince that the rank a file devs of gentoo
want to empower the user communityh to that level. Being older, it's a "show
me da money" time for those keen gentoo devs whom aspire for Gentoo to be a
user's distro.

Don't worry about me, I'm a mean old bastard; but I would worry about why
we have a lack of college age kids stepping forward into the gentoo-dev
space. Worry deeply about that, bro! Cause I can recruit them, but will
they put up with the existing fiefdoms?



Goodluck!
James

Re: [gentoo-user] Re: The end of

[Michael Orlitzky]

On 11/05/2014 10:55 AM, James wrote:
>  
>> For you personally, I would try to find one or two people on the Java
>> project (actually working on Java right now) and explain to them that
>> you'd like to help close old bugs. Then you can CC or reassign the Java
>> bugs to those people. When bug mail gets sent to a herd or project, it's
>> too easy to say "screw it, someone else will deal with it." Bugs
>> addressed to me personally get attention much sooner, even if only for
>> psychological reasons. So reassigning those to a single person might
>> prompt action sooner than you'd get otherwise.
> 
> 
> Can you send me their gentoo mail addresses, privately?
> 

I didn't have anyone in mind, it really isn't easy to figure out who's
active right now. Two things I would try:

  1. See who's active in the Java overlay. This one's easy.

       $ git clone git://git.overlays.gentoo.org/proj/java.git
       $ cd java
       $ git log

  2. Check who's been making commits under dev-java.

       $ cd $PORTDIR/dev-java
       $ find ./ -name ChangeLog | xargs ls -l -h -t

     That should give you a list of ChangeLogs, newest first. YOu can
     look through them and see who's been doing what. I'm sure there's a
     better way using CVS, but I don't know it.

Once you find a few people, just ask politely in #gentoo-java on IRC.

[gentoo-user] Re: The end of

[James]

Michael Orlitzky <mjo <at> gentoo.org> writes:


>   1. See who's active in the Java overlay. This one's easy.

>        $ git clone git://git.overlays.gentoo.org/proj/java.git
>        $ cd java
>        $ git log

agreed.


>   2. Check who's been making commits under dev-java.
 
>        $ cd $PORTDIR/dev-java
>        $ find ./ -name ChangeLog | xargs ls -l -h -t
> 
>      That should give you a list of ChangeLogs, newest first. YOu can
>      look through them and see who's been doing what. I'm sure there's a
>      better way using CVS, but I don't know it.

Yep, done this and more, but, thanks. Oh, since you took the trouble
to include syntax in your response, dozens-hundreds of folks are now
enabled to check up on what we have been talking about, quite easily!

> Once you find a few people, just ask politely in #gentoo-java on IRC.

Here is where I stopped; just before going on the gentoo-java channel. 
I have some other things to fix/finish first.
Besides I'm really curious to see how the herd/project/bugs-wranglers
ends up being organized after the "herds" are gone. It think that the few
weeks after this seminal event occurs will yeild a richly active
gentoo-user community again. I hope we can sustain that energy.
Couch it as "a gift to the user community" from the devs and you'll see
lots of interest and sustained growth in participation at all levels.



Also you did not  




Let me make this crystal clear. All devs should be allowed a manor,
a castle and some authorities the rest of us users (commoners) do not
have. It is the reward for becoming a dev. However nothing in that
reward (from the council to the devs) should interfere with users
from building their own co-op withing the gentoo infrastructers. A round
table if you like all that English-Historical-Parlance. (no offense Neil).

*Celebrate the users* by working to give them the tools (and respect) they
need as the collect with other gentoo_ers. Give them a seat at the table
too. It only takes a few keen devs to pull this off. Just look at the 
amazing work Sven has done with the docs, the wiki and SElinux.


peace && prosperity,
James

[gentoo-user] Re: The end of

[James]

James <wireless <at> tampabay.rr.com> writes:


> Also you did not  

OOps, I was interrupted here. Should have been:

Also, you did not illuminate how I can form a
cluster project, if the exisiting cluster-herd
does not request to be converted to the gentoo cluster-project.

Surely we have a container project now, but no 
active cluster herd or project. I think that is very
important, so if one does not materialize, then how
do users (commoners) go about creating one? Please keep
this question in mind as the devs/council solve the final
state of herd_vs_projects.


James

Re: [gentoo-user] Re: The end of

[Rich Freeman]

On Wed, Nov 5, 2014 at 2:14 PM, James <wireless@tampabay.rr.com> wrote:
>
> Surely we have a container project now, but no
> active cluster herd or project. I think that is very
> important, so if one does not materialize, then how
> do users (commoners) go about creating one? Please keep
> this question in mind as the devs/council solve the final
> state of herd_vs_projects.
>

Well, officially projects can be started by any dev.  We don't really
have a formal process for projects run by users only.

However, if a bunch of users want to do something serious I wouldn't
let that be a reason to stop.  By all means self-organize on any of
the lists (gentoo-user, gentoo-project, gentoo-dev as appropriate),
and if there is something standing in the way of accomplishing
something we can see what we can do to facilitate.

In any FOSS activity the #1 issue tends to be people willing to do the
work.  If we have that, then there is no reason to let anything else
stand in the way.  There are devs who are willing to proxy-maintain,
and if you just need a dev to put a page up on the wiki to call it a
project I'm sure somebody would be willing...

--
Rich

[gentoo-user] Re: The end of

[James]

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



> > Surely we have a container project now, but no
> > active cluster herd or project. 


> In any FOSS activity the #1 issue tends to be people willing to do the
> work.  If we have that, then there is no reason to let anything else
> stand in the way.  There are devs who are willing to proxy-maintain,
> and if you just need a dev to put a page up on the wiki to call it a
> project I'm sure somebody would be willing... Rich


Well well well. Thank you for standing up. I'm going to privately
work on this (cluster folks, java folks and science folks) whilst
your team of devs figures out the final configuration of
devs/projects/bug-wranglers. If you guys are successful in pulling this off,
I have
noticed several corporations with many gentoo-java-ebuilds that might
throw a few crumbs our way. Java has sunken to such a low level on
gentoo, that companies that use Java && Gentoo rarely bother with
contributing back. I cannot speak for them, but I know they watch
and listen from time to time. Java is every bit as big and important
as python is, from a worldly perspective. Gentoo_ers that wish to
be relevant, cannot merely wish this away. Java is a fundamental, enabling
technology and it should be robustly supported by those within gentoo
that care (Despite anything Whoracle does). Yes I am stepping up for this
need, mostly because it is in my critical path now.   I guess I'm acting
like a dev now? Cursed-Beloved?

I'm most willing to support others that want to pursue the cluster work that
is needed. I shall give them every opportunity to lead (those of us newer to
the cluster arena). But in the  end, I'm about getting the work done one way
or another. 

I do appreciate you and Michael for your efforts on this and other 
gentoo issues. I'm trying to be "collegial"  but, I have my viking
heretical issues, like some other over_achievers we all know..... 
One way or another we'll have a robust gentoo cluster offering; I'm just not
sure how long it will take, but we are going to have some fun!

Maybe we'll run cinelerra/blender on the gentoo clusters and build some
"anime" comics of the gentoo dev characters? Clustering will be
a blast! There is one who has done amazing things with clustering
codes and anime  on gentoo clusters already; 
but he remains aloof from gentoo. 
He is also quite young. 


thx,
James

Re: [gentoo-user] The end of "Herds"

[Alec Ten Harmsel]

On 11/04/2014 03:13 PM, James wrote:
> Hello,
>
>
> If you follog gentoo-dev you can see Rich's summary
> interpretation (which I do agree with) posted at the
> bottom of this thread.
>
>
> Recently I was asked to help clean up some of the Java
> bugs. OK, as a non-maintainer I agreed. I went through
> over 100 java bugs, mostly pre 2010, as to make a dent
> in the backlog of ~500 java bugs that would probably
> be the easiest to clean up. Sure enough, there were
> only a few that were still relevant (Hmmmmmmmmmmmmmmmmm)
>
>
> So I proposed, to one of the Java Herd members we blast out 
> a few emails notifying everyone that if folks did not
> "reaffrim" these (very old) java bugs, they would be mass-closed.
> If you look at those (old bugs) most would agree with my
> assessment. However, I listed a few as blatant examples
> that needed to be closed. It seems there is no "closer" for
> java bugs. Nobody around with the authority (will?) to close
> any old Java bugs. The herd is descimated, on furlog or just
> burnt out and non-responsive. So all of my work and 
> effort was for nothing. Over the years, I have made
> at least 3 attemps to use java on gentoo; all resulted in
> using other linix distros. For me, java is a reality
> that cannot be wished away. What I have learn in the last few
> months is that Java on Gentoo is alive and properous; folks with
> Java ebuilds just do not bother with getting them into Gentoo
> because of the morass of apathy the gentoo java hers has become.
>
> So now is the time for folks to read and post to gentoo-dev on 
> thread: :" Deprecating and killing the concept of herds" if
> you have any issues with herds being removed from Gentoo.
> Ideas on how to best organize bug_cleaning is also welcome.
> I think there will be an uptake in proxy-maintainers, if the 
> gentoo-dev club is sincere about treating these proxy maintainers
> with respect and mutual professionalism.
>
> I think the concept of "Projects" will persist, but herds have
> to become active and request to become "Projects" as defined
> on the gentoo wiki or they will be erased. Like many others, 
> I have been burned in the past with trying to get directly involved 
> with Gentoo (been here since 2004). That's all water under the bridge.
> So I am "tip_toeing" behind the scenes willing to be a grunt
> and clean up some of the java mess, participate in clustering and 
> contribute to the science project. We'll see just how long it lasts 
> before I get "bitch_slapped" like  my previous attempts........
>
>
> That's why I named by current /usr/local/portage "jackslap".
> We shall see what happens.
>
>
> I see the enabling of user patches directly into ebuilds in the tree
> (EAPI 6) and the cleansing of the irresponsible amongst the herds
> with exclusive control over bugs  as a very positive sign that the gentoo
> dev community is one again dedicated to making Gentoo an excellent platform.
> Whatever your experiences have been, I hope you read, post 
> and give direct participation in Gentoo your deepest consideration.
>
>
> James
>
>
> <snip>
> My (rich) proposal:
>
> For the steady state:
>
> 1. For the maintainer tag in metadata, have a type attribute that can
> be developer, project, or proxy.
>
> 2. Add a contacts tag in metadata that takes an email.
>
> 3. Package without maintainers (individuals or projects - regardless
> of presence of aliases) get assigned to maintainer-needed and get
> treecleaned as usual.
>
> I'm also fine with normalizing this and just switching to a contact
> tag that can have a type of developer, project, proxy, or contact.
> That is a bigger change.  However, it would probably simplify
> scripting and be a bit cleaner for the long-term.
>
>
> For the transition to the steady state:
>
> a. We generate a list of all current herds and email their aliases to
> see if they want to be converted to a non-maintainer alias, or be
> disbanded entirely.  One reply to the email is enough to keep the
> alias around, no replies means retirement.
>
> b. Anybody in Gentoo can start a project already by following GLEP 39.
> It is encouraged for these projects to take over existing aliases
> where they feel it is appropriate.  There is no need for all aliases
> to have a project - just ones that want some kind of structure (ie
> this is strictly voluntary).  When this is done the project will
> remove the herd from metadata and add the project alias as a
> maintainer with the agreed-upon tagging.
>
> c. We generate a list of all current packages that do not have a
> maintainer (either one or more individuals or projects (NOT herds)).
> That gets posted so that individuals can claim them.  I suggest not
> doing the usual treecleaning email since there could be a LOT of them.
> Or we could do it herd-by-herd over time to ease the load.
>
> d. We remove all herds from the existing packages.  Where aliases were
> kept in (a) above they are converted to aliases with appropriate
> tagging.  If no maintainer exists the package is handled per the
> result of (c).
>
>
> Comments, alternatives, etc?
>
>
>
>
>

There is a large discussion on the Spark mailing list right now about
having groups of maintainers for different areas:

http://apache-spark-developers-list.1001551.n3.nabble.com/VOTE-Designating-maintainers-for-some-Spark-components-td9115.html

I'm not sure how relevant that is, but it's interesting.

My own viewpoint is that there should be no individual maintainers;
packages should be assigned on a herd level, and the herds can
self-regulate and know who has expertise with each package. Just my two
cents; best to not have a single point of failure.

Alec

[gentoo-user] Re: The end of "Herds"

[James]

Alec Ten Harmsel <alec <at> alectenharmsel.com> writes:

> > I think the concept of "Projects" will persist, but herds have
> > to become active and request to become "Projects" as defined
> > on the gentoo wiki or they will be erased. Like many others, 
> > I have been burned in the past with trying to get directly involved 
> > with Gentoo (been here since 2004). That's all water under the bridge.
> > So I am "tip_toeing" behind the scenes willing to be a grunt
> > and clean up some of the java mess, participate in clustering and 
> > contribute to the science project. We'll see just how long it lasts 
> > before I get "bitch_slapped" like  my previous attempts........

> There is a large discussion on the Spark mailing list right now about
> having groups of maintainers for different areas:
> 
>
http://apache-spark-developers-list.1001551.n3.nabble.com/VOTE-Designating-maintainers-for-some-Spark-components-td9115.html
> 
> I'm not sure how relevant that is, but it's interesting.
> 
> My own viewpoint is that there should be no individual maintainers;
> packages should be assigned on a herd level, and the herds can
> self-regulate and know who has expertise with each package. Just my two
> cents; best to not have a single point of failure.


The spark post is relevant to the discussion. But spark is one (large)
code_set and we have thosands of different codes at Gentoo as a distro.
So some of our softwares, such as Python, are like spark and there
are multiple maintainers, like spark. We also have many smaller softwares
(ebuilds) that need someone (anyone?) to step forward and maintain that
singular package. Routine on Gentoo dev, there are packages up for
grabs that need a maintainer. Spark is in the luxury postion of having
many, very talented coders all working on one (large) piece of software.

Beside, I think the the "projects" will provide that group effort
that you admire in the current gentoo herds and the spark community for very
important codes (like gcc, python, perl etc).

 But there will also be many useful softwares that we should keep around
that just need a single maintainer. How it shakes out as to what the devs
will allow for those sorts of packages, like "elvis" for example of a
package that is not in anyone's critical path, but are cool to keep around. 

We, gentoo, have a wide variety of codes to maintain, and we'll need
everyone from the very talented coders to capable_users to maintain
these ebuilds, as our distro grows. We're going to have dozens if not
hundreds of codes (ebuilds) just to fluff out the clustering codes
necessary for a robust set of ebuilds for  gentoo_clustering, imho.

We need more devs and responsible users to help maintain and grow the base
of ebuilds, imho. But I do  agree, spark is going to need a very
talented maintainer...... with quite a bit of java and gentoo expertise?

Beside I think the decision, from what I've read, to terminate herds
is pretty much a "done deal". Think of projects and maintainers and others,
as you formulate gentoo's path forward.


James

[gentoo-user] Re: The end of "Herds"

[James]

Alec Ten Harmsel <alec <at> alectenharmsel.com> writes:


> There is a large discussion on the Spark mailing list right now about
> having groups of maintainers for different areas:

>
http://apache-spark-developers-list.1001551.n3.nabble.com/VOTE-Designating-maintainers-for-some-Spark-components-td9115.html


This is an excellent link and model for a "hi profile" software.
It is a very open and accountable model for code development, reviewing
patches, including patches and in general code maintenance and bug
fixes.

> I'm not sure how relevant that is, but it's interesting.

It is relevant to very large and important codes. I do believe that
most of the gentoo ebuilds  (packages) will not be afforded this
level and number of devs. As the gentoo distro grows, it is a model
for the devs and the council to keep in mind for those critically
important packages... 


James