Releases in 3 months
Aurélien Gâteau
agateau at kde.org
Thu Jul 11 10:49:52 BST 2013
Le mercredi 10 juillet 2013 17:55:42 Àlex Fiestas a écrit :
> 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.
This is an interesting approach, it could help for cross-repository features
like a feature requiring changes in kdepimlibs and kdepim, it can also make it
easier to test a feature while you are developing another one (basically it
boils down to -DWITH_MY_FEATURE=ON -DWITH_SOMEONE_ELSE_FEATURE=ON)
There are a few dangers with it though:
- It adds more build system work, which can be error-prone.
- Depending on how invasive the feature is, at one point you may/will commit
code which builds for you but does not build with -DWITH_MY_FEATURE=OFF.
- One must be careful to remove the CMake options after the feature is marked
as stable, to avoid accumulating cruft.
Aurélien
More information about the kde-core-devel
mailing list