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

Mon Mar 4 11:17:52 PST 2013

Hi,

On Mon, Mar 4, 2013 at 6:40 AM, Tim Sutton <lists at linfiniti.com> wrote:

> Hi
>
> On Mon, Mar 4, 2013 at 1:52 PM, 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.
> >
>
> 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 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
>
>
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20130304/9a52fed2/attachment-0001.html>