Re: [OSGeo-Discuss] Greek Inspire Metadata Editor (gimed)
On Tue, Nov 09, 2010 at 04:48:38PM -0800, Alex Mandel wrote: Noted case, how many years it took Flash to really be usable without crazy hacks on linux. Flash is still not usable without crazy hacks if you don't want non-free software on your computer. Free software programmers should pay attention about that. An example of care deficiency is potlatch2/osm [1] dropping support for Gnash [2] [1] http://gnashdev.org/?q=node/72 [2] http://www.gnu.org/software/gnash --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
[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
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 sjur.a.kolb...@sintef.no 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
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 jody.garn...@gmail.com 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 sjur.a.kolb...@sintef.no 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
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 jody.garn...@gmail.com 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 jody.garn...@gmail.com 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 sjur.a.kolb...@sintef.no 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
[OSGeo-Discuss] ESRI-OSS: just FYI
Hi, Exploring SourceForge I have found: http://sourceforge.net/apps/mediawiki/geoportal/index.php?title=Main_Page Is it a proof for the strong impact of FOSS community on proprietary software providers? Tomasz Kubik ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] ESRI-OSS: just FYI
As many people have said already, it seems to be pure marketing. As Cedric Moullet said on Twitter [1]: ArcGIS Server Geoportal goes OpenSource. Just a joke, ArcGis Server is required... it's again a marketing campaign useless for SDI ! As Jeroen Ticheler said on Twitter [2]: Pure coincidence? ESRI Geoportal toolkit = open source INSPIRE GeoPortal requirement = open source. Don't forget to OSS the backend ;) [1] https://twitter.com/cedricmoullet [2] https://twitter.com/ticheler Best regards, Bart Hi, Exploring SourceForge I have found: http://sourceforge.net/apps/mediawiki/geoportal/index.php?title=Main_Page Is it a proof for the strong impact of FOSS community on proprietary software providers? Tomasz Kubik ___ 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
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 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
