<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:arial, helvetica, sans-serif;font-size:10pt"><DIV style="FONT-SIZE: 10pt; FONT-FAMILY: arial, helvetica, sans-serif">I read the thread again and I would like to apologize for the prediction. The use of the term "most of them" was incorrect. The term "some of them" would have been more fair. </DIV>
<DIV style="FONT-SIZE: 10pt; FONT-FAMILY: arial, helvetica, sans-serif"> </DIV>
<DIV style="FONT-SIZE: 10pt; FONT-FAMILY: arial, helvetica, sans-serif"> </DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">----- Mensagem original ----<BR>De: Russell Bryant <russell@digium.com><BR>Para: trixter@0xdecafbad.com; Commercial and Business-Oriented Asterisk Discussion <asterisk-biz@lists.digium.com><BR>Enviadas: Sexta-feira, 4 de Janeiro de 2008 16:54:18<BR>Assunto: Re: [asterisk-biz] Res: 2008 Predictions<BR><BR>Trixter aka Bret McDanel wrote:<BR>> You never actually countered his argument, there were smoke and mirrors<BR>> to avoid it, but never actually counter it.<BR>> <BR>> Lets review:<BR>> you "guessed" that 1/3 were community patches, this means the other<BR>> percentages are guesses too<BR>> you "processed" issues - that doesnt mean that the patches were applied<BR><BR>It is rare that an issue that contains a patch gets closed without commit of the<BR>actual patch, or a similar patch that provides equivalent
functionality. I<BR>would go as far as to say this is the case for 95% of patch submissions. The<BR>times that issues are closed without commit are cases such as the patch is not<BR>functional and the submitter has not addressed the issues that have been raised.<BR><BR>If you can point out any individual cases where you are not happy with the<BR>outcome, I would be happy to address it individually. Also, I would very much<BR>prefer recent examples. Our handling of bugs.digium.com has come a _long_ way<BR>over the past year.<BR><BR>> Now I dont know if those numbers are accurate or not, I havent actually<BR>> gotten real stats on it. I do know that the assertion made was<BR>> challenged and focus diverted, which makes me personally suspect the<BR>> challenge. Its like the chewbacca defense when you state you disagree<BR>> with something and talk around the issue instead of being direct about<BR>>
it.<BR><BR>I certainly did not mean to divert the focus. I was simply trying to provide<BR>the information on issues handled to the best of my ability. The percentages<BR>are certainly guesses. However, as the person who as closed the 2nd most issues<BR>on bugs.digium.com, behind Mark Spencer, I feel that I have a _very_ good feel<BR>for the mix of things that get posted there. However, I invite others that have<BR>spent a lot of time working on there to post their feelings, as well.<BR><BR>>> that a lot of this type of work isn't very visible, unless you really go looking<BR>>> in the svn commit history,<BR>> <BR>> SVN keeps a revision history, that would have instantly said how many<BR>> commits were performed last year. While it wouldnt be a direct 1:1 for<BR>> the bug tracker, since someone may commit stuff multiple times during<BR>> the course of their work, there may be commits that dont
have an issue<BR>> in the bug system, it would help to justify that there were close to<BR>> 3000 bugs that were resolved. <BR><BR>Sure, I can do that.<BR><BR>For the 1.4 branch, which has a policy of bug-fix only commits, there were 1748<BR>commits in 2007. My guess was ... ( 2960 * (2 / 3) * .95 ) is about 1875.<BR>(Also, keep in mind there may have been issues that only affected Asterisk 1.2<BR>on the bug tracker, as we were fully supporting that for most of the year.)<BR><BR>~/src/asterisk/1.4$ svn log -r 49096:95577 --xml | grep '<logentry' | wc -l<BR>1748<BR><BR>For Asterisk trunk, that includes bug fixes, as well as new features, there were<BR>3345 commits in 2007. So, that is also in line with my claim that processing<BR>almost 3000 issues resulted in commits for most of them. The additional commits<BR>are merging in new features, performance enhancements, or other code cleanups<BR>that did not go through
bugs.digium.com.<BR><BR>~/src/asterisk/trunk$ svn log -r 49092:95578 --xml | grep '<logentry' | wc -l<BR>3345<BR><BR>As you said, while this does not provide an exact correlation to issues closed<BR>on bugs.digium.com, it does provide a pretty good rough picture.<BR><BR>> Now the bug tracking software probably has the ability to sort based on<BR>> date ranges and resolutions so that could probably get better numbers<BR>> for how many (based on the guess 5% of 2/3 of almost 3000 or about 100<BR>> that were closed without commit)<BR><BR>It does have some information. But, unfortunately, the resolution type is not<BR>correctly set for a number of issues. We made a change to mantis at some point<BR>to make sure that we set the resolution properly when closing an issue, but that<BR>was at some point in the middle of the year.<BR><BR>In any case, I made an attempt to get an even closer look.<BR><BR>First I got a CSV export of all
issues that have the following criteria, which<BR>is the best I could do with the data available.<BR><BR>1) Are closed<BR>2) Were last updated in 2007<BR><BR>The number comes out to be a total of 3370 issues. It includes issues that were<BR>closed at some point before 2007, but received some sort of comment in 2007...<BR><BR>Here is the breakdown:<BR><BR>--------------------------------------------<BR><BR>duplicate: 116<BR>fixed: 1918<BR>no change required: 419<BR>not fixable: 49<BR>open: 324<BR>reopened: 27<BR>suspended: 254<BR>unable to reproduce: 122<BR>won't fix: 141<BR><BR>Total: 3370<BR><BR><BR>The ones that were closed with commit:<BR><BR>fixed: 1918<BR><BR>Percent
of total: 56.9 %<BR><BR><BR>The ones closed without commit:<BR><BR>no change required: 419<BR>not fixable: 49<BR>won't fix: 141<BR>unable to reproduce: 122<BR>suspended: 254<BR>duplicate: 116<BR><BR>Percent of total: 32.7 %<BR><BR><BR>The ones with an ambiguous resolution:<BR><BR>open: 324<BR>reopened: 27<BR><BR>Percent of total: 10.4 %<BR><BR>------------------------------------------------<BR><BR>Now, I did some more analysis on the issues closed without commit (minus the<BR>duplicate issues).<BR><BR>Here are some tables of resolution type versus severity, including numbers for<BR>each that indicate how many of these issues actually had a patch associated with<BR>them:<BR><BR>(Determining that an issue had a patch is simply done by seeing if the word<BR>"patch" is in the title. We do a pretty good
job of making sure that [patch] is<BR>in the issue title when a patch is posted. So, it should be accurate enough for<BR>the sake of this discussion ...)<BR><BR>no_change_required ...<BR> "block": 8<BR> -- had patch: 1<BR><BR> "crash": 39<BR> -- had patch: 1<BR><BR> "feature": 34<BR> -- had patch: 7<BR><BR> "major": 130<BR> -- had patch: 3<BR><BR> "minor": 178<BR> -- had patch: 15<BR><BR> "text": 4<BR> -- had patch: 1<BR><BR> "trivial": 10<BR> -- had patch: 2<BR><BR> "tweak": 16<BR> -- had patch: 2<BR><BR>not_fixable ...<BR> "block":
3<BR> -- had patch: 1<BR><BR> "crash": 6<BR> -- had patch: 0<BR><BR> "feature": 1<BR> -- had patch: 0<BR><BR> "major": 14<BR> -- had patch: 0<BR><BR> "minor": 21<BR> -- had patch: 0<BR><BR> "trivial": 1<BR> -- had patch: 0<BR><BR> "tweak": 3<BR> -- had patch: 0<BR><BR>won't_fix ...<BR> "block": 2<BR> -- had patch: 0<BR><BR> "crash": 9<BR> -- had patch: 0<BR><BR> "feature": 36<BR> -- had patch: 12<BR><BR> "major": 29<BR> -- had
patch: 2<BR><BR> "minor": 55<BR> -- had patch: 10<BR><BR> "text": 2<BR> -- had patch: 1<BR><BR> "trivial": 6<BR> -- had patch: 3<BR><BR> "tweak": 2<BR> -- had patch: 0<BR><BR>unable_to_reproduce ...<BR> "block": 5<BR> -- had patch: 0<BR><BR> "crash": 56<BR> -- had patch: 1<BR><BR> "major": 31<BR> -- had patch: 0<BR><BR> "minor": 46<BR> -- had patch: 4<BR><BR> "trivial": 1<BR> -- had patch: 0<BR><BR> "tweak": 1<BR> -- had patch:
0<BR><BR>suspended ...<BR> "block": 7<BR> -- had patch: 0<BR><BR> "crash": 40<BR> -- had patch: 0<BR><BR> "feature": 50<BR> -- had patch: 25<BR><BR> "major": 64<BR> -- had patch: 3<BR><BR> "minor": 77<BR> -- had patch: 14<BR><BR> "text": 3<BR> -- had patch: 1<BR><BR> "trivial": 6<BR> -- had patch: 0<BR><BR> "tweak": 7<BR> -- had patch: 2<BR><BR><BR>Total number of issues that<BR>- were last updated in 2007<BR>- are closed<BR>- had a patch<BR><BR>==> 111, 3.3% of all issues<BR><BR>Total number of issues with a patch: 806<BR> --> Percent
closed without commit, 111 / 806 = 13.8 %<BR><BR><BR>So, by these rough calculations, about 1 in 8 patches don't make it into the<BR>tree for some reason or another. However, I promise you that you do _not_ want<BR>every patch that we get to be merged. Some patches recreate functionality that<BR>is already there. Others are not up to our quality standards. We work very<BR>hard to maintain a consistent architecture with all new things that get added,<BR>and some submissions do not fit that architecture. Again, if anyone has<BR>individual situations they are concerned with, I would be happy to address them<BR>individually.<BR><BR>-----------------------------------------------<BR><BR>> As I do not have information to the contrary but have seen bugs get<BR>> comments in the bug system saying "happy birthday" when they are over a<BR>> year and a patch has been constantly ported forward and ready to go, I<BR>> kinda
lean towards the they dont get committed side.<BR><BR>As I said, and have hopefully demonstrated to some degree, we have come a _long_<BR>way in the past year with our handling of bugs.digium.com. I know that we have<BR>definitely had issues with patch turnaround, but the situation has improved and<BR>will continue to do so. However, I also do not deny that there are still cases<BR>where it takes us longer than I am happy with to handle patch submissions.<BR><BR>However, my main point is that we _are_ committing patches - a _lot_ of patches.<BR>And, even as the project grows and we are getting more and more submissions, we<BR>are growing the development team as best we can to keep up with it.<BR><BR>-- <BR>Russell Bryant<BR>Senior Software Engineer<BR>Open Source Team Lead<BR>Digium, Inc.<BR><BR>_______________________________________________<BR>--Bandwidth and Colocation Provided by <A href="http://www.api-digital.com--/"
target=_blank>http://www.api-digital.com--</A><BR><BR>asterisk-biz mailing list<BR>To UNSUBSCRIBE or update options visit:<BR> <A href="http://lists.digium.com/mailman/listinfo/asterisk-biz" target=_blank>http://lists.digium.com/mailman/listinfo/asterisk-biz</A><BR></DIV>
<DIV style="FONT-SIZE: 10pt; FONT-FAMILY: arial, helvetica, sans-serif"><BR></DIV></div></body></html>