Proposal to Standardize Bug Number References in Commit Messages
Hi all, While we are proposing changes to workflow, etc. I would like to propose that we standardize the manner in which we reference bug numbers in our commit messages. Lately I have been working on scripts to semi-automate the generation of release notes and having a standard reference to bug numbers would greatly simplify munging through git log and extracting them. So I propose that we use the form: [BZX...X] It will be pretty nigh impossible to obtain 100% compliance, so those doing sign-off, QA, or the RM could to 'git commit --amend' to add it in if it is missing or wrong. What say ye? Kind Regards, Chris
Chris Nighswonger schreef op do 10-11-2011 om 15:39 [-0500]:
So I propose that we use the form: [BZX...X]
Most (many?) people seem to use a variant of 'Bug 1234' somewhere on the first line, why not just use that given it seems to be habit already? It'd be easy enough to regex for it, and you'd have a reasonable amount of backwards compatibility. Also, something that's compatible with the way 'git bz' does things would be very much preferred. It uses this regex: (\b[Ss]ee\s+(?:[^\s:/]+\s+){0,2})? (?:(https?://[^/]+/show_bug.cgi\?id=[^&\s]+) | [Bb]ug\s+\#?(\d+)) so, 'See: <url>' or 'Bug <number>' seem to be what it looks for. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D
2011/11/10 Robin Sheat <robin@catalyst.net.nz>:
Chris Nighswonger schreef op do 10-11-2011 om 15:39 [-0500]:
So I propose that we use the form: [BZX...X]
Most (many?) people seem to use a variant of 'Bug 1234' somewhere on the first line, why not just use that given it seems to be habit already? It'd be easy enough to regex for it, and you'd have a reasonable amount of backwards compatibility.
Actually this is true for the most part. However, it is the 1% of times when someone uses other weirdness that make it challenging. :-) I'm not stuck on any particular form, just wanting to get everyone doing the same thing.
Also, something that's compatible with the way 'git bz' does things would be very much preferred. It uses this regex: (\b[Ss]ee\s+(?:[^\s:/]+\s+){0,2})? (?:(https?://[^/]+/show_bug.cgi\?id=[^&\s]+) | [Bb]ug\s+\#?(\d+))
so, 'See: <url>' or 'Bug <number>' seem to be what it looks for.
Here's my current regex (its been through several revisions): ([B|b]ug|BZ)?\s?(?<![a-z]|\.)(\d{4})[\s|:|,] This extracts the following "styles" of bug references from git log, each of which is unique. I have a feeling that there are some other styles which I have not yet caught. (I realize that it only catches 4 digit bug numbers, but '+' causes it to pick up on other junk which I've yet to figure out how to avoid.) Bug 6905: Bug 5995 5533: bug 5780 6278 Bug 5630, BZ6268 BZ6074: I'll be posting my tools in a separate repo at git.k-c.org in the next week or so, so anyone will be welcome to submit patches for improvement. Kind Regards, Chris
On 2011-11-11, at 6:49 AM, Chris Nighswonger wrote:
2011/11/10 Robin Sheat <robin@catalyst.net.nz>:
Chris Nighswonger schreef op do 10-11-2011 om 15:39 [-0500]:
So I propose that we use the form: [BZX...X]
Most (many?) people seem to use a variant of 'Bug 1234' somewhere on the first line, why not just use that given it seems to be habit already? It'd be easy enough to regex for it, and you'd have a reasonable amount of backwards compatibility.
Actually this is true for the most part. However, it is the 1% of times when someone uses other weirdness that make it challenging. :-)
I'm not stuck on any particular form, just wanting to get everyone doing the same thing.
just my 2 cents.... i agree with Robin's suggested format 'Bug XXXX - ' is the format that Bugzilla seems to generate in various places and its also a little easier to understand than 'BZXXXX' and congrats on the release-notes script Chris, its genius!
Mason James <mtj@kohaaloha.com>
i agree with Robin's suggested format
'Bug XXXX - ' is the format that Bugzilla seems to generate in various places and its also a little easier to understand than 'BZXXXX'
and congrats on the release-notes script Chris, its genius!
I agree (on the congrats too). Z looks too like two. Bug XXXX please! -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for various work through http://www.software.coop/
On Sat, Nov 12, 2011 at 1:04 PM, MJ Ray <mjr@phonecoop.coop> wrote:
Mason James <mtj@kohaaloha.com>
i agree with Robin's suggested format
'Bug XXXX - ' is the format that Bugzilla seems to generate in various places and its also a little easier to understand than 'BZXXXX'
and congrats on the release-notes script Chris, its genius!
I agree (on the congrats too). Z looks too like two. Bug XXXX please!
Ok, so it sounds like we're working toward a consensus of Bug XXXX. I'd like to see us agree either to use some sort of markers (ie. [] or some such) or to proceed and follow the bug notation with a single whitespace. Presently we get things like colons, commas, and occasional other chars immediately following the XXXX part of the bug number. Kind Regards, Chris
I'd rather say that we'll put a white space after the bug number than to put the bug number in brackets or some such, I often mistype the brackets in my signed off messages :) Nicole On Sat, Nov 12, 2011 at 8:36 PM, Chris Nighswonger < cnighswonger@foundations.edu> wrote:
Mason James <mtj@kohaaloha.com>
i agree with Robin's suggested format
'Bug XXXX - ' is the format that Bugzilla seems to generate in various
On Sat, Nov 12, 2011 at 1:04 PM, MJ Ray <mjr@phonecoop.coop> wrote: places
and its also a little easier to understand than 'BZXXXX'
and congrats on the release-notes script Chris, its genius!
I agree (on the congrats too). Z looks too like two. Bug XXXX please!
Ok, so it sounds like we're working toward a consensus of Bug XXXX. I'd like to see us agree either to use some sort of markers (ie. [] or some such) or to proceed and follow the bug notation with a single whitespace. Presently we get things like colons, commas, and occasional other chars immediately following the XXXX part of the bug number.
Kind Regards, Chris _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
On 13/11/11 14:36, Chris Nighswonger wrote:
Ok, so it sounds like we're working toward a consensus of Bug XXXX. I'd like to see us agree either to use some sort of markers (ie. [] or some such) or to proceed and follow the bug notation with a single
Two things, one is that regexing for 'Bug 1234' should be pretty easy to do, no matter what follows it (something like '/^[Bb]ug (\d+)/' would do the trick.) Though I like whitespace, I think it makes it more readable too. Secondly with [...], git will strip out things in square brackets at the start of a git comment when editing (maybe applying, not sure exactly where), possibly leading to the bug number getting stripped off on signoff. Additionally, git-bz won't realise you have a bug number in there, and so will attach the URL of the bug to the bottom of the message, nor will it automatically work out what bug you're aiming to attach to. My convention, which I think is parseable and readable is something like: Bug 1234 - something something or Bug 1234 [3.6.x] - something something for things that have to apply to a specific branch. That said, I mostly do this because I picked it up somewhere else, so take that for what it's worth :) Aside: at Kohacon, Mason was working on something to auto-post to -patches from bugzilla. Hopefully that'll be ready to go when he's back from holiday. Robin.
Le 10/11/2011 21:39, Chris Nighswonger a écrit : > Hi all, > > While we are proposing changes to workflow, etc. I would like to > propose that we standardize the manner in which we reference bug > numbers in our commit messages. Lately I have been working on scripts > to semi-automate the generation of release notes and having a standard > reference to bug numbers would greatly simplify munging through git > log and extracting them. > > So I propose that we use the form: [BZX...X] I love this idea ! For many reasons: * I already use BZXXX ;-) (OK, it's a wrong reason) * Not every patch is a bug, so BZ is related to bugzilla, not bug * it takes only 2 chars, where "Bug XXXX" takes 4. In (many) places where only a part of the bug message is displayed, those 2 chars are usefull * Companies like BibLibre uses another tool to track customers bugs (Mantis). So all our internal bugs are prefixed "MTXXXX" where MT is the mantis number. I know that Catalyst uses WRMS, ByWater bugzilla, and there are probably more. We (at BibLibre) make sometimes a mistake because one of us says "bug 5432". The other search in bugzilla, while the speaker was speaking of Mantis ! (maybe that's also because we are in the same array of number in Mantis as we're in bugzilla...) PROPOSAL: Why not having each company "reserve" a prefix, thus we would know that WRMS5432 => Catalyst internal bug number. BW5432 => ByWaterSolutions BZ5432 => koha-community bugzilla number -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
I'm afraid I'm not seeing the need to standardize the expression of bug number in commit messages. We're already using "Bug XXXX" or "Enh XXXX" most of the time, and that's worked just fine for me in all my lookups and QA'ing. Do we just need a pattern that's regex-able so we can program a script to automatically process the patches? As for each company reserving it's own prefix, I don't think that's necessary (at least for ByWater). Everything we submit already has a Koha Bugzilla entry, since that's a requirement for getting submitting code in the first place. We link our local ticketing system to the Koha Bug report, so we can update the appropriate tickets as the fix makes it's way through the community process. It would just introduce complication for us to have local ByWater numbers in the first line of the commit; there could be some advantage to having them at the end of the commit message, but that would be purely for our internal use, and has particular place in a Koha commit message. I'm also with MJ: Z looks too much like 2. -Ian On Sun, Nov 13, 2011 at 2:47 PM, Paul Poulain <paul.poulain@biblibre.com>wrote: > Le 10/11/2011 21:39, Chris Nighswonger a écrit : > > Hi all, > > > > While we are proposing changes to workflow, etc. I would like to > > propose that we standardize the manner in which we reference bug > > numbers in our commit messages. Lately I have been working on scripts > > to semi-automate the generation of release notes and having a standard > > reference to bug numbers would greatly simplify munging through git > > log and extracting them. > > > > So I propose that we use the form: [BZX...X] > I love this idea ! > For many reasons: > * I already use BZXXX ;-) (OK, it's a wrong reason) > * Not every patch is a bug, so BZ is related to bugzilla, not bug > * it takes only 2 chars, where "Bug XXXX" takes 4. In (many) places > where only a part of the bug message is displayed, those 2 chars are > usefull > * Companies like BibLibre uses another tool to track customers bugs > (Mantis). So all our internal bugs are prefixed "MTXXXX" where MT is > the mantis number. I know that Catalyst uses WRMS, ByWater bugzilla, and > there are probably more. > > We (at BibLibre) make sometimes a mistake because one of us says "bug > 5432". The other search in bugzilla, while the speaker was speaking of > Mantis ! (maybe that's also because we are in the same array of number > in Mantis as we're in bugzilla...) > > PROPOSAL: Why not having each company "reserve" a prefix, thus we would > know that WRMS5432 => Catalyst internal bug number. BW5432 => > ByWaterSolutions BZ5432 => koha-community bugzilla number > > -- > Paul POULAIN > http://www.biblibre.com > Expert en Logiciels Libres pour l'info-doc > Tel : (33) 4 91 81 35 08 > _______________________________________________ > Koha-devel mailing list > Koha-devel@lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls@bywatersolutions.com Twitter: @sekjal
Sorry for the pause on my part here. 2011/11/14 Ian Walls <ian.walls@bywatersolutions.com>:
I'm afraid I'm not seeing the need to standardize the expression of bug number in commit messages. We're already using "Bug XXXX" or "Enh XXXX" most of the time, and that's worked just fine for me in all my lookups and QA'ing. Do we just need a pattern that's regex-able so we can program a script to automatically process the patches?
This is moving along in a direction I did not anticipate in my original post. Ian, it would be great if we *only* using the notation you mention above. But, in fact, we are not. To clarify, I quote from my earlier response to Robin:
Also, something that's compatible with the way 'git bz' does things would be very much preferred. It uses this regex: (\b[Ss]ee\s+(?:[^\s:/]+\s+){0,2})? (?:(https?://[^/]+/show_bug.cgi\?id=[^&\s]+) | [Bb]ug\s+\#?(\d+))
so, 'See: <url>' or 'Bug <number>' seem to be what it looks for.
Here's my current regex (its been through several revisions):
([B|b]ug|BZ)?\s?(?<![a-z]|\.)(\d{4})[\s|:|,]
This extracts the following "styles" of bug references from git log, each of which is unique. I have a feeling that there are some other styles which I have not yet caught. (I realize that it only catches 4 digit bug numbers, but '+' causes it to pick up on other junk which I've yet to figure out how to avoid.)
Bug 6905: Bug 5995 5533: bug 5780 6278 Bug 5630, BZ6268 BZ6074:
All of the eight flavors mentioned above are presently in use. As I mentioned in an earlier post as well, \d+ "should" work, but runs in to some problems when commit ids are included. At any rate. The entire discussion is irrelevant if someone can come up with a "one size fits all" regexp for every style of bug tagging currently in use. I've made my script available and am accepting any and all patches which improve it. Thanks to everyone taking time to participate in this thread! Kind Regards, Chris
participants (7)
-
Chris Nighswonger -
Ian Walls -
Mason James -
MJ Ray -
Nicole Engard -
Paul Poulain -
Robin Sheat