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

[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.

murf

> Cheers,
> -- jra
-- 
Steve Murphy
Software Developer
Digium
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3227 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20080811/e4e3604e/attachment.bin