Re: [Qgis-developer] A roadmap to QGIS 2.0
Hi Martin - identify which parts of the rendering stack are in python and explicitly run rendering of these layers in main branch. This would actually avoid the whole problem and might work fine. I haven't investigated this option yet, I'm mainly interested in an simple way how to find out if a class is implemented in python. I would appreciate any comments for that. Yes, difficult problem with the GIL. A simple solution would be to check the loaded python plugins and see if there are any with type RENDERER or MAPLAYER (maybe it would need an additional type for symbollayer plugins too). If so, do the rendering single threaded. I know, there are disvantages of this approach. E.g. people could forget to unload the openlayers plugin even if they don't use such a layer in the current project. Or a plugin could use the wrong declaration and block QGIS (but plugins can also block QGIS because of other bugs). However, it seems much simpler to me compared to force the python rendering components to the main branch. Regards, Marco Am Freitag, 4. Februar 2011, um 13.32:38 schrieb Martin Dobias: Hi Juergen On Fri, Feb 4, 2011 at 11:27 AM, Jürgen E. j...@norbit.de wrote: Did I miss Martins comments on that? I didn't find any. Sorry for not joining the discussion, first I was too busy, then I've been away, so after 14 days I thought it's too late to join the discussion :-) Anyway I'm going to share my thoughts now. I agree with Tim's goals for the 2.0 release. I also agree with the point that we should do few releases (e.g. 1.9.x) before 2.0 that would incrementally throw out old stuff and bring a lot of polish, so that 2.0 will be merely a renamed 1.9.x version - in order to have a solid release, not a feature-packed unstable release. (Probably many people will give 2.0 a try and if it's buggy they'll wait again for 3.0). At the same time I would be a bit more modest regarding the timeline, but as Tim noted, it looks like everyone has a different opinion on that and his plan is quite reasonable. One of the many things that I would like to see in 2.0 is a reworked geometry class. I hope everyone who knows the inner working of QgsGeometry will agree with me :-) I think boost.geometry library (former GGL) is a strong candidate for the backend, since it starts to mature and has several advantages over GEOS: - allows to use our own geometry classes - no need to copy geometries back and forth - it's pure header library - so it's only build dependency, not runtime dependency It could miss some functionality that is available in geos, though - I haven't done an extensive comparison yet. One of the important things is how/when to merge the threading branch. I know that just few people tried it, so I didn't get much feedback apart from Marco's and Pirmin's comments. As of now, I am aware of just one important blocker that prevents me to merge the branch (there will be probably few bugs, but I don't think of them as critical). The blocker is the issue of threading vs python. Python in general is not a great friend with threading - it has an infamous Global Interpreter Lock (GIL) which ensures that only one thread in application can run Python code. To enable threaded applications, GIL is unlocked periodically (when running python code) and locked again to give other threads a chance to run The problem in QGIS shows up if any part of the rendering stack is in Python. That could be a custom symbol layer instance, custom renderer or a custom plugin layer. Rendering freezes at that point, because Python code is waiting for GIL, but it doesn't receive it since no Python code is running either (in main thread) that could unlock the GIL. The question is how to handle this situation. I had few ideas how to solve this: - run periodically some python code in main thread, so GIL could be acquired by rendering thread. This is lame: if called often, it eats a lot of cpu, if called rarely the code in rendering thread progresses slowly. - unlock GIL manually when rendering starts and lock it again when rendering finished. Until now I have failed to produce a result which wouldn't crash/deadlock when tried running python code in main thread while rendering thread is running python code. (As someone noted on one mailing list, python documentation for this topic is clear as mud). - identify which parts of the rendering stack are in python and explicitly run rendering of these layers in main branch. This would actually avoid the whole problem and might work fine. I haven't investigated this option yet, I'm mainly interested in an simple way how to find out if a class is implemented in python. I would appreciate any comments for that. Among the smaller issues, there should be more aggressive locking to prevent data corruption when rendering and modifying the data at the same time (e.g. vector edit buffer, raster/vector layer properties). I also had
Re: [Qgis-developer] A roadmap to QGIS 2.0
Hi, Martin Dobias wrote : One of the important things is how/when to merge the threading branch. I know that just few people tried it, so I didn't get much feedback apart from Marco's and Pirmin's comments. Just my two cents as you seem to lack feedback about the threading branch: IMHO, it is just amazing! When I saw the announcement of the Google summer of code, I was waiting forward to test it. I made a local build some time ago and I was impressed (even on an old dual core AMD Athlon). I am waiting to have the branch merged to test it at work and then probably buy a new machine for home (just for this!); I believe it will largely solve the first (speed) of ticket http://trac.osgeo.org/qgis/ticket/3222 [Fast, easy and beautiful on the fly rule-based rendering of OSM maps]. I am working on improving the easiness and performance of postgis as a qgis backend for osm data here, which I hope together with the multi-threading will allow to have fast on-the fly vector rendering for huge .osm files. (Currently I have fair results for italy.osm but performance with osm data + 25 m level curves still need to be improved). In short, all the best for merging the threading branch; I'll be on the list of testers! In addition, since OSM is a very rich and complex dataset, I believe it is an interesting piece of data to make tests on multi-threading. Mayeul ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] A roadmap to QGIS 2.0
Hi Marco, On Tue, 18. Jan 2011 at 20:37:10 +0100, Marco Hugentobler wrote: Releasing 2.0 and still no table joins seems to be less than ideal to me and will likely be criticized (e.g. in feature comparisons with other GIS). I'd rather invest more time on the really needed stuff that a basic 2D GIS should deliver, than in 3D. 3D, in my opinion, can wait for 2.0 and would then justify the 2.0 release feature wise. I'm proposing to insert the table join for version 1.8 into the realease timeline (one after the merge of the threading branch). Did I miss Martins comments on that? I didn't find any. Did anyone try merges yet? I've was going to try - but I all I managed so far is to get git (and that took quite some amount of persuasiveness to get there - git rookie here) to checkout trunk, rasterproviders, threading and table branch into one repository. I'd like to work more on the forms stuff and I think the table join branch could be a prerequisite for that. Anything I can do to help with the merges? Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-20 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] A roadmap to QGIS 2.0
Hi Marco, On Fri, 04. Feb 2011 at 11:51:17 +0100, Marco Hugentobler wrote: I was proposing to merge the table join branch after the threading branch because they would conflict in the QgsVectorLayer class. The join branch implements logic to manage attribute ids of joined tables (including consideration of uncommited attribute columns), while the threading branch moves the handling of uncommited changes to a related class (QgsEditingBuffer). So the handling of joined attribute ids would need to be adapted to the new situation. Right. So I'm waiting for you and you're waiting for Martin. And Martin is probably burried alive in something completely different. I'm just asking what I can to to help... Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-20 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] A roadmap to QGIS 2.0
Hi Juergen On Fri, Feb 4, 2011 at 11:27 AM, Jürgen E. j...@norbit.de wrote: Did I miss Martins comments on that? I didn't find any. Sorry for not joining the discussion, first I was too busy, then I've been away, so after 14 days I thought it's too late to join the discussion :-) Anyway I'm going to share my thoughts now. I agree with Tim's goals for the 2.0 release. I also agree with the point that we should do few releases (e.g. 1.9.x) before 2.0 that would incrementally throw out old stuff and bring a lot of polish, so that 2.0 will be merely a renamed 1.9.x version - in order to have a solid release, not a feature-packed unstable release. (Probably many people will give 2.0 a try and if it's buggy they'll wait again for 3.0). At the same time I would be a bit more modest regarding the timeline, but as Tim noted, it looks like everyone has a different opinion on that and his plan is quite reasonable. One of the many things that I would like to see in 2.0 is a reworked geometry class. I hope everyone who knows the inner working of QgsGeometry will agree with me :-) I think boost.geometry library (former GGL) is a strong candidate for the backend, since it starts to mature and has several advantages over GEOS: - allows to use our own geometry classes - no need to copy geometries back and forth - it's pure header library - so it's only build dependency, not runtime dependency It could miss some functionality that is available in geos, though - I haven't done an extensive comparison yet. One of the important things is how/when to merge the threading branch. I know that just few people tried it, so I didn't get much feedback apart from Marco's and Pirmin's comments. As of now, I am aware of just one important blocker that prevents me to merge the branch (there will be probably few bugs, but I don't think of them as critical). The blocker is the issue of threading vs python. Python in general is not a great friend with threading - it has an infamous Global Interpreter Lock (GIL) which ensures that only one thread in application can run Python code. To enable threaded applications, GIL is unlocked periodically (when running python code) and locked again to give other threads a chance to run The problem in QGIS shows up if any part of the rendering stack is in Python. That could be a custom symbol layer instance, custom renderer or a custom plugin layer. Rendering freezes at that point, because Python code is waiting for GIL, but it doesn't receive it since no Python code is running either (in main thread) that could unlock the GIL. The question is how to handle this situation. I had few ideas how to solve this: - run periodically some python code in main thread, so GIL could be acquired by rendering thread. This is lame: if called often, it eats a lot of cpu, if called rarely the code in rendering thread progresses slowly. - unlock GIL manually when rendering starts and lock it again when rendering finished. Until now I have failed to produce a result which wouldn't crash/deadlock when tried running python code in main thread while rendering thread is running python code. (As someone noted on one mailing list, python documentation for this topic is clear as mud). - identify which parts of the rendering stack are in python and explicitly run rendering of these layers in main branch. This would actually avoid the whole problem and might work fine. I haven't investigated this option yet, I'm mainly interested in an simple way how to find out if a class is implemented in python. I would appreciate any comments for that. Among the smaller issues, there should be more aggressive locking to prevent data corruption when rendering and modifying the data at the same time (e.g. vector edit buffer, raster/vector layer properties). I also had to remove connection pooling for postgis layers from one server, since it's not possible to read data for more than one layer at once from one connection. But these things can be fixed as the time goes. Did anyone try merges yet? I haven't tried to merge the code yet. I would recommend to merge Radim's raster providers branch prior to the threading branch, since it's much simpler. However then we will have to make sure that rasters work correctly with the threading. I've was going to try - but I all I managed so far is to get git (and that took quite some amount of persuasiveness to get there - git rookie here) to checkout trunk, rasterproviders, threading and table branch into one repository. I'd like to work more on the forms stuff and I think the table join branch could be a prerequisite for that. Anything I can do to help with the merges? It will be useful to merge the table join branch to threading branch first, and then update it with the zillion of commits that happened in trunk in meanwhile. With that help, I think threading branch could be merged to trunk much sooner. I would really appreciate that! Regards Martin
Re: [Qgis-developer] A roadmap to QGIS 2.0
Hi Martin I think boost.geometry library (former GGL) is a strong candidate for the backend This library looks very promising. Seems we could just use the Qt classes, e.g. QPolygonF for polygon rings (http://geometrylibrary.geodan.nl/x01__qt__example_8cpp-example.html). Like this, there could be a very fast transfer from the data provider to the rendering. But first the threading, the raster providers and the table joins :-) Regards, Marco Am Freitag, 4. Februar 2011, um 13.32:38 schrieb Martin Dobias: Hi Juergen On Fri, Feb 4, 2011 at 11:27 AM, Jürgen E. j...@norbit.de wrote: Did I miss Martins comments on that? I didn't find any. Sorry for not joining the discussion, first I was too busy, then I've been away, so after 14 days I thought it's too late to join the discussion :-) Anyway I'm going to share my thoughts now. I agree with Tim's goals for the 2.0 release. I also agree with the point that we should do few releases (e.g. 1.9.x) before 2.0 that would incrementally throw out old stuff and bring a lot of polish, so that 2.0 will be merely a renamed 1.9.x version - in order to have a solid release, not a feature-packed unstable release. (Probably many people will give 2.0 a try and if it's buggy they'll wait again for 3.0). At the same time I would be a bit more modest regarding the timeline, but as Tim noted, it looks like everyone has a different opinion on that and his plan is quite reasonable. One of the many things that I would like to see in 2.0 is a reworked geometry class. I hope everyone who knows the inner working of QgsGeometry will agree with me :-) I think boost.geometry library (former GGL) is a strong candidate for the backend, since it starts to mature and has several advantages over GEOS: - allows to use our own geometry classes - no need to copy geometries back and forth - it's pure header library - so it's only build dependency, not runtime dependency It could miss some functionality that is available in geos, though - I haven't done an extensive comparison yet. One of the important things is how/when to merge the threading branch. I know that just few people tried it, so I didn't get much feedback apart from Marco's and Pirmin's comments. As of now, I am aware of just one important blocker that prevents me to merge the branch (there will be probably few bugs, but I don't think of them as critical). The blocker is the issue of threading vs python. Python in general is not a great friend with threading - it has an infamous Global Interpreter Lock (GIL) which ensures that only one thread in application can run Python code. To enable threaded applications, GIL is unlocked periodically (when running python code) and locked again to give other threads a chance to run The problem in QGIS shows up if any part of the rendering stack is in Python. That could be a custom symbol layer instance, custom renderer or a custom plugin layer. Rendering freezes at that point, because Python code is waiting for GIL, but it doesn't receive it since no Python code is running either (in main thread) that could unlock the GIL. The question is how to handle this situation. I had few ideas how to solve this: - run periodically some python code in main thread, so GIL could be acquired by rendering thread. This is lame: if called often, it eats a lot of cpu, if called rarely the code in rendering thread progresses slowly. - unlock GIL manually when rendering starts and lock it again when rendering finished. Until now I have failed to produce a result which wouldn't crash/deadlock when tried running python code in main thread while rendering thread is running python code. (As someone noted on one mailing list, python documentation for this topic is clear as mud). - identify which parts of the rendering stack are in python and explicitly run rendering of these layers in main branch. This would actually avoid the whole problem and might work fine. I haven't investigated this option yet, I'm mainly interested in an simple way how to find out if a class is implemented in python. I would appreciate any comments for that. Among the smaller issues, there should be more aggressive locking to prevent data corruption when rendering and modifying the data at the same time (e.g. vector edit buffer, raster/vector layer properties). I also had to remove connection pooling for postgis layers from one server, since it's not possible to read data for more than one layer at once from one connection. But these things can be fixed as the time goes. Did anyone try merges yet? I haven't tried to merge the code yet. I would recommend to merge Radim's raster providers branch prior to the threading branch, since it's much simpler. However then we will have to make sure that rasters work correctly with the threading. I've was going to try - but I all I managed so far is to get git (and that took quite some amount of
Re: Re[2]: [Qgis-developer] A roadmap to QGIS 2.0
Ah an inadvertant click of the send button - please see below for full message... 2011/1/25 Tim Sutton li...@linfiniti.com: Hi All To summarise the opinions (toungue in cheek here): - we should wait a long time for 2.0 - like maybe in ten years - lets release it tomorrow - september sounds fine I would like to suggest we head along the path I described, nothing is cast in stone and come september if everything is not 100% good to go we obviously won't release until we feel ready to do so. Personally I am excited about the idea of having another major release and starting towards making QGIS a mature analytical GIS in the 2.x series culminating in 3.0, rather than primarily a GIS data browser. Regarding the idea of long term supported releases, we have tried to do this before, and variations of stable and unstable release cycles etc. From past experience my opinion is that we will only be able to realise that kind of release process when there are a team of QGIS developers whose time is wholely devoted to maintaining stable releases and backporting bugfixes from upstream to them. The reality is that developers (or their sponsors) work on what they need or feel like and we have no leverage to dictate how they should ...continued spend their time. As such I suggest we continue as we are until such time that E$RI gives up on that toy GIS of theirs and throws all their resources into stabilising QGIS LTS releases. Best regards Tim 2011/1/24 Sergey Yakushev yakush...@list.ru: Mon, 24 Jan 2011 17:14:29 +0100 письмо от Marco Hugentobler marco.hugentob...@sourcepole.ch: Hi Sergey C++ plugin developer can use boost graph library The role of the boost library is not clear to me. Do you mean that plugin developers may use it or do you plan to implement parts of the analysis/vector code on top of boost? Plugin developers may use boost graph library. -- С уважением Якушев Сергей yakush...@list.ru ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: Re[2]: [Qgis-developer] A roadmap to QGIS 2.0
Il giorno mar, 25/01/2011 alle 23.07 +0200, Tim Sutton ha scritto: spend their time. As such I suggest we continue as we are until such time that E$RI gives up on that toy GIS of theirs and throws all their resources into stabilising QGIS LTS releases. +1 ;) -- http://www.faunalia.it/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] A roadmap to QGIS 2.0
Hi Sergey I think it is optimal and really roadmap. Please comment... Thank you for commiting the roadgraph plugin to trunk. Release Checklist 1.8 - Not yet named 1 July 2011 Сonstructing graph part is stable and moved to analysis/vector library Yes, it will be great to have the routing functionality in the analysis lib (and the gui elements in app as discussed). C++ plugin developer can use boost graph library The role of the boost library is not clear to me. Do you mean that plugin developers may use it or do you plan to implement parts of the analysis/vector code on top of boost? Regards, Marco Am Samstag, 22. Januar 2011, um 23.00:18 schrieb Sergey Yakushev: Hi, All. This roadmap for integration RoadGraph plugin in to QGIS: Release Checklist 1.7 - Not yet named 1 April 2011 Plugin have advanced export tool. Plugin can find shortest path on polygon layer (eg, the chip move on water) Release Checklist 1.8 - Not yet named 1 July 2011 Сonstructing graph part is stable and moved to analysis/vector library. Python plugin developers can use NetworkX ( http://networkx.lanl.gov/ ), C++ plugin developer can use boost graph library ( http://www.boost.org/doc/libs/1_45_0/libs/graph/doc/table_of_contents.html ). For demo I write simple plugin. This plugin can be find мinimum spanning tree. Release Checklist 2.0 - Not yet named 1 September 2010 Мany tools for network analysis and visualisation. RoadGraph plugin is a simple and user-friendly plugin for routing. On all steps. I think it is optimal and really roadmap. Please comment... -- С уважением Якушев Сергей yakush...@list.ru ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Dr. Marco Hugentobler Sourcepole - Linux Open Source Solutions Churerstrasse 22, CH-8808 Pfäffikon SZ, Switzerland marco.hugentob...@sourcepole.ch http://www.sourcepole.ch Technical Advisor QGIS Project Steering Committee ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] A roadmap to QGIS 2.0
Hi, All. This roadmap for integration RoadGraph plugin in to QGIS: Release Checklist 1.7 - Not yet named 1 April 2011 Plugin have advanced export tool. Plugin can find shortest path on polygon layer (eg, the chip move on water) Release Checklist 1.8 - Not yet named 1 July 2011 Сonstructing graph part is stable and moved to analysis/vector library. Python plugin developers can use NetworkX ( http://networkx.lanl.gov/ ), C++ plugin developer can use boost graph library ( http://www.boost.org/doc/libs/1_45_0/libs/graph/doc/table_of_contents.html ). For demo I write simple plugin. This plugin can be find мinimum spanning tree. Release Checklist 2.0 - Not yet named 1 September 2010 Мany tools for network analysis and visualisation. RoadGraph plugin is a simple and user-friendly plugin for routing. On all steps. I think it is optimal and really roadmap. Please comment... -- С уважением Якушев Сергей yakush...@list.ru ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] A roadmap to QGIS 2.0
On 18/01/2011 16:04, Andreas Neumann wrote: Hi all, I like your enthusiasm. However, a release of 2.0 in September at Fossgis, with two additional in between releases, sounds a bit too ambitious to me. Maybe we also shouldn't put too much pressure on us just because the Fossgis conference is happening. There should be a release (maybe 1.8), but it should not be 2.0 in my opinion. Let's save 2.0 until it is really ready and of good quality. Also, I would prefer fewer, more stable features and bug fixes, over too many new features that aren't ready for the average user. To me the switch to the new labeling and symbology engine is a priority (but there is still a lot of work to do!), as well as the multi-threading branch and the table joins. The new rasters and on-the-fly raster reprojection would also be nice. Even tho' I'm not a developer I would chime in with one comment, following what you said: I'd like to see some version be declared stable. At this point, with the greatly improved maturity of QGIS, I think having a recognized stable version is more important than additional features. I wish that devs had 5 € for each time, on the maillist there was an answer You prob has been solved in the next version, please upgrade. But that's not the answer that users want to read. The QGIS project doesn't use the release candidate naming convention. And it seems that as soon as each release comes out, it is abandoned by developers, who direct their attention to new functionality in the next development version. Essentially each and every release is an RC, with fixes always being done in next up-coming version. Isn't it time to have a stable QGIS ? Call it LTS, or stable or whatever. But users want to know that it will be supported for some time, with *no changes* in the GUI, a well known feature set, and including backporting of bug fixes, etc. Perhaps that should be the goal for 2.0? Thanks, Micha Releasing 2.0 and still no table joins seems to be less than ideal to me and will likely be criticized (e.g. in feature comparisons with other GIS). I'd rather invest more time on the really needed stuff that a basic 2D GIS should deliver, than in 3D. 3D, in my opinion, can wait for 2.0 and would then justify the 2.0 release feature wise. This is just my opinion as a user/organization who has to rely on QGIS in daily work. Thanks to all of you developers for your efforts! Andreas On Tue, 18 Jan 2011 08:05:56 +0200, Tim Sutton wrote: Hi All I think its time to start thinking about getting 2.0 'out'. What do others think? The major goal would be to - clean up the api and remove cruft / inelegant parts / backwards compatibility wrappers - do an overhaul of the api docs and get it to a good state (doxygen wise) - get rid of old labelling completely - get rid of old symbology completely - merge many of the plugins directly into trunk (north arrow, gps, coordinate capture, delimited text, georeferencer, some form of raster colours / 1 band raster colour table etc.) - capitalise on the bug fixing work of SunilRaj from kCube so that his time is going into stabilising for a 2.0 release - show the world that we have reached the next level of maturity and functionality - As such I would propose the following time line (http://www.qgis.org/wiki/Release_Checklists) Release Checklist 1.7 - Not yet named 1 April 2011 Introduce threaded rendering, raster on the fly projection, 3D globe mode Release Checklist 1.8 - Not yet named 1 July 2011 Full GUI freeze for 2.0, no more old symbology, old labelling Release Checklist 2.0 - Not yet named 1 September 2010 API changes finalised, all deprecation wrappers removed, API docs tidied up. The timing would allow us to have 2.0 ready to make a splash at the next FOSS4G conference. Any comments? Does this work for others? Any other major additions folks think should be in place before QGIS goes out? I look forward to your feedback, Regards Tim -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Micha Silver http://www.surfaces.co.il/ Arava Development Co. +972-52-3665918 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org
Re: [Qgis-developer] A roadmap to QGIS 2.0
Hi! Isn't it time to have a stable QGIS ? Call it LTS, or stable or whatever. But users want to know that it will be supported for some time, with *no changes* in the GUI, a well known feature set, and including backporting of bug fixes, etc. Perhaps that should be the goal for 2.0? You are definitely right! I agree that we probably should do the same as we did with 1.0 (with less success) and call 2.0 a Long Term release. Probably we should look at how other projects handle these thing (like GRASS or any other software). But nevertheless first of all there need to be a 2.0 :) And to be honest I'd like to see all those nice new features (raster reprojection, new symbology, labeling, threading, globe) in the 2.0 otherwise a 2.0 does not make sense to me. We probably could really put those new things slowly into 1.7/1.8/1.9 and than have a few RC Releases of 2.0 to clean out most of the bugs and than release a 2.0 with long term support. But remember - we would also need a whole infrastructure for going into long term support for 2.0.x. (forum for 2.0.x?, bug reports for 2.0.x) which means a lot more work (especially for devs to backport some fixes) but all in all - i think it was meant to be to have 2.0 as a long term/stable version anyway kind regards Werner ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] A roadmap to QGIS 2.0
Il giorno mer, 19/01/2011 alle 11.30 +0100, Werner Macho ha scritto: I agree that we probably should do the same as we did with 1.0 (with less success) and call 2.0 a Long Term release. I may be wrong, but given the current pace of development I am rather skeptical about long term. Better keep it dynamic than freeze it. All the best. -- http://www.faunalia.it/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] A roadmap to QGIS 2.0
qgis-developer-boun...@lists.osgeo.org scritti il 19/01/2011 11.30.15 You are definitely right! I agree that we probably should do the same as we did with 1.0 (with less success) and call 2.0 a Long Term release. 1.0 was almost abbandoned in favour of more stable 1.2/1.4. So I think it will happen when 2.2/2.4 will be out. If a 2.0 project can be opened with QGIS 2.2, I don't see why I should stay at 2.0 without all bugfixes of 2.2. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] A roadmap to QGIS 2.0
sure - but you are a dev .. think of a normal user .. i have a lot of people working here in my company that install a program and are afraid of going to the next version because probably something might not work as expected or buttons are placed elsewhere .. I also do not have such problems - but thats because i am used to test new software every day .. but i definitely can understand the view of a normal or new user ... It was just the suggestion that we surely should go on with development but also provide the user with a known interface and a known version number called stable On the other hand - I can already hear the rants plugin xxx is not working in my qgis when the plugin is meant to run in a higher version .. but thats one of the things we would have to deal with .. kind regards Werner On Wed, Jan 19, 2011 at 11:36 AM, luca_mangane...@comune.trento.it wrote: qgis-developer-boun...@lists.osgeo.org scritti il 19/01/2011 11.30.15 You are definitely right! I agree that we probably should do the same as we did with 1.0 (with less success) and call 2.0 a Long Term release. 1.0 was almost abbandoned in favour of more stable 1.2/1.4. So I think it will happen when 2.2/2.4 will be out. If a 2.0 project can be opened with QGIS 2.2, I don't see why I should stay at 2.0 without all bugfixes of 2.2. ___ 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] A roadmap to QGIS 2.0
Paolo wrote: Il giorno mer, 19/01/2011 alle 11.30 +0100, Werner Macho ha scritto: I agree that we probably should do the same as we did with 1.0 (with less success) and call 2.0 a Long Term release. I may be wrong, but given the current pace of development I am rather skeptical about long term. Better keep it dynamic than freeze it. I'm also concerned that we couldn't keep up our current pace if we need to support two versions. Werner wrote: On the other hand - I can already hear the rants plugin xxx is not working in my qgis when the plugin is meant to run in a higher version .. but thats one of the things we would have to deal with .. Forum and user mailing list will be flooded with such posts. We'd need a really good plugin installer mechanism that informs users about which versions are required for a plugin. Of course plugin devs also have to be aware of possible problems. Anita ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] A roadmap to QGIS 2.0
On 01/19/2011 02:10 AM, Micha Silver wrote: On 18/01/2011 16:04, Andreas Neumann wrote: Hi all, I like your enthusiasm. However, a release of 2.0 in September at Fossgis, with two additional in between releases, sounds a bit too ambitious to me. Maybe we also shouldn't put too much pressure on us just because the Fossgis conference is happening. There should be a release (maybe 1.8), but it should not be 2.0 in my opinion. Let's save 2.0 until it is really ready and of good quality. Also, I would prefer fewer, more stable features and bug fixes, over too many new features that aren't ready for the average user. To me the switch to the new labeling and symbology engine is a priority (but there is still a lot of work to do!), as well as the multi-threading branch and the table joins. The new rasters and on-the-fly raster reprojection would also be nice. Even tho' I'm not a developer I would chime in with one comment, following what you said: I'd like to see some version be declared stable. At this point, with the greatly improved maturity of QGIS, I think having a recognized stable version is more important than additional features. I wish that devs had 5 € for each time, on the maillist there was an answer You prob has been solved in the next version, please upgrade. But that's not the answer that users want to read. The QGIS project doesn't use the release candidate naming convention. And it seems that as soon as each release comes out, it is abandoned by developers, who direct their attention to new functionality in the next development version. Essentially each and every release is an RC, with fixes always being done in next up-coming version. Isn't it time to have a stable QGIS ? Call it LTS, or stable or whatever. But users want to know that it will be supported for some time, with *no changes* in the GUI, a well known feature set, and including backporting of bug fixes, etc. Perhaps that should be the goal for 2.0? Thanks, Micha I think we probably need to step back and think about the development process we have, if we want to modify it and how we want to name things. The tricky part with the 1.x series was that a lot of the bug fixes required changing the API (by addition or modification) and that bug releases required full reinstalls. So it really didn't make any sense to 'backport' them to 1.0.x as that would require a complete reinstall. Now GUI changes or significant branch merges might be considered a different topic. I would tend to agree that minimizing GUI changes could be a hallmark of a 'stable' release even if all sorts of stuff underneath changes slightly. What I'm hearing from people, is that bug fixes even if they tweak the api or require new stuff should be 2.0.x and that only the merge of new features or major overhauls of UI/Core components(Like changing save file structure) would earn a 2.x designation. Under a plan like this we could do RC and when 2.x finalizes it would be the new 'stable' version. You can see how this dev model is a bit different than the current. And to be honest might not work well for this particular project. I've seen plenty of cases where stuff gets added to the python api to allow some plugin to happen and that plugin is really useful that most users want it. Maybe what we should do is maintain a GUI backward compatibility (toggle to see new/old) so that icons etc only change on major versions. As for plugins, we really need to enforce the qgis-minimum version property as a requirement and encourage plugin testing (maybe unittests?) against versions it's supposed to work with. On the Topic of when 2.0, I think a complete list of all things we want done for 2.0 should be made and the PSC should declare 2.0 when those are finished (Obviously with some leeway to not get 100% in certain cases). Maybe how we do it now actually works, and we just need an overhaul of how we number/explain it to the general users. Thanks, Alex ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] A roadmap to QGIS 2.0
Werner wrote: On the other hand - I can already hear the rants plugin xxx is not working in my qgis when the plugin is meant to run in a higher version .. but thats one of the things we would have to deal with .. Anita wrote: Forum and user mailing list will be flooded with such posts. We'd need a really good plugin installer mechanism that informs users about which versions are required for a plugin. Of course plugin devs also have to be aware of possible problems. I think the plugins should have: 1. ReadMe file - for instruction for needed packages to be installed to make it run and where to get it (URL) if needed - Minimum QGIS version for the plugin run - possible problem - python version needed to run - mailing list (e.g. QGIS- developer) to post the problem and bugs. - how to uninstall / delete the plugin 2. Changelog file - for bug fixes and changes for every update - credit for patches and testers and ranters 3. HTML file - description / induction of the plugin - for the help - and it should link in the HELP Button in the plugin 4. HELP Button for the above reason 6. Email address of the developer - for contact and rant directly to the developer. 5. About Form for the plugin with Help Button and email address of the developer. I think plugin problems and bugs should be posted in the QGIS-developer and CC: the developer. The plugin problem should be posted with Plugin as as first part of the title topic in posting. e.g. Re: Plugin: PostGIS query not working in Windows 7 These suggestions apply to QGIS 1.x and QGIS 2.0. Thanks. Noli ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] A roadmap to QGIS 2.0
On 18 January 2011 08:50, Werner Macho werner.ma...@gmail.com wrote: - merge many of the plugins directly into trunk (north arrow, gps, coordinate capture, delimited text, georeferencer, some form of raster colours / 1 band raster colour table etc.) +1 very good idea .. I'd like to see more and more plugins getting into core (but that also reminds me on the idea of creating an my own toolbox menu where i can put just the functions (plugins) i need and not everything somewhere under plugins. Someone on the mailinglist also wrote something about the idea of consolidating all the menus which are dealing with database connections. So a menu and GUI-overhaul would be also a good idea I like the idea of having toolsets as a way of decluttering the GUI by having a toolbox and/or menu of commonly used functions easily accessible, and the less-commonly used functions moved out of plain sight. QGIS could come with some pre-defined toolsets, and the user also has the ability to create their own. Sort of like the perspectives you get in Eclipse or Qt Creator, and also ties in with the multi-view work that has been done. Indeed, this could possibly be extended to making the composer a first-class citizen of the GUI rather than a separate window. This will help alleviate the problem with a certain SSS (superficially similar software) that has a vast tree of functions and plugins that are placed based on the whims of the developer and not the user, thus justifying the huge training costs to use it... (rant over :) -JD ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] A roadmap to QGIS 2.0
Hi, Am Dienstag, 18. Januar 2011, um 07.05:56 schrieb Tim Sutton: Hi All I think its time to start thinking about getting 2.0 'out'. What do others think? The major goal would be to - clean up the api and remove cruft / inelegant parts / backwards compatibility wrappers - do an overhaul of the api docs and get it to a good state (doxygen wise) - get rid of old labelling completely - get rid of old symbology completely - merge many of the plugins directly into trunk (north arrow, gps, coordinate capture, delimited text, georeferencer, some form of raster colours / 1 band raster colour table etc.) - capitalise on the bug fixing work of SunilRaj from kCube so that his time is going into stabilising for a 2.0 release - show the world that we have reached the next level of maturity and functionality - As such I would propose the following time line (http://www.qgis.org/wiki/Release_Checklists) Release Checklist 1.7 - Not yet named 1 April 2011 Introduce threaded rendering, raster on the fly projection, 3D globe mode Like Werner and Anita I've overlooked your entries threaded rendering, raster on the fly projection, 3D globe mode for 1.7. Hopefully Martin has time for this important merge soon! * Version numbering: In my opinion version 2.0 should not be given from a developers point of view (code cleanup, etc.) but from a users point of view (new features, new GUI). In that sense 1.7 or 1.8 would deserve the version 2.0 tag. * API transition: From a users point of view we should keep compatibility to old project files and API calls (plugins!) as long as possible. We should give users as much help as possible to migrate their projects and developers to migrate their plugins to the 2.0 API. Therefore I would add the following points to 1.7: -New symbology and new labelling used by default -Deprecate old features (symbology, labelling) and API's I propose adding a deprecation mechanism, which sends messages to the plugin manager. The plugin manager should mark plugins which are not 2.0 compatible and collect their deprecation messages. In contrary, C++ plugins will get deprecation messages at compile time. So there would be time to update plugins after 1.7, complete the implementation of new symbology and new labelling and implement a migration mechanism for old features (good goals for a Hackfest!). Regards Pirmin Release Checklist 1.8 - Not yet named 1 July 2011 Full GUI freeze for 2.0, no more old symbology, old labelling Release Checklist 2.0 - Not yet named 1 September 2010 API changes finalised, all deprecation wrappers removed, API docs tidied up. The timing would allow us to have 2.0 ready to make a splash at the next FOSS4G conference. Any comments? Does this work for others? Any other major additions folks think should be in place before QGIS goes out? I look forward to your feedback, Regards Tim -- Pirmin Kalberer Sourcepole - Linux Open Source Solutions http://www.sourcepole.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] A roadmap to QGIS 2.0
Hi all, I like your enthusiasm. However, a release of 2.0 in September at Fossgis, with two additional in between releases, sounds a bit too ambitious to me. Maybe we also shouldn't put too much pressure on us just because the Fossgis conference is happening. There should be a release (maybe 1.8), but it should not be 2.0 in my opinion. Let's save 2.0 until it is really ready and of good quality. Also, I would prefer fewer, more stable features and bug fixes, over too many new features that aren't ready for the average user. To me the switch to the new labeling and symbology engine is a priority (but there is still a lot of work to do!), as well as the multi-threading branch and the table joins. The new rasters and on-the-fly raster reprojection would also be nice. Releasing 2.0 and still no table joins seems to be less than ideal to me and will likely be criticized (e.g. in feature comparisons with other GIS). I'd rather invest more time on the really needed stuff that a basic 2D GIS should deliver, than in 3D. 3D, in my opinion, can wait for 2.0 and would then justify the 2.0 release feature wise. This is just my opinion as a user/organization who has to rely on QGIS in daily work. Thanks to all of you developers for your efforts! Andreas On Tue, 18 Jan 2011 08:05:56 +0200, Tim Sutton wrote: Hi All I think its time to start thinking about getting 2.0 'out'. What do others think? The major goal would be to - clean up the api and remove cruft / inelegant parts / backwards compatibility wrappers - do an overhaul of the api docs and get it to a good state (doxygen wise) - get rid of old labelling completely - get rid of old symbology completely - merge many of the plugins directly into trunk (north arrow, gps, coordinate capture, delimited text, georeferencer, some form of raster colours / 1 band raster colour table etc.) - capitalise on the bug fixing work of SunilRaj from kCube so that his time is going into stabilising for a 2.0 release - show the world that we have reached the next level of maturity and functionality - As such I would propose the following time line (http://www.qgis.org/wiki/Release_Checklists) Release Checklist 1.7 - Not yet named 1 April 2011 Introduce threaded rendering, raster on the fly projection, 3D globe mode Release Checklist 1.8 - Not yet named 1 July 2011 Full GUI freeze for 2.0, no more old symbology, old labelling Release Checklist 2.0 - Not yet named 1 September 2010 API changes finalised, all deprecation wrappers removed, API docs tidied up. The timing would allow us to have 2.0 ready to make a splash at the next FOSS4G conference. Any comments? Does this work for others? Any other major additions folks think should be in place before QGIS goes out? I look forward to your feedback, Regards Tim -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- -- Andreas Neumann Böschacherstrasse 10A 8624 Grüt (Gossau ZH) Switzerland ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] A roadmap to QGIS 2.0
Il giorno mar, 18/01/2011 alle 15.04 +0100, Andreas Neumann ha scritto: switch to the new labeling and symbology engine is a priority (but there is still a lot of work to do!) agreed: Andreas, would you mind starting a wiki page on the missing features? thanks. -- http://www.faunalia.it/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] A roadmap to QGIS 2.0
Releasing 2.0 and still no table joins seems to be less than ideal to me and will likely be criticized (e.g. in feature comparisons with other GIS). I'd rather invest more time on the really needed stuff that a basic 2D GIS should deliver, than in 3D. 3D, in my opinion, can wait for 2.0 and would then justify the 2.0 release feature wise. I'm proposing to insert the table join for version 1.8 into the realease timeline (one after the merge of the threading branch). There is no conflict between 3D and table join, because different developers are working on it. Regards, Marco Am Dienstag, 18. Januar 2011, um 15.04:12 schrieb Andreas Neumann: Hi all, I like your enthusiasm. However, a release of 2.0 in September at Fossgis, with two additional in between releases, sounds a bit too ambitious to me. Maybe we also shouldn't put too much pressure on us just because the Fossgis conference is happening. There should be a release (maybe 1.8), but it should not be 2.0 in my opinion. Let's save 2.0 until it is really ready and of good quality. Also, I would prefer fewer, more stable features and bug fixes, over too many new features that aren't ready for the average user. To me the switch to the new labeling and symbology engine is a priority (but there is still a lot of work to do!), as well as the multi-threading branch and the table joins. The new rasters and on-the-fly raster reprojection would also be nice. Releasing 2.0 and still no table joins seems to be less than ideal to me and will likely be criticized (e.g. in feature comparisons with other GIS). I'd rather invest more time on the really needed stuff that a basic 2D GIS should deliver, than in 3D. 3D, in my opinion, can wait for 2.0 and would then justify the 2.0 release feature wise. This is just my opinion as a user/organization who has to rely on QGIS in daily work. Thanks to all of you developers for your efforts! Andreas On Tue, 18 Jan 2011 08:05:56 +0200, Tim Sutton wrote: Hi All I think its time to start thinking about getting 2.0 'out'. What do others think? The major goal would be to - clean up the api and remove cruft / inelegant parts / backwards compatibility wrappers - do an overhaul of the api docs and get it to a good state (doxygen wise) - get rid of old labelling completely - get rid of old symbology completely - merge many of the plugins directly into trunk (north arrow, gps, coordinate capture, delimited text, georeferencer, some form of raster colours / 1 band raster colour table etc.) - capitalise on the bug fixing work of SunilRaj from kCube so that his time is going into stabilising for a 2.0 release - show the world that we have reached the next level of maturity and functionality - As such I would propose the following time line (http://www.qgis.org/wiki/Release_Checklists) Release Checklist 1.7 - Not yet named 1 April 2011 Introduce threaded rendering, raster on the fly projection, 3D globe mode Release Checklist 1.8 - Not yet named 1 July 2011 Full GUI freeze for 2.0, no more old symbology, old labelling Release Checklist 2.0 - Not yet named 1 September 2010 API changes finalised, all deprecation wrappers removed, API docs tidied up. The timing would allow us to have 2.0 ready to make a splash at the next FOSS4G conference. Any comments? Does this work for others? Any other major additions folks think should be in place before QGIS goes out? I look forward to your feedback, Regards Tim -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Dr. Marco Hugentobler Sourcepole - Linux Open Source Solutions Churerstr. 22, CH-8808 Pfäffikon SZ, Switzerland marco.hugentob...@sourcepole.ch http://www.sourcepole.ch Technical Advisor QGIS Project Steering Committee ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] A roadmap to QGIS 2.0
Hi All I think its time to start thinking about getting 2.0 'out'. What do others think? The major goal would be to - clean up the api and remove cruft / inelegant parts / backwards compatibility wrappers - do an overhaul of the api docs and get it to a good state (doxygen wise) - get rid of old labelling completely - get rid of old symbology completely - merge many of the plugins directly into trunk (north arrow, gps, coordinate capture, delimited text, georeferencer, some form of raster colours / 1 band raster colour table etc.) - capitalise on the bug fixing work of SunilRaj from kCube so that his time is going into stabilising for a 2.0 release - show the world that we have reached the next level of maturity and functionality - As such I would propose the following time line (http://www.qgis.org/wiki/Release_Checklists) Release Checklist 1.7 - Not yet named 1 April 2011 Introduce threaded rendering, raster on the fly projection, 3D globe mode Release Checklist 1.8 - Not yet named 1 July 2011 Full GUI freeze for 2.0, no more old symbology, old labelling Release Checklist 2.0 - Not yet named 1 September 2010 API changes finalised, all deprecation wrappers removed, API docs tidied up. The timing would allow us to have 2.0 ready to make a splash at the next FOSS4G conference. Any comments? Does this work for others? Any other major additions folks think should be in place before QGIS goes out? I look forward to your feedback, Regards Tim -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] A roadmap to QGIS 2.0
Thanks Yim for starting a discussion on this crucial issue. My comments inline. Il giorno mar, 18/01/2011 alle 08.05 +0200, Tim Sutton ha scritto: - get rid of old labelling completely we still have some things to solve in the new labelling; I think of speed (very low, unacceptable in several cases) and curved labels along complex lines - get rid of old symbology completely I think we should start documenting what is missing from the new symbology; I do not think we have a complete list yet - merge many of the plugins directly into trunk (north arrow, gps, coordinate capture, delimited text, georeferencer, some form of raster colours / 1 band raster colour table etc.) +1! - capitalise on the bug fixing work of SunilRaj from kCube so that his time is going into stabilising for a 2.0 release +1 - show the world that we have reached the next level of maturity and functionality For this I think we should get rid of most crashes, still a bit too frequent. - As such I would propose the following time line (http://www.qgis.org/wiki/Release_Checklists) Release Checklist 1.7 - Not yet named 1 April 2011 May I suggest 30 March? ;) Any comments? Does this work for others? Any other major additions folks think should be in place before QGIS goes out? I think we need more cleanup than new functionalities. All the best. -- http://www.faunalia.it/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
