Re: [gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)

[Andrew Savchenko <bircoph@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 3127 bytes --]

On Mon, 10 Aug 2015 15:11:02 +0200 Michał Górny wrote:
> > > > 2. Bug number can be easily typed, URL has to be copied or
> > > > generated by some tool.
> > > 
> > > So, please remind me, how many times the 'easy typing' got the bug
> > > number wrong? This is not a real argument, just another of Gentoo's
> > > 'I'm too lazy to do things right'.
> > 
> > URLs are longer, so probability of error during typing increases
> > compared to raw numbers.
> 
> Not really. You are closer to the threshold when you are too lazy to
> type it and you just copy-paste it.

Copy and pasting requires more time than typing 6 digits.
 
> > > > 3. Too many text, hard to read. Some bugs may refer to a dozen of
> > > > URLs.
> > > 
> > > And how is a dozen numbers better?
> > 
> > Less text, more readable.
> 
> How is:
> 
>   Bug: 123451, 453445, 344334, 343444
> 
> more readable than:
> 
>   Bug: https://bugs.gentoo.org/123451
>   Bug: https://bugs.gentoo.org/453445
>   Bug: https://bugs.gentoo.org/344334
>   Bug: https://bugs.gentoo.org/343444
> 
> Readability is a matter of formatting, not contents.

1. One line and 35 chars are certainly more readable than four lines
and 140 chars.

2. Strings are read from left to right (at least in English), thus
having most important information last on the line is not
convenient.

3. A lot of duplicated and useless information consumes time and
space, irritating people.

4. Think about people using special accessibility devices like
speech-to-text engine or Braille terminal. It will be pain for them
to read all this notorious URLs. And we have at least one developer
relying upon such devices.

> > What is a corner case? Why not defining "clicking on the link in
> > the git log" as a corner case?
> 
> As far as I'm aware, URLs are supported much more widely than
> Gentoo-specific bug numbers. They are uniform and unique by definition.
> The tools using bug numbers can be easily expanded to extract them from
> URLs. I don't really see forking cgit to support Gentoo bug numbers, or
> asking github to provide special rules for our commits.

We should not adjust our ecosystem for closed and proprietary
solutions like github.
 
> > > > 5. Clicking is less convenient than typing "bugs search $number" —
> > > > user have to move hands from a keyboard to a mouse — a terrible
> > > > waste of time, at least in my case with my typing speed.
> > > 
> > > You can type the number you see at the end of the URL. If you really
> > > want to go l33t, that shouldn't a problem for you.
> >  
> > This is not a matter of going l33t, this is a matter of getting rid
> > of redundant and pretty much useless data all the same through
> > almost all commit messages.
> 
> Which reminds me of the metadata.xml discussion. These days we have
> transparent compression which handles redundant data much better than
> explicit obfuscation, and with much less harm.
 
I'm not talking about bits on disk (though they matter too), but
more about human being reading them.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]