Releases in 3 months

[Àlex Fiestas]

On Tuesday 09 July 2013 16:12:35 Andras Mantia wrote:
> Two point I want to mention:
> 1) working in a branch for kdepim is quite painful, as you need actually
> work on branches of 3 (or sometimes 4) modules: kdepimlibs, kdepim-runtime,
> kdepim (and akonadi). Keep them up-to-date, merge them at the right point,
> etc. Developing in master is *much* easier.
I do this web KDE-Accounts integration, it is more painful but doable, not 
like the month is ending like it was with svn.

> 2) some people don't like branches, we have to understand it. :) There is no
> one schedule that will fit all, that's sure. But dismissing once preference
> with a way that tells him how he SHOULD do, is not really a good.
Developing big features in master is even disrespectful to your fellow 
developers, countless time things have broken because of this and people have 
not been able to use master as their work environment.

I could understand it for small things, and in the case you are an exceptional 
developer that does not make mistakes and tests everything before pushing. So 
maybe we can find a compromise? what about:

Features can be developed in master, if they are big or delicate just add 
compile option to remove them for release.

This way we can we could even add something like
cmake -DDISABLE_WIP_FEATURES 

And then leave this up to each module developers to decide whether this way of 
working is acceptable for them or not.

What do you think?
> I also find the motivation somewhat contradictory. Yes, you want to provide
> new features faster, but by cutting down testing time. *Are you sure?*
Testing time by whom? we will be cutting not even a month of user testing 
(according to 4.11 schedule).