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

[Michał Górny]

Dnia 2015-08-10, o godz. 23:43:29
Andrew Savchenko <bircoph@g.o> napisał(a):

> 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.

Excuse me but could you stop shifting from one argument to another?
Because this is not going anywhere if we're going to switch from X to
Y, and back, depending on which goal fits you at the moment.

> > > > > 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.

Character counts are completely irrelevant to readability. Visual space
is. And in this case, exhibit A (also known as wall of digits) is more
likely to get people confused.

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

This is not literature. Keys usually precede values, and namespaces
precede namespaced identifiers.

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

Well, maybe I'm very special then because I can *instantly* notice that
the four quoted lines are almost identical and differ only by bug
numbers.

> 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.

And that's the first valid argument. Though I would doubt that
accessibility software handles random numbers better than URLs. Unless
you consider retyping one of the six numbers you just heard easier than
triggering some kind of URL activation feature.

> > > 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.

URLs are not github invention. Localized bug numbers are local Gentoo
non-sense. So should we adjust it to ignore the rest of the world and
expect everyone to create custom hackery just to be able to see a bug
report?

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>