1 |
Michael Orlitzky <mjo <at> gentoo.org> writes: |
2 |
|
3 |
|
4 |
> This is exactly the problem we're trying to solve (and I'm sorry to hear |
5 |
> it, many of us have been in a similar position). |
6 |
|
7 |
Yep. |
8 |
The point is not to "bemoan" the issue, but steer gentoo into a direction |
9 |
where those who are not devs (for whatever reason) can easily contribute |
10 |
to creating and maintaining a richer diversity of (ebuild) sofware |
11 |
packages on Gentoo. Nothing is this movement prevents the good_old_dev |
12 |
club from propering; it just allows the user community to build out |
13 |
their systems, as they like. Devs can help, or stand aside, but |
14 |
blocking (Gentoo) users form making their systems what they want |
15 |
should be "celebrated" because that is the essential core value |
16 |
of Gentoo, imho. |
17 |
|
18 |
|
19 |
> Herds as a group of developers have always been very poorly-defined. As |
20 |
> I've heard it repeated, originally packages were supposed to belong to |
21 |
> herds, and developers were supposed to belong to projects. But herds |
22 |
> almost always had an associated email address, so people who cared about |
23 |
> groups of packages would add themselves to the herd to get on the email |
24 |
> alias. But projects were there all along, too, and we wound up with a |
25 |
> bunch of people in herds who were never going to fix bugs and some |
26 |
> smaller number of people in projects (who might fix bugs) that weren't |
27 |
> in the herds. It was all very confusing, so the council is voting to |
28 |
> replace them with something that makes sense. |
29 |
|
30 |
Finally. I understand that herds and projects, although not completely |
31 |
the same thing, have so much overlap that both are not needed. Cleaning |
32 |
out the cruft {} is a major step in revitalizing the Gentoo distro, imho. |
33 |
|
34 |
|
35 |
> Basically we want to fix the situation we have right now where it's |
36 |
> impossible to tell who is actually working on Java packages. Once herds |
37 |
> are replaced, you should be able to get an accurate reading out of |
38 |
> metadata.xml and/or the wiki page. (And I'm sure anyone actually working |
39 |
> on Java would appreciate your help.) |
40 |
|
41 |
One problem I see is there is not a "one to one" mapping of the herds |
42 |
to projects. There is a clustering herd and some are still active devs, |
43 |
but the herd has no balls (a bunch of steers?). I proposed that that |
44 |
group be migrated to a project and was told that somebody in the cluster |
45 |
herd (a dev) would have to make that effort (sending a one sentence email). |
46 |
|
47 |
If they are not interested, how do a group of users become the cluster project? |
48 |
|
49 |
|
50 |
Right now, most cluster related codes are worked on by the science herd/project. |
51 |
|
52 |
|
53 |
|
54 |
> For you personally, I would try to find one or two people on the Java |
55 |
> project (actually working on Java right now) and explain to them that |
56 |
> you'd like to help close old bugs. Then you can CC or reassign the Java |
57 |
> bugs to those people. When bug mail gets sent to a herd or project, it's |
58 |
> too easy to say "screw it, someone else will deal with it." Bugs |
59 |
> addressed to me personally get attention much sooner, even if only for |
60 |
> psychological reasons. So reassigning those to a single person might |
61 |
> prompt action sooner than you'd get otherwise. |
62 |
|
63 |
|
64 |
Can you send me their gentoo mail addresses, privately? |
65 |
|
66 |
I understand that we are all a bunch of volunteers. I get it, having |
67 |
bootstrapped 6 companies myself over the years. I appreciate all |
68 |
of the former and current devs. I do not wish to be a burden on anyone. |
69 |
That said, I'm a team builder and would prefer to get users to do the |
70 |
vast majority of the work, with me. If folks (kids) want to become |
71 |
a gentoo dev, *thats great*; I just want a gentoo distro where *I* can |
72 |
get done what I want and a dev community that either supports my vision(s) |
73 |
or builds the core tools, systems and infrastructure that makes my |
74 |
efforts and the efforts of other users, an enjoyable experience with Gentoo. |
75 |
|
76 |
|
77 |
Sure some will migrate to the gentoo dev status, that's great. For me |
78 |
I'd have to *see the changes* before going down that road again. Just look |
79 |
at those old bugs for Java, You can "flush" them all older that 2010 |
80 |
without issue, in one blasted email, deprecation define stroke. I'm |
81 |
not waisting any more time on that crap. If you doubt this, start searching |
82 |
out those old bugs and find me one from pre-2010 that is still relevant; |
83 |
also report how many you looked at before you found one that is still |
84 |
relevant? |
85 |
|
86 |
Facilitating an easy, straightforward, with plenty of examples for user |
87 |
to patch (gentoo-tree) ebuilds on their systems, to setup there own, git |
88 |
hub repository and clearly document examples of how to hack ebuilds, would |
89 |
go a long way to making the user base very happy, imho. There are efforts, |
90 |
but they are mostly "piece_meal", imho. If this finally emerges, you have |
91 |
too many (qualified) applicants for gentoo dev and you'll have a very happy |
92 |
user base; which will grow the gentoo adoptions vastly around the net. |
93 |
|
94 |
Crib to Palace (or as the brothers would say, Mom's crib to my crib |
95 |
aka crib-2-crib). But I'm not convince that the rank a file devs of gentoo |
96 |
want to empower the user communityh to that level. Being older, it's a "show |
97 |
me da money" time for those keen gentoo devs whom aspire for Gentoo to be a |
98 |
user's distro. |
99 |
|
100 |
Don't worry about me, I'm a mean old bastard; but I would worry about why |
101 |
we have a lack of college age kids stepping forward into the gentoo-dev |
102 |
space. Worry deeply about that, bro! Cause I can recruit them, but will |
103 |
they put up with the existing fiefdoms? |
104 |
|
105 |
|
106 |
|
107 |
Goodluck! |
108 |
James |