[asterisk-dev] Bugs/patches 16033 and 16590 ignored forever

[Paul Belanger]

I was talking about this on #asterisk-bugs this morning. And asked a
few question:

<pabelanger> Currently it seem we don't have a good method for getting
people involved for testing patches.  Either new features or bug
fixes.  It seems only people _attached_ to the mantis issue really
seem to know the status of that issue.
<pabelanger> We almost need a new method to get people involved with
testing.  IE: asterisk-qa or asterisk-testing.
<pabelanger> I only started thinking about this because of the heat on
#asterisk-dev 2 nights ago.  Somebody was complaining his patches
we're stilling for 7months and not merged into trunk.
<pabelanger> While his approach was WRONG, his logic was correct.
<pabelanger> It seem is actually problem was there was not enough
testing done for his patches to be merged into trunk
<pabelanger> or branch
<pabelanger> And took his frustrations out on developers.

I agree with Leif, lack of resources does seem to be an issue however
I don't believe Digium or #asterisk-dev should handle that
responsibility alone. In my eyes, when something is marked 'Ready for
Testing', the issue falls into the Asterisk community responsibility
to get the required testing done, not #asterisk-dev. Once that testing
has been accomplished, the issue _should_ be able to move forward
(merge).  This did raise the following question:

<pabelanger> What if the process of 'Ready for Testing' and 'Ready for
Review' switch? Wouldn't you want to review somthing and sign off on
it before a testing was completed?
<pabelanger> This way.  When #asterisk-dev signed off on the code
review, we move it to testing and the community takes over.

This raised its own questions about the change in the workflow
process. Which would have to be hashed out.

On Fri, Apr 16, 2010 at 10:10 AM, Leif Madsen
<leif.madsen at asteriskdocs.org> wrote:
> I'm sorry you're frustrated. Unfortunately with the amount of resources we have
> to move issues forward, these particular issues have not made it onto any
> developers plate at the moment.
>
> As you may have noticed, there are over 600 open issues in the Asterisk project
> alone, so we're doing our best to keep up with all the issues filed. I'm
> estimating there are about 5-8 issues filed a day with a mix of minor issues,
> crash issues, feature submissions, and non-issues (configuration problem on the
> part of the reporter).
>
> These issues will get a review and moved forward as soon as time and available
> resources allow.
>
> Thanks for your understanding.
>
> Leif Madsen - Asterisk Bug Marshal
>
> Kirill 'Big K' Katsnelson wrote:
>> I keep bring these up to the attention of the list to no avail for
>> months! This is the last time I am bothered. There are two very real
>> very creepy bugs in asterisk that I submitted patches for, and the
>> patches are sitting there "ready for testing" month after month. Every
>> time I post a message here about these patches I am getting responses
>> like "thanks for reminding us," "how nice you are being persistent,"
>> and... that ends the attention span.
>>
>> If anybody is interested, the patches are:
>>
>> https://issues.asterisk.org/view.php?id=16033
>> [patch] Autocreated peers not deleted when unregister explicitly, become
>> zombies
>> 2009-10-08 07:06 lmadsen Status acknowledged => ready for testing
>>
>> https://issues.asterisk.org/view.php?id=16590
>> [patch] Monitor resumes recording after SIP transfer despite
>> StopMonitor() having been called
>> 2010-01-13 09:19 lmadsen Status new => ready for testing
>>
>> I am dropping these off my monitoring list. If they are gone, they are
>> gone. I will continue to maintain them privately for myself.
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>



-- 
Paul Belanger
Polybeacon | Consultant
Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode)
blog.polybeacon.com