Re: [Qgis-developer] Feature freeze commencing the ides of March
Hi On Wed, Mar 20, 2013 at 1:34 AM, Olivier Dalang olivier.dal...@gmail.com wrote: Hi ! Just for information : - will QGis 2.0 have the PyQt API changed to version 2 ? I don't understand? - will it have a separate plugin folder than QGis 1.8 ? It would probably make sense for it to have a separate plugin folder and also a separate QSettings namespace. Regards Tim Thanks ! Olivier 2013/3/15 Tim Sutton li...@linfiniti.com Hi All Just to confirm on this thread that following the discussions here the following updated timeline to 2.0 will apply: 1 April 2013 - Feature freeze - no new features in master 1 May 2013 - GUI Freeze and String freeze - no changes to ui or strings except where required for critical bug fixes. Call for translations. 1 June 2013 - Branch 2.0, code freeze (except for packaging related changes), call for packaging 7 June 2013 - Public release of 2.0 Regards Tim On Fri, Mar 15, 2013 at 5:44 PM, Marco Hugentobler marco.hugentob...@sourcepole.ch wrote: Pushed to master branch now. On 13.03.2013 17:44, Marco Hugentobler wrote: Hi devs The first part of the symbology improvements is available in my github fork: https://github.com/mhugent/Quantum-GIS/tree/data_defined_symbology Currently, one symbol is either in mm or in map units. The changeset in the branch adds the possibility to mix different output units ( mm / map units ) in one symbol and even in one symbol layer. So it is now e.g. possible to have line width in mm and line offset in map units. Let me know if you have feedback on this. Next enhancement part will be to add more data defined symbol properties (from attribute / expression). Regards, Marco On 04.03.2013 13:07, Marco Hugentobler wrote: Moving the date to say start of April wouldn't hurt. Would that help? Start of April would be ok for the data defined symbology. Regards, Marco On 04.03.2013 11:44, Jürgen E. Fischer wrote: Hi Marco, On Mon, 04. Mar 2013 at 11:37:15 +0100, Marco Hugentobler wrote: Disadvantage is that 15 March is too close for it to go into master. What should we do (wait for 2.1 / shift feature freeze date / exception from feature freeze) ? How much time would you need? Moving the date to say start of April wouldn't hurt. Would that help? Jürgen -- Dr. Marco Hugentobler Sourcepole - Linux Open Source Solutions Weberstrasse 5, CH-8004 Zürich, 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 -- 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 -- 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] Feature freeze commencing the ides of March
I was talking about that proposition: http://osgeo-org.1560.n6.nabble.com/Merging-of-incompatible-changes-td5010325.html ( specifically the part about using the new api, as explained here : http://pyqt.sourceforge.net/Docs/PyQt4/incompatible_apis.html ) 2013/3/20 Tim Sutton li...@linfiniti.com Hi On Wed, Mar 20, 2013 at 1:34 AM, Olivier Dalang olivier.dal...@gmail.com wrote: Hi ! Just for information : - will QGis 2.0 have the PyQt API changed to version 2 ? I don't understand? - will it have a separate plugin folder than QGis 1.8 ? It would probably make sense for it to have a separate plugin folder and also a separate QSettings namespace. Regards Tim Thanks ! Olivier 2013/3/15 Tim Sutton li...@linfiniti.com Hi All Just to confirm on this thread that following the discussions here the following updated timeline to 2.0 will apply: 1 April 2013 - Feature freeze - no new features in master 1 May 2013 - GUI Freeze and String freeze - no changes to ui or strings except where required for critical bug fixes. Call for translations. 1 June 2013 - Branch 2.0, code freeze (except for packaging related changes), call for packaging 7 June 2013 - Public release of 2.0 Regards Tim On Fri, Mar 15, 2013 at 5:44 PM, Marco Hugentobler marco.hugentob...@sourcepole.ch wrote: Pushed to master branch now. On 13.03.2013 17:44, Marco Hugentobler wrote: Hi devs The first part of the symbology improvements is available in my github fork: https://github.com/mhugent/Quantum-GIS/tree/data_defined_symbology Currently, one symbol is either in mm or in map units. The changeset in the branch adds the possibility to mix different output units ( mm / map units ) in one symbol and even in one symbol layer. So it is now e.g. possible to have line width in mm and line offset in map units. Let me know if you have feedback on this. Next enhancement part will be to add more data defined symbol properties (from attribute / expression). Regards, Marco On 04.03.2013 13:07, Marco Hugentobler wrote: Moving the date to say start of April wouldn't hurt. Would that help? Start of April would be ok for the data defined symbology. Regards, Marco On 04.03.2013 11:44, Jürgen E. Fischer wrote: Hi Marco, On Mon, 04. Mar 2013 at 11:37:15 +0100, Marco Hugentobler wrote: Disadvantage is that 15 March is too close for it to go into master. What should we do (wait for 2.1 / shift feature freeze date / exception from feature freeze) ? How much time would you need? Moving the date to say start of April wouldn't hurt. Would that help? Jürgen -- Dr. Marco Hugentobler Sourcepole - Linux Open Source Solutions Weberstrasse 5, CH-8004 Zürich, 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 -- 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 -- 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] Feature freeze commencing the ides of March
Hi ! Just for information : - will QGis 2.0 have the PyQt API changed to version 2 ? - will it have a separate plugin folder than QGis 1.8 ? Thanks ! Olivier 2013/3/15 Tim Sutton li...@linfiniti.com Hi All Just to confirm on this thread that following the discussions here the following updated timeline to 2.0 will apply: 1 April 2013 - Feature freeze - no new features in master 1 May 2013 - GUI Freeze and String freeze - no changes to ui or strings except where required for critical bug fixes. Call for translations. 1 June 2013 - Branch 2.0, code freeze (except for packaging related changes), call for packaging 7 June 2013 - Public release of 2.0 Regards Tim On Fri, Mar 15, 2013 at 5:44 PM, Marco Hugentobler marco.hugentob...@sourcepole.ch wrote: Pushed to master branch now. On 13.03.2013 17:44, Marco Hugentobler wrote: Hi devs The first part of the symbology improvements is available in my github fork: https://github.com/mhugent/Quantum-GIS/tree/data_defined_symbology Currently, one symbol is either in mm or in map units. The changeset in the branch adds the possibility to mix different output units ( mm / map units ) in one symbol and even in one symbol layer. So it is now e.g. possible to have line width in mm and line offset in map units. Let me know if you have feedback on this. Next enhancement part will be to add more data defined symbol properties (from attribute / expression). Regards, Marco On 04.03.2013 13:07, Marco Hugentobler wrote: Moving the date to say start of April wouldn't hurt. Would that help? Start of April would be ok for the data defined symbology. Regards, Marco On 04.03.2013 11:44, Jürgen E. Fischer wrote: Hi Marco, On Mon, 04. Mar 2013 at 11:37:15 +0100, Marco Hugentobler wrote: Disadvantage is that 15 March is too close for it to go into master. What should we do (wait for 2.1 / shift feature freeze date / exception from feature freeze) ? How much time would you need? Moving the date to say start of April wouldn't hurt. Would that help? Jürgen -- Dr. Marco Hugentobler Sourcepole - Linux Open Source Solutions Weberstrasse 5, CH-8004 Zürich, 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 -- 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 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Feature freeze commencing the ides of March
Pushed to master branch now. On 13.03.2013 17:44, Marco Hugentobler wrote: Hi devs The first part of the symbology improvements is available in my github fork: https://github.com/mhugent/Quantum-GIS/tree/data_defined_symbology Currently, one symbol is either in mm or in map units. The changeset in the branch adds the possibility to mix different output units ( mm / map units ) in one symbol and even in one symbol layer. So it is now e.g. possible to have line width in mm and line offset in map units. Let me know if you have feedback on this. Next enhancement part will be to add more data defined symbol properties (from attribute / expression). Regards, Marco On 04.03.2013 13:07, Marco Hugentobler wrote: Moving the date to say start of April wouldn't hurt. Would that help? Start of April would be ok for the data defined symbology. Regards, Marco On 04.03.2013 11:44, Jürgen E. Fischer wrote: Hi Marco, On Mon, 04. Mar 2013 at 11:37:15 +0100, Marco Hugentobler wrote: Disadvantage is that 15 March is too close for it to go into master. What should we do (wait for 2.1 / shift feature freeze date / exception from feature freeze) ? How much time would you need? Moving the date to say start of April wouldn't hurt. Would that help? Jürgen -- Dr. Marco Hugentobler Sourcepole - Linux Open Source Solutions Weberstrasse 5, CH-8004 Zürich, 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] Feature freeze commencing the ides of March
Hi All Just to confirm on this thread that following the discussions here the following updated timeline to 2.0 will apply: 1 April 2013 - Feature freeze - no new features in master 1 May 2013 - GUI Freeze and String freeze - no changes to ui or strings except where required for critical bug fixes. Call for translations. 1 June 2013 - Branch 2.0, code freeze (except for packaging related changes), call for packaging 7 June 2013 - Public release of 2.0 Regards Tim On Fri, Mar 15, 2013 at 5:44 PM, Marco Hugentobler marco.hugentob...@sourcepole.ch wrote: Pushed to master branch now. On 13.03.2013 17:44, Marco Hugentobler wrote: Hi devs The first part of the symbology improvements is available in my github fork: https://github.com/mhugent/Quantum-GIS/tree/data_defined_symbology Currently, one symbol is either in mm or in map units. The changeset in the branch adds the possibility to mix different output units ( mm / map units ) in one symbol and even in one symbol layer. So it is now e.g. possible to have line width in mm and line offset in map units. Let me know if you have feedback on this. Next enhancement part will be to add more data defined symbol properties (from attribute / expression). Regards, Marco On 04.03.2013 13:07, Marco Hugentobler wrote: Moving the date to say start of April wouldn't hurt. Would that help? Start of April would be ok for the data defined symbology. Regards, Marco On 04.03.2013 11:44, Jürgen E. Fischer wrote: Hi Marco, On Mon, 04. Mar 2013 at 11:37:15 +0100, Marco Hugentobler wrote: Disadvantage is that 15 March is too close for it to go into master. What should we do (wait for 2.1 / shift feature freeze date / exception from feature freeze) ? How much time would you need? Moving the date to say start of April wouldn't hurt. Would that help? Jürgen -- Dr. Marco Hugentobler Sourcepole - Linux Open Source Solutions Weberstrasse 5, CH-8004 Zürich, 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 -- 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] Feature freeze commencing the ides of March
Hi devs The first part of the symbology improvements is available in my github fork: https://github.com/mhugent/Quantum-GIS/tree/data_defined_symbology Currently, one symbol is either in mm or in map units. The changeset in the branch adds the possibility to mix different output units ( mm / map units ) in one symbol and even in one symbol layer. So it is now e.g. possible to have line width in mm and line offset in map units. Let me know if you have feedback on this. Next enhancement part will be to add more data defined symbol properties (from attribute / expression). Regards, Marco On 04.03.2013 13:07, Marco Hugentobler wrote: Moving the date to say start of April wouldn't hurt. Would that help? Start of April would be ok for the data defined symbology. Regards, Marco On 04.03.2013 11:44, Jürgen E. Fischer wrote: Hi Marco, On Mon, 04. Mar 2013 at 11:37:15 +0100, Marco Hugentobler wrote: Disadvantage is that 15 March is too close for it to go into master. What should we do (wait for 2.1 / shift feature freeze date / exception from feature freeze) ? How much time would you need? Moving the date to say start of April wouldn't hurt. Would that help? Jürgen -- Dr. Marco Hugentobler Sourcepole - Linux Open Source Solutions Weberstrasse 5, CH-8004 Zürich, 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] Feature freeze commencing the ides of March
Hi On 03/04/2013 08:17 PM, Larry Shaffer wrote: Hi, On Mon, Mar 4, 2013 at 6:40 AM, Tim Sutton li...@linfiniti.com mailto:li...@linfiniti.com wrote: Hi On Mon, Mar 4, 2013 at 1:52 PM, Radim Blazek radim.bla...@gmail.com mailto:radim.bla...@gmail.com wrote: On Mon, Mar 4, 2013 at 11:58 AM, Matthias Kuhn matthias.k...@gmx.ch mailto:matthias.k...@gmx.ch wrote: Hi, I appreciate that a release plan is finally getting published and the way for a shiny 2.0 is being paved. I'm currently working on relation enhancements and nested forms for related features. Unfortunately, this branch will not be ready by March 15, but I know, that there are some people who would like to see this included in 2.0. I'm sure it will offer a handy possibility for lots of users. Of course, there will always be some new features, that just won't make it into a new release and as Tim said, the line has to be drawn somewhere in the sand. Anyway, if the feature freeze would be a month later, the relation enhancements could go into master before 2.0. So I have the same question as Marco. What should we do: wait for 2.1, shift feature freeze or except this from feature freeze? It seems that 2 weeks to finish all works won't be sufficient. The date itself probably would not be problem if it was announced 2 months ago. We should have probably always enough time between freeze announcement and freeze date. Some developers are also working on contracted works which are expected to go to 2.0. And it was reasonable expectation if feature freeze date was not known until now. I think that feature freeze should be announced at least 2 months before feature freeze. Well in Essen we said we were going to wait for a defined feature set to make it into GIT and then call the freeze. Basically we have been waiting for Martin's vector refactor branch to be merged and other features as listed on our short list. We didnt have an ETA for this so we didnt have a specific freeze date. I'm happy to follow your suggestion for 2.1 but I'm not sure we want to wait another 2 months before commencing feature freeze for 2.0 (during which other new features will start arriving and being almost ready just before the cut off date etc.). I would propose we give specific features (Marco H and Matthias K's work) leeway to come into master up to 1 April but still call the freeze on 15 March as laid out. If there is a general concensus that we should wait two months before the freeze then we can shift the timeline along I guess. For me, April 1st will not be enough time to finish this work. I'll therefore postpone these features to 2.1. +1 for April 1 as a general feature freeze date, i.e. not for any specific feature. I believe that's enough time to finish some of the labeling features I've been wanting to focus on for 2.0. If someone could help out with optimizing PAL for speed, that would be great. I think it may be above my standard C++ coding skills at this time. I also think April 1st as general deadline for new features is the better way. Looking at the 22 open pull requests, I don't think core developers will be happy to have some more time to review than March 15 would offer. Maybe 15 April 2013 for GUI Freeze and String freeze, but keep the same timetable for the rest... can always bump those dates if blockers can not be rectified. Here's a suggestion related to the feature freeze: Considering the sheer number of new features and the lack of any beta version, it might be prudent to also have the feature freeze extended beyond the release date. While I understand the current focus is to not do any incremental or backported updates, e.g. version 2.0.1, due to lack of resources, I feel this may hurt the project with regards to this particular release. If the feature freeze remains in effect for a certain time beyond the release it will allow the public to test the new version and have the developers respond without having to work on two separate branches. In other words, I suggest we should plan for one (and only one) incremental release, 2.0.1, and notify users upon release of 2.0 that they have a set amount of time to report bugs that should be addressed for 2.0.1. IMHO, if we again have to essentially say to users, 'you'll have to wait until 2.1, just keep using it broken,' it would be a bad thing. However, I also suggest with such a setup that after 2.0.1 there only be forward commits to 2.1, with zero backporting. In fact, with such a setup there should never be any backporting or working on multiple branches, except new feature branches waiting for the freeze to end. In other words, I think the project would maintain good karma if it publicly
Re: [Qgis-developer] Feature freeze commencing the ides of March
Hi Tim The release plan sounds good to me (especially the longer bug fix period). I don't know however if 15 March is a bit close for feature freeze (at least for me, see below). Things we planned to fix for 2.0 that still need love are, IMHO: * general interface cleanup * symbology migration to the new one * labelling migration to the new one * Sextante bugfixing, and especially setting up a full test suite for it For symbology migration from old to new one, I have good news: thanks to a project from Uster and Jena, I can implement data defined symbology settings for new symbology. It is one of the few things which are possible in old symbology and not in new. Disadvantage is that 15 March is too close for it to go into master. What should we do (wait for 2.1 / shift feature freeze date / exception from feature freeze) ? Regards, Marco On 02.03.2013 22:15, Tim Sutton wrote: Hi All I would like to get 2.0 release process rolling - I think all the key features we were after have made their way into master and those that haven't can probably wait for 2.1. Unless there is vigorous and widespread objection, I propose that we embark on the following release schedule: 15 March 2013 - Feature freeze - no new features in master 1 April 2013 - GUI Freeze and String freeze - no changes to ui or strings except where required for critical bug fixes. Call for translations. 1 June 2013 - Branch 2.0, code freeze (except for packaging related changes), call for packaging 7 June 2013 - Public release of 2.0 The schedule basically allows for 3 months in order to work away the ~50 blockers in the bug queue.[1] I appreciate there are some who will wish the release period is longer and others who wish it was shorter, but we need to draw a line in the sand somewhere and this schedule seems like a good place to draw it. If you are in some way funding development of QGIS features (or building them yourself), please bear in mind that the features being developed for you will no longer be part of the nightly builds after 15 March unless they are already part of the 'master' code base at that time. Also if you have the financial resources to do so, please consider hiring a developer to take care of one or more blocker issues so that we can avoid extending the release deadline because of blockers. If you take this path, please also ask your contractee to provide unit tests for the fixes so that we can ensure that there are no regressions in the future. As always donations to the project itself to support fixing these blockers will be gratefully accepted - contact Paolo Cavallini if you need more info, or visit our donations page[2]. To bug queue maintainers, could you please go through the blocker list and carefully evaluate whether they should really be in the blocker queue. IMHO a blocker should be a cross cutting issue (i.e. not affecting a user base of 1 only) that causes QGIS to crash, corrupt data or introduces a significant regression to existing functionality. To documentors and translators - its probably a good time to start encouraging your communities to get ready for 2.0 and start translating / documenting new features. [1] http://hub.qgis.org/projects/quantum-gis/issues?query_id=23 [2] http://www.qgis.org/en/sponsorship.html 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 Weberstrasse 5, CH-8004 Zürich, 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] Feature freeze commencing the ides of March
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 04/03/2013 11:37, Marco Hugentobler ha scritto: For symbology migration from old to new one, I have good news: thanks to a project from Uster and Jena, I can implement data defined symbology settings for new symbology. It is one of the few things which are possible in old symbology and not in new. Disadvantage is that 15 March is too close for it to go into master. What should we do (wait for 2.1 / shift feature freeze date / exception from feature freeze) ? IMHO better having limited, well thought exceptions. When do you plan to have this completed? Thanks. - -- 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.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlE0egAACgkQ/NedwLUzIr7W7wCeMNvfQHDS6VpGj2F+hHNQh7c7 3qEAoKQsLa/uw72iY21mW0z+bD95tLKv =q/SZ -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Feature freeze commencing the ides of March
Hi Marco, On Mon, 04. Mar 2013 at 11:37:15 +0100, Marco Hugentobler wrote: Disadvantage is that 15 March is too close for it to go into master. What should we do (wait for 2.1 / shift feature freeze date / exception from feature freeze) ? How much time would you need? Moving the date to say start of April wouldn't hurt. Would that help? Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de committ(ed|ing) to Quantum GIS IRC: jef on FreeNode -- 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] Feature freeze commencing the ides of March
Hi, I appreciate that a release plan is finally getting published and the way for a shiny 2.0 is being paved. I'm currently working on relation enhancements and nested forms for related features. Unfortunately, this branch will not be ready by March 15, but I know, that there are some people who would like to see this included in 2.0. I'm sure it will offer a handy possibility for lots of users. Of course, there will always be some new features, that just won't make it into a new release and as Tim said, the line has to be drawn somewhere in the sand. Anyway, if the feature freeze would be a month later, the relation enhancements could go into master before 2.0. So I have the same question as Marco. What should we do: wait for 2.1, shift feature freeze or except this from feature freeze? Kind regards, Matthias On 03/04/2013 11:37 AM, Marco Hugentobler wrote: Hi Tim The release plan sounds good to me (especially the longer bug fix period). I don't know however if 15 March is a bit close for feature freeze (at least for me, see below). Things we planned to fix for 2.0 that still need love are, IMHO: * general interface cleanup * symbology migration to the new one * labelling migration to the new one * Sextante bugfixing, and especially setting up a full test suite for it For symbology migration from old to new one, I have good news: thanks to a project from Uster and Jena, I can implement data defined symbology settings for new symbology. It is one of the few things which are possible in old symbology and not in new. Disadvantage is that 15 March is too close for it to go into master. What should we do (wait for 2.1 / shift feature freeze date / exception from feature freeze) ? Regards, Marco On 02.03.2013 22:15, Tim Sutton wrote: Hi All I would like to get 2.0 release process rolling - I think all the key features we were after have made their way into master and those that haven't can probably wait for 2.1. Unless there is vigorous and widespread objection, I propose that we embark on the following release schedule: 15 March 2013 - Feature freeze - no new features in master 1 April 2013 - GUI Freeze and String freeze - no changes to ui or strings except where required for critical bug fixes. Call for translations. 1 June 2013 - Branch 2.0, code freeze (except for packaging related changes), call for packaging 7 June 2013 - Public release of 2.0 The schedule basically allows for 3 months in order to work away the ~50 blockers in the bug queue.[1] I appreciate there are some who will wish the release period is longer and others who wish it was shorter, but we need to draw a line in the sand somewhere and this schedule seems like a good place to draw it. If you are in some way funding development of QGIS features (or building them yourself), please bear in mind that the features being developed for you will no longer be part of the nightly builds after 15 March unless they are already part of the 'master' code base at that time. Also if you have the financial resources to do so, please consider hiring a developer to take care of one or more blocker issues so that we can avoid extending the release deadline because of blockers. If you take this path, please also ask your contractee to provide unit tests for the fixes so that we can ensure that there are no regressions in the future. As always donations to the project itself to support fixing these blockers will be gratefully accepted - contact Paolo Cavallini if you need more info, or visit our donations page[2]. To bug queue maintainers, could you please go through the blocker list and carefully evaluate whether they should really be in the blocker queue. IMHO a blocker should be a cross cutting issue (i.e. not affecting a user base of 1 only) that causes QGIS to crash, corrupt data or introduces a significant regression to existing functionality. To documentors and translators - its probably a good time to start encouraging your communities to get ready for 2.0 and start translating / documenting new features. [1] http://hub.qgis.org/projects/quantum-gis/issues?query_id=23 [2] http://www.qgis.org/en/sponsorship.html 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] Feature freeze commencing the ides of March
On Mon, Mar 4, 2013 at 11:58 AM, Matthias Kuhn matthias.k...@gmx.ch wrote: Hi, I appreciate that a release plan is finally getting published and the way for a shiny 2.0 is being paved. I'm currently working on relation enhancements and nested forms for related features. Unfortunately, this branch will not be ready by March 15, but I know, that there are some people who would like to see this included in 2.0. I'm sure it will offer a handy possibility for lots of users. Of course, there will always be some new features, that just won't make it into a new release and as Tim said, the line has to be drawn somewhere in the sand. Anyway, if the feature freeze would be a month later, the relation enhancements could go into master before 2.0. So I have the same question as Marco. What should we do: wait for 2.1, shift feature freeze or except this from feature freeze? It seems that 2 weeks to finish all works won't be sufficient. The date itself probably would not be problem if it was announced 2 months ago. We should have probably always enough time between freeze announcement and freeze date. Some developers are also working on contracted works which are expected to go to 2.0. And it was reasonable expectation if feature freeze date was not known until now. I think that feature freeze should be announced at least 2 months before feature freeze. Radim Kind regards, Matthias On 03/04/2013 11:37 AM, Marco Hugentobler wrote: Hi Tim The release plan sounds good to me (especially the longer bug fix period). I don't know however if 15 March is a bit close for feature freeze (at least for me, see below). Things we planned to fix for 2.0 that still need love are, IMHO: * general interface cleanup * symbology migration to the new one * labelling migration to the new one * Sextante bugfixing, and especially setting up a full test suite for it For symbology migration from old to new one, I have good news: thanks to a project from Uster and Jena, I can implement data defined symbology settings for new symbology. It is one of the few things which are possible in old symbology and not in new. Disadvantage is that 15 March is too close for it to go into master. What should we do (wait for 2.1 / shift feature freeze date / exception from feature freeze) ? Regards, Marco On 02.03.2013 22:15, Tim Sutton wrote: Hi All I would like to get 2.0 release process rolling - I think all the key features we were after have made their way into master and those that haven't can probably wait for 2.1. Unless there is vigorous and widespread objection, I propose that we embark on the following release schedule: 15 March 2013 - Feature freeze - no new features in master 1 April 2013 - GUI Freeze and String freeze - no changes to ui or strings except where required for critical bug fixes. Call for translations. 1 June 2013 - Branch 2.0, code freeze (except for packaging related changes), call for packaging 7 June 2013 - Public release of 2.0 The schedule basically allows for 3 months in order to work away the ~50 blockers in the bug queue.[1] I appreciate there are some who will wish the release period is longer and others who wish it was shorter, but we need to draw a line in the sand somewhere and this schedule seems like a good place to draw it. If you are in some way funding development of QGIS features (or building them yourself), please bear in mind that the features being developed for you will no longer be part of the nightly builds after 15 March unless they are already part of the 'master' code base at that time. Also if you have the financial resources to do so, please consider hiring a developer to take care of one or more blocker issues so that we can avoid extending the release deadline because of blockers. If you take this path, please also ask your contractee to provide unit tests for the fixes so that we can ensure that there are no regressions in the future. As always donations to the project itself to support fixing these blockers will be gratefully accepted - contact Paolo Cavallini if you need more info, or visit our donations page[2]. To bug queue maintainers, could you please go through the blocker list and carefully evaluate whether they should really be in the blocker queue. IMHO a blocker should be a cross cutting issue (i.e. not affecting a user base of 1 only) that causes QGIS to crash, corrupt data or introduces a significant regression to existing functionality. To documentors and translators - its probably a good time to start encouraging your communities to get ready for 2.0 and start translating / documenting new features. [1] http://hub.qgis.org/projects/quantum-gis/issues?query_id=23 [2] http://www.qgis.org/en/sponsorship.html Regards Tim -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with
Re: [Qgis-developer] Feature freeze commencing the ides of March
I agree with Radim we need to start calling this much early then this. 2 or 3 months should be fine but I also think that we should have a more planned out release time. This way people know it is coming +/- a month or so. - Nathan On 4 Mar 2013 21:52, Radim Blazek radim.bla...@gmail.com wrote: On Mon, Mar 4, 2013 at 11:58 AM, Matthias Kuhn matthias.k...@gmx.ch wrote: Hi, I appreciate that a release plan is finally getting published and the way for a shiny 2.0 is being paved. I'm currently working on relation enhancements and nested forms for related features. Unfortunately, this branch will not be ready by March 15, but I know, that there are some people who would like to see this included in 2.0. I'm sure it will offer a handy possibility for lots of users. Of course, there will always be some new features, that just won't make it into a new release and as Tim said, the line has to be drawn somewhere in the sand. Anyway, if the feature freeze would be a month later, the relation enhancements could go into master before 2.0. So I have the same question as Marco. What should we do: wait for 2.1, shift feature freeze or except this from feature freeze? It seems that 2 weeks to finish all works won't be sufficient. The date itself probably would not be problem if it was announced 2 months ago. We should have probably always enough time between freeze announcement and freeze date. Some developers are also working on contracted works which are expected to go to 2.0. And it was reasonable expectation if feature freeze date was not known until now. I think that feature freeze should be announced at least 2 months before feature freeze. Radim Kind regards, Matthias On 03/04/2013 11:37 AM, Marco Hugentobler wrote: Hi Tim The release plan sounds good to me (especially the longer bug fix period). I don't know however if 15 March is a bit close for feature freeze (at least for me, see below). Things we planned to fix for 2.0 that still need love are, IMHO: * general interface cleanup * symbology migration to the new one * labelling migration to the new one * Sextante bugfixing, and especially setting up a full test suite for it For symbology migration from old to new one, I have good news: thanks to a project from Uster and Jena, I can implement data defined symbology settings for new symbology. It is one of the few things which are possible in old symbology and not in new. Disadvantage is that 15 March is too close for it to go into master. What should we do (wait for 2.1 / shift feature freeze date / exception from feature freeze) ? Regards, Marco On 02.03.2013 22:15, Tim Sutton wrote: Hi All I would like to get 2.0 release process rolling - I think all the key features we were after have made their way into master and those that haven't can probably wait for 2.1. Unless there is vigorous and widespread objection, I propose that we embark on the following release schedule: 15 March 2013 - Feature freeze - no new features in master 1 April 2013 - GUI Freeze and String freeze - no changes to ui or strings except where required for critical bug fixes. Call for translations. 1 June 2013 - Branch 2.0, code freeze (except for packaging related changes), call for packaging 7 June 2013 - Public release of 2.0 The schedule basically allows for 3 months in order to work away the ~50 blockers in the bug queue.[1] I appreciate there are some who will wish the release period is longer and others who wish it was shorter, but we need to draw a line in the sand somewhere and this schedule seems like a good place to draw it. If you are in some way funding development of QGIS features (or building them yourself), please bear in mind that the features being developed for you will no longer be part of the nightly builds after 15 March unless they are already part of the 'master' code base at that time. Also if you have the financial resources to do so, please consider hiring a developer to take care of one or more blocker issues so that we can avoid extending the release deadline because of blockers. If you take this path, please also ask your contractee to provide unit tests for the fixes so that we can ensure that there are no regressions in the future. As always donations to the project itself to support fixing these blockers will be gratefully accepted - contact Paolo Cavallini if you need more info, or visit our donations page[2]. To bug queue maintainers, could you please go through the blocker list and carefully evaluate whether they should really be in the blocker queue. IMHO a blocker should be a cross cutting issue (i.e. not affecting a user base of 1 only) that causes QGIS to crash, corrupt data or introduces a significant regression to existing functionality. To documentors and translators - its probably a
Re: [Qgis-developer] Feature freeze commencing the ides of March
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 04/03/2013 12:52, Radim Blazek ha scritto: It seems that 2 weeks to finish all works won't be sufficient. How about planning a 2.1 release shortly after June, where all this job could fit in? I know it's imposing an additional strain on the whole chain, but it might be a good compromise. - From the power user point of view, please remember that we are now in a farily difficult state, with a 1.8 with several bugs, and a dev version with several of these fixed, but often broken. Thanks. - -- 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.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlE0jO4ACgkQ/NedwLUzIr77DwCggyuEXb3f0cM3oIi7Z/Pw7XXb oosAn0DhEC0vBrSVUNGlJARZ2nGaHdiL =sU9z -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Feature freeze commencing the ides of March
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 04/03/2013 12:52, Radim Blazek ha scritto: It seems that 2 weeks to finish all works won't be sufficient. How about planning a 2.1 release shortly after June, where all this job could fit in? I know it's imposing an additional strain on the whole chain, but it might be a good compromise. - From the power user point of view, please remember that we are now in a fairly difficult state, with a 1.8 with several bugs, and a dev version with several of these fixed, but often broken. Thanks. - -- 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.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlE0jP4ACgkQ/NedwLUzIr4wcwCgpP4DoNZMy1mWpYISSenmT7Mz MO0An0Log9SYhb0ZFp9f9VY9hVahz0Ir =BA9q -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Feature freeze commencing the ides of March
Moving the date to say start of April wouldn't hurt. Would that help? Start of April would be ok for the data defined symbology. Regards, Marco On 04.03.2013 11:44, Jürgen E. Fischer wrote: Hi Marco, On Mon, 04. Mar 2013 at 11:37:15 +0100, Marco Hugentobler wrote: Disadvantage is that 15 March is too close for it to go into master. What should we do (wait for 2.1 / shift feature freeze date / exception from feature freeze) ? How much time would you need? Moving the date to say start of April wouldn't hurt. Would that help? Jürgen -- Dr. Marco Hugentobler Sourcepole - Linux Open Source Solutions Weberstrasse 5, CH-8004 Zürich, 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] Feature freeze commencing the ides of March
Hi On Mon, Mar 4, 2013 at 1:52 PM, Radim Blazek radim.bla...@gmail.com wrote: On Mon, Mar 4, 2013 at 11:58 AM, Matthias Kuhn matthias.k...@gmx.ch wrote: Hi, I appreciate that a release plan is finally getting published and the way for a shiny 2.0 is being paved. I'm currently working on relation enhancements and nested forms for related features. Unfortunately, this branch will not be ready by March 15, but I know, that there are some people who would like to see this included in 2.0. I'm sure it will offer a handy possibility for lots of users. Of course, there will always be some new features, that just won't make it into a new release and as Tim said, the line has to be drawn somewhere in the sand. Anyway, if the feature freeze would be a month later, the relation enhancements could go into master before 2.0. So I have the same question as Marco. What should we do: wait for 2.1, shift feature freeze or except this from feature freeze? It seems that 2 weeks to finish all works won't be sufficient. The date itself probably would not be problem if it was announced 2 months ago. We should have probably always enough time between freeze announcement and freeze date. Some developers are also working on contracted works which are expected to go to 2.0. And it was reasonable expectation if feature freeze date was not known until now. I think that feature freeze should be announced at least 2 months before feature freeze. Well in Essen we said we were going to wait for a defined feature set to make it into GIT and then call the freeze. Basically we have been waiting for Martin's vector refactor branch to be merged and other features as listed on our short list. We didnt have an ETA for this so we didnt have a specific freeze date. I'm happy to follow your suggestion for 2.1 but I'm not sure we want to wait another 2 months before commencing feature freeze for 2.0 (during which other new features will start arriving and being almost ready just before the cut off date etc.). I would propose we give specific features (Marco H and Matthias K's work) leeway to come into master up to 1 April but still call the freeze on 15 March as laid out. If there is a general concensus that we should wait two months before the freeze then we can shift the timeline along I guess. Regards Tim Radim Kind regards, Matthias On 03/04/2013 11:37 AM, Marco Hugentobler wrote: Hi Tim The release plan sounds good to me (especially the longer bug fix period). I don't know however if 15 March is a bit close for feature freeze (at least for me, see below). Things we planned to fix for 2.0 that still need love are, IMHO: * general interface cleanup * symbology migration to the new one * labelling migration to the new one * Sextante bugfixing, and especially setting up a full test suite for it For symbology migration from old to new one, I have good news: thanks to a project from Uster and Jena, I can implement data defined symbology settings for new symbology. It is one of the few things which are possible in old symbology and not in new. Disadvantage is that 15 March is too close for it to go into master. What should we do (wait for 2.1 / shift feature freeze date / exception from feature freeze) ? Regards, Marco On 02.03.2013 22:15, Tim Sutton wrote: Hi All I would like to get 2.0 release process rolling - I think all the key features we were after have made their way into master and those that haven't can probably wait for 2.1. Unless there is vigorous and widespread objection, I propose that we embark on the following release schedule: 15 March 2013 - Feature freeze - no new features in master 1 April 2013 - GUI Freeze and String freeze - no changes to ui or strings except where required for critical bug fixes. Call for translations. 1 June 2013 - Branch 2.0, code freeze (except for packaging related changes), call for packaging 7 June 2013 - Public release of 2.0 The schedule basically allows for 3 months in order to work away the ~50 blockers in the bug queue.[1] I appreciate there are some who will wish the release period is longer and others who wish it was shorter, but we need to draw a line in the sand somewhere and this schedule seems like a good place to draw it. If you are in some way funding development of QGIS features (or building them yourself), please bear in mind that the features being developed for you will no longer be part of the nightly builds after 15 March unless they are already part of the 'master' code base at that time. Also if you have the financial resources to do so, please consider hiring a developer to take care of one or more blocker issues so that we can avoid extending the release deadline because of blockers. If you take this path, please also ask your contractee to provide unit tests for the fixes so that we can ensure that there are no regressions in the future. As always donations to the project
Re: [Qgis-developer] Feature freeze commencing the ides of March
Hi, We have the (german speaking) FOSSGIS 2013 conference in Switzerland from June 12 to 14 - would be kind of nice if we could announce QGIS 2.0 there (http://www.fossgis.de/konferenz/2013/). I agree that data-defined symbology and raster improvements should be finished. The relations manager would be nice as well - though, with only relations manager, you cannot do much. You would also need the nested forms - and this will most likely not make it into QGIS 2.0. Thanks, Andreas On Mon, 4 Mar 2013 15:40:24 +0200, Tim Sutton wrote: Hi On Mon, Mar 4, 2013 at 1:52 PM, Radim Blazek radim.bla...@gmail.com wrote: On Mon, Mar 4, 2013 at 11:58 AM, Matthias Kuhn matthias.k...@gmx.ch wrote: Hi, I appreciate that a release plan is finally getting published and the way for a shiny 2.0 is being paved. I'm currently working on relation enhancements and nested forms for related features. Unfortunately, this branch will not be ready by March 15, but I know, that there are some people who would like to see this included in 2.0. I'm sure it will offer a handy possibility for lots of users. Of course, there will always be some new features, that just won't make it into a new release and as Tim said, the line has to be drawn somewhere in the sand. Anyway, if the feature freeze would be a month later, the relation enhancements could go into master before 2.0. So I have the same question as Marco. What should we do: wait for 2.1, shift feature freeze or except this from feature freeze? It seems that 2 weeks to finish all works won't be sufficient. The date itself probably would not be problem if it was announced 2 months ago. We should have probably always enough time between freeze announcement and freeze date. Some developers are also working on contracted works which are expected to go to 2.0. And it was reasonable expectation if feature freeze date was not known until now. I think that feature freeze should be announced at least 2 months before feature freeze. Well in Essen we said we were going to wait for a defined feature set to make it into GIT and then call the freeze. Basically we have been waiting for Martin's vector refactor branch to be merged and other features as listed on our short list. We didnt have an ETA for this so we didnt have a specific freeze date. I'm happy to follow your suggestion for 2.1 but I'm not sure we want to wait another 2 months before commencing feature freeze for 2.0 (during which other new features will start arriving and being almost ready just before the cut off date etc.). I would propose we give specific features (Marco H and Matthias K's work) leeway to come into master up to 1 April but still call the freeze on 15 March as laid out. If there is a general concensus that we should wait two months before the freeze then we can shift the timeline along I guess. Regards Tim Radim Kind regards, Matthias On 03/04/2013 11:37 AM, Marco Hugentobler wrote: Hi Tim The release plan sounds good to me (especially the longer bug fix period). I don't know however if 15 March is a bit close for feature freeze (at least for me, see below). Things we planned to fix for 2.0 that still need love are, IMHO: * general interface cleanup * symbology migration to the new one * labelling migration to the new one * Sextante bugfixing, and especially setting up a full test suite for it For symbology migration from old to new one, I have good news: thanks to a project from Uster and Jena, I can implement data defined symbology settings for new symbology. It is one of the few things which are possible in old symbology and not in new. Disadvantage is that 15 March is too close for it to go into master. What should we do (wait for 2.1 / shift feature freeze date / exception from feature freeze) ? Regards, Marco On 02.03.2013 22:15, Tim Sutton wrote: Hi All I would like to get 2.0 release process rolling - I think all the key features we were after have made their way into master and those that haven't can probably wait for 2.1. Unless there is vigorous and widespread objection, I propose that we embark on the following release schedule: 15 March 2013 - Feature freeze - no new features in master 1 April 2013 - GUI Freeze and String freeze - no changes to ui or strings except where required for critical bug fixes. Call for translations. 1 June 2013 - Branch 2.0, code freeze (except for packaging related changes), call for packaging 7 June 2013 - Public release of 2.0 The schedule basically allows for 3 months in order to work away the ~50 blockers in the bug queue.[1] I appreciate there are some who will wish the release period is longer and others who wish it was shorter, but we need to draw a line in the sand somewhere and this schedule seems like a good place to draw it. If you are in some way funding development of QGIS features (or building them yourself), please bear in mind that the features being developed for you
Re: [Qgis-developer] Feature freeze commencing the ides of March
Hi, On Mon, Mar 4, 2013 at 6:40 AM, Tim Sutton li...@linfiniti.com wrote: Hi On Mon, Mar 4, 2013 at 1:52 PM, Radim Blazek radim.bla...@gmail.com wrote: On Mon, Mar 4, 2013 at 11:58 AM, Matthias Kuhn matthias.k...@gmx.ch wrote: Hi, I appreciate that a release plan is finally getting published and the way for a shiny 2.0 is being paved. I'm currently working on relation enhancements and nested forms for related features. Unfortunately, this branch will not be ready by March 15, but I know, that there are some people who would like to see this included in 2.0. I'm sure it will offer a handy possibility for lots of users. Of course, there will always be some new features, that just won't make it into a new release and as Tim said, the line has to be drawn somewhere in the sand. Anyway, if the feature freeze would be a month later, the relation enhancements could go into master before 2.0. So I have the same question as Marco. What should we do: wait for 2.1, shift feature freeze or except this from feature freeze? It seems that 2 weeks to finish all works won't be sufficient. The date itself probably would not be problem if it was announced 2 months ago. We should have probably always enough time between freeze announcement and freeze date. Some developers are also working on contracted works which are expected to go to 2.0. And it was reasonable expectation if feature freeze date was not known until now. I think that feature freeze should be announced at least 2 months before feature freeze. Well in Essen we said we were going to wait for a defined feature set to make it into GIT and then call the freeze. Basically we have been waiting for Martin's vector refactor branch to be merged and other features as listed on our short list. We didnt have an ETA for this so we didnt have a specific freeze date. I'm happy to follow your suggestion for 2.1 but I'm not sure we want to wait another 2 months before commencing feature freeze for 2.0 (during which other new features will start arriving and being almost ready just before the cut off date etc.). I would propose we give specific features (Marco H and Matthias K's work) leeway to come into master up to 1 April but still call the freeze on 15 March as laid out. If there is a general concensus that we should wait two months before the freeze then we can shift the timeline along I guess. +1 for April 1 as a general feature freeze date, i.e. not for any specific feature. I believe that's enough time to finish some of the labeling features I've been wanting to focus on for 2.0. If someone could help out with optimizing PAL for speed, that would be great. I think it may be above my standard C++ coding skills at this time. Maybe 15 April 2013 for GUI Freeze and String freeze, but keep the same timetable for the rest... can always bump those dates if blockers can not be rectified. Here's a suggestion related to the feature freeze: Considering the sheer number of new features and the lack of any beta version, it might be prudent to also have the feature freeze extended beyond the release date. While I understand the current focus is to not do any incremental or backported updates, e.g. version 2.0.1, due to lack of resources, I feel this may hurt the project with regards to this particular release. If the feature freeze remains in effect for a certain time beyond the release it will allow the public to test the new version and have the developers respond without having to work on two separate branches. In other words, I suggest we should plan for one (and only one) incremental release, 2.0.1, and notify users upon release of 2.0 that they have a set amount of time to report bugs that should be addressed for 2.0.1. IMHO, if we again have to essentially say to users, 'you'll have to wait until 2.1, just keep using it broken,' it would be a bad thing. However, I also suggest with such a setup that after 2.0.1 there only be forward commits to 2.1, with zero backporting. In fact, with such a setup there should never be any backporting or working on multiple branches, except new feature branches waiting for the freeze to end. In other words, I think the project would maintain good karma if it publicly acknowledged the need for a bug fix release after such a significant release as 2.0. Best regards, Larry Regards Tim Radim Kind regards, Matthias On 03/04/2013 11:37 AM, Marco Hugentobler wrote: Hi Tim The release plan sounds good to me (especially the longer bug fix period). I don't know however if 15 March is a bit close for feature freeze (at least for me, see below). Things we planned to fix for 2.0 that still need love are, IMHO: * general interface cleanup * symbology migration to the new one * labelling migration to the new one * Sextante bugfixing, and especially setting up a full test suite for it For symbology migration
Re: [Qgis-developer] Feature freeze commencing the ides of March
On Mar 4, 2013 8:17 PM, Larry Shaffer lar...@dakotacarto.com wrote: +1 for April 1 as a general feature freeze date, i.e. not for any specific feature. I believe that's enough time to finish some of the labeling features I've been wanting to focus on for 2.0. If someone could help out with optimizing PAL for speed, that would be great. I think it may be above my standard C++ coding skills at this time. Also from my point of view, April 1 is a better target to finish 2.0 features. Seeing my recent development speed (slowness) it is clear that threaded rendering has to be moved to 2.1 or later. It seems that merging of new vector api branch has introduced various bugs that I need to focus on in the followong weeks... I would also like to finally remove old symbology - whether being fully replaced by features in new symbology or not - otherwise we will need to live the whole 2.x release cycle with old symbology. Regards Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Feature freeze commencing the ides of March
On Tue, 5 Mar 2013 01:28:30 +0100 Martin Dobias wonder...@gmail.com wrote: I would also like to finally remove old symbology - whether being fully replaced by features in new symbology or not - otherwise we will need to live the whole 2.x release cycle with old symbology. But what about other duplicate things like old labeling and diagrams? As I understand Marco works on improving new symbology (data-defined settings) so old one can be removed too. Regarding diagrams, if I'm not wrong, new implementation has same features as old and can replace it smoothly. -- Alexander Bruy ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Feature freeze commencing the ides of March
On 03/05/2013 08:06 AM, Alexander Bruy wrote: On Tue, 5 Mar 2013 01:28:30 +0100 Martin Dobias wonder...@gmail.com wrote: I would also like to finally remove old symbology - whether being fully replaced by features in new symbology or not - otherwise we will need to live the whole 2.x release cycle with old symbology. But what about other duplicate things like old labeling and diagrams? As I understand Marco works on improving new symbology (data-defined settings) so old one can be removed too. Regarding diagrams, if I'm not wrong, new implementation has same features as old and can replace it smoothly. Diagrams should be ready for 2.0. The code has been merged about half a year ago. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Feature freeze commencing the ides of March
The new diagrams engine is solid, working better than the old one in all the scenarios I've met. It's only weakness is that it doesn't play well with the PAL engine. M On Tue, Mar 5, 2013 at 2:10 PM, Matthias Kuhn matthias.k...@gmx.ch wrote: On 03/05/2013 08:06 AM, Alexander Bruy wrote: On Tue, 5 Mar 2013 01:28:30 +0100 Martin Dobias wonder...@gmail.com wrote: I would also like to finally remove old symbology - whether being fully replaced by features in new symbology or not - otherwise we will need to live the whole 2.x release cycle with old symbology. But what about other duplicate things like old labeling and diagrams? As I understand Marco works on improving new symbology (data-defined settings) so old one can be removed too. Regarding diagrams, if I'm not wrong, new implementation has same features as old and can replace it smoothly. Diagrams should be ready for 2.0. The code has been merged about half a year ago. __**_ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/**mailman/listinfo/qgis-**developerhttp://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] Feature freeze commencing the ides of March
2013/3/5 Matthias Kuhn matthias.k...@gmx.ch: On 03/05/2013 08:06 AM, Alexander Bruy wrote: Diagrams should be ready for 2.0. The code has been merged about half a year ago. Yes, I know. But old implementation also still available. -- Alexander Bruy ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Feature freeze commencing the ides of March
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 02/03/2013 22:15, Tim Sutton ha scritto: I would like to get 2.0 release process rolling - I think all the key features we were after have made their way into master and those that haven't can probably wait for 2.1. Unless there is vigorous and widespread objection, I propose that we embark on the following release schedule: Hi Tim, thanks a lot for drawing the line - much needed. Things we planned to fix for 2.0 that still need love are, IMHO: * general interface cleanup * symbology migration to the new one * labelling migration to the new one * Sextante bugfixing, and especially setting up a full test suite for it So I would solicitate funders and developers to concentrate on these issues, during feature freeze. I would add the same target (7 June) for the publication of the new website (we're going to work on this in Valmiera, hopefully this is feasible). Additionally, I would like to release with plugins in good shape: * add a bugtracker for all the plugins that miss it * update to the new API the plugins that are not working * migrate the plugin from the old to the new repo I think that, given the rather long period of feature freeze, we should be tolerant and lift it in very limited circumstances for non invasive, well tested [with unit tests] improvements. 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.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEzF7IACgkQ/NedwLUzIr5KZQCgo1hN9rK9viwiHTfGXDig+8Zz 5B4An23bSqh0GuV3XEmovsPDOo889pps =sz48 -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Feature freeze commencing the ides of March
Dnia sobota, 2 marca 2013 o 22:15:41 Tim Sutton napisał(a): Hi All I would like to get 2.0 release process rolling - I think all the key features we were after have made their way into master and those that haven't can probably wait for 2.1. Unless there is vigorous and widespread objection, I propose that we embark on the following release schedule: It will be great to see the 2.0 in the end, however first I'd like to ensure its API will be ready for all the features to be postponed to 2.1. Of course, I mean especially the threading. I would ask Martin about his attitude to the freeze date. Also Radim put Raster API revision to his hackfest tasks. Seems we postpone the long-awaited GUI usability overhaul to 2.1, but at least we should decide for the horizontal/vertical tabs :) B. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Feature freeze commencing the ides of March
Hi, On Sun, Mar 3, 2013 at 2:58 AM, Borys Jurgiel li...@borysjurgiel.pl wrote: Dnia sobota, 2 marca 2013 o 22:15:41 Tim Sutton napisał(a): Hi All I would like to get 2.0 release process rolling - I think all the key features we were after have made their way into master and those that haven't can probably wait for 2.1. Unless there is vigorous and widespread objection, I propose that we embark on the following release schedule: It will be great to see the 2.0 in the end, however first I'd like to ensure its API will be ready for all the features to be postponed to 2.1. Of course, I mean especially the threading. I would ask Martin about his attitude to the freeze date. Also Radim put Raster API revision to his hackfest tasks. Seems we postpone the long-awaited GUI usability overhaul to 2.1, but at least we should decide for the horizontal/vertical tabs :) That's next on my list. :^) I'll be finishing the work on converting the project, vector and raster option dialogs to vertical tabs, probably starting on Monday. Considering the number of current outstanding issues for the project as a whole, I think any more large GUI changes (like the recent ones to Print Composer) should be slated for 2.1. There is still quite a bit of work just to bring more consistency to the current GUI. Regards, Larry B. ___ 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] Feature freeze commencing the ides of March
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 03/03/2013 11:33, Nathan Woodrow ha scritto: add vector layer stuff is starting to really get out of hand. I would like to use the vertical tab idea and just have one dialog. I had bigger plans for the dialog but don't have time currently. Hi Nathan, could you please elaborate a little bit more on this? Thanks. - -- 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.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEzJ6QACgkQ/NedwLUzIr5+CgCghX7IxT9vvmlTTO+tXNXzPbma Xu0An3Eam35htKVRY663QdNkgPcBALYu =L447 -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Feature freeze commencing the ides of March
* symbology migration to the new one * labelling migration to the new one related issues are here http://hub.qgis.org/wiki/quantum-gis/Switching_from_Old_to_New_Symbology_and_Labeling Would not be also great to fix issue that are known to cause crashes or data corruption, but are not not known regressions so are not tagged as blockers? http://hub.qgis.org/projects/quantum-gis/issues?query_id=27 otherwise in 2.0 we will ship tools that are known to fail. cheers -- Giovanni -- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Feature freeze commencing the ides of March
Paolo, I had the idea of using the vertical list of icons on the left, one for each provider, and having the current providers widget/dialog that opens normally when you press the button docked on the right. This would mean the UI is more consistent with the other dialog that follow this style and would reduce the Open xxx Layer down to a single Add Data/Layer button. I will see if my new employer is happy for me to spend some time on this for 2.0. - Nathan On Sun, Mar 3, 2013 at 8:36 PM, Paolo Cavallini cavall...@faunalia.itwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 03/03/2013 11:33, Nathan Woodrow ha scritto: add vector layer stuff is starting to really get out of hand. I would like to use the vertical tab idea and just have one dialog. I had bigger plans for the dialog but don't have time currently. Hi Nathan, could you please elaborate a little bit more on this? Thanks. - -- 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.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEzJ6QACgkQ/NedwLUzIr5+CgCghX7IxT9vvmlTTO+tXNXzPbma Xu0An3Eam35htKVRY663QdNkgPcBALYu =L447 -END PGP SIGNATURE- ___ 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] Feature freeze commencing the ides of March
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 03/03/2013 13:58, Nathan Woodrow ha scritto: Paolo, I had the idea of using the vertical list of icons on the left, one for each provider, and having the current providers widget/dialog that opens normally when you press the button docked on the right. This would mean the UI is more consistent with the other dialog that follow this style and would reduce the Open xxx Layer down to a single Add Data/Layer button. I will see if my new employer is happy for me to spend some time on this for 2.0. I see, thanks. Wouldn't it be better to remove it entirely, and put all the necessary functions in the Browser? 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.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEzj8oACgkQ/NedwLUzIr4LzwCfflzsb8dfA/FZcw9oLmiQar3Q FQsAoLv79IM/zWnKjTYSdIiwW7QCYXY0 =VHUK -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
