1 |
On Tue, 6 Aug 2013 23:46:08 +0200 |
2 |
Jeroen Roovers <jer@g.o> wrote: |
3 |
|
4 |
> 23:37:25 <willikins> rej, you have notes! [21:13] <mrueg> Let me |
5 |
> rephrase this: Just a friendly notice to please refrain from |
6 |
> rephrasing bug summaries from "Stabilize ${P}" to "${P} stable req". |
7 |
> This just adds unneeded noise to the bug. I don't want this on bugs |
8 |
> I've reported or am assigned to. |
9 |
> |
10 |
> This is my equally short and "friendly" note: It's not going to |
11 |
> happen. Forget about it. They are not "your" bug reports and anyone is |
12 |
> actually /welcome/ to improve them. Get used to it. |
13 |
|
14 |
This note doesn't really hold well; if two people, not necessarily the |
15 |
reporter or assignee of a bug, want to do opposing improvements then |
16 |
you get an edit war as a result. In mrueg's words, "unneeded noise". |
17 |
|
18 |
The concern is valid; if a person is bothered by changes you make, that |
19 |
person won't get used to those changes at all if they can be undone. |
20 |
|
21 |
-> Why do you think there's only one way of doing it? |
22 |
|
23 |
While I don't know how to search for such change; the last unneeded |
24 |
noise I remember you doing to a bug is adding or removing the dot at |
25 |
the end of a bug summary, doing nothing else to the bug. |
26 |
|
27 |
There are sites, like Stack Exchange, where you are forced to edit |
28 |
multiple characters and type out a summary that explains what you did, |
29 |
as well as providing an easy rollback option; to avoid unneeded edits. |
30 |
It's hand holding because almost anyone can edit on such site; from |
31 |
what I've saw, it really works out well but shouldn't be necessary. |
32 |
|
33 |
-> What does such small unimportant change gain you? |
34 |
|
35 |
Not that I'm bothered, because that was just one extra mail; but |
36 |
repetitively doing stuff similar to this generates much more than just |
37 |
one extra mail, so I get to see multiple mails of this type over the |
38 |
place. And while you're just one person, there are others too; it adds |
39 |
up, up to the point that it's really just a waste of time. |
40 |
|
41 |
-> Why do you think the burden generated from this is worth it? |
42 |
|
43 |
> To get technical on the "improvement" bit, we have agreed time on time |
44 |
> that stating the atom and then the action is the way to go. |
45 |
|
46 |
Who is "we"? Why is it the "way to go"? If you use such language you |
47 |
need to link to the actual evidence; otherwise, despite the reasoning |
48 |
you give, it will be seen as an authoritative contradiction instead of |
49 |
an actual counterargument. You and I know when that was decided, but a |
50 |
new developer doesn't; well, at least I know of the last time it did: |
51 |
|
52 |
http://article.gmane.org/gmane.linux.gentoo.devel/85647 |
53 |
|
54 |
You do the same thing there with "we agreed a little while ago"; and |
55 |
upon request of djc, phajdan.jr and myself there appears to have been |
56 |
no response, only to later be answered by someone else that knows: |
57 |
|
58 |
http://www.gossamer-threads.com/lists/gentoo/dev/173889 |
59 |
|
60 |
As far as I know, there is no requirement to read the entire mail |
61 |
archives and this is undocumented; so, as it is not always as easy to |
62 |
search matters like this (wrong search terms, result on last page, ...) |
63 |
it would help a lot if things were referred to. |
64 |
|
65 |
Otherwise people might simply ignore your statements, discuss it again |
66 |
or just apply the opposite changes; neither of which is what you want. |
67 |
|
68 |
> The main reasons is that it helps people who need to regularly |
69 |
> read /lists/ of bug summaries sort them better. Until we get a |
70 |
> specific [Atoms] field implemented, it will need to stay this way. |
71 |
|
72 |
Has someone already filed a bug with a request for this? |
73 |
|
74 |
> Besides the finer technical points of bug maintenance, it simply |
75 |
> infuriates me that anyone would think of bug reports in the |
76 |
> possessive. |
77 |
|
78 |
It's actually more natural. Again using Stack Exchange as an example, a |
79 |
lot of question titles there tend to be an actual question because |
80 |
some people think it reads much better; I don't think that this is |
81 |
necessarily a good idea for bug summaries, but just want to point out |
82 |
that it is a possibility. |
83 |
|
84 |
Putting the atom first focuses on a summary that feels a bit more |
85 |
machine readable; whereas if you put it into a sentence, it gives a bit |
86 |
more freedom to express it as an actual sentence. It's weird to think |
87 |
about the other way if you're used to one way; but, I consider the end |
88 |
result rather equal, which you probably do as well as it is easy to |
89 |
change between the formats. |
90 |
|
91 |
We can go on for this for a long time, but that would be bike shedding; |
92 |
s,o I just wanted to demonstrate that there are at actually at least two |
93 |
sides on the matter. As agreed in earlier threads, the list readability |
94 |
is indeed a valid reason until a more proper field becomes implemented. |
95 |
|
96 |
Besides that, I think there are much bigger concerns; let me take a |
97 |
random bug title "dnsmasq systemd unit file improvement" and point out |
98 |
that it bothers me more not knowing what the improvement is, let's say |
99 |
you have another bug like this then how would you tell them apart? |
100 |
|
101 |
Knowing which improvements the bug consists of, helps to process the list. |
102 |
|
103 |
> This is not the way to improve the distro. You're on the |
104 |
> wrong track there. And you weren't being friendly. |
105 |
|
106 |
Have you friendly explained the bug list reasoning to him before posting |
107 |
this to the mailing list? Your mail reads more like a personal message |
108 |
to him; this mailing list is for technical discussions, this is none. |
109 |
|
110 |
-- |
111 |
With kind regards, |
112 |
|
113 |
Tom Wijsman (TomWij) |
114 |
Gentoo Developer |
115 |
|
116 |
E-mail address : TomWij@g.o |
117 |
GPG Public Key : 6D34E57D |
118 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D |