<div dir="ltr"><br>When I first hear about the changes, I thought/understood that the new architecture was almost decided, it was something like:<br><br>- Qt-copy, Kdelibs and probably (to be decided) kdebase in SVN , 6 months release, nothing really changes there. (i.e. stations, not only summer)<br>
<br>- In SVN there will also live files with links to external repositories and their status (may be GIT repositories, but to be decided). Status would be an ORDERED list like development, feature freeze, strings freeze, docs freeze, ... <br>
<br>- Some external (gitorous?) mechanism to let easy navigation, forking and branching of external repositories (aiming at casual contributors?)<br><br>KDE will continue to have 6 months releases with the same phases (feature freeze, etc.) that applies directly to everything on SVN and apply to select the correct repository to pull the code from.<br>
To make it clear. Let's have Kopete with a 4.2 code branch or repository and a 4.3 repository. When feature freeze comes, if the repository for 4.3 is not marked as feature freeze status or superior, then the 4.2 branch will be used. <br>
It means that any project can skip a KDE release if it is not able to be ready on time or simply don't want to be tied to the same 6 month release than the rest of KDE for whatever reason (Plasma?). Obviously most projects want to release often so won't skip KDE releases. <br>
It also means that kdelibs is the base with a known schedule and status. <br>Projects can release independent from KDE. Each KDE release will fetch the last stable version of each project (much like Xorg does). <br>Scripts will automatically pull all the relevant outside branches, fetch the code and build all KDE.<br>
<br>I was sure it was the idea someone proposed before and more or less accepted. But reading this thread, it seems that the new development model is far from decided. Is the "always summer in trunk" already decided?<br>
<br><br><br><div class="gmail_quote">On Fri, Sep 12, 2008 at 9:21 AM, David Jarvie <span dir="ltr"><<a href="mailto:djarvie@kde.org">djarvie@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Thu 11 September 2008 17:41:13 Aaron J. Seigo wrote:<br>
> On Thursday 11 September 2008, David Jarvie wrote:<br>
> > For application development, the biggest obstacle to updating<br>
> > kdelibs/kdebase (whether by moving between branch and trunk, or simply<br>
> > updating the existing checkout) is not updating the SVN checkout (which<br>
> > if you have a broadband connection is easy), but rebuilding and<br>
> > reinstalling once the code has been checked out.<br>
><br>
> this is where having an SCM that can pull changes between branches without<br>
> touching *every file* is pretty important. with an decent SCM when one<br>
> switches branches it should only rebuild what's actually different between<br>
> the branches.<br>
><br>
> obviously this is more than "no changes" but it should be less than what it<br>
> would be right now with our current SCM solution.<br>
><br>
> > If the application needs new features in kdelibs, then updating is<br>
> > obviously necessary. But if it doesn't need new kdelibs features,<br>
> > rebuilding is a risky and often time consuming process which brings no<br>
> > real benefit to developing the application.<br>
><br>
> ... aside from identifying bugs in the libraries it depends on before those<br>
> bugs are passed on to your users.<br>
<br>
</div>I agree that it's important to build up-to-date libraries at some stage before<br>
a new release to test that applications still work properly with them.<br>
<div class="Ih2E3d"><br>
> > If I'm doing application work,<br>
> > I'd rather spend time dealing with build or dependency problems, bugs or<br>
> > functional changes in kdelibs/kdebase only when really necessary rather<br>
> > than every week or two. A constant non-updating environment to work in is<br>
> > the most productive, regardless of whether it's trunk or 4.x branch.<br>
><br>
> right, so what i suggested is that we put app developers who want/need this<br>
> onto the most-stable-but-still-development branch at all times: stay on 4.x<br>
> branch until trunk is declared feature frozen, then when trunk is branched<br>
> for the 4.(x+1) move to that.<br>
><br>
> this is a way for app developers to help out by testing without causing<br>
> more grief than necessary for them, as they won't be following a hot branch<br>
> at any point.<br>
<br>
</div>All I'm saying is that building libraries isn't something that a lot of<br>
application developers will necessarily want to do often, whether or not it's<br>
made easier to do (because there is always some potential for problems). Your<br>
suggestion might improve things a bit, but I'd be surprised if it would make<br>
a huge difference. Application developers' main focus is inevitably on their<br>
applications rather than the libraries.<br>
<font color="#888888"><br>
--<br>
David Jarvie.<br>
KAlarm author and maintainer.<br>
</font><div><div></div><div class="Wj3C7c"><a href="http://www.astrojar.org.uk/kalarm" target="_blank">http://www.astrojar.org.uk/kalarm</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Jordi Polo Carres<br>NLP laboratory - NAIST<br><a href="http://www.bahasara.org">http://www.bahasara.org</a><br><br>
</div>