Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: Andrew Savchenko <bircoph@g.o>
Cc: 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 13:11:28
Message-Id: 20150810151102.1a5f11fe@pomiot
In Reply to: Re: [gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/) by Andrew Savchenko
1 Dnia 2015-08-10, o godz. 02:16:01
2 Andrew Savchenko <bircoph@g.o> napisał(a):
3
4 > On Mon, 10 Aug 2015 00:40:44 +0200 Michał Górny wrote:
5 > > > > Which is terribly redundant. Just put the whole bug URL. Advantages:
6 > > > >
7 > > > > - keeps the bug namespaced to bugs.gentoo.org,
8 > > > > - has the bug no inside,
9 > > > > - is convenient -- you can click it instead of copy-pasting the no.
10 > > >
11 > > > 1. URL may change in future, bug number — unlikely.
12 > >
13 > > If the URL changes, we need to provide backwards compatibility. Too
14 > > many resources already depend on that.
15 > >
16 > > > 2. Bug number can be easily typed, URL has to be copied or
17 > > > generated by some tool.
18 > >
19 > > So, please remind me, how many times the 'easy typing' got the bug
20 > > number wrong? This is not a real argument, just another of Gentoo's
21 > > 'I'm too lazy to do things right'.
22 >
23 > URLs are longer, so probability of error during typing increases
24 > compared to raw numbers.
25
26 Not really. You are closer to the threshold when you are too lazy to
27 type it and you just copy-paste it.
28
29 > > > 3. Too many text, hard to read. Some bugs may refer to a dozen of
30 > > > URLs.
31 > >
32 > > And how is a dozen numbers better?
33 >
34 > Less text, more readable.
35
36 How is:
37
38 Bug: 123451, 453445, 344334, 343444
39
40 more readable than:
41
42 Bug: https://bugs.gentoo.org/123451
43 Bug: https://bugs.gentoo.org/453445
44 Bug: https://bugs.gentoo.org/344334
45 Bug: https://bugs.gentoo.org/343444
46
47 Readability is a matter of formatting, not contents.
48
49 > > > 4. It is easier to copy a number, than selecting and copying whole
50 > > > string. Not all terminals support running browser on URL click.
51 > >
52 > > So we should optimize for a corner case?
53 >
54 > What is a corner case? Why not defining "clicking on the link in
55 > the git log" as a corner case?
56
57 As far as I'm aware, URLs are supported much more widely than
58 Gentoo-specific bug numbers. They are uniform and unique by definition.
59 The tools using bug numbers can be easily expanded to extract them from
60 URLs. I don't really see forking cgit to support Gentoo bug numbers, or
61 asking github to provide special rules for our commits.
62
63 > > > 5. Clicking is less convenient than typing "bugs search $number" —
64 > > > user have to move hands from a keyboard to a mouse — a terrible
65 > > > waste of time, at least in my case with my typing speed.
66 > >
67 > > You can type the number you see at the end of the URL. If you really
68 > > want to go l33t, that shouldn't a problem for you.
69 >
70 > This is not a matter of going l33t, this is a matter of getting rid
71 > of redundant and pretty much useless data all the same through
72 > almost all commit messages.
73
74 Which reminds me of the metadata.xml discussion. These days we have
75 transparent compression which handles redundant data much better than
76 explicit obfuscation, and with much less harm.
77
78 --
79 Best regards,
80 Michał Górny
81 <http://dev.gentoo.org/~mgorny/>

Replies