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