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

hasufell
So, I've just tried to count the ++ for different ideas and even if I
missed one or two or misread someone's opinion, I think the result is
pretty clear:

reference the bug only in the summary: 1
don't make any of this mandatory: 1
"Gentoo-Bug: 123" or similar short form: 9
"Gentoo-Bug: <url>" or similar long form: 2-3

Reply | Threaded
Open this post in threaded view
|

Re: Referencing bug reports in git

Chí-Thanh Christopher Nguyễn
hasufell schrieb:
> So, I've just tried to count the ++ for different ideas and even if I
> missed one or two or misread someone's opinion, I think the result is
> pretty clear:
>
> reference the bug only in the summary: 1
> don't make any of this mandatory: 1
> "Gentoo-Bug: 123" or similar short form: 9
> "Gentoo-Bug: <url>" or similar long form: 2-3
>

As there was no formal call for a vote, I don't think you can take the
number of voiced opinions as an indicator for the support of an option.
After all, if someone's opinion is already sufficiently represented by
an existing post, that person would not have reason to write to -dev and
further clutter the discussion.

The only thing you can derive from this counting is that consensus has
not been reached.

Bug: https://bugs.gentoo.org/show_bug.cgi?id=333531 format, with the
"https://bugs.gentoo.org/show_bug.cgi?id=" optional for Gentoo Bugzilla,
would be a compromise I can accept.

I would not like having to redundantly give the bug number when I
already gave the URL.


Best regards,
Chí-Thanh Christopher Nguyễn


Reply | Threaded
Open this post in threaded view
|

Re: Referencing bug reports in git

Michał Górny-5
Dnia 2015-08-12, o godz. 17:59:03
Chí-Thanh Christopher Nguyễn <[hidden email]> napisał(a):

> hasufell schrieb:
> > So, I've just tried to count the ++ for different ideas and even if I
> > missed one or two or misread someone's opinion, I think the result is
> > pretty clear:
> >
> > reference the bug only in the summary: 1
> > don't make any of this mandatory: 1
> > "Gentoo-Bug: 123" or similar short form: 9
> > "Gentoo-Bug: <url>" or similar long form: 2-3
> >
>
> As there was no formal call for a vote, I don't think you can take the
> number of voiced opinions as an indicator for the support of an option.
> After all, if someone's opinion is already sufficiently represented by
> an existing post, that person would not have reason to write to -dev and
> further clutter the discussion.
>
> The only thing you can derive from this counting is that consensus has
> not been reached.
>
> Bug: https://bugs.gentoo.org/show_bug.cgi?id=333531 format, with the
> "https://bugs.gentoo.org/show_bug.cgi?id=" optional for Gentoo Bugzilla,
> would be a compromise I can accept.
>
> I would not like having to redundantly give the bug number when I
> already gave the URL.
Can we make it clear whether we are allowed/supposed to use the short
form:

  https://bugs.gentoo.org/333531

?

--
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
In reply to this post by Chí-Thanh Christopher Nguyễn
On 08/12/2015 05:59 PM, Chí-Thanh Christopher Nguyễn wrote:

> hasufell schrieb:
>> So, I've just tried to count the ++ for different ideas and even if I
>> missed one or two or misread someone's opinion, I think the result is
>> pretty clear:
>>
>> reference the bug only in the summary: 1
>> don't make any of this mandatory: 1
>> "Gentoo-Bug: 123" or similar short form: 9
>> "Gentoo-Bug: <url>" or similar long form: 2-3
>>
>
> As there was no formal call for a vote, I don't think you can take the
> number of voiced opinions as an indicator for the support of an option.

Uhm, why not? When I ask for "++", then that is a rough call for
opinions. If someone doesn't voice his opinion, then it doesn't count,
just like in a formal vote.

The only argument you can make is that you want a formal vote, because
the amount of consensus is not high enough (is it not?). I guess you
will have the same people participating who have already voiced their
opinion here.

As a compromise, I guess we could say that people are allowed to do both
(but must do one of them). The additional code that this would impose on
parsing tools is minor.

So, either:
=====
app-misc/foo: stabilize and stuff

Gentoo-Bug: 333531, 502062, 562062, 502772, 502077
Gentoo-Bug: 502362, 512062
=====

Or
=====
app-misc/foo: stabilize and stuff

Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=333531
Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=502062
...
=====

If people don't want this either, then I'm done with this topic and will
do whatever I like, until someone wants to take this the "formal" route.
I'm not interested to go there for such a trivial thing.

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
Michał Górny schrieb:

>> Bug: https://bugs.gentoo.org/show_bug.cgi?id=333531 format, with the
>> "https://bugs.gentoo.org/show_bug.cgi?id=" optional for Gentoo
>> Bugzilla, would be a compromise I can accept. I would not like having
>> to redundantly give the bug number when I already gave the URL.
> Can we make it clear whether we are allowed/supposed to use the short
> form:
>
>    https://bugs.gentoo.org/333531
>
> ?
>

As that redirects to the longer form I don't see a problem with allowing
that.

Note that the short form does not allow for referencing individual
comments, because
https://bugs.gentoo.org/333531#c4
redirects to
https://bugs.gentoo.org/show_bug.cgi?id=333531
and not
https://bugs.gentoo.org/show_bug.cgi?id=333531#c4


Best regards,
Chí-Thanh Christopher Nguyễn

Reply | Threaded
Open this post in threaded view
|

Re: Referencing bug reports in git

Michał Górny-5
Dnia 2015-08-12, o godz. 18:25:07
Chí-Thanh Christopher Nguyễn <[hidden email]> napisał(a):

> Michał Górny schrieb:
> >> Bug: https://bugs.gentoo.org/show_bug.cgi?id=333531 format, with the
> >> "https://bugs.gentoo.org/show_bug.cgi?id=" optional for Gentoo
> >> Bugzilla, would be a compromise I can accept. I would not like having
> >> to redundantly give the bug number when I already gave the URL.
> > Can we make it clear whether we are allowed/supposed to use the short
> > form:
> >
> >    https://bugs.gentoo.org/333531
> >
> > ?
> >
>
> As that redirects to the longer form I don't see a problem with allowing
> that.
>
> Note that the short form does not allow for referencing individual
> comments, because
> https://bugs.gentoo.org/333531#c4
> redirects to
> https://bugs.gentoo.org/show_bug.cgi?id=333531
> and not
> https://bugs.gentoo.org/show_bug.cgi?id=333531#c4
Well, to be clear it doesn't actually redirect. If you didn't use one
of those fancy new-age web browsers, you'd notice #c4 works as
expected. I suspect it does some fancy JavaScript addressbar update
though. Anyway, breaking '#c4' should be definitely treated as a bug,
not expected limitation.

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

Ian Stakenvicius-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 12/08/15 12:34 PM, Michał Górny wrote:

> Dnia 2015-08-12, o godz. 18:25:07 Chí-Thanh Christopher Nguyễn
> <[hidden email]> napisał(a):
>
>> Michał Górny schrieb:
>>>> Bug: https://bugs.gentoo.org/show_bug.cgi?id=333531 format,
>>>> with the "https://bugs.gentoo.org/show_bug.cgi?id="
>>>> optional for Gentoo Bugzilla, would be a compromise I can
>>>> accept. I would not like having to redundantly give the bug
>>>> number when I already gave the URL.
>>> Can we make it clear whether we are allowed/supposed to use
>>> the short form:
>>>
>>> https://bugs.gentoo.org/333531
>>>
>>> ?
>>>
>>
>> As that redirects to the longer form I don't see a problem with
>> allowing that.
>>
>> Note that the short form does not allow for referencing
>> individual comments, because https://bugs.gentoo.org/333531#c4 
>> redirects to https://bugs.gentoo.org/show_bug.cgi?id=333531 and
>> not https://bugs.gentoo.org/show_bug.cgi?id=333531#c4
>
> Well, to be clear it doesn't actually redirect. If you didn't use
> one of those fancy new-age web browsers, you'd notice #c4 works
> as expected. I suspect it does some fancy JavaScript addressbar
> update though. Anyway, breaking '#c4' should be definitely
> treated as a bug, not expected limitation.
>


Can we assume if a URL is to be the format, that any URL which
resolves to whatever it is you're trying to link to is permitted
(within reason, ideally we don't want ones with 128-character-long
session-id hashes in them of course)..?


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

iF4EAREIAAYFAlXLdtQACgkQAJxUfCtlWe06rQEAiTu9MxA6AeEnGXahOtd7c74U
c0rLqHJcXmgRPrdj/qwA/2i7CtmCU2uNoaq0tlcaqIky6cgtxY7pQ9bNDTRM0ujH
=1f2m
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: Referencing bug reports in git

Matt Turner-5
In reply to this post by hasufell
On Wed, Aug 12, 2015 at 3:40 AM, hasufell <[hidden email]> wrote:
> So, I've just tried to count the ++ for different ideas and even if I
> missed one or two or misread someone's opinion, I think the result is
> pretty clear:
>
> reference the bug only in the summary: 1
> don't make any of this mandatory: 1
> "Gentoo-Bug: 123" or similar short form: 9
> "Gentoo-Bug: <url>" or similar long form: 2-3

I'm in favor of Gentoo-Bug: <url> in case we're voting. I don't see
much use in the "Gentoo-" prefix if it's a URL though. In that case,
just Bug: <url> seems better.

Reply | Threaded
Open this post in threaded view
|

Re: Referencing bug reports in git

Dmitry Yu Okunev


On 08/12/2015 08:38 PM, Matt Turner wrote:

> On Wed, Aug 12, 2015 at 3:40 AM, hasufell <[hidden email]> wrote:
>> So, I've just tried to count the ++ for different ideas and even if I
>> missed one or two or misread someone's opinion, I think the result is
>> pretty clear:
>>
>> reference the bug only in the summary: 1
>> don't make any of this mandatory: 1
>> "Gentoo-Bug: 123" or similar short form: 9
>> "Gentoo-Bug: <url>" or similar long form: 2-3
>
> I'm in favor of Gentoo-Bug: <url> in case we're voting.
May be "Bug-Gentoo" should be used instead. It's to use the same header
name format as Debian in their patches ("Bug-Debian").

--
Best regards, Dmitry


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

Re: Referencing bug reports in git

hasufell
On 08/12/2015 07:48 PM, Dmitry Yu Okunev wrote:

>
>
> On 08/12/2015 08:38 PM, Matt Turner wrote:
>> On Wed, Aug 12, 2015 at 3:40 AM, hasufell <[hidden email]> wrote:
>>> So, I've just tried to count the ++ for different ideas and even if I
>>> missed one or two or misread someone's opinion, I think the result is
>>> pretty clear:
>>>
>>> reference the bug only in the summary: 1
>>> don't make any of this mandatory: 1
>>> "Gentoo-Bug: 123" or similar short form: 9
>>> "Gentoo-Bug: <url>" or similar long form: 2-3
>>
>> I'm in favor of Gentoo-Bug: <url> in case we're voting.
>
> May be "Bug-Gentoo" should be used instead. It's to use the same header
> name format as Debian in their patches ("Bug-Debian").
>

I'm out of the discussion. Do whatever you want with bug references. We
clearly need more different opinions.

Someone end the bikeshed train please.

Reply | Threaded
Open this post in threaded view
|

Re: Referencing bug reports in git

Steev Klimaszewski-2

Someone end the bikeshed train please.

Seconded.
Reply | Threaded
Open this post in threaded view
|

Re: Referencing bug reports in git

Ryan Hill
In reply to this post by Michał Górny-5
On Wed, 12 Aug 2015 18:03:52 +0200
Michał Górny <[hidden email]> wrote:


> Can we make it clear whether we are allowed/supposed to use the short
> form:
>
>   https://bugs.gentoo.org/333531
>
> ?

I'd like this to be the preferred form.  It's cleaner, the show_bug.cgi=id? is
just noise.

If we do go with a URI is it possible to do some kind of magic behind the scenes
to canonicalize it?  By that I mean is that any of these:

Gentoo-Bug: https://bugs.gentoo.org/333531
Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=333531
Gentoo-Bug: 333531

would automatically be converted to https://bugs.gentoo.org/333531 (or whatever
is decided on).  That way everyone can use whatever they like best and it'll
all come out consistent.


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

Ben de Groot-2
I vote for a simple

Bug: 333531

If it is going to be any longer than that, then you need to make sure
it is part of the commit message template magic. Because I'm surely
not the only one who is lazy and thus averse to typing anything longer
for the most common use case: Gentoo bugs.

--
Cheers,

Ben | yngwin
Gentoo developer

Reply | Threaded
Open this post in threaded view
|

Re: Referencing bug reports in git

Rich Freeman
On Thu, Aug 13, 2015 at 7:19 AM, Ben de Groot <[hidden email]> wrote:
> I vote for a simple
>
> Bug: 333531
>
> If it is going to be any longer than that, then you need to make sure
> it is part of the commit message template magic. Because I'm surely
> not the only one who is lazy and thus averse to typing anything longer
> for the most common use case: Gentoo bugs.
>

++ laziness

I don't mind it being a URL, but stick the header in the template (way
easier to delete it than to type it),

If it is a URL, please make it whatever is already in my browser
address bar.  A nice shorthand URL looks pretty but it isn't so pretty
if I have to edit it instead of just hitting copy/paste.  When I'm
fixing bugs I have the bug open in a browser already, since the next
step after committing the fix is going to be closing the bug.

Otherwise, I really don't care.  "Bug" gets the job done.  I haven't
seen any recent proposals that include the "X-" but that is one thing
I'd definitely avoid per the RFC.

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: Referencing bug reports in git

Aaron W. Swenson-2
On 2015-08-13 08:13, Rich Freeman wrote:

> On Thu, Aug 13, 2015 at 7:19 AM, Ben de Groot <[hidden email]> wrote:
> > I vote for a simple
> >
> > Bug: 333531
> >
> > If it is going to be any longer than that, then you need to make sure
> > it is part of the commit message template magic. Because I'm surely
> > not the only one who is lazy and thus averse to typing anything longer
> > for the most common use case: Gentoo bugs.
> >
>
> ++ laziness
>
> I don't mind it being a URL, but stick the header in the template (way
> easier to delete it than to type it),
>
> If it is a URL, please make it whatever is already in my browser
> address bar.  A nice shorthand URL looks pretty but it isn't so pretty
> if I have to edit it instead of just hitting copy/paste.  When I'm
> fixing bugs I have the bug open in a browser already, since the next
> step after committing the fix is going to be closing the bug.
>
> Otherwise, I really don't care.  "Bug" gets the job done.  I haven't
> seen any recent proposals that include the "X-" but that is one thing
> I'd definitely avoid per the RFC.
>
> --
> Rich
>
I'm for just a simple "Bug:" line with b.g.o URL being optional.

 - Implies b.g.o
     Bug: 123456
 - Equivalent to multiple lines for implied b.g.o
     Bug: 123456,654321
 - explicit b.g.o
     Bug: https://bugs.gentoo.org/123456
     Bug: https://bugs.gentoo.org/show_bug.cgi?id=123456
 - external bug reference
     Bug: https://bugs.debian.org/123456

There'd be no option to concatenate multiple external bug references on the
same line.

Really there's no difference between an explicit b.g.o bug reference and
an external bug reference.

Tools can easily parse the 3 different forms. If the string after "Bug:
" starts with http:// or https://, it's a URL, else it's a list of
Gentoo bug numbers separated by commas.

    if ($line =~ m|^Bug: (https?://.+)|i) {
        fetch $1
    } elsif ($line =~ m|^Bug:|i) {
        $line =~ s/^Bug: //i;
        $line =~ s/\s+//g;
        my @nums = split /,/, $line;
        fetch_from_bgo $_ for @nums;
    }

Yes, URLs may change, but what really matters is that the reference is
valid when it's made. There are projects who have not only changed URLs,
but bug tracking systems, and have just decided to restart on the bug
count because they weren't able to or couldn't be bothered to make a
proper transfer. In short: Bug numbers are as immutable as
URLs. Fortunately, it's a rare occurrence that we shouldn't worry about.

- Aaron

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

Re: Referencing bug reports in git

Andrew Savchenko
In reply to this post by Ben de Groot-2
On Thu, 13 Aug 2015 19:19:10 +0800 Ben de Groot wrote:
> I vote for a simple
>
> Bug: 333531

+1

Of course, for external bugs (e.g. in other projects) full URI
should be used.


Best regards,
Andrew Savchenko

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

Re: Referencing bug reports in git

Matthias Maier-3

On Fri, Aug 14, 2015, at 15:04 CDT, Andrew Savchenko <[hidden email]> wrote:

> On Thu, 13 Aug 2015 19:19:10 +0800 Ben de Groot wrote:
>> I vote for a simple
>>
>> Bug: 333531
>
> +1
>
> Of course, for external bugs (e.g. in other projects) full URI
> should be used.

+1

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

Re: Referencing bug reports in git

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

On 08/14/2015 01:04 PM, Andrew Savchenko wrote:

> On Thu, 13 Aug 2015 19:19:10 +0800 Ben de Groot wrote:
>> I vote for a simple
>>
>> Bug: 333531
>
> +1
>
> Of course, for external bugs (e.g. in other projects) full URI
> should be used.
>
>
> Best regards, Andrew Savchenko
>
++

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

iQIcBAEBCAAGBQJVzuebAAoJEAEkDpRQOeFw+lEP/jzDH6e7fOGdKuLGafvM1n5j
tg4otbjmK6p/IL5i3RoOP0e9dRejKjIjkiWEi5gdDhG82ZXfuK2F9ym9Z3OMsNI5
x/4uRk/0rU9Fa9Aaoo9Xwh7LUvL3DyB5qspLf45FZNTNX5qizHL+kmWv2Jl3ei9P
rmS/dfVMZbAPguiaatiutTHPQ/MWRlv2NhNu7r9I1supI5cGs59O8nAp2Gc2IApI
cGYozTWs5C73cPeEnzKnWNRsvvjyxE2tCTk84OGRAgCw9QcC7FJMOI32hcX6fUvY
cckVBu19HRN+PJAGqF6ONjJm9KJ1iFKc77v2fg5hzrwAGyDf6VLeFVBUL9BZFAqI
vPTfGV/TIu+ro6xLJFoTPcaKl9EQHbIXHZDbQyx7QpazPaALdunj7qAChFyVVPVU
hA9kadV5sMO0mUqvue2vOw2bpqZnZMn3kO14trlsu7BrwPHPJ/8LQJCBAXXQOR1d
9vVZ5h0wl2XhQ3qBwlji+2y+zinCNJJ8FIFYyQdnjN1v53y1MKLssKM+OguiET4v
ytfcxmI+PtbaL3Lx9zKeoEd37hxeGIa5HdEYEo6LRjFltKTTX0gwWAQHact/hHtD
QaIVFHuIYfg2walhSJYj9n3gJpb8mx9vDT0eInhoFUumZyjfx1GXz9Az71pjliaP
HnlMBdyUGldz4uq8ahnC
=gih6
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: Referencing bug reports in git

Ryan Hill
In reply to this post by Rich Freeman
On Thu, 13 Aug 2015 08:13:59 -0400
Rich Freeman <[hidden email]> wrote:

> If it is a URL, please make it whatever is already in my browser
> address bar.  A nice shorthand URL looks pretty but it isn't so pretty
> if I have to edit it instead of just hitting copy/paste.  When I'm
> fixing bugs I have the bug open in a browser already, since the next
> step after committing the fix is going to be closing the bug.

Same here, which is why I suggested the canonicalization.  I want to be able to
paste in whatever is handy and have it come out looking nice.

> Otherwise, I really don't care.  "Bug" gets the job done.

I don't care that much either.  We never had URLs in the changelogs before so
it's not like we're losing anything.


--
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: Summary line (was: Re: Referencing bug reports in git)

Alec Warner-2
In reply to this post by Kent Fredric


On Tue, Aug 11, 2015 at 7:35 AM, Kent Fredric <[hidden email]> wrote:
On 12 August 2015 at 02:28, Ian Stakenvicius <[hidden email]> wrote:
> Stuff like 'cat/pn: version bumps', 'cat/pn: new features', 'cat/pn:
> adjusted dependencies' are generic (and short) enough yet descriptive
> enough to see what went on while scanning the log.

I personally find those summaries a bit too terse.

Summaries are supposed to be terse, they are summaries ;)
 

Mostly, because when I see "A version is bumped" I immediately expect
to know which version the bump is to, but have to dig out the diff to
find out.


So I thought we used to have scripts that would dig out this information and populate them in headers?

-A
 
I would also prefer, where possible, to replace "adjusted
dependencies" to be more concise, like "include dev-perl/Foo in
dependencies", ( though of course, apply some taste, listing more than
3 distinct new dependencies in the summary is execessive, treat them
like hashtags on twitter, 1 is good, 2 is OK, 3 and you're starting to
get crazy )

> Multi-package commits are going to be more of an issue of course..  I
> did one last night, fortunately I think I can get away with using
> "mozilla packages" in place of cat/pn since it is a very specific set
> of packages.  Perhaps for sweeping changes like that we can use the
> herdname or projectname or the category name (if its a particular
> category only)?

Agreed. If you need multi-package changes and you can't think of a
good category prefix to use, the commit message should visibly
acknowledge that its a multi-package commit of some kind, and the
*kind* of change should be very clear.

Just keep in mind really the recommendations for prefix naming are
descriptive, not prescriptive, and interpretation and good taste need
to be applied everywhere.



--
Kent

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


12345