<br><br><div class="gmail_quote">On Tue, Apr 20, 2010 at 6:48 AM, Leif Madsen <span dir="ltr"><<a href="mailto:leif.madsen@asteriskdocs.org">leif.madsen@asteriskdocs.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">Kirill 'Big K' Katsnelson wrote:<br>
</div><div class="im">> Your explanation is indeed sensible, but there are different resource<br>
> pools involved in debugging/fixing the problem, and in testing the fix.<br>
> If I report a bug without sending in a fix, there is a chance that it<br>
> will be fixed by a developer. Then I confirm the fix, and it is good to<br>
> go. On the other hand, when I fix the problem by myself, there is no one<br>
> out there to try the fix, and, therefore, assuming rare enough a<br>
> problem, the fix will unlikely be confirmed and committed. There are<br>
> just many more developers willing to fix the bug that does not affect<br>
> them personally that testers willing to test a fix to a bug that does<br>
> not affect them personally.<br>
><br>
> Such a disposition looks quite paradoxical to me.<br>
<br>
</div>I don't quite see it that way though. From the viewpoint of the Digium developer<br>
resource pool, issues that have patches actually get rated higher on the list of<br>
issues to be resolved because the engineering effort to resolve such an issue is<br>
(typically) much lower. With a patch that resolves the issue for the reporter,<br>
the developer is that much further ahead than if they just had debugging<br>
information. With the patch, the developer knows the exact area of code to start<br>
working in, and can potentially reproduce the issue more quickly.<br>
<br>
Sometimes it just requires a code review because the issue is that much more<br>
transparent when a patch is provided.<br>
<br>
Of course if the issue does not affect a large number of users, then it may be<br>
possible an issue could sit for a long time even with a patch. But as Kevin<br>
states, there are open source developers who hang out in #asterisk-dev who may<br>
be willing to move an issue forward, and if a patch is provided, it certainly<br>
makes it easier for them to do that.<br>
<br>
I guess what I'm saying is don't stop submitting issues and providing patches<br>
with the thought that issues without patches get worked on first, because that<br>
is certainly not the case. In some cases they do, but it generally is because<br>
they affect a large(r) pool of users.<br>
<div class="im"><br>
> (I know -- I have already be advised to find a sympathetic soul or pay<br>
> someone for testing -- but that does not resolve the paradox: I do not<br>
> have to do all that If I do not send in a patch).<br>
><br>
> I think that Paul Belanger describes essentially the same problem, but<br>
> from a different vantage point.<br>
<br>
</div>I'm not sure how to resolve the paradox you're speaking of. I'm not even sure I<br>
agree a paradox exists. Separate pools of resources do not exist for testing and<br>
development.<br>
<br>
The Digium development team does both testing and development, along with code<br>
review and committing. We don't have separate testing teams outside of the<br>
development group for each of those tasks. Each issue that is assigned to a<br>
developer is taken through all steps of the process (reproducing the issue,<br>
resolving the issue, and closing the issue).<br>
<br>
All that can be done is to pick the issues that affect the most number of people<br>
and work on larger issues (i.e. many development hours that otherwise might not<br>
be done by the community because development of Asterisk is not their primary<br>
responsibility). And with the knowledge that not every issue can be resolved by<br>
this pool alone, it is up to the community to determine what other issues are<br>
most important to them to resolve.<br>
<br>
Now with that said, if you have a particular issue that isn't overly large that<br>
you need a code review done on to move it forward, Kevin mentioned that several<br>
developers hang out in #asterisk-dev on <a href="http://irc.freenode.net" target="_blank">irc.freenode.net</a> that may be able to<br>
move the issue forward. Beyond that, I'm all ears for how we can continue to<br>
refine the process to move issues forward at a more efficient pace with the<br>
available resources.<br>
<font color="#888888"><br>
Leif Madsen -- Bug Marshal<br>
</font><div><div></div><br></div></blockquote></div><br>I offer the solution to all such paradoxes. This may sound pretty mercenary, but<br>time and money and fixes to Asterisk are all highly intermingled....<br><br>I have the necessary qualifications to test patches, to interpret them from one<br>
release to the next, to merge them into trunk, to make sure there are no side<br>affects. If you don't have a patch, I can even come up with one for you.<br>I have commit privileges to the source, I am familiar with the system,<br>
and can handle bugs (and I've closed a lot of them), at least, until I mess up, <br>or abuse the system, and I don't plan on doing such. <br><br>For a price, I can represent both an individual and the asterisk community <br>
at the same time. If indeed the patch does have no side-effects, this might be done in just<br>a few hours. I charge a standard rate per hour that is less than, or comparable to<br>what plumbers, machinists, and so forth require. Others would require less, others<br>
more. I am a, if not THE :), gun-for-hire for the minority, for the ignored, for the outcast, the downtrodden,<br>the oppressed. <br><br>If you have a just cause, and are correct in your patch, I can join you in your cause. <br>
<br>If you don't, I'll tell you so. <br><br>Hire me. Make life easier. I am your average Asterisk Consultant. I'd normally <br>restrict this kind of talk to asterisk-biz, but it is just crying to be said here!<br>
<br>murf<br><br>-- <br>Steve Murphy<br>ParseTree Corp<br><br>