Re: [Qgis-developer] QGIS 2 64bits, is it stable ?
I think if a case be made that x amount of money would put 3 full time positions for the project ( I would suggest mainly squash bugs) people might actually contribute. -- View this message in context: http://osgeo-org.1560.x6.nabble.com/QGIS-2-64bits-is-it-stable-tp5081507p5088791.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS 2 64bits, is it stable ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 03/10/2013 21:19, Vincent Picavet ha scritto: And another +1. It's time to focus on code quality to reduce bugs and sure, we all agree on this. maintainance costs, for which it is always difficult to find funding. We need more unit test, more code quality dashboards and much stricter rules relative to what code has to be accepted into master. I think this is a matter of balance: a large part of QGIS success is due to the huge number of new functions and developers that keep on coming. Setting up to srtict rules will dry up our main source. A PostgreSQL-like code inclusion workflow, with commitfest and review, could be something interested, to be discussed. IMHO a desktop program is a totally different beast from a server one. Unit testing for atomic functions is relatively easy, it can be a nightmare when you have very complex user interactions. IMHO our main problem is sheer lack of resources: to work properly, we would need at least 3 full time, paid persons: * one for bugfixing and patch reviewing * one for QA and unit testing * one for infrastructure. With 1M+ users, many local and central governments relying on our code, this seems a reasonable requirement/goal. Until we have this, I'm afraid all the rest will be largely speculative. On the funding side, for information, public administrations, at least in france, cannot pay for a time based contract. Estimating how much time a bug fix could take is a really hard task (except if you fixed the bug already). This is a problem both for company willing to fix bug for paid contracts and for public administrations wanting to finance bugs, and can explain the funding situation related to maintainance and bugfixing. Yes, this is a crucial problem: I'm sure many people would be happy to pay for their most annoying bug, if they knew how much would this cost, but as you described, estimating the cost is about the same as fixing it. We (Faunalia) solve this by proposing support contracts, with a fixed number of hours for bugfixing, that can be used on demand. Possibly not the ideal solution, but it works, both from a technical and from an administrative point of view. All the best. - -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlJOXT0ACgkQ/NedwLUzIr76jQCdG9hWip28xvjnJlfqSJEirn2c bUIAoJvBsUP4unmfJnvEkc8PHYrJMGqY =Bj3n -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS 2 64bits, is it stable ?
maintainance costs, for which it is always difficult to find funding. We need more unit test, more code quality dashboards and much stricter rules relative to what code has to be accepted into master. I think this is a matter of balance: a large part of QGIS success is due to the huge number of new functions and developers that keep on coming. Setting up to srtict rules will dry up our main source. I have to respectfully disagree with the premise behind this. I'm sure ease-of-committing has facilitated much of the development, but at a certain point in a popular project's life it should become mature - unit tests, code reviews, etc. This will make it harder to commit that cool new tool that someone hacked up over the weekend, but you know that when it is committed and approved, it is a lot less likely to break something else. Yes QGIS is almost undoubtedly the most popular FOSS GIS on the planet, but it will struggle to maintain that reputation if lots of users start encountering regressions and bugs and crashes. A PostgreSQL-like code inclusion workflow, with commitfest and review, could be something interested, to be discussed. IMHO a desktop program is a totally different beast from a server one. Unit testing for atomic functions is relatively easy, it can be a nightmare when you have very complex user interactions. Maybe the question should be - how do other successful Open Source desktop applications do it? Could QGIS not find some other projects that release regular relatively bug-free builds and ask them what their process is? QGIS isn't the first project to encounter these problems; it can learn from others. I don't know the answers which is why I'm posing them as questions - but maybe someone else does. Cheers, Jonathan -- This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS 2 64bits, is it stable ?
I think we have to be fair with the current state of the project in this discussion. The stability of the current release is heavily influenced by increasing the major version number. What I mean with this is, that because for the next release only the minor number will increase, I expect it to be to be more stable and not less. Regardless of testing. I'm by no means opposed to testing. I would like to encourage everybody to write test-cases. But, recently it appears to me, that testing is proposed as cure to all evil, which I don't believe. It can surely help to get feedback about broken functionality fast, but in the end it is also additional effort to implement these tests and keep them up to date. Let me quote Martin Grässlin I rather use a working system without unit tests than a system with unit tests that doesn’t work [1]. So right now, I think it is important to fix bugs. If somebody pays a developer to fix a bug, please feel free to include a regression-test in this contract. It will be appreciated. But even more important: Please DO consider hiring a developer to fix bugs at all. Matthias [1] http://blog.martin-graesslin.com/blog/2013/05/mir-in-kubuntu/ On Fre 04 Okt 2013 12:01:53 CEST, Jonathan Moules wrote: maintainance costs, for which it is always difficult to find funding. We need more unit test, more code quality dashboards and much stricter rules relative to what code has to be accepted into master. I think this is a matter of balance: a large part of QGIS success is due to the huge number of new functions and developers that keep on coming. Setting up to srtict rules will dry up our main source. I have to respectfully disagree with the premise behind this. I'm sure ease-of-committing has facilitated much of the development, but at a certain point in a popular project's life it should become mature - unit tests, code reviews, etc. This will make it harder to commit that cool new tool that someone hacked up over the weekend, but you know that when it is committed and approved, it is a lot less likely to break something else. Yes QGIS is almost undoubtedly the most popular FOSS GIS on the planet, but it will struggle to maintain that reputation if lots of users start encountering regressions and bugs and crashes. A PostgreSQL-like code inclusion workflow, with commitfest and review, could be something interested, to be discussed. IMHO a desktop program is a totally different beast from a server one. Unit testing for atomic functions is relatively easy, it can be a nightmare when you have very complex user interactions. Maybe the question should be - how do other successful Open Source desktop applications do it? Could QGIS not find some other projects that release regular relatively bug-free builds and ask them what their process is? QGIS isn't the first project to encounter these problems; it can learn from others. I don't know the answers which is why I'm posing them as questions - but maybe someone else does. Cheers, Jonathan This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS 2 64bits, is it stable ?
The stability of the current release is heavily influenced by increasing the major version number. What I mean with this is, that because for the next release only the minor number will increase, I expect it to be to be more stable and not less. Regardless of testing. Agreed, the new features should be expected to have bugs in, but with a proper testing regime the regressions should be fewer as they'd get picked up and the commit wouldn't/shouldn't be accepted until they're fixed. You're right it won't cure everything, but it would mitigate a good chunk of one subset of bug type. Let me quote Martin Grässlin I rather use a working system without unit tests than a system with unit tests that doesn’t work It sounds good, but it's a false dichotomy - why can't you have both? Regards, Jonathan -- This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS 2 64bits, is it stable ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 04/10/2013 13:52, Jonathan Moules ha scritto: It sounds good, but it's a false dichotomy - why can't you have both? because of limited resources. if all the 1.000.000+ users of QGIS would invest 1 euro per year in it, this would be quite feasible. All the best. - -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlJOrfgACgkQ/NedwLUzIr7TxwCgp+2yEzKArmjW/rz0B6jaTtFO /0cAoJ9Q3qZXVZjLQJ0C0R45fncPgmnu =cIGS -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS 2 64bits, is it stable ?
It sounds good, but it's a false dichotomy - why can't you have both? because of limited resources. if all the 1.000.000+ users of QGIS would invest 1 euro per year in it, this would be quite feasible. All the best. True, but that's back to my comment previously about what other projects do - there's bound to be OS software out there that also has very limited resources (most aren't supported by RedHat or IBM) yet manage a more rigorous testing regime. What could be learnt from them? Staying within the very-niche GIS world I know the GeoServer devs also complain about limited resources (it appears to have far fewer committers than QGIS), yet they have a unit-test requirement for all patches/commits and regular bugfix releases. I know it's not like-for-like, but it's indicative of what might be accomplished. Kind regards, Jonathan -- This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS 2 64bits, is it stable ?
Hi, I must say my opinion is somewhere between Jonathan's and Paolo's. QGIS is getting fast with new feature, and this is needed to stick and go beyond to proprietary softs. QGIS is the only one with such mapping and redering capabilities, but it still lacks some critical basic features (proportionnal object legend, totally solid joins, relates, label callouts.. ) . So, we need to still be opened to new features. In the same time, regressions do cost ressources also, both for developpers and users. What about starting the infrastructure for unit test and commit validation and testing it now? I must say I could be very interested in a commercial support for this, if this is sticking to community version and not a separate branch. The only offer I saw was Sourcepole, in Switzerland, so out of Europe market rules (yes), maybe I missed some others. Régis -- View this message in context: http://osgeo-org.1560.x6.nabble.com/QGIS-2-64bits-is-it-stable-tp5081507p5081821.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS 2 64bits, is it stable ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 04/10/2013 14:33, Régis Haubourg ha scritto: What about starting the infrastructure for unit test and commit validation and testing it now? AFAIK the infrastructure is already in place and running. I must say I could be very interested in a commercial support for this, if this is sticking to community version and not a separate branch. If you set up a list of requirements, I'm sure there will be people willing to undertake the task. All the best. - -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlJOznkACgkQ/NedwLUzIr42zQCeIc6J7bI4mHrPDWo+5vpocZ/5 qSUAoJPdkovMjnlxCwUTqIYLeWL9sM3m =KV8V -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS 2 64bits, is it stable ?
Hi René-Luc, hi all, I don't know about these specific problems, but I can well imagine, that there are some flaws hidden in all the new features introduced, since 2.0 marks a huge step forward in terms of functionality. Recently there has been a discussion around the topic of managing a stable release with different opinions and plans from different parties. As already said, I think that 2.0 marks a big step forward. All this would not have been possible without a lot of time invested by various people, some of it on a contract basis and some on a voluntary basis. I have myself been spending countless unpaid hours on fixing bugs because I wanted to make this release awesome (Just to be clear, it was fun, I don't want to complain!) I think the developers have (once more) shown, that they are able to produce a professional product. However, at the current stage, I think it would be very good, to have a sponsored bug-squashing effort, just like we had to have Jürgen work on getting rid of blockers before the release. I think we should promote targeted donations to get rid of the most annoying issues. I'm sure there are companies out there which save a lot on licenses. It would be a good time to reinvest part of this money into the project. Kind regards, Matthias On Mit 02 Okt 2013 19:01:06 CEST, rldhont wrote: Hi all, Some french users downloading the windows standalone 64bits version and they encounter bugs considered as blockers : * IGNF:LAMBE -- not reprojecting https://hub.qgis.org/issues/7941 * Interpolation crash * not conserving EPSG:900913 and not transform to EPSG:3857 for old project * no GRASS plugin * 'The selected color palette is not available' on windows7 I don't know if its just for 64bits version, but some users thought that *QGIS 2.0.1 is not stable enough* to be used in production. They are waiting for a bugfix release. Regards, René-Luc D'Hont 3Liz ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS 2 64bits, is it stable ?
Hi Matthias. agreed. How to fund, this is the question. I have budget (at least at the moment). I haven't been able to spend it completly in 2.0 release sprint because all goes too fast for classical contract, where I'm constrained to pay for a specific work (debug or feature). Please be warned to public finances are not good in europe, and every unconsumed budget can be erased. Sponsoring should be a way to finance infrastructure consolidation, but in current rules, sponsoring can't be oriented. I need help from the community to have a serious real use case unit test suite. I'm ready to fund a part if PSC gives an infrastructure and a manager. If no work canvas is given, I'm sure I won't have any successfull commercial proposal to such a funding. I also kindly ask other funders to systematically include unit test developpement for every new feature. Again today, I found 3 regressions, hard to find. I thought once 2.0 was out, I could spend less time testing, and more time working. It's still not the case. Again, you gave a lot unpaid work, when I was struggling to find a way to spend some.. Hope we'll find a way. Régis -- View this message in context: http://osgeo-org.1560.x6.nabble.com/QGIS-2-64bits-is-it-stable-tp5081507p5081586.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS 2 64bits, is it stable ?
Assuming it's not already done, I'd suggest that requiring Unit Tests for all new features should be mandatory for a Pull Request/patch to be accepted into QGIS. In the long term that would hopefully help alleviate the significant number of regressions that we're seeing in 2.0. Jonathan On 3 October 2013 11:51, Régis Haubourg regis.haubo...@eau-adour-garonne.fr wrote: Hi Matthias. agreed. How to fund, this is the question. I have budget (at least at the moment). I haven't been able to spend it completly in 2.0 release sprint because all goes too fast for classical contract, where I'm constrained to pay for a specific work (debug or feature). Please be warned to public finances are not good in europe, and every unconsumed budget can be erased. Sponsoring should be a way to finance infrastructure consolidation, but in current rules, sponsoring can't be oriented. I need help from the community to have a serious real use case unit test suite. I'm ready to fund a part if PSC gives an infrastructure and a manager. If no work canvas is given, I'm sure I won't have any successfull commercial proposal to such a funding. I also kindly ask other funders to systematically include unit test developpement for every new feature. Again today, I found 3 regressions, hard to find. I thought once 2.0 was out, I could spend less time testing, and more time working. It's still not the case. Again, you gave a lot unpaid work, when I was struggling to find a way to spend some.. Hope we'll find a way. Régis -- View this message in context: http://osgeo-org.1560.x6.nabble.com/QGIS-2-64bits-is-it-stable-tp5081507p5081586.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS 2 64bits, is it stable ?
On Thu, Oct 03, 2013 at 12:00:05PM +0100, Jonathan Moules wrote: Assuming it's not already done, I'd suggest that requiring Unit Tests for all new features should be mandatory for a Pull Request/patch to be accepted into QGIS. In the long term that would hopefully help alleviate the significant number of regressions that we're seeing in 2.0. +1 Of course providing tests will only be effective when there's also a rule of not accepting changes beaking any of the tests, and that's only effective when there's a continuous monitoring of testsuite runs. All of that is likely yet to be defined by the new Testing and QA Manager. Speaking of which, the psc page describes the roles but there's no link to the currently appointed person for each role: http://www.qgis.org/en/site/getinvolved/governance/organisation/psc.html (nor links to contextualize the path that brings there from the homepage) --strk; Jonathan On 3 October 2013 11:51, Régis Haubourg regis.haubo...@eau-adour-garonne.fr wrote: Hi Matthias. agreed. How to fund, this is the question. I have budget (at least at the moment). I haven't been able to spend it completly in 2.0 release sprint because all goes too fast for classical contract, where I'm constrained to pay for a specific work (debug or feature). Please be warned to public finances are not good in europe, and every unconsumed budget can be erased. Sponsoring should be a way to finance infrastructure consolidation, but in current rules, sponsoring can't be oriented. I need help from the community to have a serious real use case unit test suite. I'm ready to fund a part if PSC gives an infrastructure and a manager. If no work canvas is given, I'm sure I won't have any successfull commercial proposal to such a funding. I also kindly ask other funders to systematically include unit test developpement for every new feature. Again today, I found 3 regressions, hard to find. I thought once 2.0 was out, I could spend less time testing, and more time working. It's still not the case. Again, you gave a lot unpaid work, when I was struggling to find a way to spend some.. Hope we'll find a way. Régis ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS 2 64bits, is it stable ?
Hello, Le jeudi 3 octobre 2013 13:13:10, Sandro Santilli a écrit : On Thu, Oct 03, 2013 at 12:00:05PM +0100, Jonathan Moules wrote: Assuming it's not already done, I'd suggest that requiring Unit Tests for all new features should be mandatory for a Pull Request/patch to be accepted into QGIS. In the long term that would hopefully help alleviate the significant number of regressions that we're seeing in 2.0. +1 Of course providing tests will only be effective when there's also a rule of not accepting changes beaking any of the tests, and that's only effective when there's a continuous monitoring of testsuite runs. All of that is likely yet to be defined by the new Testing and QA Manager. And another +1. It's time to focus on code quality to reduce bugs and maintainance costs, for which it is always difficult to find funding. We need more unit test, more code quality dashboards and much stricter rules relative to what code has to be accepted into master. A PostgreSQL-like code inclusion workflow, with commitfest and review, could be something interested, to be discussed. On the funding side, for information, public administrations, at least in france, cannot pay for a time based contract. Estimating how much time a bug fix could take is a really hard task (except if you fixed the bug already). This is a problem both for company willing to fix bug for paid contracts and for public administrations wanting to finance bugs, and can explain the funding situation related to maintainance and bugfixing. Vincent Speaking of which, the psc page describes the roles but there's no link to the currently appointed person for each role: http://www.qgis.org/en/site/getinvolved/governance/organisation/psc.html (nor links to contextualize the path that brings there from the homepage) --strk; Jonathan On 3 October 2013 11:51, Régis Haubourg regis.haubo...@eau-adour-garonne.fr wrote: Hi Matthias. agreed. How to fund, this is the question. I have budget (at least at the moment). I haven't been able to spend it completly in 2.0 release sprint because all goes too fast for classical contract, where I'm constrained to pay for a specific work (debug or feature). Please be warned to public finances are not good in europe, and every unconsumed budget can be erased. Sponsoring should be a way to finance infrastructure consolidation, but in current rules, sponsoring can't be oriented. I need help from the community to have a serious real use case unit test suite. I'm ready to fund a part if PSC gives an infrastructure and a manager. If no work canvas is given, I'm sure I won't have any successfull commercial proposal to such a funding. I also kindly ask other funders to systematically include unit test developpement for every new feature. Again today, I found 3 regressions, hard to find. I thought once 2.0 was out, I could spend less time testing, and more time working. It's still not the case. Again, you gave a lot unpaid work, when I was struggling to find a way to spend some.. Hope we'll find a way. Régis ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] QGIS 2 64bits, is it stable ?
Hi all, Some french users downloading the windows standalone 64bits version and they encounter bugs considered as blockers : * IGNF:LAMBE -- not reprojecting https://hub.qgis.org/issues/7941 * Interpolation crash * not conserving EPSG:900913 and not transform to EPSG:3857 for old project * no GRASS plugin * 'The selected color palette is not available' on windows7 I don't know if its just for 64bits version, but some users thought that *QGIS 2.0.1 is not stable enough* to be used in production. They are waiting for a bugfix release. Regards, René-Luc D'Hont 3Liz ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
