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

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

[hasufell]

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

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

[Ian Whyman]

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

On 9 August 2015 at 15:09, hasufell <hasufell@gentoo.org> wrote:

> 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
> =====
>
>
Having the URL and number seems like a duplication of effort,
but X-Gentoo-Bug works for me.

-- 
Ian Whyman
www.gentoo.org

[-- Attachment #2: Type: text/html, Size: 2010 bytes --]

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

[Dirkjan Ochtman]

On Sun, Aug 9, 2015 at 4:09 PM, hasufell <hasufell@gentoo.org> wrote:
> 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
> =====

I don't really see why it has to be so verbose. Can we just make it
"bug 557022", or even #557022? That would also make it fit better if
you have a single-line commit message only.

Cheers,

Dirkjan

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

[hasufell]

On 08/09/2015 04:26 PM, Dirkjan Ochtman wrote:
> On Sun, Aug 9, 2015 at 4:09 PM, hasufell <hasufell@gentoo.org> wrote:
>> 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
>> =====
> 
> I don't really see why it has to be so verbose. Can we just make it
> "bug 557022", or even #557022? That would also make it fit better if
> you have a single-line commit message only.
> 

I think "X-Gentoo-Bug: 557022" also makes the job easier for tools that
parse commit messages.

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

[Dirkjan Ochtman]

On Sun, Aug 9, 2015 at 4:38 PM, hasufell <hasufell@gentoo.org> wrote:
>> I don't really see why it has to be so verbose. Can we just make it
>> "bug 557022", or even #557022? That would also make it fit better if
>> you have a single-line commit message only.
>
> 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.

Also, https://tools.ietf.org/html/rfc6648.

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

[hasufell]

On 08/09/2015 04:43 PM, Dirkjan Ochtman wrote:
> On Sun, Aug 9, 2015 at 4:38 PM, hasufell <hasufell@gentoo.org> wrote:
>>> I don't really see why it has to be so verbose. Can we just make it
>>> "bug 557022", or even #557022? That would also make it fit better if
>>> you have a single-line commit message only.
>>
>> 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.
> 
> Also, https://tools.ietf.org/html/rfc6648.
> 

That can be ambiguous, because it isn't clear whether you are
referencing a gentoo bug. You can reference bugs from other bugtrackers
as well.

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

[Michael Orlitzky]

On 08/09/2015 10:43 AM, Dirkjan Ochtman wrote:
> On Sun, Aug 9, 2015 at 4:38 PM, hasufell <hasufell@gentoo.org> wrote:
>>> I don't really see why it has to be so verbose. Can we just make it
>>> "bug 557022", or even #557022? That would also make it fit better if
>>> you have a single-line commit message only.
>>
>> 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.
> 
> Also, https://tools.ietf.org/html/rfc6648.
> 

There's a "standard" set of patch tags all in the style of RFC822
headers -- Signed-off-by, Acked-by, Suggested-by, etc. are all common:

  https://www.kernel.org/doc/Documentation/SubmittingPatches

X-Gentoo-Bug is just following that example for metadata.

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

[Sven Vermeulen]

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

Wkr,
	Sven Vermeulen

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

[hasufell]

On 08/09/2015 05:03 PM, 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).
> 

At the time we decide to depend on it, it will already be useless for
the complete past history, because some people did it... and others not.

Deciding on such things early on is a good idea, especially for a
project as big as gentoo. That is... if we want our history to be useful.

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

[Tobias Klausmann]

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.

Regards,
Tobias

-- 
Sent from aboard the Culture ship
	(ex) General Transport Craft (Interstellar-class) Now We Try It My Way

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

[hasufell]

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.


[0] https://www.kernel.org/doc/Documentation/SubmittingPatches

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

[Mike Gilbert]

On Sun, Aug 9, 2015 at 11:30 AM, hasufell <hasufell@gentoo.org> 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-.

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

[Davide Pesavento]

On Sun, Aug 9, 2015 at 8:43 AM, Mike Gilbert <floppym@gentoo.org> wrote:
> On Sun, Aug 9, 2015 at 11:30 AM, hasufell <hasufell@gentoo.org> 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)

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

[Michał Górny]

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

Dnia 2015-08-09, o godz. 16:09:29
hasufell <hasufell@gentoo.org> 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.

Also there are some standard keywords that are sometimes used to
reference bugs, like 'Fixes:' used by x.org.

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

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

[hasufell]

On 08/09/2015 09:56 PM, Michał Górny wrote:
> Dnia 2015-08-09, o godz. 16:09:29
> hasufell <hasufell@gentoo.org> 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.
> 
> 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.

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

[Michał Górny]

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

Dnia 2015-08-09, o godz. 23:01:32
hasufell <hasufell@gentoo.org> napisał(a):

> On 08/09/2015 09:56 PM, Michał Górny wrote:
> > Dnia 2015-08-09, o godz. 16:09:29
> > hasufell <hasufell@gentoo.org> 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.
> > 
> > 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.

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

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

[Rich Freeman]

On Sun, Aug 9, 2015 at 5:11 PM, Michał Górny <mgorny@gentoo.org> wrote:
> X-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=557022

How about just:
Bug-URL: xxx
or Bug: xxx

X- is not recommended as a prefix for the various reasons already
well-stated by the IETF in the previously-linked RFC.

-- 
Rich

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

[Andrew Savchenko]

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

On Sun, 9 Aug 2015 21:56:05 +0200 Michał Górny wrote:
> Dnia 2015-08-09, o godz. 16:09:29
> hasufell <hasufell@gentoo.org> 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

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

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

[Michał Górny]

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

Dnia 2015-08-10, o godz. 00:44:09
Andrew Savchenko <bircoph@gentoo.org> napisał(a):

> On Sun, 9 Aug 2015 21:56:05 +0200 Michał Górny wrote:
> > Dnia 2015-08-09, o godz. 16:09:29
> > hasufell <hasufell@gentoo.org> 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.

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

> 3. Too many text, hard to read. Some bugs may refer to a dozen of
> URLs.

And how is a dozen numbers better?

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

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

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

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

[Andrew Savchenko]

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

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

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

Best regards,
Andrew Savchenko

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

Re: [gentoo-dev] 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: ...".

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

[Daniel Campbell (zlg)]

-----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 <floppym@gentoo.org>
> wrote:
>> On Sun, Aug 9, 2015 at 11:30 AM, hasufell <hasufell@gentoo.org>
>> 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-----

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

[Daniel Campbell (zlg)]

-----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 <hasufell@gentoo.org>
> napisał(a):
> 
>> On 08/09/2015 09:56 PM, Michał Górny wrote:
>>> Dnia 2015-08-09, o godz. 16:09:29 hasufell
>>> <hasufell@gentoo.org> 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-----

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

[Daniel Campbell (zlg)]

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

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

[Ryan Hill]

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

On Mon, 10 Aug 2015 00:44:09 +0300
Andrew Savchenko <bircoph@gentoo.org> wrote:

> On Sun, 9 Aug 2015 21:56:05 +0200 Michał Górny wrote:
> > Dnia 2015-08-09, o godz. 16:09:29
> > hasufell <hasufell@gentoo.org> 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 475 bytes --]

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

[Kent Fredric]

On 10 August 2015 at 11:46, hasufell <hasufell@gentoo.org> 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

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

[Alexandre Rostovtsev]

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

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-dev] Referencing bug reports in git

[Ulrich Mueller]

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

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

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

Re: [gentoo-dev] 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"

[gentoo-dev] Re: Referencing bug reports in git

[Ryan Hill]

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

On Mon, 10 Aug 2015 03:02:43 +0200
hasufell <hasufell@gentoo.org> 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 475 bytes --]

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

[Andrew Savchenko]

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

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

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

Re: [gentoo-dev] Referencing bug reports in git

[Chí-Thanh Christopher Nguyễn]

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

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] Referencing bug reports in git

[Ulrich Mueller]

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

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

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

[gentoo-dev] Re: Referencing bug reports in git

[Duncan]

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

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

[Michał Górny]

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

Dnia 2015-08-10, o godz. 02:16:01
Andrew Savchenko <bircoph@gentoo.org> 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/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] Referencing bug reports in git

[Michał Górny]

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

Dnia 2015-08-10, o godz. 11:45:33
Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> 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/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] 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.

Re: [gentoo-dev] Referencing bug reports in git

[Chí-Thanh Christopher Nguyễn]

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

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

[Andrew Savchenko]

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

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

[Michał Górny]

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

Dnia 2015-08-10, o godz. 23:43:29
Andrew Savchenko <bircoph@gentoo.org> 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/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] Re: Referencing bug reports in git

[Gordon Pettey]

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

On Mon, Aug 10, 2015 at 7:25 AM, Duncan <1i5t5.duncan@cox.net> wrote:

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

If you're going to prepend the project, just spell it out. Don't invent new
acronyms and abbreviations. Don't add a B suffix to everything. If it's the
same everywhere, then it is meaningless, and just confuses things. I know
what KDE is, but I'd have to go Google for what KDEB is (Is that KDE B? K
Debian?), and hope Google indexed the above email from gmane or something.

Don't prefix bugs with #. 1. It doesn't apply to every system: Random
Project using Jira is going to have bugs like RP-123. You'd have to insert
it in the middle of the identifier like RP-#123. 2. It is a relatively
useless prefix at best: In the bug tracker UI, you search for 123, not
#123. At worst, it makes the identifier invalid (as in the Jira example).

[-- Attachment #2: Type: text/html, Size: 1426 bytes --]

[gentoo-dev] Re: Referencing bug reports in git

[Ryan Hill]

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

On Mon, 10 Aug 2015 12:25:58 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:
> 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.

Making the bug number in the summary manditory or strongly encouraged leads to
wonderful commit messages like:

---
cat-pkg: Fix bug #504321.

Gentoo-Bug: 504321
---

I would like to see this be more common:

---
cat-pkg: Make the thingy work again.

Gentoo-Bug: https://bugs.gentoo.org/504321 or 504321 Idon'tcarewhich
----

If we're limiting the summary to 1 line, 70-75 chars, manditory cat/package
and bug number there's not a lot of room to summarize in.


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

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 475 bytes --]

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

[Ryan Hill]

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

On Mon, 10 Aug 2015 23:43:29 +0300
Andrew Savchenko <bircoph@gentoo.org> wrote:

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

It isn't.  There's a reason why lists of things are generally written top to
bottom.  I found the second form to be much more readable.  In fact I was
generally against the URIs until I saw this.

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

Maybe if you were reading the whole line, but you're not.  You have built-in
pattern recognition.  Try it out.

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

Arg, that is so irritating how I have easily-clickable machine-parsable links in
my git log. Look at all the space we could have saved!  How much time have I
wasted reading every character?!  Sorry kids, can't play, daddy's busy reading
commit logs.

No matter what we decide three months from now we won't remember arguing about
it.  So let's save some time an irritability now and pick something.



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

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 475 bytes --]

[gentoo-dev] Re: Referencing bug reports in git

[Duncan]

Gordon Pettey posted on Mon, 10 Aug 2015 17:57:56 -0500 as excerpted:

> On Mon, Aug 10, 2015 at 7:25 AM, Duncan <1i5t5.duncan@cox.net> wrote:
> 
>> ** 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
>>
>>
> If you're going to prepend the project, just spell it out.

My thought is that this is the one-line summary, generally limited to 75 
chars, including category/package.  Spelling it out thus takes precious 
character-space that can better be used to describe the problem in words.

> Don't add a B suffix to everything. If it's the same everywhere, then
> it is meaningless, and just confuses things.

Very good point, particularly in light of the above -- that's another 
character-slot from 75 that can't be used for other things.

> Don't prefix bugs with #. 1. It doesn't apply to every system: Random
> Project using Jira is going to have bugs like RP-123. You'd have to
> insert it in the middle of the identifier like RP-#123. 2. It is a
> relatively useless prefix at best: In the bug tracker UI, you search for
> 123, not #123. At worst, it makes the identifier invalid (as in the Jira
> example).

Once again, very good point.  Thanks. =:^)

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

[gentoo-dev] Re: Referencing bug reports in git

[Duncan]

Ryan Hill posted on Mon, 10 Aug 2015 18:17:30 -0600 as excerpted:

> On Mon, 10 Aug 2015 12:25:58 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
>> What about:
>> 
>> * bug number in summary strongly recommended
> 
> Making the bug number in the summary manditory or strongly encouraged
> leads to wonderful commit messages like:
> 
> ---
> cat-pkg: Fix bug #504321.

Ideally, it'd be something a bit more informative (here taking Gordon's 
points about the previously suggested B#):

cat-egory/semi-long-package-name: fix amd64-fbsd build error G-504321

> I would like to see this be more common:
> 
> ---
> cat-pkg: Make the thingy work again
> 
> Gentoo-Bug: https://bugs.gentoo.org/504321 *(or 504321 Idon'tcarewhich)
> ----
> 
> If we're limiting the summary to 1 line, 70-75 chars, manditory
> cat/package and bug number there's not a lot of room to summarize in.

Note that a bug number would fit in your above summary very easily, 
omitting nothing, as it's only ~35/75 length.

Even with my somewhat longer cat/pkg example with the longest arch-
keyword I could quickly find, there's still room to indicate at minimum 
build vs runtime error, with the gentoo bug number reference for anyone 
who might find it interesting enough to look further than the one-line.  
People can then either select and klipper-popup (adding my usual trigger 
method to the others people have mentioned), or read the longer 
description for the full bug URL to click, if they prefer.

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

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

[Dmitry Yu Okunev]

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

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

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

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

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

Yes. But as for me this duplicated text adds a lot of garbage to the
total text of a comment. It's harder to fast look over it. You were
right — "Visual space" does matter.

And Andrew said "useless information" — I agree.

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

I remember that William Hubbs asked me to remove one very simple
ASCII-arted scheme (that explains how the code works) from a patch,
because it's very inconvenient to listen that stuff using speech-to-text
engines. May be somebody should just ask him for his opinion on this
question? I think it's more convenient to listen pure bug IDs rather
than a lot of full URLs.

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

You can use header "Gentoo-Bug:" (instead of "Bug:") and explain in
documentation ways to parse that.

-- 
Best regards, Dmitry.


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

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

[Michał Górny]

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

Dnia 2015-08-11, o godz. 09:56:55
Dmitry Yu Okunev <dyokunev@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/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

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

[Dmitry Yu Okunev]

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



On 08/11/2015 10:12 AM, Michał Górny wrote:
> Dnia 2015-08-11, o godz. 09:56:55
> Dmitry Yu Okunev <dyokunev@ut.mephi.ru> napisał(a):
>> 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...

For example Gentoo may use "Gentoo-Bug:"/"Bug-Gentoo:" as I mentioned.
Debian uses "Bug-Debian:" for Debian ITS references and "Bug:" for
upstream bugreport references in their patches (debian/patches/*), IIRC.

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

Why? Just migrate with saved IDs.

> In fact, since the URLs
> are Bugzilla-specific it will allow us to ensure better compatibility
> if we start numbering bugs from 1 again.

IMHO, it's a really bad idea to do not migrate previous data to the new ITS.

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

Only if you will use Bugzilla or some workarounds to imitate Bugzilla.
It's a lock-in.

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

Well, ok. But personally I have a habit to read such text left-to-right.
It requires split seconds to recognize this lines similarity but it
requires.

Anyway as I said, I will see much more garbage while looking on the
whole text if you will use URLs instead of pure IDs.

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

What you mean with the "custom format"? I suggest to use comment as a
comment, but not as a documentation about "How to reach Gentoo ITS" in
every comment.

I can agree with another argument:
There should be a possibility to define an upstream bug which format in
turn can be simply unified only by URLs. And it may became harder to
read when neighboring headlines are formatted different ways (one header
— pure IDs, another one — URLs). But _IMHO_, it doesn't outweigh
disadvantages of this approach (with URLs for reference on Gentoo bug).

--
Best regards, Dmitry.


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

Re: [gentoo-dev] Re: Referencing bug reports in git

[Tobias Klausmann]

Hi! 

On Tue, 11 Aug 2015, Duncan wrote:

> Ryan Hill posted on Mon, 10 Aug 2015 18:17:30 -0600 as excerpted:
> 
> > On Mon, 10 Aug 2015 12:25:58 +0000 (UTC)
> > Duncan <1i5t5.duncan@cox.net> wrote:
> >> What about:
> >> 
> >> * bug number in summary strongly recommended
> > 
> > Making the bug number in the summary manditory or strongly encouraged
> > leads to wonderful commit messages like:
> > 
> > ---
> > cat-pkg: Fix bug #504321.
> 
> Ideally, it'd be something a bit more informative (here taking Gordon's 
> points about the previously suggested B#):
> 
> cat-egory/semi-long-package-name: fix amd64-fbsd build error G-504321
> 
> > I would like to see this be more common:
> > 
> > ---
> > cat-pkg: Make the thingy work again
> > 
> > Gentoo-Bug: https://bugs.gentoo.org/504321 *(or 504321 Idon'tcarewhich)
> > ----
> > 
> > If we're limiting the summary to 1 line, 70-75 chars, manditory
> > cat/package and bug number there's not a lot of room to summarize in.
> 
> Note that a bug number would fit in your above summary very easily, 
> omitting nothing, as it's only ~35/75 length.
> 
> Even with my somewhat longer cat/pkg example with the longest arch-
> keyword I could quickly find, there's still room to indicate at minimum 
> build vs runtime error, with the gentoo bug number reference for anyone 
> who might find it interesting enough to look further than the one-line.  
> People can then either select and klipper-popup (adding my usual trigger 
> method to the others people have mentioned), or read the longer 
> description for the full bug URL to click, if they prefer.

The more we stuff into the summary line, the harder it will be to
write meaningful summaries. And thus, people will write crappy
ones or ignore the length limit. I recommend against any more
prescription over "Add the the cat/pn if meaningful, don't use
more than 75 characters".

The cat/pn rule is tricky anyway: what if one commit touches 100
packages? Or should that be split into 100 commits for easier
partial rollback?

Regards,
Tobias

-- 
Sent from aboard the Culture ship
	Fine Till You Came Along

Re: [gentoo-dev] Re: Referencing bug reports in git

[Kent Fredric]

On 11 August 2015 at 20:57, Tobias Klausmann <klausman@gentoo.org> wrote:
>
> The cat/pn rule is tricky anyway: what if one commit touches 100
> packages? Or should that be split into 100 commits for easier
> partial rollback?


I think you've misread "The rule"

https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Commit_Message_Format

Emphasis added:

>> commits that affect **primarily** a particular subsystem should prepend the >> following code to the first line of the commit message:

>> **if the change affects multiple directories**, but is mostly related to a particular subsystem, then prepend the subsystem which best reflects the intention (e.g. you add a new license, but also modify profiles/license_group


-- 
Kent

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

Re: [gentoo-dev] Re: Referencing bug reports in git

[Rich Freeman]

On Tue, Aug 11, 2015 at 5:12 AM, Kent Fredric <kentfredric@gmail.com> wrote:
> On 11 August 2015 at 20:57, Tobias Klausmann <klausman@gentoo.org> wrote:
>>
>> The cat/pn rule is tricky anyway: what if one commit touches 100
>> packages? Or should that be split into 100 commits for easier
>> partial rollback?
>
>>> **if the change affects multiple directories**, but is mostly related to a particular subsystem, then prepend the subsystem which best reflects the intention (e.g. you add a new license, but also modify profiles/license_group

++
Go read the proposal.  This email chain simplifies it but people have
already thought of most of those corner cases already.

However, I do want to touch on this bit from the previous email: "Or
should that be split into 100 commits for easier partial rollback?"

Each commit should be one logical change.  If you stabilize 100
separate packages in an afternoon, there should be 100 commits.  If
you stabilize kde-5.0 there probably should be one commit that touches
100 packages.  Likewise if you rename a package and fix 100 references
to it in other packages, that should probably also be a single commit
(but I'd separate renaming the package from any other changes to the
content of the package).

That is actually one of the advantages of git.  You can stabilize
kde-5 and a user doing an rsync will either get kde 4.x or the full
kde 5, and nothing in-between.

But, one commit in the final tree should still remain one logical change.

-- 
Rich

Re: [gentoo-dev] Re: Referencing bug reports in git

[hasufell]

On 08/11/2015 01:49 PM, Rich Freeman wrote:
> On Tue, Aug 11, 2015 at 5:12 AM, Kent Fredric <kentfredric@gmail.com> wrote:
>> On 11 August 2015 at 20:57, Tobias Klausmann <klausman@gentoo.org> wrote:
>>>
>>> The cat/pn rule is tricky anyway: what if one commit touches 100
>>> packages? Or should that be split into 100 commits for easier
>>> partial rollback?
>>
>>>> **if the change affects multiple directories**, but is mostly related to a particular subsystem, then prepend the subsystem which best reflects the intention (e.g. you add a new license, but also modify profiles/license_group
> 
> ++
> Go read the proposal.  This email chain simplifies it but people have
> already thought of most of those corner cases already.
> 
> However, I do want to touch on this bit from the previous email: "Or
> should that be split into 100 commits for easier partial rollback?"
> 
> Each commit should be one logical change.  If you stabilize 100
> separate packages in an afternoon, there should be 100 commits.  If
> you stabilize kde-5.0 there probably should be one commit that touches
> 100 packages.  Likewise if you rename a package and fix 100 references
> to it in other packages, that should probably also be a single commit
> (but I'd separate renaming the package from any other changes to the
> content of the package).
> 
> That is actually one of the advantages of git.  You can stabilize
> kde-5 and a user doing an rsync will either get kde 4.x or the full
> kde 5, and nothing in-between.
> 
> But, one commit in the final tree should still remain one logical change.
> 

Right.

In addition, we just took the freedom to add the clause "all commits
must be repoman-valid":
https://wiki.gentoo.org/index.php?title=Gentoo_git_workflow&diff=352978&oldid=352858

That will be necessary too for the CI work mgorny is doing and will also
make bisecting and cherry-picking easier.

That is: if splitting up a commit into several makes repoman fail on
some of them, it probably should be one commit instead (or you have to
reconsider the order you commit stuff in... e.g. first add the license
and then the package).


But we are drifting OT again.

[gentoo-dev] Summary line (was: Re: Referencing bug reports in git)

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 11/08/15 04:57 AM, Tobias Klausmann wrote:
> The more we stuff into the summary line, the harder it will be to 
> write meaningful summaries. And thus, people will write crappy ones
> or ignore the length limit. I recommend against any more 
> prescription over "Add the the cat/pn if meaningful, don't use more
> than 75 characters".
> 
> The cat/pn rule is tricky anyway: what if one commit touches 100 
> packages? Or should that be split into 100 commits for easier 
> partial rollback?
> 
> Regards, Tobias
> 


The summary line limit is going to be a real issue, tbh.  I think it
would probably be best to adopt the convention of putting a few
choice, perhaps even canned, phrases in the summary line, and ensure
any and all details (effectively what the summary line used to be for
when it had practically no limit) within the commit message body instead
.

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.  'Fix bug' IMO in
the summary doesn't work at all because, although its accurate, that
bug could literally be anything at all.

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


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

iF4EAREIAAYFAlXKBpIACgkQAJxUfCtlWe3pQgD8Ct1elGvDIObKKvskQJ1jCZIK
cYvuWdMD7pobr/hH6iIA/jnYirAb9CDe4iNlVPqG2AKYbj9NJdGnpoL/TFhJtj8U
=vnTb
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Summary line (was: Re: Referencing bug reports in git)

[Kent Fredric]

On 12 August 2015 at 02:28, Ian Stakenvicius <axs@gentoo.org> 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.

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.

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

Re: [gentoo-dev] Summary line

[hasufell]

On 08/11/2015 04:28 PM, Ian Stakenvicius wrote:
> On 11/08/15 04:57 AM, Tobias Klausmann wrote:
>> The more we stuff into the summary line, the harder it will be to 
>> write meaningful summaries. And thus, people will write crappy ones
>> or ignore the length limit. I recommend against any more 
>> prescription over "Add the the cat/pn if meaningful, don't use more
>> than 75 characters".
> 
>> The cat/pn rule is tricky anyway: what if one commit touches 100 
>> packages? Or should that be split into 100 commits for easier 
>> partial rollback?
> 
>> Regards, Tobias
> 
> 
> 
> The summary line limit is going to be a real issue, tbh.  I think it
> would probably be best to adopt the convention of putting a few
> choice, perhaps even canned, phrases in the summary line, and ensure
> any and all details (effectively what the summary line used to be for
> when it had practically no limit) within the commit message body instead
> .
> 
> 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.  'Fix bug' IMO in
> the summary doesn't work at all because, although its accurate, that
> bug could literally be anything at all.
> 
> 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)?
> 
> 
> 

The "CATEGORY:" prefix is already in the wiki. Interesting idea about
projectname/herdname prefix.

I've already seen someone (I think ulm) prefixing with [QA].

I don't feel strong about this. IMO, if there is no useful prefix...
just don't use any. The lack of prefix will make it obvious that this is
a larger change. But project/herd specific prefixes could still make sense.

Re: [gentoo-dev] Summary line

[Mikle Kolyada]

11.08.2015 17:36, hasufell пишет:
> On 08/11/2015 04:28 PM, Ian Stakenvicius wrote:
>> On 11/08/15 04:57 AM, Tobias Klausmann wrote:
>>> The more we stuff into the summary line, the harder it will be to 
>>> write meaningful summaries. And thus, people will write crappy ones
>>> or ignore the length limit. I recommend against any more 
>>> prescription over "Add the the cat/pn if meaningful, don't use more
>>> than 75 characters".
>>> The cat/pn rule is tricky anyway: what if one commit touches 100 
>>> packages? Or should that be split into 100 commits for easier 
>>> partial rollback?
>>> Regards, Tobias
>>
>>
>> The summary line limit is going to be a real issue, tbh.  I think it
>> would probably be best to adopt the convention of putting a few
>> choice, perhaps even canned, phrases in the summary line, and ensure
>> any and all details (effectively what the summary line used to be for
>> when it had practically no limit) within the commit message body instead
>> .
>>
>> 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.  'Fix bug' IMO in
>> the summary doesn't work at all because, although its accurate, that
>> bug could literally be anything at all.
>>
>> 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)?
>>
>>
>>
> The "CATEGORY:" prefix is already in the wiki. Interesting idea about
> projectname/herdname prefix.
>
> I've already seen someone (I think ulm) prefixing with [QA].
>
> I don't feel strong about this. IMO, if there is no useful prefix...
> just don't use any. The lack of prefix will make it obvious that this is
> a larger change. But project/herd specific prefixes could still make sense.
>
Mgorny has commited a fix to live portage

https://github.com/gentoo/portage/commit/46dafadff58da0220511f20480b73ad09f913430

I think it will be in the tree soon.

Re: [gentoo-dev] Summary line

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 11/08/15 10:35 AM, Kent Fredric wrote:
> On 12 August 2015 at 02:28, Ian Stakenvicius <axs@gentoo.org>
> 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.
> 
> 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.
> 
> 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 )
> 

I agree, these are short and don't have nearly as much meaning as
they should -- if there's space, absolutely we should add more
meaning.  I think my point still stands though that the short
description should be more like these messages rather than "fix
bug#someting" when there's absolutely no indication of what the bug
is actually about.

So long as all of the details are in the main commit message body,
of course...

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

iF4EAREIAAYFAlXKFFcACgkQAJxUfCtlWe0FRAEAgrL/FYmdYlA10JQyjkhrWPW6
Md6CjK5CCWQh35sz5U8A/Agp6d8HHSu69ZinmhE1VCw9D8TjJ3r5WtQYEo0X8Vhj
=WHfg
-----END PGP SIGNATURE-----

[gentoo-dev] Bisecting Was: Referencing bug reports in git

[Duncan]

hasufell posted on Tue, 11 Aug 2015 13:58:20 +0200 as excerpted:

> In addition, we just took the freedom to add the clause "all commits
> must be repoman-valid":
> https://wiki.gentoo.org/index.php?
title=Gentoo_git_workflow&diff=352978&oldid=352858
> 
> That will be necessary too for the CI work mgorny is doing and will also
> make bisecting and cherry-picking easier.

The mention of bisect got me thinking... I'm not exactly sure I'm wording 
this right, but hopefully the question is clear enough...

What are the practical implications of and reasons for doing a bisect, on 
a package-tree repo, where it's typically the out-of-tree package sources 
where most functionality-bisection would happen, and in-tree commits tend 
to result in atomic package updates, or at least atomic USE flag, etc, 
changes on a package?

The typical reason for a bisect is to find the commit where a bug 
originated, but that's upstream package/project bisects.  I don't quite 
see how that maps to distro package tree repo bisects, as it seems to me 
there's nothing really to bisect -- problems should be with specific 
package versions or with USE flag or similar changes within an ebuild/
eclass, and it seems to me that's known along with awareness of the 
problem in the first place, leaving no reason to bisect to find the 
problem.

Tho arguably eclass change issues are an exception, and bisectable in the 
usual sense for the usual purpose.  Actually, that could make 
troubleshooting eclass updates MUCH simpler than it was before.  Luckily, 
at least I as a user didn't end up with too many direct eclass issues to 
troubleshoot.

Tho I can definitely think of a non-traditional use for bisect.  While I 
update my workstation more or less weekly, I updated my 32-bit 
netbook[1]  far less frequently, every year or two.  It occurs to me that 
using git bisect to automate working out the resulting update issues 
might be far easier than some of the manual tricks and workaround I used 
to end up doing, to finally get an updated to current, working system 
once again.  Bisect start, immediately declare bisect bad, inner looping 
until I got to about a three-month update, update to it, bisect reset, 
outer-looping on the bisect to another 3-4 month update... until I was 
caught up.  Of course one can't go back past our current switch to git, 
but in five years, one could in theory pull the old laptop out that was 
last updated yesterday, and roll back gentoo's now five-years-future tree 
four years and nine months, and start the update process, ultimately 
bringing it upto date without starting with a new stage tarball install, 
as would have been the only really feasible pre-git alternative for a 
five-year-outdated system.  Not that a new stage tarball wouldn't be 
faster after five years in any case, but at least the incremental update-
in-place should now be possible.

---
[1] 32-bit netbook: Now gone and not yet replaced, but I intend to get 
another, tho amd64 this time so I can mostly build once for both, one for 
three if I setup an amd64-based router as I intend to as well, and 
hopefully avoid the year-plus update period issue as I can just binpkg-
update after the first one.

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

Re: [gentoo-dev] Bisecting Was: Referencing bug reports in git

[Jason Zaman]

On Wed, Aug 12, 2015 at 07:20:54AM +0000, Duncan wrote:
> hasufell posted on Tue, 11 Aug 2015 13:58:20 +0200 as excerpted:
> 
> > In addition, we just took the freedom to add the clause "all commits
> > must be repoman-valid":
> > https://wiki.gentoo.org/index.php?
> title=Gentoo_git_workflow&diff=352978&oldid=352858
> > 
> > That will be necessary too for the CI work mgorny is doing and will also
> > make bisecting and cherry-picking easier.
> 
> The mention of bisect got me thinking... I'm not exactly sure I'm wording 
> this right, but hopefully the question is clear enough...
> 
> What are the practical implications of and reasons for doing a bisect, on 
> a package-tree repo, where it's typically the out-of-tree package sources 
> where most functionality-bisection would happen, and in-tree commits tend 
> to result in atomic package updates, or at least atomic USE flag, etc, 
> changes on a package?
> 
> The typical reason for a bisect is to find the commit where a bug 
> originated, but that's upstream package/project bisects.  I don't quite 
> see how that maps to distro package tree repo bisects, as it seems to me 
> there's nothing really to bisect -- problems should be with specific 
> package versions or with USE flag or similar changes within an ebuild/
> eclass, and it seems to me that's known along with awareness of the 
> problem in the first place, leaving no reason to bisect to find the 
> problem.
> 
> Tho arguably eclass change issues are an exception, and bisectable in the 
> usual sense for the usual purpose.  Actually, that could make 
> troubleshooting eclass updates MUCH simpler than it was before.  Luckily, 
> at least I as a user didn't end up with too many direct eclass issues to 
> troubleshoot.

I agree that bisecting would typically not happen that often because
usually you'd just emerge =cat/pkg-1.2.3 but there are times when
updates are done without a revbump that might have broken something so
it could be useful. Also eclasses would definitely be useful. There are
a few useful cases when it might make things easier but probably rare,
tho its good to have the tool available in case.

> Tho I can definitely think of a non-traditional use for bisect.  While I 
> update my workstation more or less weekly, I updated my 32-bit 
> netbook[1]  far less frequently, every year or two.  It occurs to me that 
> using git bisect to automate working out the resulting update issues 
> might be far easier than some of the manual tricks and workaround I used 
> to end up doing, to finally get an updated to current, working system 
> once again.  Bisect start, immediately declare bisect bad, inner looping 
> until I got to about a three-month update, update to it, bisect reset, 
> outer-looping on the bisect to another 3-4 month update... until I was 
> caught up.  Of course one can't go back past our current switch to git, 
> but in five years, one could in theory pull the old laptop out that was 
> last updated yesterday, and roll back gentoo's now five-years-future tree 
> four years and nine months, and start the update process, ultimately 
> bringing it upto date without starting with a new stage tarball install, 
> as would have been the only really feasible pre-git alternative for a 
> five-year-outdated system.  Not that a new stage tarball wouldn't be 
> faster after five years in any case, but at least the incremental update-
> in-place should now be possible.

I like the idea, but its probably easier to just
git checkout $(git rev-list -n 1 --before="2015-12-01 12:00" master)
and then you just change the date a month at a time or something

-- Jason

> ---
> [1] 32-bit netbook: Now gone and not yet replaced, but I intend to get 
> another, tho amd64 this time so I can mostly build once for both, one for 
> three if I setup an amd64-based router as I intend to as well, and 
> hopefully avoid the year-plus update period issue as I can just binpkg-
> update after the first one.
> 
> -- 
> 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
> 
> 

[gentoo-dev] Re: Bisecting Was: Referencing bug reports in git

[Duncan]

Jason Zaman posted on Wed, 12 Aug 2015 15:38:01 +0800 as excerpted:

>> Tho I can definitely think of a non-traditional use for bisect.  
>> [When a system hasn't been updated in over a year, bisect the update.]
> 
> I like the idea, but its probably easier to just git checkout $(git
> rev-list -n 1 --before="2015-12-01 12:00" master) and then you just
> change the date a month at a time or something

You're correct, and I did think about that, but...

The nice thing with bisect at least in something like the kernel where 
most of the direct main-tree changes are merges, is that it'll stay at 
the higher merge level as long as possible, drilling down to individual 
commits only after bisects to an individual merge.

Again, however, I'm not entirely sure how that translates to gentoo's 
rebase-and-fast-forward recommendation, with fewer merges.  But at the 
3-4 month level, if it avoids landing in the middle of a kde or gnome 
update, that'd be very useful.

It could well be that with gentoo's merges-discouraged workflow, the 
effect would be the same either way, in which case, you're correct, your 
suggestion would be easier.

But it's still a creative use of bisect I hadn't thought of before, even 
if bisect isn't the most efficient method to that end. Which means I know 
a bit more about bisect than I did.  =:^)

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

[gentoo-dev] 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

Re: [gentoo-dev] 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

Re: [gentoo-dev] Re: Referencing bug reports in git

[Michał Górny]

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

Dnia 2015-08-12, o godz. 17:59:03
Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> 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/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] Re: Referencing bug reports in git

[hasufell]

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.

Re: [gentoo-dev] Re: Referencing bug reports in git

[Chí-Thanh Christopher Nguyễn]

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

Re: [gentoo-dev] Re: Referencing bug reports in git

[Michał Górny]

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

Dnia 2015-08-12, o godz. 18:25:07
Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> 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/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] Re: Referencing bug reports in git

[Ian Stakenvicius]

-----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
> <chithanh@gentoo.org> 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-----

Re: [gentoo-dev] Re: Referencing bug reports in git

[Matt Turner]

On Wed, Aug 12, 2015 at 3:40 AM, hasufell <hasufell@gentoo.org> 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.

Re: [gentoo-dev] Re: Referencing bug reports in git

[Dmitry Yu Okunev]

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



On 08/12/2015 08:38 PM, Matt Turner wrote:
> On Wed, Aug 12, 2015 at 3:40 AM, hasufell <hasufell@gentoo.org> 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


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

Re: [gentoo-dev] 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 <hasufell@gentoo.org> 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.

Re: [gentoo-dev] Referencing bug reports in git

[Steev Klimaszewski]

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

> 
> Someone end the bikeshed train please.

Seconded.

[-- Attachment #2: Type: text/html, Size: 1080 bytes --]

[gentoo-dev] Re: Referencing bug reports in git

[Ryan Hill]

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

On Wed, 12 Aug 2015 18:03:52 +0200
Michał Górny <mgorny@gentoo.org> 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 475 bytes --]

Re: [gentoo-dev] Re: Referencing bug reports in git

[Ben de Groot]

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

Re: [gentoo-dev] Re: Referencing bug reports in git

[Rich Freeman]

On Thu, Aug 13, 2015 at 7:19 AM, Ben de Groot <yngwin@gentoo.org> 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

Re: [gentoo-dev] Re: Referencing bug reports in git

[Aaron W. Swenson]

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

On 2015-08-13 08:13, Rich Freeman wrote:
> On Thu, Aug 13, 2015 at 7:19 AM, Ben de Groot <yngwin@gentoo.org> 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

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

Re: [gentoo-dev] Re: Referencing bug reports in git

[Andrew Savchenko]

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

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

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

Re: [gentoo-dev] Re: Referencing bug reports in git

[Matthias Maier]

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


On Fri, Aug 14, 2015, at 15:04 CDT, Andrew Savchenko <bircoph@gentoo.org> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 820 bytes --]

Re: [gentoo-dev] Re: Referencing bug reports in git

[Daniel Campbell (zlg)]

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

[gentoo-dev] Re: Referencing bug reports in git

[Ryan Hill]

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

On Thu, 13 Aug 2015 08:13:59 -0400
Rich Freeman <rich0@gentoo.org> 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 475 bytes --]

Re: [gentoo-dev] Summary line (was: Re: Referencing bug reports in git)

[Alec Warner]

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

On Tue, Aug 11, 2015 at 7:35 AM, Kent Fredric <kentfredric@gmail.com> wrote:

> On 12 August 2015 at 02:28, Ian Stakenvicius <axs@gentoo.org> 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
>
>

[-- Attachment #2: Type: text/html, Size: 3050 bytes --]

Re: [gentoo-dev] Summary line (was: Re: Referencing bug reports in git)

[Rich Freeman]

On Mon, Aug 31, 2015 at 10:53 AM, Alec Warner <antarus@gentoo.org> wrote:
>>
>> 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?
>

Rather than embedding info about the content of the commit into the
headers, wouldn't it make sense to just obtain it from git on-demand?
Maybe you want to run git whatchaged instead of git log, or use one of
the bazillion different log pretty formats, or define your own?

-- 
Rich

Re: [gentoo-dev] Summary line

[Michael Orlitzky]

On 08/31/2015 01:33 PM, Rich Freeman wrote:
> On Mon, Aug 31, 2015 at 10:53 AM, Alec Warner <antarus@gentoo.org> wrote:
>>>
>>> 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?
>>
> 
> Rather than embedding info about the content of the commit into the
> headers, wouldn't it make sense to just obtain it from git on-demand?
> Maybe you want to run git whatchaged instead of git log, or use one of
> the bazillion different log pretty formats, or define your own?
> 

Yes, `git log --stat` tells me what I want `git log` to tell me.