[Marble-devel] feature freeze

[Torsten Rahn]

On Monday 27 April 2009 10:54:55 Patrick Spendrin wrote:
> as feature freeze is coming near and we have once again two GSoC
> students working with us, there is once again the feature freeze of the
> KDE 4.3 release in our way.

Well I wouldn't say it's in our way ;-)

Official GSoC will start on May 23rd, so I feel that we still have about 2-3 
weeks left to make up our minds about this. 

Regarding the feature freeze: In general it's always very subjective to decide 
what is a new feature and what is just "a fix" or an "optimization". 

Therefore I'd like to clarify the timeline a bit for Marble:

May 4th, Beta 1:
==========
After this day:
- No new user-visible features should be started anymore. Those features which 
have their basics working but need some fixing and polishing can still be 
committed to (like e.g. the panoramio plugin and the planet filter).

- No new tr() and i18n() strings are allowed. Only if during the Beta 1 phase 
there turns out to be some strings completely "wrong" then these changes may 
be changed if kde-i18n agrees to it. However naturally this shouldn't be 
necessary and should be avoided.

- Backend-Improvements like e.g. speed optimization and e.g. (new handlers 
for) KML parsing can still be addressed. I consider these kinds of changes 
"fixes" and "polishing" for the functionality. Bigger backend changes that 
could break things shouldn't happen at this time anymore. So if you want to 
make a bigger backend change you need to provide a patch that provides the 
whole tested functionality that fully works.

- API might still be subject to change. 


May23rd, 2009: Students officially start their work on their GSoC project
==========================================
Action items about these need to be discussed


May 26th, 2009: Documentation/Handbook Freeze 
=============================
- We need to make sure that the User Docs are ready by this point of time 
(Screenshots and Text).


June 2th, 2009: Tag KDE 4.3 Beta 2 
====================
- Minor speed optimizations and fixes are allowed after this point of time only
- We'd like to have the final API for the 0.8 (and maybe 0.9 series) in place 
and ideally not to change. All API Changes need peer review and need to get 
communicated to the Python binding author.
- All buildsystem


June 23rd, 2009: Tag KDE 4.3 RC 1 
====================
- Only urgent bugfixes are allowed


I wonder whether it would make sense to branch the Marble development branch 
off on June 2nd

> So instead of adding multiple branches now and doing work there, I think
> we also could move the qt only marble code to kdesupport. 

Interesting idea.
I'm not sure though whether this would help: what "version" of kdesupport is 
supposed to be shipped with KDE 4.3 then? I also wonder that if we "move" 
there prematurely whether this wouldn't confuse packagers so that maybe they 
package the wrong thing? :)

> This would
> mean that we have a) a repository which is open for further development,
> b) we don't need to keep up the branches and c) we make marblewidget
> available for all applications in KDE (and of course also outside KDE).
>
> This will also remove the problems of the shared code between KDE and Qt
> version of marble and we can certainly cleanup the cmake code after it.

Sounds interesting. But I'd like to have a more detailed plan (ideally in the 
wiki) about this. We also need some wiki page that has the planning for the 
kdesupport move in general (what steps need to be taken, etc.).

If we go for this I'd say that June 2nd (Beta 2) could be a good point to do 
this. 

Regards,

Torsten

> What do you think?
>
> regards,
> Patrick