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 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 _______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
