1 |
On Mon, Nov 20, 2017 at 10:19 PM, Matt Turner <mattst88@g.o> wrote: |
2 |
> On Mon, Nov 20, 2017 at 7:15 PM, R0b0t1 <r030t1@×××××.com> wrote: |
3 |
>> What I wanted to avoid was something I encountered on the GCC mailing |
4 |
>> list: When I asked why GCJ was removed, I was told that it was hard to |
5 |
>> maintain. When I asked for an example of past maintenance issues (and |
6 |
>> made it clear I had no interest in disputing whether the issues were |
7 |
>> valid or not) I received no reply from the maintainer except his |
8 |
>> original answer, leaving me to wonder whether GCJ was actually hard to |
9 |
>> maintain. |
10 |
>> |
11 |
>> I have seen similar exchanges associated with other projects. |
12 |
> |
13 |
> When you have no standing in the project, there's little incentive to |
14 |
> justify one's actions and decisions to you. |
15 |
> |
16 |
|
17 |
No, but common courtesy would be to provide a short answer. If what I |
18 |
have requested is more work than the individual wants to undertake |
19 |
they would be free to say so (which is why I was confused, I only |
20 |
expected a sentence or two, and this is why I felt I should explain |
21 |
robbat2's answer was better than I expected). At the same time, I aim |
22 |
to only ask questions that I feel the other person would have already |
23 |
considered. In this case, if the decision is the right one, then a |
24 |
coherent explanation of why the actions being taken are being taken |
25 |
should already exist in some form. |
26 |
|
27 |
If they don't, then why is action being taken? |
28 |
|
29 |
|
30 |
There is another comment of mine on this list where I asked a |
31 |
developer why a package was being dropped. I had no intention of |
32 |
disputing their decision, but I felt the given reason was too vague to |
33 |
be useful. Their response was maybe two sentences and added something |
34 |
like "upstream is being difficult." That seemed fine. |
35 |
|
36 |
Cheers, |
37 |
R0b0t1 |