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

[Johansson Olle E]

11 aug 2008 kl. 23.43 skrev Steve Murphy:

> On Mon, 2008-08-11 at 16:47 -0400, Jay R. Ashworth wrote:
>> On Sun, Aug 10, 2008 at 10:47:25PM -0500, Tilghman Lesher wrote:
>>> On Monday 11 August 2008 09:07:26 Leif Madsen 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.
>>>>
>>>>      b) FEATURE: As new features should be filed with a patch, it  
>>>> can
>>>> be immediately moved to the 'confirmed' status, making it ready for
>>>> basic formatting and code review. From there any changes to style  
>>>> or
>>>> feel of the patch based on feedback from the community can be  
>>>> discussed,
>>>> and changes to the patch made. It can then be moved forward to the
>>>> 'ready for testing' status. Once the feature has been merged, or a
>>>> decision has been made that it will not be merged, the issue  
>>>> should be
>>>> taken to 'closed' with the appropriate resolution.[Note2]
>>>
>>> I'd like to note that the statuses as noted here are in fact the  
>>> reverse of
>>> the previous policy, and I'd like to suggest that we continue the  
>>> previous
>>> policy, that features are acknowledged and bugs are confirmed.
>>
>> +1
>>
>> How, precisely, could you "confirm" a feature request?  You *can*, on
>> the other hand, confirm that something is a bug: not everything is a
>> bug.   If it's documented, then it's either a feature request to
>> *change* the behavior, or merely a complaint that won't accomplish
>> anything.
>
> I suppose that if a patch actually not only solves a problem or  
> provides
> functionality in a way compatible with the system as a whole (few
> actually
> do!), then it's 'confirmed', maybe?
>
> Enhancement providers often have great ideas, but their provided  
> patches
> are often sub-standard. They don't cover all the cases, use interfaces
> in the wrong ways, etc.
>
> So, it's not uncommon for several reviews of new contributed code to  
> be
> made,
> with suggestions for improvement to be made. (Sometimes we just do it
> ourselves on behalf of the submitter). After going the rounds, we  
> could
> mark it as 'Confirmed'. It may have to wait a while for merging, as we
> are trying to not put a boatload of changes in a single new release.

And it may be moved to a feature request - classifying the patch
as experimental code that shows a new cool feature that we want,
but the code can't possibly be merged in the current state.

/O
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2207 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20080812/241acb95/attachment.bin