[asterisk-dev] [policy] Bug Tracker Workflow Discussion

[Leif Madsen]

Russell Bryant wrote:
>> 3) The next step is to determine whether the report is about a bug or a 
>> submission of a new feature:
>>
>>       a) BUG: A bug should be moved into the status 'acknowledged'. The 
>> bug may also be assigned to a developer for the creation of the initial 
>> patch, or review of the issue. Once a patch has been created for the 
>> issue and attached, the issue can then be moved to the 'confirmed' 
>> status. At this point initial code review and discussion about the patch 
>> will take place. Once an adequate amount of support for the 
>> implementation of the patch is acquired, then the bug can be moved to 
>> the 'ready for testing' status for wider testing by the community. After 
>> the testing phase is complete and it appears the issue is resolved, the 
>> patch can be committed by a developer and closed.
> 
> This sounds good, as long as it is understood that this is the "full" 
> workflow.  For example, if I see a bug in "acknowledged" that I know the 
> exact fix for, I would just commit it and close the issue immediately. 
> I'd rather not force myself to go through these other steps unless we 
> feel it is necessary.  For code written by commiters, it's generally 
> easier to go with post-commit peer-review of the patch.

I will make a note of that. You are right, it should be unnecessary to 
follow the entire work flow if it is not needed. This is the workflow 
that would be followed all the way through should it be necessary.

>> 4) If at any point in the workflow, an issue requires feedback from the 
>> original poster of the issue, the status should be changed to 
>> 'feedback'.  Once the required information has been provided, it should 
>> be placed back in the appropriate point of the workflow.
> 
> I really wish we had a way so that the reporter could move it out of 
> feedback, but we'll have to put this on our mantis wish-list, I guess. 
> It may be worth noting that reviewing issues in feedback for updates is 
> another part of the bug marshal team duties.

Will make a note of that.


>> PENDING RELEASE BRANCH: This status is no longer used. It is a relic of 
>> the Asterisk 1.2 days.
> 
> These sound good.

Sexy party status?!

>> 2) The bug tracker now has the ability to monitor the commits list, and 
>> if the commit message contains something like, "closes issue 9999", the 
>> bug will be automatically closed.
> 
> To close an issue, it _must_ be "closes issue #9999".  Note the missing 
> #.  Otherwise, to just have the commit noted in the issue, you can say 
> "issue #9999", or just "#9999".  (Some other patterns are matched, but 
> we can leave the guide at that for simplicity.)

Ah gotcha. Thanks for catching that. I have made the update!

>> RELEASE BRANCH COMMIT POLICY
>>
>> The code in the release branches should be changed as little as 
>> possible.  The only time the release branches will be changed is to fix 
>> a bug.  New features will never be included in the release branch unless 
>> a special exception is made by the release branch maintainers.
>>
>> Sometimes it is difficult to determine whether a patch is considered to 
>> fix a bug or if it is a new feature.  Patches that are considered code 
>> cleanup, or to improve performance, are NOT to be included in the 
>> release branches.  Performance issues will only be considered for the 
>> release branch if they are considered significant, and should be 
>> approved by the maintainers.
>>
>> If there is ever a question about what should be included in the release 
>> branch, the maintainers should be allowed to make the decision.
> 
> Two things here.  First, please change "RELEASE BRANCH COMMIT POLICY" to 
> "1.4 RELEASE BRANCH COMMIT POLICY".  Asterisk 1.6 is managed 
> differently.  Also, you can either replace "maintainers" with my name, 
> or just note that currently, the person to contact is me.

Done and done.

> I'll take it on as my action item to create a separate document that 
> describes the current state of all Asterisk releases, their maintenance 
> levels, and the commit policies associated with them.  It's something we 
> have needed for a while, anyway.

Thanks for doing that Russell! Let me know if you need a review.


-- 
Leif Madsen
http://www.leifmadsen.com
http://www.oreilly.com/catalog/asterisk