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