[Qgis-developer] Feature freeze commencing the ides of March

Nathan Woodrow madmanwoo at gmail.com
Mon Mar 4 03:58:02 PST 2013


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.blazek at gmail.com> wrote:

> On Mon, Mar 4, 2013 at 11:58 AM, Matthias Kuhn <matthias.kuhn at 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 at lists.osgeo.org
> >>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> >>
> >>
> >>
> >
> > _______________________________________________
> > Qgis-developer mailing list
> > Qgis-developer at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/qgis-developer
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20130304/9d1dbc85/attachment-0001.html>


More information about the Qgis-developer mailing list