Hi
On 03/04/2013 08:17 PM, Larry Shaffer wrote:
Hi,
On Mon, Mar 4, 2013 at 6:40 AM, Tim Sutton <li...@linfiniti.com
<mailto:li...@linfiniti.com>> wrote:
Hi
On Mon, Mar 4, 2013 at 1:52 PM, Radim Blazek
<radim.bla...@gmail.com <mailto:radim.bla...@gmail.com>> wrote:
> On Mon, Mar 4, 2013 at 11:58 AM, Matthias Kuhn
<matthias.k...@gmx.ch <mailto: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.
>
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
_______________________________________________
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
