Re: [gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)
On 08/11/2015 10:12 AM, Michał Górny wrote: Dnia 2015-08-11, o godz. 09:56:55 Dmitry Yu Okunev dyoku...@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. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)
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. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)
Dnia 2015-08-11, o godz. 09:56:55 Dmitry Yu Okunev dyoku...@ut.mephi.ru napisał(a): Hello. I'm not a gentoo-dev, so sorry if I shouldn't express my thoughts with my lame English here. Please tell me if it's so. On 08/11/2015 12:06 AM, Michał Górny wrote: 3. Too many text, hard to read. Some bugs may refer to a dozen of URLs. And how is a dozen numbers better? Less text, more readable. How is: Bug: 123451, 453445, 344334, 343444 more readable than: Bug: https://bugs.gentoo.org/123451 Bug: https://bugs.gentoo.org/453445 Bug: https://bugs.gentoo.org/344334 Bug: https://bugs.gentoo.org/343444 Readability is a matter of formatting, not contents. 1. One line and 35 chars are certainly more readable than four lines and 140 chars. Character counts are completely irrelevant to readability. Visual space is. And in this case, exhibit A (also known as wall of digits) is more likely to get people confused. I think it's just individual preference. No sense to argue this. Just everybody should consider that there exists another position on this question. However I want to add an other argument: 1a. It's easier to parse the Bug: header is there only bug IDs (without URLs). What if there are different bug trackers involved? We sometimes note upstream bugs, other distro bugs, pull requests... And is there any guarantee that URL format won't be changed in future (that everybody won't be have to rewrite their parsers). I mean not near future, but any long future. I doubt it can change *without* changing the bug tracker software. And then, old IDs will no longer be relevant. In fact, since the URLs are Bugzilla-specific it will allow us to ensure better compatibility if we start numbering bugs from 1 again. There's URL and there's URI. Even if URL is no longer valid, it will still be a valid URI. It will still allow us to uniquely identify the bug report. 2. Strings are read from left to right (at least in English), thus having most important information last on the line is not convenient. This is not literature. Keys usually precede values, and namespaces precede namespaced identifiers. A commit-comment is not a source code. It's an ordinary text (like literature). Literature is a long continuous text which you read left-to-right, and usually without going back. This is short text which you read randomly, possibly going back and forth, and scanning for specific details. As far as I'm aware, URLs are supported much more widely than Gentoo-specific bug numbers. They are uniform and unique by definition. The tools using bug numbers can be easily expanded to extract them from URLs. I don't really see forking cgit to support Gentoo bug numbers, or asking github to provide special rules for our commits. We should not adjust our ecosystem for closed and proprietary solutions like github. URLs are not github invention. Localized bug numbers are local Gentoo non-sense. So should we adjust it to ignore the rest of the world and expect everyone to create custom hackery just to be able to see a bug report? You can use header Gentoo-Bug: (instead of Bug:) and explain in documentation ways to parse that. So you're suggesting it's better to invent a custom format and tell people how to handle it, rather than use a commonly-supported format? -- Best regards, Michał Górny http://dev.gentoo.org/~mgorny/ pgpFUxUHmcnoq.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)
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 pgp16i0YCp7ll.pgp Description: PGP signature
Re: [gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)
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 xx 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 pgpR_HPHe1iEN.pgp Description: PGP signature
Re: [gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)
Dnia 2015-08-10, o godz. 02:16:01 Andrew Savchenko birc...@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/ pgp4YORhnUYTk.pgp Description: OpenPGP digital signature
[gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)
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 + Commit: Michael Weber xmw AT gentoo DOT org CommitDate: Sun Aug 9 13:58:26 2015 + 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/)
On 08/09/2015 10:43 AM, Dirkjan Ochtman wrote: On Sun, Aug 9, 2015 at 4:38 PM, hasufell hasuf...@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/)
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/)
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/)
On Sun, Aug 9, 2015 at 4:38 PM, hasufell hasuf...@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/)
On 9 August 2015 at 15:09, hasufell hasuf...@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 + Commit: Michael Weber xmw AT gentoo DOT org CommitDate: Sun Aug 9 13:58:26 2015 + 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
Re: [gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)
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/)
On Sun, Aug 9, 2015 at 11:30 AM, hasufell hasuf...@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/)
On Sun, Aug 9, 2015 at 4:09 PM, hasufell hasuf...@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/)
On Sun, Aug 9, 2015 at 8:43 AM, Mike Gilbert flop...@gentoo.org wrote: On Sun, Aug 9, 2015 at 11:30 AM, hasufell hasuf...@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/)
Dnia 2015-08-09, o godz. 16:09:29 hasufell hasuf...@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 + Commit: Michael Weber xmw AT gentoo DOT org CommitDate: Sun Aug 9 13:58:26 2015 + 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/ pgpXxgIIsdJ32.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)
On Sun, Aug 9, 2015 at 5:11 PM, Michał Górny mgo...@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/)
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/)
-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-
Re: [gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)
Dnia 2015-08-09, o godz. 23:01:32 hasufell hasuf...@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 hasuf...@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 + Commit: Michael Weber xmw AT gentoo DOT org CommitDate: Sun Aug 9 13:58:26 2015 + 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/ pgpwNTt8k8VDn.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)
On Sun, 9 Aug 2015 21:56:05 +0200 Michał Górny wrote: Dnia 2015-08-09, o godz. 16:09:29 hasufell hasuf...@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 + Commit: Michael Weber xmw AT gentoo DOT org CommitDate: Sun Aug 9 13:58:26 2015 + 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 pgp9XJzgDvj9P.pgp Description: PGP signature
Re: [gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)
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 pgp6CFjNKrcEs.pgp Description: PGP signature
Re: [gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)
-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 hasuf...@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 hasuf...@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 + Commit: Michael Weber xmw AT gentoo DOT org CommitDate: Sun Aug 9 13:58:26 2015 + 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 xx 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/)
On 08/09/2015 09:56 PM, Michał Górny wrote: Dnia 2015-08-09, o godz. 16:09:29 hasufell hasuf...@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 + Commit: Michael Weber xmw AT gentoo DOT org CommitDate: Sun Aug 9 13:58:26 2015 + 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/)
Dnia 2015-08-10, o godz. 00:44:09 Andrew Savchenko birc...@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 hasuf...@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 + Commit: Michael Weber xmw AT gentoo DOT org CommitDate: Sun Aug 9 13:58:26 2015 + 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/ pgpwcfLVWgGDw.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)
-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 flop...@gentoo.org wrote: On Sun, Aug 9, 2015 at 11:30 AM, hasufell hasuf...@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: xx 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/)
On 10 August 2015 at 11:46, hasufell hasuf...@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/)
On Sun, 2015-08-09 at 17:30 +0200, hasufell wrote: On 08/09/2015 05:19 PM, Tobias Klausmann wrote: On Sun, 09 Aug 2015, Sven Vermeulen wrote: I'd just go with Gentoo-Bug. The X- is pointless since it was for eXtending Email-Headers. And what we do is only linked in style. I'd be fine with that and add a reference to the kernel guideline [0] to the wiki as well, so that it is clear that we also allow/use Acked-by, Reviewed-by, Suggested-by and whatnot. I'll wait for more ++ though. [0] https://www.kernel.org/doc/Documentation/SubmittingPatches ++ from me. And a question: what about multiple bugs fixed by one commit? Is it Gentoo-Bug: 1234567, 1234568 or Gentoo-Bug: 1234567 Gentoo-Bug: 1234568 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)
On 08/09/2015 04:26 PM, Dirkjan Ochtman wrote: On Sun, Aug 9, 2015 at 4:09 PM, hasufell hasuf...@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/)
On 08/09/2015 04:43 PM, Dirkjan Ochtman wrote: On Sun, Aug 9, 2015 at 4:38 PM, hasufell hasuf...@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/)
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
