1 |
On Mon, 10 Aug 2015 15:11:02 +0200 Michał Górny wrote: |
2 |
> > > > 2. Bug number can be easily typed, URL has to be copied or |
3 |
> > > > generated by some tool. |
4 |
> > > |
5 |
> > > So, please remind me, how many times the 'easy typing' got the bug |
6 |
> > > number wrong? This is not a real argument, just another of Gentoo's |
7 |
> > > 'I'm too lazy to do things right'. |
8 |
> > |
9 |
> > URLs are longer, so probability of error during typing increases |
10 |
> > compared to raw numbers. |
11 |
> |
12 |
> Not really. You are closer to the threshold when you are too lazy to |
13 |
> type it and you just copy-paste it. |
14 |
|
15 |
Copy and pasting requires more time than typing 6 digits. |
16 |
|
17 |
> > > > 3. Too many text, hard to read. Some bugs may refer to a dozen of |
18 |
> > > > URLs. |
19 |
> > > |
20 |
> > > And how is a dozen numbers better? |
21 |
> > |
22 |
> > Less text, more readable. |
23 |
> |
24 |
> How is: |
25 |
> |
26 |
> Bug: 123451, 453445, 344334, 343444 |
27 |
> |
28 |
> more readable than: |
29 |
> |
30 |
> Bug: https://bugs.gentoo.org/123451 |
31 |
> Bug: https://bugs.gentoo.org/453445 |
32 |
> Bug: https://bugs.gentoo.org/344334 |
33 |
> Bug: https://bugs.gentoo.org/343444 |
34 |
> |
35 |
> Readability is a matter of formatting, not contents. |
36 |
|
37 |
1. One line and 35 chars are certainly more readable than four lines |
38 |
and 140 chars. |
39 |
|
40 |
2. Strings are read from left to right (at least in English), thus |
41 |
having most important information last on the line is not |
42 |
convenient. |
43 |
|
44 |
3. A lot of duplicated and useless information consumes time and |
45 |
space, irritating people. |
46 |
|
47 |
4. Think about people using special accessibility devices like |
48 |
speech-to-text engine or Braille terminal. It will be pain for them |
49 |
to read all this notorious URLs. And we have at least one developer |
50 |
relying upon such devices. |
51 |
|
52 |
> > What is a corner case? Why not defining "clicking on the link in |
53 |
> > the git log" as a corner case? |
54 |
> |
55 |
> As far as I'm aware, URLs are supported much more widely than |
56 |
> Gentoo-specific bug numbers. They are uniform and unique by definition. |
57 |
> The tools using bug numbers can be easily expanded to extract them from |
58 |
> URLs. I don't really see forking cgit to support Gentoo bug numbers, or |
59 |
> asking github to provide special rules for our commits. |
60 |
|
61 |
We should not adjust our ecosystem for closed and proprietary |
62 |
solutions like github. |
63 |
|
64 |
> > > > 5. Clicking is less convenient than typing "bugs search $number" — |
65 |
> > > > user have to move hands from a keyboard to a mouse — a terrible |
66 |
> > > > waste of time, at least in my case with my typing speed. |
67 |
> > > |
68 |
> > > You can type the number you see at the end of the URL. If you really |
69 |
> > > want to go l33t, that shouldn't a problem for you. |
70 |
> > |
71 |
> > This is not a matter of going l33t, this is a matter of getting rid |
72 |
> > of redundant and pretty much useless data all the same through |
73 |
> > almost all commit messages. |
74 |
> |
75 |
> Which reminds me of the metadata.xml discussion. These days we have |
76 |
> transparent compression which handles redundant data much better than |
77 |
> explicit obfuscation, and with much less harm. |
78 |
|
79 |
I'm not talking about bits on disk (though they matter too), but |
80 |
more about human being reading them. |
81 |
|
82 |
Best regards, |
83 |
Andrew Savchenko |