[asterisk-dev] The fate of 16033

[Leif Madsen]

Olle E. Johansson wrote:
> 17 feb 2010 kl. 15.16 skrev Russell Bryant:
> 
>> With that level of activity, it's not surprising that we fall behind on 
>> some of the issues.  I'm not happy about it, but I don't think it's a 
>> process or policy problem.  I think it's primarily a resource issue.
> Agreed.
> 
>> If anyone is looking for ways to help out with our issue tracker, please 
>> talk to Leif Madsen (lmadsen at digium.com).  :-)
> 
> Please do that - we need more people that act as a bug tracker "reception", not solving issues or coding or anything - just making sure that all the data is in the report and that the reporter gets some kind of human confirmation, not just a flag moved to something else. Acting as a filter so that developers get complete bug reports not the  "this Asterisk thingy doesn't work, I can't call my mom" type of reports or configuration questions. You help us focus and you learn a lot. I did this myself for a long time and accidentally learned stuff that ended up being part of dCAP...

I don't think we do need anything additional in terms of the reception of 
issues. I look at every single issue that is submitted (i.e. I move all issues 
from New to something appropriate). Sometimes they get closed, sometimes they 
are moved to Acknowledged, sometimes Ready for Testing (if there is a patch 
submitted that appears to resolve the issue, especially if the reporters states 
are much, or its a new feature), and sometimes I set them to Feedback when I 
need to request more information (i.e. a bug that was submitted with very little 
information, or not enough information to determine how to move the issue forward).

I also monitor all the issues I touch (i.e. all of them) via my email. Whenever 
an issue that I touched gets an update, then I get an email. So in this way 
issues get moved out of Feedback to something appropriate when information is 
gathered.

What we REALLY need is for people to actually test issues in Ready for Testing 
and to report back issues they have, or to say, "Works for me!". There is a lot 
of triage to do, but honestly, I'm able to handle all of it. We're probably 
averaging somewhere around 10-20 new issues a day. Some of those get closed, 
some get moved to Acknowledged, etc...

> If you have time and want to join the project more actively, this is a perfect entry point. As a bug marshal, you have the unique right to bug any developer and ask questions in ways no one else can :-)

As a bug marshal, you have the rights to look at the bug tracker and to help 
move issues forward. That includes reproducing issues on newer versions to 
verify an issue still exists; providing additional information that may be not 
available from the original poster; testing an issue (feature or bug) and 
reporting back your experiences with it.

These are the things you get to do as a bug marshal such as reading through 
issues in feedback and determining if something can move forward, or be changed 
to a different status. You can update titles and descriptions to be more 
accurate, or you can make sure the issue is filed into the right category.

As a bug marshal you do not get to bug a developer, or request higher priority 
for your issues. You don't get any advanced rights or access to developers than 
the general community. I'm sure you were joking, but it must be stated that bug 
marshals do not get any preferential treatment. The developers you are able to 
contribute do a lot of work already.

However, if you would like to help out with the bug tracker, feel free to get 
involved in the #asterisk-bugs channel on the Freenode IRC network and hit me up 
(I'm usually listed as 'leifmadsen'). If you notice something wrong in an issue, 
just let me know and I'll get it fixed up. After a bit of time and going through 
helping you with our (my :)) current strategy with keeping the issue tracker up 
to date, then we could up your privilege in the issue tracker so you can modify 
issues on your own.

If you're interested in helping, here are a couple of things to keep in mind:

1) please keep your issues up to date and be sure to supply as much information 
that you can about how to reproduce an issue. If you have a crash, please be 
sure to attach a backtrace per the doc/backtrace.txt file in your Asterisk source.

2) If you have an issue related to SIP at all, you must file a SIP trace, with 
SIP history enabled (via sip.conf) and debug level console logging (logger.conf 
with debug level logging) and 'core set verbose 10' and "core set debug 10' 
enabled. Attach these files as a text file attachment.

3) Do not copy and paste large blocks of text into issues you file -- please 
attach these as text file (and not compressed files). If it's too big, then you 
likely have too much information, or it needs to be broken up into smaller files.

4) If a developer has been assigned to your issue, please do your best to reply 
as quickly as possible.

5) Do not file issues as "block" -- this is a special indication used by bug 
marshals to help track issues that may be potential blockers for the next release.

6) If you're filing an issue, please be sure to test on the latest branch. 
Asterisk development moves at a rapid pace, and testing on the latest available 
changes ensures time is not wasted trying to reproduce or determine if an issue 
has already been fixed.

7) Test issues in the Ready for Testing state! We have a lot of very cool 
features and additions that can be tested to help move them forward. 
Additionally, many bug fixes can be found in the Ready for Testing state as 
well, and if you're able to reproduce an issue, then apply a patch and the issue 
goes away (as is intentioned by the reporter or developer of the patch), then 
that helps to determine if the issue is resolved in multiple environments.

I think that's all I have for now :)  If you're interested in getting involved, 
then please join us in #asterisk-bugs and we'll find something for you to do :)

Thanks!
Leif Madsen.