Re: [OSGeo-Discuss] Bug report response time
On Thu, Nov 11, 2010 at 1:01 PM, maning sambale wrote: ... > I prefer concrete examples when highlighting bug response time. For > example, during one of our training, a participant noticed a simple > bug in QGIS. I promised to report them to the devs which was fixed in > less than 24 hours. An (impressive) statistics could be how *many* bugs have been resolved in 24-48 hs. As a first pick one could start with that since it is a great advertisement for the Open Source development model. Markus ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Bug report response time
On 12/11/10 08:01, Paolo Cavallini wrote: > Il 11/11/2010 23:12, Mateusz Loskot ha scritto: > >> Statistics is evil. As long as the methodology is right, you can >> proof any bullshit you like, or shoot yourself in your the foot. >> So, I'd be careful. > > Sorry, I do not agree. Statistic is good, if (as anything) you use > the correct method. Using single cases, as you did, is not using > proper statistics. I used simplified example, though well expressing my concern. Imagine each single "proof" is a sample of 1000 cases. Given enough amount of time, I can find it. > If you analyse averages or medians, quartiles and standard > deviations, you get meaningful tests of your hypotheses. I can use the same techniques to calculate the statistics to prove there is a relation between number of bugs reported to GDAL Trac and number of sunspots observed within a period of time. "Statistics is not math", my math teacher used to say. George Cobb "In mathematics, context obscures structure. In data analysis, context provides meaning" David Moore "Mathematical theorems are true; statistical methods are sometimes effective when used with skill" Statistics is bad. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Bug report response time
Il 11/11/2010 23:12, Mateusz Loskot ha scritto: Statistics is evil. As long as the methodology is right, you can proof any bullshit you like, or shoot yourself in your the foot. So, I'd be careful. Sorry, I do not agree. Statistic is good, if (as anything) you use the correct method. Using single cases, as you did, is not using proper statistics. If you analyse averages or medians, quartiles and standard deviations, you get meaningful tests of your hypotheses. All the best. -- http://www.faunalia.it/pc ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Bug report response time
On Thu, Nov 11, 2010 at 10:12:05PM +, Mateusz Loskot wrote: > Hypothesis 0: There is no relation between an open source development of > a project and fast pace of fixing bugs > > Hypothesis 1: There is relation between an open source development of a > project and fast pace of fixing bugs I belive it has to do with how many people actually look at the code and are capable of fixing the bugs they find. Opening the source isn't enough. You need partecipation. You need "freedom", not "open source". << Freedom is neither being on a tree nor the flight of a blowfly freedom is not an empty space freedom is partecipation. >> << La liberta' non e' star sopra un albero non e' neanche il volo di un moscone la liberta' non e' uno spazio libero liberta' e' partecipazione. >> Giorgio Gaber (1973) http://www.youtube.com/watch?v=WYAIgWu_VXI --strk; () Free GIS & Flash consultant/developer /\ http://strk.keybit.net/services.html ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Bug report response time
On 11/11/2010 02:12 PM, Mateusz Loskot wrote: > On 11/11/10 09:43, Sjur Kolberg wrote: >> I am trying to convince people that open source GIS is a better >> solution than buying proprietary software. Such discussions follow a >> well-known path (is it mature/stable? How about support? All our >> clients use ..., Nice for programmers, but...) etc. Conclusions >> precede arguments, and some hard numbers could be of great help in >> all the religion. > > Hypothesis 0: There is no relation between an open source development of > a project and fast pace of fixing bugs > > Hypothesis 1: There is relation between an open source development of a > project and fast pace of fixing bugs > > Accept the hypothesis 0: > > http://news.bbc.co.uk/1/hi/technology/8499859.stm > > Reject the hypothesis 0: > > http://www.osnews.com/story/19731/The-25-Year-Old-UNIX-Bug > > Accept the hypothesis 1: > > http://trac.osgeo.org/gdal/ticket/3810 > > Reject the hypothesis 1: > > http://trac.osgeo.org/gdal/ticket/249 > > What is the conclusion? > > Statistics is evil. As long as the methodology is right, > you can proof any bullshit you like, or shoot yourself in your the foot. > So, I'd be careful. > > > Best regards, Agreed, it might be more important to highlight that the bug database is publicly available. I know with many closed source apps it's hard to know if they've even acknowledged a bug and aren't really forthcoming about if they plan to fix it. I have actually been told, yes that's a bug and no we don't plan to fix it. Thanks, Alex ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Bug report response time
On 11/11/10 09:43, Sjur Kolberg wrote: > I am trying to convince people that open source GIS is a better > solution than buying proprietary software. Such discussions follow a > well-known path (is it mature/stable? How about support? All our > clients use ..., Nice for programmers, but...) etc. Conclusions > precede arguments, and some hard numbers could be of great help in > all the religion. Hypothesis 0: There is no relation between an open source development of a project and fast pace of fixing bugs Hypothesis 1: There is relation between an open source development of a project and fast pace of fixing bugs Accept the hypothesis 0: http://news.bbc.co.uk/1/hi/technology/8499859.stm Reject the hypothesis 0: http://www.osnews.com/story/19731/The-25-Year-Old-UNIX-Bug Accept the hypothesis 1: http://trac.osgeo.org/gdal/ticket/3810 Reject the hypothesis 1: http://trac.osgeo.org/gdal/ticket/249 What is the conclusion? Statistics is evil. As long as the methodology is right, you can proof any bullshit you like, or shoot yourself in your the foot. So, I'd be careful. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Bug report response time
There are projects which have done comprehensive analysis of Open Source metrics. Here is one: http://www.flossmetrics.org/ On 11/11/2010 8:43 PM, Sjur Kolberg wrote: Hello, Is there any mechanism in the bug tracking systems being used, that can export the distribution (histogram or mean) of time taken from a bug report is filed to it is declared successfully closed? I guess I could figure that out manually by reading through all tickets; that is probably not going to happen... I am trying to convince people that open source GIS is a better solution than buying proprietary software. Such discussions follow a well-known path (is it mature/stable? How about support? All our clients use ..., Nice for programmers, but...) etc. Conclusions precede arguments, and some hard numbers could be of great help in all the religion. Best regards, Sjur K :-) ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss -- Cameron Shorter Geospatial Solutions Manager Tel: +61 (0)2 8570 5050 Mob: +61 (0)419 142 254 Think Globally, Fix Locally Geospatial Solutions enhanced with Open Standards and Open Source http://www.lisasoft.com ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Bug report response time
IMO, listing bugs vis-a-vis response time can be counter-productive. Generally, we have more bugs than being squashed because a lot of people are reporting them (which is a good thing btw). I prefer concrete examples when highlighting bug response time. For example, during one of our training, a participant noticed a simple bug in QGIS. I promised to report them to the devs which was fixed in less than 24 hours. Come next training, I shared the incident to other participants. With an encouragement that if they can find some bug during the workshop, we will then report it to the devs this way they already contributed to the open source community. Works for me. On Thu, Nov 11, 2010 at 6:49 PM, Jody Garnett wrote: > Just to put myself on the line ... > > For GeoTools the bug tracker is here: > - http://jira.codehaus.org/browse/GEOT > > The initial page shows the current open vs close rate. > > If you click on "Reports" you can get a "resolution time" report; you > will need to sign in first. > > Jody > > On Thu, Nov 11, 2010 at 8:47 PM, Jody Garnett wrote: >> You can often export the bug database out into excel for analysis. You >> may need to play with the results to focus on problem reporting. >> >> Why? Often open source projects end up with "wish list" bugs that do >> not fall within anyone's funding or mandate. >> >> Personally I would love to see the difference not between open source >> and proprietary software - as I think that sells us short (we are more >> amazing than that!). >> >> The true test would be the track record for paying customers - getting >> a bug fixed with an open source product vs a proprietary product. >> Since a common open source model is to pay for support; it would be >> great to show the amazing service provided. >> >> Now that *would* be an impressive difference. >> >> Jody >> >> On Thu, Nov 11, 2010 at 7:43 PM, Sjur Kolberg >> wrote: >>> Hello, >>> >>> Is there any mechanism in the bug tracking systems being used, that can >>> export the distribution (histogram or mean) of time taken from a bug report >>> is filed to it is declared successfully closed? >>> >>> I guess I could figure that out manually by reading through all tickets; >>> that is probably not going to happen... >>> >>> >>> >>> I am trying to convince people that open source GIS is a better solution >>> than buying proprietary software. Such discussions follow a well-known path >>> (is it mature/stable? How about support? All our clients use ..., Nice >>> for programmers, but...) etc. Conclusions precede arguments, and some hard >>> numbers could be of great help in all the religion. >>> >>> >>> >>> Best regards, >>> >>> Sjur K :-) >>> >>> >>> >>> ___ >>> Discuss mailing list >>> Discuss@lists.osgeo.org >>> http://lists.osgeo.org/mailman/listinfo/discuss >>> >>> >> > ___ > Discuss mailing list > Discuss@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/discuss > -- cheers, maning -- "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Bug report response time
Just to put myself on the line ... For GeoTools the bug tracker is here: - http://jira.codehaus.org/browse/GEOT The initial page shows the current open vs close rate. If you click on "Reports" you can get a "resolution time" report; you will need to sign in first. Jody On Thu, Nov 11, 2010 at 8:47 PM, Jody Garnett wrote: > You can often export the bug database out into excel for analysis. You > may need to play with the results to focus on problem reporting. > > Why? Often open source projects end up with "wish list" bugs that do > not fall within anyone's funding or mandate. > > Personally I would love to see the difference not between open source > and proprietary software - as I think that sells us short (we are more > amazing than that!). > > The true test would be the track record for paying customers - getting > a bug fixed with an open source product vs a proprietary product. > Since a common open source model is to pay for support; it would be > great to show the amazing service provided. > > Now that *would* be an impressive difference. > > Jody > > On Thu, Nov 11, 2010 at 7:43 PM, Sjur Kolberg > wrote: >> Hello, >> >> Is there any mechanism in the bug tracking systems being used, that can >> export the distribution (histogram or mean) of time taken from a bug report >> is filed to it is declared successfully closed? >> >> I guess I could figure that out manually by reading through all tickets; >> that is probably not going to happen... >> >> >> >> I am trying to convince people that open source GIS is a better solution >> than buying proprietary software. Such discussions follow a well-known path >> (is it mature/stable? How about support? All our clients use ..., Nice >> for programmers, but...) etc. Conclusions precede arguments, and some hard >> numbers could be of great help in all the religion. >> >> >> >> Best regards, >> >> Sjur K :-) >> >> >> >> ___ >> Discuss mailing list >> Discuss@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/discuss >> >> > ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Bug report response time
You can often export the bug database out into excel for analysis. You may need to play with the results to focus on problem reporting. Why? Often open source projects end up with "wish list" bugs that do not fall within anyone's funding or mandate. Personally I would love to see the difference not between open source and proprietary software - as I think that sells us short (we are more amazing than that!). The true test would be the track record for paying customers - getting a bug fixed with an open source product vs a proprietary product. Since a common open source model is to pay for support; it would be great to show the amazing service provided. Now that *would* be an impressive difference. Jody On Thu, Nov 11, 2010 at 7:43 PM, Sjur Kolberg wrote: > Hello, > > Is there any mechanism in the bug tracking systems being used, that can > export the distribution (histogram or mean) of time taken from a bug report > is filed to it is declared successfully closed? > > I guess I could figure that out manually by reading through all tickets; > that is probably not going to happen... > > > > I am trying to convince people that open source GIS is a better solution > than buying proprietary software. Such discussions follow a well-known path > (is it mature/stable? How about support? All our clients use ..., Nice > for programmers, but...) etc. Conclusions precede arguments, and some hard > numbers could be of great help in all the religion. > > > > Best regards, > > Sjur K :-) > > > > ___ > Discuss mailing list > Discuss@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/discuss > > ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
[OSGeo-Discuss] Bug report response time
Hello, Is there any mechanism in the bug tracking systems being used, that can export the distribution (histogram or mean) of time taken from a bug report is filed to it is declared successfully closed? I guess I could figure that out manually by reading through all tickets; that is probably not going to happen... I am trying to convince people that open source GIS is a better solution than buying proprietary software. Such discussions follow a well-known path (is it mature/stable? How about support? All our clients use ..., Nice for programmers, but...) etc. Conclusions precede arguments, and some hard numbers could be of great help in all the religion. Best regards, Sjur K :-) ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
