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
