Heads-up: kdeutils is moving to git

Thomas Zander zander at kde.org
Thu Aug 25 17:32:43 UTC 2011

Like Aaron, I also have the greatest respect for the people doing the 
migration, I migrated koffice and that took a lot of time and effort (not to 
mention the many nights that test conversions were run on my only laptop with 
enough space)

The emails were also not read by me to be an objection, more as a signaling 
that we have an open issue that needs solving. :)

(to recap) The issue is that people following kde development previously had 
to know only a couple of module-names and a repeated update and compile was 
enough to stay up-to-date. 
Now people have to manually identify each sub-project and manually browse the 
projects.kde.org website and manually go a clone of each project.  Added repos 
are almost guarenteed to be missed.

On Sunday 21 August 2011 17.46.29 Aaron J. Seigo wrote:
> kdesrc-build was recommended again .. i took the time tonight (after a
> long  day in Taipei working on behalf of KDE) to examine it "from scratch"
> again.
> first the good news: it took me less time to set up this time than in the 
> past, so it is indeed improving. there is no doubt that it is an
> impressive  tool.

Same here, I tried and failed some monts ago, now it seemed to behave better. 
The README still misses a "how thit works in 3 steps" and I ignored it and 
typed the command to compile kdeutils.
The tool responded by doing a checkout of qt-copy.

This is in line with what the description of the tool says;
  «kdesrc-build is a tool to allow you to easily build KDE from its 
  source repositories. »

This, however, is not directly similar to the problem that is being put 
forward :)
Most self-compiler I know don't actually want a full build of KDE, they just 
want to replace one module with the development version of it.
So the tool as it is now is not a natural-match.

Maybe it can be changed to do that, but until that date I would say that we 
still need an automated way to;
 * allow user to select from all top-level modules. (kdebase, kdeedu etc)
 * initial checkout of repos
 * update of all repos and  detecting new projects that can be cloned too.
 * optional are things like detecting new branches and allowing the
   user to switch to the 4.7 branch once it gets created.

Thomas Zander

More information about the release-team mailing list