[gentoo-dev] Re: Referencing bug reports in git
On Thu, 13 Aug 2015 08:13:59 -0400 Rich Freeman ri...@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 Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 pgpOKZwJ7NJob.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Referencing bug reports in git
-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-
Re: [gentoo-dev] Re: Referencing bug reports in git
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 pgpwvJxv7YOQ_.pgp Description: PGP signature
Re: [gentoo-dev] Re: Referencing bug reports in git
On Fri, Aug 14, 2015, at 15:04 CDT, Andrew Savchenko birc...@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 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Referencing bug reports in git
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
On Thu, Aug 13, 2015 at 7:19 AM, Ben de Groot yng...@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
[gentoo-dev] Re: Referencing bug reports in git
On Wed, 12 Aug 2015 18:03:52 +0200 Michał Górny mgo...@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 Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 pgpZvwfTybaI_.pgp Description: OpenPGP digital signature
[gentoo-dev] Re: Referencing bug reports in git
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
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
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
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
Dnia 2015-08-12, o godz. 17:59:03 Chí-Thanh Christopher Nguyễn chith...@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/ pgpC1eGhgSGd0.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Referencing bug reports in git
Dnia 2015-08-12, o godz. 18:25:07 Chí-Thanh Christopher Nguyễn chith...@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/ pgpkGDHB8vrMj.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Referencing bug reports in git
-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 chith...@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
On Wed, Aug 12, 2015 at 3:40 AM, hasufell hasuf...@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
On 08/12/2015 08:38 PM, Matt Turner wrote: On Wed, Aug 12, 2015 at 3:40 AM, hasufell hasuf...@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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Referencing bug reports in git
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 hasuf...@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] Re: Referencing bug reports in git
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 + (UTC) Duncan 1i5t5.dun...@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
On 11 August 2015 at 20:57, Tobias Klausmann klaus...@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
On Tue, Aug 11, 2015 at 5:12 AM, Kent Fredric kentfred...@gmail.com wrote: On 11 August 2015 at 20:57, Tobias Klausmann klaus...@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
On 08/11/2015 01:49 PM, Rich Freeman wrote: On Tue, Aug 11, 2015 at 5:12 AM, Kent Fredric kentfred...@gmail.com wrote: On 11 August 2015 at 20:57, Tobias Klausmann klaus...@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_workflowdiff=352978oldid=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.
Re: [gentoo-dev] Re: Referencing bug reports in git
On Mon, Aug 10, 2015 at 7:25 AM, Duncan 1i5t5.dun...@cox.net wrote: ** summary bug number standardized to GB#xx or #xx 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).
[gentoo-dev] Re: Referencing bug reports in git
On Mon, 10 Aug 2015 12:25:58 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: What about: * bug number in summary strongly recommended ** summary bug number standardized to GB#xx or #xx 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 Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 pgpHa8xvvMufS.pgp Description: OpenPGP digital signature
[gentoo-dev] Re: Referencing bug reports in git
Ryan Hill posted on Mon, 10 Aug 2015 18:17:30 -0600 as excerpted: On Mon, 10 Aug 2015 12:25:58 + (UTC) Duncan 1i5t5.dun...@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
[gentoo-dev] Re: Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)
On Mon, 10 Aug 2015 23:43:29 +0300 Andrew Savchenko birc...@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 Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 pgpjwTP4s_CiU.pgp Description: OpenPGP digital signature
[gentoo-dev] Re: Referencing bug reports in git
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.dun...@cox.net wrote: ** summary bug number standardized to GB#xx or #xx 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
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#xx or #xx 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
[gentoo-dev] Re: Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)
On Mon, 10 Aug 2015 00:44:09 +0300 Andrew Savchenko birc...@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 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 Also the URL should be https://bugs.gentoo.org/557022 so already that's wrong. -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 pgpSyBwzJyfPG.pgp Description: OpenPGP digital signature
[gentoo-dev] Re: Referencing bug reports in git
On Mon, 10 Aug 2015 03:02:43 +0200 hasufell hasuf...@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 Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 pgplEZSjsocFk.pgp Description: OpenPGP digital signature
