1 |
On 11/04/2014 03:13 PM, James wrote: |
2 |
> Hello, |
3 |
> |
4 |
> |
5 |
> If you follog gentoo-dev you can see Rich's summary |
6 |
> interpretation (which I do agree with) posted at the |
7 |
> bottom of this thread. |
8 |
> |
9 |
> |
10 |
> Recently I was asked to help clean up some of the Java |
11 |
> bugs. |
12 |
> |
13 |
> ... |
14 |
> So I proposed, to one of the Java Herd members we blast out |
15 |
> a few emails notifying everyone that if folks did not |
16 |
> "reaffrim" these (very old) java bugs, they would be mass-closed. |
17 |
> If you look at those (old bugs) most would agree with my |
18 |
> assessment. However, I listed a few as blatant examples |
19 |
> that needed to be closed. It seems there is no "closer" for |
20 |
> java bugs. Nobody around with the authority (will?) to close |
21 |
> any old Java bugs. The herd is descimated, on furlog or just |
22 |
> burnt out and non-responsive. So all of my work and |
23 |
> effort was for nothing. |
24 |
|
25 |
This is exactly the problem we're trying to solve (and I'm sorry to hear |
26 |
it, many of us have been in a similar position). |
27 |
|
28 |
Herds as a group of developers have always been very poorly-defined. As |
29 |
I've heard it repeated, originally packages were supposed to belong to |
30 |
herds, and developers were supposed to belong to projects. But herds |
31 |
almost always had an associated email address, so people who cared about |
32 |
groups of packages would add themselves to the herd to get on the email |
33 |
alias. But projects were there all along, too, and we wound up with a |
34 |
bunch of people in herds who were never going to fix bugs and some |
35 |
smaller number of people in projects (who might fix bugs) that weren't |
36 |
in the herds. It was all very confusing, so the council is voting to |
37 |
replace them with something that makes sense. |
38 |
|
39 |
Basically we want to fix the situation we have right now where it's |
40 |
impossible to tell who is actually working on Java packages. Once herds |
41 |
are replaced, you should be able to get an accurate reading out of |
42 |
metadata.xml and/or the wiki page. (And I'm sure anyone actually working |
43 |
on Java would appreciate your help.) |
44 |
|
45 |
For you personally, I would try to find one or two people on the Java |
46 |
project (actually working on Java right now) and explain to them that |
47 |
you'd like to help close old bugs. Then you can CC or reassign the Java |
48 |
bugs to those people. When bug mail gets sent to a herd or project, it's |
49 |
too easy to say "screw it, someone else will deal with it." Bugs |
50 |
addressed to me personally get attention much sooner, even if only for |
51 |
psychological reasons. So reassigning those to a single person might |
52 |
prompt action sooner than you'd get otherwise. |