<div dir="ltr">What about a single official development branch?<div>Just use two branches:</div><div>- master branch (stable)</div><div>- kdevel branch (devel)<br><div style>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.</div>
<div style>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".</div><div style>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.</div>
<div style> </div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/7/11 Aurélien Gâteau <span dir="ltr"><<a href="mailto:agateau@kde.org" target="_blank">agateau@kde.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Le mercredi 10 juillet 2013 17:55:42 Àlex Fiestas a écrit :<br>
<div><div class="h5">> On Tuesday 09 July 2013 16:12:35 Andras Mantia wrote:<br>
> > Two point I want to mention:<br>
> > 1) working in a branch for kdepim is quite painful, as you need actually<br>
> > work on branches of 3 (or sometimes 4) modules: kdepimlibs,<br>
> > kdepim-runtime,<br>
> > kdepim (and akonadi). Keep them up-to-date, merge them at the right point,<br>
> > etc. Developing in master is *much* easier.<br>
><br>
> I do this web KDE-Accounts integration, it is more painful but doable, not<br>
> like the month is ending like it was with svn.<br>
><br>
> > 2) some people don't like branches, we have to understand it. :) There is<br>
> > no one schedule that will fit all, that's sure. But dismissing once<br>
> > preference with a way that tells him how he SHOULD do, is not really a<br>
> > good.<br>
><br>
> Developing big features in master is even disrespectful to your fellow<br>
> developers, countless time things have broken because of this and people<br>
> have not been able to use master as their work environment.<br>
><br>
> I could understand it for small things, and in the case you are an<br>
> exceptional developer that does not make mistakes and tests everything<br>
> before pushing. So maybe we can find a compromise? what about:<br>
><br>
> Features can be developed in master, if they are big or delicate just add<br>
> compile option to remove them for release.<br>
><br>
> This way we can we could even add something like<br>
> cmake -DDISABLE_WIP_FEATURES<br>
><br>
> And then leave this up to each module developers to decide whether this way<br>
> of working is acceptable for them or not.<br>
<br>
</div></div>This is an interesting approach, it could help for cross-repository features<br>
like a feature requiring changes in kdepimlibs and kdepim, it can also make it<br>
easier to test a feature while you are developing another one (basically it<br>
boils down to -DWITH_MY_FEATURE=ON -DWITH_SOMEONE_ELSE_FEATURE=ON)<br>
<br>
There are a few dangers with it though:<br>
<br>
- It adds more build system work, which can be error-prone.<br>
<br>
- Depending on how invasive the feature is, at one point you may/will commit<br>
code which builds for you but does not build with -DWITH_MY_FEATURE=OFF.<br>
<br>
- One must be careful to remove the CMake options after the feature is marked<br>
as stable, to avoid accumulating cruft.<br>
<span class="HOEnZb"><font color="#888888"><br>
Aurélien<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><pre style="color:rgb(0,0,0);font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;word-spacing:0px;background-color:rgb(255,255,255);font-size:medium">
Andrea Diamantini
WEB: <a href="http://www.adjam.org" target="_blank">http://www.adjam.org</a>

Sponsored by BlueSystems to work on the rekonq project
WEB: <a rel="nofollow" href="http://rekonq.kde.org/" style="color:rgb(0,0,0)" target="_blank">http://rekonq.kde.org</a>
IRC: rekonq@freenode</pre></div>
</div>