Gentoo Archives: gentoo-dev

From: Andrew Savchenko <bircoph@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)
Date: Mon, 10 Aug 2015 20:43:58
Message-Id: 20150810234329.4007a427b15375814f9c7ea2@gentoo.org
In Reply to: Re: [gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/) by "Michał Górny"
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

Replies