Releases in 3 months

[andrea diamantini]

What about a single official development branch?
Just use two branches:
- master branch (stable)
- kdevel branch (devel)
You develop wherever you like and push things on "kdevel" branch when
ready. If you like the "one branch approach", you devel things directly in
kdevel branch.
People knows there are just 2 important branches: master and kdevel. One
people per project can think merging from kdevel to master when things are
"ok".
I think this adds just a tiny layer for people working with one branch and
it is basically the same for "multibranches people". And it allows both
worlds to cohexists.



2013/7/11 Aurélien Gâteau <agateau at kde.org>

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



-- 

Andrea Diamantini
WEB: http://www.adjam.org

Sponsored by BlueSystems to work on the rekonq project
WEB: http://rekonq.kde.org
IRC: rekonq at freenode
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20130711/4cde2802/attachment.htm>