<p dir="ltr">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.</p>

<p dir="ltr">- Nathan</p>
<div class="gmail_quote">On 4 Mar 2013 21:52, "Radim Blazek" <<a href="mailto:radim.blazek@gmail.com">radim.blazek@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, Mar 4, 2013 at 11:58 AM, Matthias Kuhn <<a href="mailto:matthias.kuhn@gmx.ch">matthias.kuhn@gmx.ch</a>> wrote:<br>
> Hi,<br>
><br>
> I appreciate that a release plan is finally getting published and the way<br>
> for a shiny 2.0 is being paved.<br>
><br>
> I'm currently working on relation enhancements and nested forms for related<br>
> features. Unfortunately, this branch will not be ready by March 15, but I<br>
> know, that there are some people who would like to see this included in 2.0.<br>
> I'm sure it will offer a handy possibility for lots of users.<br>
> Of course, there will always be some new features, that just won't make it<br>
> into a new release and as Tim said, "the line has to be drawn somewhere in<br>
> the sand".<br>
> Anyway, if the feature freeze would be a month later, the relation<br>
> enhancements could go into master before 2.0.<br>
><br>
> So I have the same question as Marco. What should we do: wait for 2.1, shift<br>
> feature freeze or except this from feature freeze?<br>
<br>
It seems that 2 weeks to finish all works won't be sufficient. The<br>
date itself probably would not be problem if it was announced 2 months<br>
ago. We should have probably always enough time between freeze<br>
announcement and freeze date. Some developers are also working on<br>
contracted works which are expected to go to 2.0. And it was<br>
reasonable expectation if feature freeze date was not known until now.<br>
<br>
I think that feature freeze should be announced at least 2 months<br>
before feature freeze.<br>
<br>
Radim<br>
<br>
> Kind regards,<br>
> Matthias<br>
><br>
><br>
> On 03/04/2013 11:37 AM, Marco Hugentobler wrote:<br>
>><br>
>> Hi Tim<br>
>><br>
>> The release plan sounds good to me (especially the longer bug fix period).<br>
>> I don't know however if 15 March is a bit close for feature freeze (at least<br>
>> for me, see below).<br>
>><br>
>> >Things we planned to fix for 2.0 that still need love are, IMHO:<br>
>> >* general interface cleanup<br>
>> >* symbology migration to the new one<br>
>> >* labelling migration to the new one<br>
>> >* Sextante bugfixing, and especially setting up a full test suite for it<br>
>><br>
>> For symbology migration from old to new one, I have good news: thanks to a<br>
>> project from Uster and Jena, I can implement data defined symbology settings<br>
>> for new symbology. It is one of the few things which are possible in old<br>
>> symbology and not in new. Disadvantage is that 15 March is too close for it<br>
>> to go into master. What should we do (wait for 2.1 / shift feature freeze<br>
>> date / exception from feature freeze) ?<br>
>><br>
>><br>
>> Regards,<br>
>> Marco<br>
>><br>
>> On 02.03.2013 22:15, Tim Sutton wrote:<br>
>>><br>
>>> Hi All<br>
>>><br>
>>> I would like to get 2.0 release process rolling - I think all the key<br>
>>> features we were after have made their way into master and those that<br>
>>> haven't can probably wait for 2.1. Unless there is vigorous and<br>
>>> widespread objection, I propose that we embark on the following<br>
>>> release schedule:<br>
>>><br>
>>> 15 March 2013 - Feature freeze - no new features in master<br>
>>> 1 April 2013 - GUI Freeze and String freeze - no changes to ui or<br>
>>> strings except where required for critical bug fixes. Call for<br>
>>> translations.<br>
>>> 1 June 2013 - Branch 2.0, code freeze (except for packaging related<br>
>>> changes), call for packaging<br>
>>> 7 June 2013 - Public release of 2.0<br>
>>><br>
>>> The schedule basically allows for 3 months in order to work away the<br>
>>> ~50 blockers in the bug queue.[1]<br>
>>><br>
>>> I appreciate there are some who will wish the release period is longer<br>
>>> and others who wish it was shorter, but we need to draw a line in the<br>
>>> sand somewhere and this schedule seems like a good place to draw it.<br>
>>><br>
>>> If you are in some way funding development of QGIS features (or<br>
>>> building them yourself), please bear in mind that the features being<br>
>>> developed for you will no longer be part of the nightly builds after<br>
>>> 15 March unless they are already part of the 'master' code base at<br>
>>> that time.<br>
>>><br>
>>> Also if you have the financial resources to do so, please consider<br>
>>> hiring a developer to take care of one or more blocker issues so that<br>
>>> we can avoid extending the release deadline because of blockers. If<br>
>>> you take this path, please also ask your contractee to provide unit<br>
>>> tests for the fixes so that we can ensure that there are no<br>
>>> regressions in the future. As always donations to the project itself<br>
>>> to support fixing these blockers will be gratefully accepted - contact<br>
>>> Paolo Cavallini if you need more info, or visit our donations page[2].<br>
>>><br>
>>> To bug queue maintainers, could you please go through the blocker list<br>
>>> and carefully evaluate whether they should really be in the blocker<br>
>>> queue. IMHO a blocker should be a cross cutting issue (i.e. not<br>
>>> affecting a user base of 1 only) that causes QGIS to crash, corrupt<br>
>>> data or introduces a significant regression to existing functionality.<br>
>>><br>
>>> To documentors and translators - its probably a good time to start<br>
>>> encouraging your communities to get ready for 2.0 and start<br>
>>> translating / documenting new features.<br>
>>><br>
>>> [1] <a href="http://hub.qgis.org/projects/quantum-gis/issues?query_id=23" target="_blank">http://hub.qgis.org/projects/quantum-gis/issues?query_id=23</a><br>
>>> [2] <a href="http://www.qgis.org/en/sponsorship.html" target="_blank">http://www.qgis.org/en/sponsorship.html</a><br>
>>><br>
>>> Regards<br>
>>><br>
>>> Tim<br>
>>><br>
>>> --<br>
>>> Tim Sutton - QGIS Project Steering Committee Member (Release Manager)<br>
>>> ==============================================<br>
>>> Please do not email me off-list with technical<br>
>>> support questions. Using the lists will gain<br>
>>> more exposure for your issues and the knowledge<br>
>>> surrounding your issue will be shared with all.<br>
>>><br>
>>> Visit <a href="http://linfiniti.com" target="_blank">http://linfiniti.com</a> to find out about:<br>
>>>   * QGIS programming and support services<br>
>>>   * Mapserver and PostGIS based hosting plans<br>
>>>   * FOSS Consulting Services<br>
>>> Skype: timlinux<br>
>>> Irc: timlinux on #qgis at <a href="http://freenode.net" target="_blank">freenode.net</a><br>
>>> ==============================================<br>
>>> _______________________________________________<br>
>>> Qgis-developer mailing list<br>
>>> <a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
>>> <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
>><br>
>><br>
>><br>
><br>
> _______________________________________________<br>
> Qgis-developer mailing list<br>
> <a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</blockquote></div>