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

classic Classic list List threaded Threaded
82 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

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

hasufell
As I see it, a lot of people already stuff the bug number into the
summary and I can't really say anything against that. It gives a nice
overview when you look at it:
https://gitweb.gentoo.org/repo/gentoo.git/log/

Given that fact, I am not sure we can convince people to repeat the bug
number in the description of the commit. However, the bug url definitely
does not fit into the summary, but in the description. That would be an
argument for the bug url thing (so we actually have both).

As in: try to stuff the bug number in the summary and also give a link
in the commit description in the form of "Gentoo-Bug-url: ...".

Reply | Threaded
Open this post in threaded view
|

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

Daniel Campbell (zlg)
In reply to this post by Davide Pesavento-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 08/09/2015 11:49 AM, Davide Pesavento wrote:

> On Sun, Aug 9, 2015 at 8:43 AM, Mike Gilbert <[hidden email]>
> wrote:
>> On Sun, Aug 9, 2015 at 11:30 AM, hasufell <[hidden email]>
>> wrote:
>>> On 08/09/2015 05:19 PM, Tobias Klausmann wrote:
>>>> Hi!
>>>>
>>>> On Sun, 09 Aug 2015, Sven Vermeulen wrote:
>>>>
>>>>> On Sun, Aug 09, 2015 at 04:43:36PM +0200, Dirkjan Ochtman
>>>>> wrote:
>>>>>>> I think "X-Gentoo-Bug: 557022" also makes the job
>>>>>>> easier for tools that parse commit messages.
>>>>>>
>>>>>> I don't. Just the "bug " prefix should be fine for almost
>>>>>> all purposes, even for tools.
>>>>>
>>>>> I'm pretty sure the majority of developers don't care that
>>>>> one developer uses "X-Gentoo-Bug" and another just adds it
>>>>> to the commit title.
>>>>>
>>>>> I like /guidelines/ in the sense that, if I don't know
>>>>> something, I can look it up. But don't make it mandatory
>>>>> until we start depending on it (for instance, when we would
>>>>> automate stuff based on the content of the commit
>>>>> message).
>>>>
>>>> I'd just go with "Gentoo-Bug". The X- is pointless since it
>>>> was for eXtending Email-Headers. And what we do is only
>>>> linked in style.
>>>>
>>>
>>> I'd be fine with that and add a reference to the kernel
>>> guideline [0] to the wiki as well, so that it is clear that we
>>> also allow/use Acked-by, Reviewed-by, Suggested-by and
>>> whatnot.
>>>
>>> I'll wait for more ++ though.
>>
>> I like Gentoo-Bug. Much nicer without the X-.
>>
>
> +1 for Gentoo-Bug (or Gentoo-bug? not sure about the
> capitalization)
>
I guess I'm the third +1 here. Gentoo-Bug: xxxxxx is far better than
linking to it, since the URL scheme may change in the future. Bug
number is not likely to and it's clear what the number is referring to.

- --
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVx+k8AAoJEAEkDpRQOeFwff8P/ROogCO8pBB7GH7epA3E/ObZ
udQIG8qupPiXfY9JUSR64ST4qNeeRL9Exu0RqeicgbLWdm0fXfmVkxzFmtGjahlp
nkNIGQOZX4f8Y27+2Ly9HO3oJqTNVq6sKgJBNkRnybOhqOFgaqEYWiJUZVdcNfUZ
7G1aS3MXTxysG2CzQwt3sEQSoMFKwp1PetXgF2f4ZsQlr/wHkyyd3yllQyKS9iqK
VG+IawTTYylQa04MTn8V9oW0jdoU8uL0HEH+3FKFZJq7t2bGT/GsW6iIxW78kaVt
iBQCkW6CK24IFRnP31oz8zuwbtK6OFg1Cx5fIRYYfsvaqCDzg5HqV81I5iZ61ZEr
GWUwoHYRXrw2RG6kC0V6TyvOVUDGTAGA+9jYIRNkMJtNhTlDosztyhCmkXLvajZE
QWXQ4FYXJy0OXytk1kK2+6cRNUJLhz/QfwXOlsSQNHfcCJuZQJ2xN73twzOpSPo+
ZCDclX84MV+cLJslZZVLNcjWToE/LZLw4a1VKvt3MDOAlhpMiPfcABWB65RcR7N4
7LcOM6APIsaYsJsgsZDSNlq5ckIkqZk55d6S7LADHwbyQac/o7kP05atGOuiaw9/
EbmTcXoM73+oemhce/dGc5/iPH+JYkoAkN94pbqWhj4wWykatcmE2TW1FLNPZdmi
/a0RFqIXsv8k9y0MZvEs
=ydn7
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

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

Daniel Campbell (zlg)
In reply to this post by Michał Górny-5
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 08/09/2015 02:11 PM, Michał Górny wrote:

> Dnia 2015-08-09, o godz. 23:01:32 hasufell <[hidden email]>
> napisał(a):
>
>> On 08/09/2015 09:56 PM, Michał Górny wrote:
>>> Dnia 2015-08-09, o godz. 16:09:29 hasufell
>>> <[hidden email]> napisał(a):
>>>
>>>> On 08/09/2015 03:58 PM, Michael Weber wrote:
>>>>> commit:     40b3fd64ec9c5d6d94f0f0897740bc77622c24a1
>>>>> Author:     Michael Weber <xmw <AT> gentoo <DOT> org>
>>>>> AuthorDate: Sun Aug  9 13:58:26 2015 +0000 Commit:
>>>>> Michael Weber <xmw <AT> gentoo <DOT> org> CommitDate: Sun
>>>>> Aug  9 13:58:26 2015 +0000 URL:
>>>>> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=40b3fd64
>>>>>
>>>>>
>>>>>
sci-libs/opencascade: add USE=vtk (bug 557022, thanks Helmut Jarausch).
>>>>>
>>>>
>>>> I was wondering if we should set a standard for referencing
>>>> bug reports. The portage team already does something like
>>>> that:
>>>> https://github.com/gentoo/portage/commit/b7149002bf23889f280c502afe
6ceda0b1345ca3
>>>>
>>>>
>>>>
Following that, the commit could have been:

>>>> ===== sci-libs/opencascade: add USE=vtk
>>>>
>>>> thanks to Helmut Jarausch
>>>>
>>>> X-Gentoo-Bug: 557022 X-Gentoo-Bug-url:
>>>> https://bugs.gentoo.org/show_bug.cgi?id=557022 =====
>>>
>>> Which is terribly redundant. Just put the whole bug URL.
>>> Advantages:
>>>
>>> - keeps the bug namespaced to bugs.gentoo.org, - has the bug no
>>> inside, - is convenient -- you can click it instead of
>>> copy-pasting the no.
>>>
>>> Also there are some standard keywords that are sometimes used
>>> to reference bugs, like 'Fixes:' used by x.org.
>>>
>>
>> I am not sure what exactly you do propose.
>
> Fixes: https://bugs.gentoo.org/show_bug.cgi?id=557022 References:
> https://bugs.gentoo.org/show_bug.cgi?id=557022 X-Bug-URL:
> https://bugs.gentoo.org/show_bug.cgi?id=557022 Whatever:
> https://bugs.gentoo.org/show_bug.cgi?id=557022
>
> Just no magical numbers which are meaningless without the context.
>
The issue with linking is that we may not be using show_bug.cgi (or
'id' in GET) forever. Bug numbers would be feasible to migrate outside
of Bugzilla, and technically a webserver can be used to translate
those URLs, but the important bit of information is the bug number.

I don't know about you guys, but I have a "smart bookmark" in Firefox
where I type "bgo xxxxxx" and it'll take me to the relevant bug. It'd
be trivial to set that up as a bash alias, too. There are tons of ways
to get to a bug; the important part is the bug number. I think putting
the URL in there adds extra work for us later down the road should we
migrate away from Bugzilla.

- --
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVx+oQAAoJEAEkDpRQOeFwoYwQAKSYfi2sXsYfghAsA/ym+sV9
aP6+1iTlOqxibYwfMrF5S6PeCIZDgfX/FMV41L344b2nchcOQz6JrgZ/iAWeOOHR
fvlzP1jz879P3xW2vktdOpEBK8j2Pz8M12qJuYLCM98u2mTqGKl6MieuTD5l5LDq
PASSyI1BckNcBDgiiI9IDkXzINLEYDIoTKCLvndyCBabeF+0ydRK9iX+iHHPhnG7
qz7AndjuSl6JbT0W6IPvkpssSFC67bfq2vEUows+Ek3CvhE/K+qcopcbnJjJyfsf
0ELaKUzNgioW6blX/uQK6pfs5QIsZpfM/mhrMa5y03a7b+JZUt+HEsyh8hmSf7lP
LhfOnV+h4EAAREFdYa9MI1Hn+rZ/lfTOY1Gp0pHFKAX9cu7Xhxn6uu9he6M8EOPG
es03hoB5cyzvsBJ/r7OggySidXeovtFVdPuPDkom82KqqrB/qG9qM458u4d8uWh/
y3nMLKCPuOiKL981RNijXwjZ5MKxSFrgrutgEQ+tJfiLfncz8ySmqNjrP2DJQBwi
+vK7/trpooh//6yEFVq+MYH8COqFzQrImkHe4OprrxQFBTLeCfVwMp15Usw73Wbh
D8+7rW2uz9TYqBom/dAdEzLNO00DKpJpp724k4RXsE6FCeT2N+6vIJZfyNTiB8f1
ohES4L5gJI3GZnr556G3
=pxsK
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

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

Ryan Hill
In reply to this post by Andrew Savchenko
On Mon, 10 Aug 2015 00:44:09 +0300
Andrew Savchenko <[hidden email]> wrote:

> On Sun, 9 Aug 2015 21:56:05 +0200 Michał Górny wrote:
> > Dnia 2015-08-09, o godz. 16:09:29
> > hasufell <[hidden email]> napisał(a):
> >
> > > On 08/09/2015 03:58 PM, Michael Weber wrote:
> > > > commit:     40b3fd64ec9c5d6d94f0f0897740bc77622c24a1
> > > > Author:     Michael Weber <xmw <AT> gentoo <DOT> org>
> > > > AuthorDate: Sun Aug  9 13:58:26 2015 +0000
> > > > Commit:     Michael Weber <xmw <AT> gentoo <DOT> org>
> > > > CommitDate: Sun Aug  9 13:58:26 2015 +0000
> > > > URL:
> > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=40b3fd64
> > > >
> > > > sci-libs/opencascade: add USE=vtk (bug 557022, thanks Helmut Jarausch).
> > > >
> > >
> > > I was wondering if we should set a standard for referencing bug reports.
> > > The portage team already does something like that:
> > > https://github.com/gentoo/portage/commit/b7149002bf23889f280c502afe6ceda0b1345ca3
> > >
> > > Following that, the commit could have been:
> > > =====
> > > sci-libs/opencascade: add USE=vtk
> > >
> > > thanks to Helmut Jarausch
> > >
> > > X-Gentoo-Bug: 557022
> > > X-Gentoo-Bug-url: https://bugs.gentoo.org/show_bug.cgi?id=557022
> > > =====
> >
> > Which is terribly redundant. Just put the whole bug URL. Advantages:
> >
> > - keeps the bug namespaced to bugs.gentoo.org,
> > - has the bug no inside,
> > - is convenient -- you can click it instead of copy-pasting the no.
>
> 1. URL may change in future, bug number — unlikely.
> 2. Bug number can be easily typed, URL has to be copied or
> generated by some tool.
> 3. Too many text, hard to read. Some bugs may refer to a dozen of
> URLs.
> 4. It is easier to copy a number, than selecting and copying whole
> string. Not all terminals support running browser on URL click.
> 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.
>
> Best regards,
> Andrew Savchenko
>
Also the URL should be https://bugs.gentoo.org/557022 so already that's wrong.


--
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

attachment0 (486 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Daniel Campbell (zlg)
In reply to this post by hasufell
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 08/09/2015 04:46 PM, hasufell wrote:

> As I see it, a lot of people already stuff the bug number into the
> summary and I can't really say anything against that. It gives a
> nice overview when you look at it:
> https://gitweb.gentoo.org/repo/gentoo.git/log/
>
> Given that fact, I am not sure we can convince people to repeat the
> bug number in the description of the commit. However, the bug url
> definitely does not fit into the summary, but in the description.
> That would be an argument for the bug url thing (so we actually
> have both).
>
> As in: try to stuff the bug number in the summary and also give a
> link in the commit description in the form of "Gentoo-Bug-url:
> ...".
>
I'd be willing to accept a Gentoo-Bug-URL:, on the condition that it's
not required as long as Gentoo-Bug: or the bug's number is in the
description/summary.

- --
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVx+rIAAoJEAEkDpRQOeFw7xYQAN2HMXnULjqEHQiTIAAq++xg
t352gwmNsyOxOFBsOlDX5xW55mx+z2BFw4S65PoRYn76ds+eSn5GDxuDjHFijcTm
ZkJEIkNLUCvt4wKILgBKTbiy5AkqTGZMyGiQT6dkAZexeoE5mQ6HVVjeLzaMilp+
1vtqIAwYnz9PqTdP2GxeGNAkhha//gy6M5s3jJqcY1JfnvrhIBcdaOP4aXE4BbKj
asPWvlz+Fgx8ZC9ankobyyCdhaPBH3tOKWdquKHR9hwx59S4sxo6VF14IdG1yxaZ
JCe7qyQdCi5aLs6IsoMGdcQubuMPF68ugj9Z4/+yKGqxt7e3meGmO5SzwGjvG8a8
RfWIa587Uxkh+Egs/I5wMbKGFUr5QMQwgXjjjC7+dLCyVT/wQXXF+Y/vL60vO41l
tRXNe0dye251+H23eOjePJ/UrViJNpq2V0SAMz8Y2ild5TGZD6rIu25WZzyT/cHb
yikvRxCUYlu9UttbKuaCCZy+69vbPkV2ugCT9e6uq1vh7uUrFTeg60KYsp6aotcm
EmPZFiLFG1BRu2tOw8KQdEvPPkZpjCg+m+rE3OrThI+c2AkaMR4TB17PyL5wXZ6c
ZwzJnJ6Sqkv7RdZAQkq5tIUN29qgtSR+DT6VLZ7E1ZmbFqn66jiIE7+Hm+Wm4Q5p
s3DHH6qJxM40Jr5jQ+B2
=/qBQ
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

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

Kent Fredric
In reply to this post by hasufell
On 10 August 2015 at 11:46, hasufell <[hidden email]> wrote:
> As I see it, a lot of people already stuff the bug number into the
> summary and I can't really say anything against that. It gives a nice
> overview when you look at it:
> https://gitweb.gentoo.org/repo/gentoo.git/log/
>
> Given that fact, I am not sure we can convince people to repeat the bug
> number in the description of the commit. However, the bug url definitely
> does not fit into the summary, but in the description. That would be an
> argument for the bug url thing (so we actually have both


Its also "nice" to see that in #gentoo-commits, becasue it triggers
wilkins to automatically fetch and display the summary of the
referenced bug, expanding the context.

That behaviour is not *always* nice ( ie: dozens of commits doing
keywording gets a bit spammy sometimes ), but used well it is nice.

Doing that with a Gentoo-Bug: <URL> or similar means we have to
enhance the commit reporting drone to give that context if that
behaviour is deemed desirable.

--
Kent

KENTNL - https://metacpan.org/author/KENTNL

Reply | Threaded
Open this post in threaded view
|

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

Alexandre Rostovtsev-2
In reply to this post by hasufell
On Sun, 2015-08-09 at 17:30 +0200, hasufell wrote:

> On 08/09/2015 05:19 PM, Tobias Klausmann wrote:
> > On Sun, 09 Aug 2015, Sven Vermeulen wrote:
> >
> > I'd just go with "Gentoo-Bug". The X- is pointless since it was
> > for eXtending Email-Headers. And what we do is only linked in
> > style.
> >
>
> I'd be fine with that and add a reference to the kernel guideline [0] to
> the wiki as well, so that it is clear that we also allow/use Acked-by,
> Reviewed-by, Suggested-by and whatnot.
>
> I'll wait for more ++ though.
>
>
> [0] https://www.kernel.org/doc/Documentation/SubmittingPatches
++ from me.

And a question: what about multiple bugs fixed by one commit? Is it

Gentoo-Bug: 1234567, 1234568
or

Gentoo-Bug: 1234567
Gentoo-Bug: 1234568

signature.asc (970 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Referencing bug reports in git

Ulrich Mueller-2
In reply to this post by Andrew Savchenko
>>>>> On Mon, 10 Aug 2015, Andrew Savchenko wrote:

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

+1

"Gentoo-Bug: 123456" or even "Bug: 123456" is enough to uniquely
identify a bug. Also it is easier to read (and to type) than its URL
equivalent.

Ulrich

attachment0 (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Referencing bug reports in git

hasufell
On 08/10/2015 02:51 AM, Ulrich Mueller wrote:

>>>>>> On Mon, 10 Aug 2015, Andrew Savchenko wrote:
>
>> 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.
>
> +1
>
> "Gentoo-Bug: 123456" or even "Bug: 123456" is enough to uniquely
> identify a bug. Also it is easier to read (and to type) than its URL
> equivalent.
>

So, would this replace the bug number reference in the summary? Should
we tell people to reference the bug only in the commit message description?

Or do we say:
* bug number in summary optional
* bug number in description mandatory via "Gentoo-Bug: 1234"

Reply | Threaded
Open this post in threaded view
|

Re: Referencing bug reports in git

Ryan Hill
On Mon, 10 Aug 2015 03:02:43 +0200
hasufell <[hidden email]> wrote:

> On 08/10/2015 02:51 AM, Ulrich Mueller wrote:
> >>>>>> On Mon, 10 Aug 2015, Andrew Savchenko wrote:
> >
> >> 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.
> >
> > +1
> >
> > "Gentoo-Bug: 123456" or even "Bug: 123456" is enough to uniquely
> > identify a bug. Also it is easier to read (and to type) than its URL
> > equivalent.
> >
>
> So, would this replace the bug number reference in the summary? Should
> we tell people to reference the bug only in the commit message description?
>
> Or do we say:
> * bug number in summary optional
> * bug number in description mandatory via "Gentoo-Bug: 1234"
The latter I hope.


--
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

attachment0 (486 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Andrew Savchenko
In reply to this post by Daniel Campbell (zlg)
On Sun, 9 Aug 2015 17:02:27 -0700 Daniel Campbell (zlg) wrote:
> I don't know about you guys, but I have a "smart bookmark" in Firefox
> where I type "bgo xxxxxx" and it'll take me to the relevant bug. It'd
> be trivial to set that up as a bash alias, too. There are tons of ways
> to get to a bug; the important part is the bug number. I think putting
> the URL in there adds extra work for us later down the road should we
> migrate away from Bugzilla.

Same here, but "gentoo $number" in the URL field.

Best regards,
Andrew Savchenko

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Referencing bug reports in git

Chí-Thanh Christopher Nguyễn
In reply to this post by Ulrich Mueller-2
Ulrich Mueller schrieb:
>> 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.
>
> +1
>
> "Gentoo-Bug: 123456" or even "Bug: 123456" is enough to uniquely
> identify a bug. Also it is easier to read (and to type) than its URL
> equivalent.

I'd like to make the case for a URL in commit messages, like for example
freedesktop.org does, and also the kernel for external reports.

This allows us to treat Gentoo Bugzilla and upstream/external bug trackers
the same.
Besides, extracting the bug number from the URL is typically trivial. Going
from bug number to URL is sometimes not.

Regarding the argument that bug URLs change more often than bug numbers, I
think the number of instances when URL changed but the bug numbering didn't
is very low. OpenOffice did this I think, but I can't think of any other
project right now.

Here are examples from freedesktop and kernel:
http://cgit.freedesktop.org/xorg/xserver/commit/?id=db5337afb248edf81087cf8d74006fc496d70589
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ac88cd738425e04dbed3706621cf613a00708834

I prefer the

Bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=333531

format even though not all bug trackers are running Bugzilla. "Bug: " works
fine with me too, and we could make
"https://bugs.gentoo.org/show_bug.cgi?id=" optional for Gentoo bugs, to
accommodate for those who insist on not typing so much.


Best regards,
Chí-Thanh Christopher Nguyễn



signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Referencing bug reports in git

Ulrich Mueller-2
>>>>> On Mon, 10 Aug 2015, Chí-Thanh Christopher Nguyễn wrote:

> I prefer the

> Bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=333531

> format even though not all bug trackers are running Bugzilla.
> "Bug: " works fine with me too,

There are bug trackers other than bugzilla, for example
debbugs.gnu.org. So I think using "Bugzilla:" wouldn't be such a good
idea.

> and we could make "https://bugs.gentoo.org/show_bug.cgi?id="
> optional for Gentoo bugs, to accommodate for those who insist on not
> typing so much.

Ulrich

attachment0 (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Referencing bug reports in git

Duncan-42
In reply to this post by hasufell
hasufell posted on Mon, 10 Aug 2015 03:02:43 +0200 as excerpted:

> On 08/10/2015 02:51 AM, Ulrich Mueller wrote:
>>>>>>> On Mon, 10 Aug 2015, Andrew Savchenko wrote:
>>
>>> 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.
>>
>> +1
>>
>> "Gentoo-Bug: 123456" or even "Bug: 123456" is enough to uniquely
>> identify a bug. Also it is easier to read (and to type) than its URL
>> equivalent.
>>
>>
> So, would this replace the bug number reference in the summary? Should
> we tell people to reference the bug only in the commit message
> description?
>
> Or do we say:
> * bug number in summary optional
> * bug number in description mandatory via "Gentoo-Bug: 1234"

What about:

* bug number in summary strongly recommended
** summary bug number standardized to GB#xxxxxx or #xxxxxx or similar,
short enough for summary, easily identified. GB# would be distinctly
gentoo and could be expanded to KDEB#, GNB# (gnome), FDOB#, etc, for
projects where users likely to want to see the bug likely know what it is.
** summary lists gentoo bug if any, upstream only if no gentoo bug.

* bug URL in description required.
** standardized to Gentoo-Bug: .......
** gives people wanting something to click a way to do so
** U in URL is universal, unambiguously identifies reference for those
unfamiliar with summary shorthand.
** Multiple allowed, for multiple gentoo bugs or to identify upstream
bugs (using FDO-Bug: or similar) as well.

That seems a reasonable compromise, given people pulling both ways
in-thread.

--
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


Reply | Threaded
Open this post in threaded view
|

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

Michał Górny-5
In reply to this post by Andrew Savchenko
Dnia 2015-08-10, o godz. 02:16:01
Andrew Savchenko <[hidden email]> napisał(a):

> On Mon, 10 Aug 2015 00:40:44 +0200 Michał Górny wrote:
> > > > Which is terribly redundant. Just put the whole bug URL. Advantages:
> > > >
> > > > - keeps the bug namespaced to bugs.gentoo.org,
> > > > - has the bug no inside,
> > > > - is convenient -- you can click it instead of copy-pasting the no.
> > >
> > > 1. URL may change in future, bug number — unlikely.
> >
> > If the URL changes, we need to provide backwards compatibility. Too
> > many resources already depend on that.
> >
> > > 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.

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

> > > 4. It is easier to copy a number, than selecting and copying whole
> > > string. Not all terminals support running browser on URL click.
> >
> > So we should optimize for a corner case?
>
> 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.

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

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

attachment0 (968 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Referencing bug reports in git

Michał Górny-5
In reply to this post by Chí-Thanh Christopher Nguyễn
Dnia 2015-08-10, o godz. 11:45:33
Chí-Thanh Christopher Nguyễn <[hidden email]> napisał(a):

> Ulrich Mueller schrieb:
> >> 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.
> >
> > +1
> >
> > "Gentoo-Bug: 123456" or even "Bug: 123456" is enough to uniquely
> > identify a bug. Also it is easier to read (and to type) than its URL
> > equivalent.
>
> I'd like to make the case for a URL in commit messages, like for example
> freedesktop.org does, and also the kernel for external reports.
>
> This allows us to treat Gentoo Bugzilla and upstream/external bug trackers
> the same.
> Besides, extracting the bug number from the URL is typically trivial. Going
> from bug number to URL is sometimes not.
>
> Regarding the argument that bug URLs change more often than bug numbers, I
> think the number of instances when URL changed but the bug numbering didn't
> is very low. OpenOffice did this I think, but I can't think of any other
> project right now.
>
> Here are examples from freedesktop and kernel:
> http://cgit.freedesktop.org/xorg/xserver/commit/?id=db5337afb248edf81087cf8d74006fc496d70589
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ac88cd738425e04dbed3706621cf613a00708834
>
> I prefer the
>
> Bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=333531
>
> format even though not all bug trackers are running Bugzilla. "Bug: " works
> fine with me too, and we could make
> "https://bugs.gentoo.org/show_bug.cgi?id=" optional for Gentoo bugs, to
> accommodate for those who insist on not typing so much.
Thanks, this is exactly what I wanted.

"Fixes", "References", "Bug" are all good. "Bugzilla" goes against your
proposal diverging keyword depending on bug tracker software.

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

attachment0 (968 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Referencing bug reports in git

hasufell
On 08/10/2015 03:19 PM, Michał Górny wrote:
>
> Thanks, this is exactly what I wanted.
>
> "Fixes", "References", "Bug" are all good. "Bugzilla" goes against your
> proposal diverging keyword depending on bug tracker software.
>

Afaik "Fixes: " is for referencing commits, not bug reports.

And now I am completely lost, because there are too many different
opinions on this trivial matter. I guess that means people will just use
whatever they currently like.

Reply | Threaded
Open this post in threaded view
|

Re: Referencing bug reports in git

Chí-Thanh Christopher Nguyễn
In reply to this post by Michał Górny-5
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michał Górny schrieb:

>> I prefer the
>>
>> Bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=333531
>>
>> format even though not all bug trackers are running Bugzilla. "Bug: "
>> works fine with me too, and we could make
>> "https://bugs.gentoo.org/show_bug.cgi?id=" optional for Gentoo bugs,
>> to accommodate for those who insist on not typing so much.
>
> Thanks, this is exactly what I wanted.
>
> "Fixes", "References", "Bug" are all good. "Bugzilla" goes against your
> proposal diverging keyword depending on bug tracker software.
>

I'd use "Bugzilla" somewhat inaccurately even for non-Bugzilla bugtrackers.
But of course that is just a minor detail, "Bug" is fine too. "Fixes" is
maybe misleading in certain cases (e.g. a partial fix or revert).


Best regards,
Chí-Thanh Christopher Nguyễn


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlXI8QsACgkQ+gvH2voEPRCtoACfeEsi/dn7bpCvaaqzYEMozCX0
4tsAn2BIsNAK1R9ZBrQfLvEPqi9161QS
=09+F
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

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

Andrew Savchenko
In reply to this post by Michał Górny-5
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

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Michał Górny-5
Dnia 2015-08-10, o godz. 23:43:29
Andrew Savchenko <[hidden email]> 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/>

attachment0 (968 bytes) Download Attachment
12345