D pull request review process -- strawman formal definition, query for tools

[Idan Arye]

On Friday, 10 May 2013 at 01:25:16 UTC, Steven Schveighoffer 
wrote:
> On Thu, 09 May 2013 18:28:18 -0400, Daniel Murphy 
> <yebblies at nospamgmail.com> wrote:
>
>> "Steven Schveighoffer" <schveiguy at yahoo.com> wrote in message
>> news:op.wwt44fvkeav7ka at stevens-macbook-pro.local...
>>>   h) One of the reviewers (not sure if it should be primary 
>>> or secondary)
>>> should close any bugzilla bugs fixed by the pull request.  
>>> Can this be
>>> automated?
>>
>> This is what we are currently doing (sort of) and I think it 
>> would be better
>> to have the requester be responsible for closing the original 
>> bug.
>
> I think we should push for full automation.  I think it can be 
> done with github (and actually, I think it already 
> automatically records the commit in bugzilla).
>
> The problem I see with making the submitter do it is, the 
> submitter may not be active at the time, or may not care.  The 
> pull request is done, and he has his fix, but we need to make 
> sure the bug list is updated properly.

According to the description of the Bugzilla service hook on 
GitHub, it can automatically close bugs via pull requests, but 
only since version 4.0 of Bugzilla - and the one on d.puremagic 
is only 3.4.1. I have no idea what it takes to upgrade a Bugzilla 
- but the benefit of automatically closing bugs would probably 
justify it.

Another thing - in order for the Bugzilla service hook to work, 
the commit message must refer to it via the syntax "Ticket 123", 
"Bug 123" or "Tracker item 123" - while most commit messages in 
current the pull requests refer to it via the "Issue 123" syntax. 
I think the new review process should enforce proper reference to 
Bugzilla issues.


Anyways, why keep using Bugzilla instead of GitHub issues?