Dnia 2015-08-11, o godz. 09:56:55 Dmitry Yu Okunev <dyoku...@ut.mephi.ru> napisał(a):
> Hello. > > I'm not a gentoo-dev, so sorry if I shouldn't express my thoughts with > my lame English here. Please tell me if it's so. > > On 08/11/2015 12:06 AM, Michał Górny wrote: > >>>>>> 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. > > I think it's just individual preference. No sense to argue this. Just > everybody should consider that there exists another position on this > question. > > However I want to add an other argument: > > 1a. It's easier to parse the "Bug:" header is there only bug IDs > (without URLs). What if there are different bug trackers involved? We sometimes note upstream bugs, other distro bugs, pull requests... > And is there any guarantee that URL format won't be changed in future > (that everybody won't be have to rewrite their parsers). I mean not > "near future", but "any long future". I doubt it can change *without* changing the bug tracker software. And then, old IDs will no longer be relevant. In fact, since the URLs are Bugzilla-specific it will allow us to ensure better compatibility if we start numbering bugs from 1 again. There's URL and there's URI. Even if URL is no longer valid, it will still be a valid URI. It will still allow us to uniquely identify the bug report. > >> 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. > > A commit-comment is not a source code. It's an ordinary text (like > "literature"). Literature is a long continuous text which you read left-to-right, and usually without going back. This is short text which you read randomly, possibly going back and forth, and scanning for specific details. > >>> 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? > > You can use header "Gentoo-Bug:" (instead of "Bug:") and explain in > documentation ways to parse that. So you're suggesting it's better to invent a custom format and tell people how to handle it, rather than use a commonly-supported format? -- Best regards, Michał Górny <http://dev.gentoo.org/~mgorny/>
pgpFUxUHmcnoq.pgp
Description: OpenPGP digital signature
