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

[Matthias Kuhn]

Hi

On 03/04/2013 08:17 PM, Larry Shaffer wrote:
> Hi,
>
> On Mon, Mar 4, 2013 at 6:40 AM, Tim Sutton <lists at linfiniti.com 
> <mailto:lists at linfiniti.com>> wrote:
>
>     Hi
>
>     On Mon, Mar 4, 2013 at 1:52 PM, Radim Blazek
>     <radim.blazek at gmail.com <mailto:radim.blazek at gmail.com>> wrote:
>     > On Mon, Mar 4, 2013 at 11:58 AM, Matthias Kuhn
>     <matthias.kuhn at gmx.ch <mailto: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.
>

For me, April 1st will not be enough time to finish this work. I'll 
therefore postpone these features to 2.1.

>
> +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.
>

I also think April 1st as general deadline for new features is the 
better way. Looking at the 22 open pull requests, I don't think core 
developers will be happy to have some more time to review than March 15 
would offer.

> 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

I'm not sure what the best way is to keep new features coming but at the 
same time guarantee for stability.

One thing, while not directly connected to release schedules, is the 
way, issue reports work. We've got now close to 2000 open issues. More 
than anyone could handle. I think we need to shoot down some of the 
non-issues to allow the real bugs to gain some attention. And then keep 
the issue count down by e.g. automatically closing issues being in 
"Feedback" status for more than 2 weeks.

Anyway, I didn't want to distract from the real discussion.
I would appreciate some more opinions on this topic about the way 
forward - and eventually a decision with support from the PSC.

Regards,
Matthias