On Fri, Apr 16, 2010 at 12:56 PM, Kirill 'Big K' Katsnelson <span dir="ltr"><<a href="mailto:kkm@adaptiveai.com" target="_blank">kkm@adaptiveai.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>On 100416 0852, Steve Murphy wrote:<br>
> While I can understand your frustration, giving up now would make all you've<br>
> done a total waste of time. You will have to keep updating your patches with<br>
> every release to the end of time. You need to see it thru.<br>
<br>
</div>Right. I will have to maintain the patches to the end of time, and this<br>
is what I already do. But, honestly, I do not see any other choice here.<br>
<div><br>
> First of all, did you go in and test your fixes on 1.4 thru trunk?<br>
<br>
</div>No. We do not have resources here to do that.<br>
<br>
So, just for me to understand, the rule of thumb is that it is better<br>
not to fix anything at all than fix a bug in 1.6 alone, correct?<br>
<div><br>
> Next, did you test your patch in a rigorous manner?<br>
<br>
</div>Define rigorous. The patches have been on a production server for<br>
months. But the usage pattern is narrow indeed.<br>
<div><br>
> Can you prove there will be side effects?<br>
<br>
</div>No. Formal proof of algorithm correctness is a whole another story. I do<br>
not believe, though, that any piece of code in Asterisk has been proved<br>
to be correct. C, as a language, especially unyielding to formal proofs.<br>
<div><br>
> Another tactic is reviewboard. For anything but trivial bug fixes, you might<br>
> post your diffs there, and seek comments on fixes there.<br>
<br>
</div>Advice taken and appreciated, thank you. But we are talking about a<br>
2-line patch here (the second of the 2, which is only 3 months old).<br>
Does not look like it could be posted to the review board without rather<br>
irritating people there, right?<br>
<div><br>
> Next, did you test each release?<br>
<br>
</div>Same as 1.4. Have no resources to test older releases, sorry. Changes<br>
have been production tested in 1.6.1.6, 1.6.1.12, 1.6.1.13, and 1.6.2.4<br>
only.<br>
<div><br>
> And next, find someone with commit privileges and a sympathetic ear, and<br>
> sell them on the patch. Help them, and usually, they will help you.<br>
<br>
</div>Asked about that on the list already. Nobody.<br>
<div><br>
> Lastly, have patience. It could take months, if not a year or two to<br>
> get some stuff coordinated and into a future release. If your mods<br>
> are seen as possibly disruptive to other parts of the codebase, there<br>
> may be concerns or reservations that will need to be addressed. If<br>
> your fix isn't perceived to the be "best" fix for the problem, then<br>
> that could hold things up.<br>
<br>
</div>A discussion would be indeed perfect. Dead silence is not.<br>
<br>
Now, an interesting observation. When I report a bug, it gets fixed by a<br>
developer, I confirm the fix works, and it gets into the 1.6 branches.<br>
Now, If I both report and fix the same bug, it is doomed to sit there<br>
forever. That raises another question -- that is a strong disincentive<br>
for me to send in a patch *even if I have one*. Instead, I should<br>
consider my fix "a temporary hack" and then throw it away when an<br>
"official" fix is implemented by somebody else.<br>
<br>
That seems kind of wrong to me, but then, I am feeling feel like I am<br>
giving an advice when not asked for one.<br>
<div><div></div><div><br>
-kkm<br></div></div></blockquote><div><br>If I am reading this correctly, the patch is only two lines of code, why not go for the low hanging fruit?<br><br>Thanks,<br>Steve Totaro<br></div></div>