1 |
On Tue, 07 Jul 2009 13:49:34 +0100 |
2 |
Steven J Long <slong@××××××××××××××××××.uk> wrote: |
3 |
> I'll second that; it's impossible to discuss on bugzilla, as you just |
4 |
> get trolled or spammed. |
5 |
|
6 |
Funny. Other people manage just fine. Perhaps you should consider that |
7 |
it's your behaviour that's the issue here. In the mean time, please |
8 |
provide examples of PMS bugs where you feel you've been unable to |
9 |
provide a useful contribution -- I had a look through bugs with your |
10 |
comments in the PMS/EAPI component, and I found: |
11 |
|
12 |
182028: You post a 'solution' that doesn't solve the requirements, and |
13 |
then go off and start hurling abuse at David when he tells you that. |
14 |
|
15 |
201499: You suggest a few things involving metadata.xml, and you are |
16 |
told why that can't be done. The discussion continues productively. |
17 |
|
18 |
230725: You helpfully implement a patch. The Council decides it doesn't |
19 |
like the feature in question and rejects it. |
20 |
|
21 |
250077: You jump in the middle of a discussion and start muddying the |
22 |
waters with something we're not addressing. |
23 |
|
24 |
> The process appears to be moving to "get discussion off ML and onto |
25 |
> bugzilla where it can be killed" which appears to be a subversion of |
26 |
> things, from where I'm sitting; I thought the idea was to have ML |
27 |
> discussion _before_ stuff was proposed for a new EAPI? |
28 |
|
29 |
That's up to the developers that file the bug. The PMS team has been |
30 |
fairly flexible in how it handles input, although per Council request |
31 |
we're going to try to do everything on bugzilla for EAPI 4. |
32 |
|
33 |
> As it is, we're now getting long lists of stuff dumped on to the ML |
34 |
> as "the new EAPI" with little review beyond a post-hoc justification |
35 |
> that "a Gentoo dev filed a bug asking for it." |
36 |
|
37 |
This is a no-win situation. When I do review features and suggest |
38 |
modifications or not including them, I'm accused of meddling and only |
39 |
allowing through things I like. When I don't, I'm accused of allowing |
40 |
features through without review. |
41 |
|
42 |
Also, did you miss the whole extensive review thing the Council and |
43 |
any developer who feels like it does? I shall remind you that a good |
44 |
number of features on the EAPI 3 proposal didn't make it. |
45 |
|
46 |
> NB: I'm happy for there to be discussion via bugzilla, but not under |
47 |
> ciaranm's supervision. After all, he's been proven to have issues |
48 |
> when it comes to social interaction, which is pretty much essential |
49 |
> to leading a project. |
50 |
|
51 |
I'll agree I get confused easily when people start sockpuppeting or |
52 |
posting pages of incoherent nonsense to unrelated bugs. If you can find |
53 |
someone capable of dealing with the odd bad apple who does that then |
54 |
I'd be happy for them to handle that part. |
55 |
|
56 |
> And even then, I think ideas should be mooted to the list (via the |
57 |
> RFC mechanism?) in line with the agreed process. |
58 |
|
59 |
The agreed process is to go to bugzilla, not the list. |
60 |
|
61 |
> The PMS list has the same problem: it's seen as ciaranm's domain, and |
62 |
> we all know he doesn't set a collaborative tone, but rather one of |
63 |
> conflict, which anyone on a clock can't be bothered with. |
64 |
|
65 |
Please point to examples of conflict on the PMS mailing list. Also, I |
66 |
shall remind you that the PMS list was a Council decision and that it |
67 |
was primarily to replace the alias we were using for sending patches |
68 |
for review -- that's still what it's being used for. |
69 |
|
70 |
-- |
71 |
Ciaran McCreesh |