gmane.comp.kde.scm-interest

KDESDK to git migration: Build system changes

Sebastian Dörner — 2012-05-23T21:29:51

Hi,
how does the new structure works in terms of building?

So far we have one top-level CMakeLists.txt for the whole of KDESDK.
This seems to be useful for releasing a KDESDK tarball to end users /
distributions. However I suppose that every single repository should
have an independently-working build file in its own root directory,
i.e. one that does not depend on the KDESDK one for finding stuff out
(as is the case now).

Can anyone confirm or correct this?

Regards
Sebastian

Re: Migration of KDESDK to git

Friedrich W. H. Kossebau — 2012-05-22T16:55:21

Hi Jeremy,

Am Mittwoch, 16. Mai 2012, 13:00:04 schrieb Jeremy Whiting:

Good, thank you! Let's try to spread the tasks on many shoulders where doable, 
so things take less time for each and the results are quicker seen.


Okay, so took that as guide to roughly follow for now.

Cheers
Friedrich

KDESDK to git migration: how many repos for thesmall developer utils?

Friedrich W. H. Kossebau — 2012-05-22T16:31:12

Hi,

[[cc: to kde-scm-interest just for heads-up,
  follow-ups _only_ on kde-sdk-devel please]]

so we are in Phase 1 of the process:
"Decide which repos should be created from which submodules".

For the kind-of-standalone programs and the plugins it seems there is 
consensus how they should be split, a repo per program as well as a repo per 
plugin type.

But what about all those small developer utils?
There are some for developers using... 
... KDE libs/framework: 
* kpartloader - David Faure 
* scripts - Michael Pyne 

... Qt libs/framework: 
* kuiviewer - Benjamin C. Meyer 
* kprofilemethod - David Faure 

... X libs: 
* kstartperf - Geert Jansen 

... C++(/C?): 
* kmtrace - ? 

How should these submodules be split? 
a) One repo with all? 
b) "scripts" in a separate repo, rest in one? 
c) Each an own repo?
d) ?

(Above from http://community.kde.org/KDESDK/Git_Migration#Development_utils )

I currently would vote for b) or a). But I have no real hard rules besides the 
amount of files in the submodules.
What rules to base the decision on do you propose?
How would you split up these submodules?

Cheers
Friedrich

Re: Migration of KDESDK to git

Jeremy Whiting — 2012-05-16T19:00:04

Hi Friedrich,

Thanks for revitalizing this discussion and project.

On Wed, May 16, 2012 at 9:50 AM, Friedrich W. H. Kossebau
<kossebau-RoXCvvDuEio< at >public.gmane.org> wrote:

I would love to help out as I am able to.  Lots of stuff going on at
home so don't have a ton of time to devote to this, but I would like
to see it happen and can spare a few hours a week to help someone get
up to speed.


Yes, that's correct.  For 3 we have previously just used scratch repos
in git.kde.org.  No need to set up a separate git server.  Otherwise,
yes that looks like the process we've used in the past.

thanks again,
Jeremy

Re: Migration of KDESDK to git

Friedrich W. H. Kossebau — 2012-05-16T15:50:44

Hi, especially Nicolás and Jeremy,

so far it seems everyone is looking forward to seeing the migration of kdesdk 
to git finally happen, good :)

Am Dienstag, 8. Mai 2012, 17:11:51 schrieb Friedrich W. H. Kossebau:

Those "brave people" are you, Nicolás and Jeremy :) Do you want to pick up 
your work again and be our experts in the kdesdk migration?

I myself have not really followed any of the migrations to git, so have no 
real idea about the process. http://techbase.kde.org/Projects/MovetoGit only 
helped me a little. Do kdeedu or kdeutils or else have a log of their process 
which could be followed?

I guess it's something like this:

1. Decide which repos should be created from which submodules
2. Write migration rules
3. Setup a test git server with resulting repos to check rules
4. Have everyone okay the rules
5. Migration!
  a) Put writelock on module in svn 
  b) Create real repos by the rules
  c) Configure EBN, API DOX, translations systems (what else?) for new repos
  d) Put "Moved to git" note to module in svn
  e) Enable write access to git modules

Correct?
Steps 1 and 4 are to be done basically by the maintainers of the stuff in 
kdesdk. For step 1, the continuation of the discussion about the splitup of 
module will happen next on the kdesdk-devel mailinglist (I still need to get a 
complete picture of all the stuff in kdesdk, if anyone else has that do not 
hesitate to start off), the result should end up on a wikipage.

The other steps need to be done by people with migration experience and 
admins, here I hope for the help of e.g. Nicolás and Jeremy, as said above :)

BTW, there is now an additional submodule since last week, 
"kdesdk/thumbnailers" which does not yet have rules.

Cheers
Friedrich

PS: Sorry, am not available on IRC due to an unstable internet connection...

Re: Migration of KDESDK to git, finally? :)

Nicolás Alvarez — 2012-05-10T18:37:26

http://websvn.kde.org/?view=revision&revision=628013

Nothing in main modules is straightforward, there are many work branches 
around :)

Please subscribe to kde-sdk-devel (was: Re:Migration of KDESDK to git, finally?)

Friedrich W. H. Kossebau — 2012-05-10T16:49:19

Hi all,

thanks for your replies so far, encouraging to continue on the pushing of 
kdesdk to git :)

Just the lots of cc: are a pain (and result in the posts being blocked for 
kde-scm-interest-RoXCvvDuEio< at >public.gmane.org by default). So the admins have been nice and quickly 
added a new mailinglist for kdesdk, kde-sdk-devel.

So please anyone also quickly subscribe to

https://mail.kde.org/mailman/listinfo/kde-sdk-devel

so the discussion can be continued there (and is also archived for any kdesdk 
maintainer/shareholder who is not yet in cc:), at least for the parts not 
interesting to kde-scm-interest.

Please spread this info also to anyone else interested in stuff in kdesdk.

Cheers
Friedrich

Re: Migration of KDESDK to git, finally? :)

Albert Astals Cid — 2012-05-08T23:55:06

El Dimarts, 8 de maig de 2012, a les 19:37:54, Michael Pyne va escriure:

Reorganizing toplevel modules is kind of pain in the ass since we have lots of 
scripts, tools, packages (in the distro side) that expect a given set of 
names/packages, so first I'd want to ask for thiking if this new module really 
is worth anonying our ecosystem (and besides i guess a new module should be 
approved by the release-team and/or k-c-d).

Cheers,
  Albert

Re: Migration of KDESDK to git, finally? :)

Sebastian Dörner — 2012-05-08T23:23:26

Thanks for bringing this up and for stepping up as module coordinator!

+1 for 1 repo per type

I'd be available to help in the implementation (rules etc) after 18
May, though I don't know much about the history myself (it's pretty
straightforward for the dolphin plugins).

Regards
Sebastian

Re: Migration of KDESDK to git, finally? :)

Anne-Marie Mahfouf — 2012-05-08T18:27:22

Hi,
No, not at all. KAppTemplate is a full application which generates 
templates to start coding. It's not examples.
kdeexamples has already the same sort of staring code than KAppTemplate 
but new developers cannot use itso easily. With KAppTemplate, they say: 
I want a new project named trial and they choose which sort of project 
and it's generated right with the trial name and ready to be built.

Anne-Marie

Re: Migration of KDESDK to git, finally? :)

Michael Pyne — 2012-05-08T23:37:54

Aside from kio_perldoc as you suggested, I'm also marked as the maintainer for 
kdesdk-scripts.


This sounds agreeable. I will volunteer to maintain the kioslaves-kdesdk 
grouping.


Yes. We can rename to kde-developer-scripts to make it more clear what their 
intent is.


That actually sounds like a good idea, instead of having 'kde/kdesdk/kde-
developer-scripts' have 'kde-developer-scripts' as a toplevel git module.


Sounds good to me.

Regards,
 - Michael Pyne

Re: Migration of KDESDK to git, finally? :)

Peter Penz — 2012-05-08T18:44:46

[...]

I also think having one repository per type 
(dolphin-plugins/kio-slave/strigi-analyzer) would be fine.

BTW: Thanks for bringing this topic up again :-)

Cheers,
Peter

Re: Migration of KDESDK to git, finally? :)

Albert Astals Cid — 2012-05-08T17:33:41

El Dimarts, 8 de maig de 2012, a les 17:11:51, Friedrich W. H. Kossebau va 
escriure:

Ho


Not me


I think one repo per plugin is an overkill.


If i's your assumption that the poxml is not used outside KDE developers, it's 
a wrong assumption. We regularly have people filling bugs complaining it 
doesn't work for their non KDE use case.


Has nothing to do in my opinion, kdeexamples are examples on how to use 
technology, kapptemplate are "barebones compilable code" for some type of 
application.


Makes sense

Re: Migration of KDESDK to git, finally? :)

Josef Weidendorfer — 2012-05-08T16:03:18

Hi,

thanks for getting this started again!

Am 08.05.2012 17:11, schrieb Friedrich W. H. Kossebau:

Yes.


Yes.


Ah, nice. I didn't know.

I do not really know the syntax for the rules, but at least for
kcachegrind there are no special (feature-)branches, and everything
within the kcachegrind/ directory is self-contained (apart from
translation/documentation). So the migration should be straight-forward.


Looks good.
For the rest, I do not really have an opinion.

Cheers,
Josef

Re: Migration of KDESDK to git, finally? :)

Anne-Marie Mahfouf — 2012-05-08T18:23:16

Hi,

On 05/08/2012 05:11 PM, Friedrich W. H. Kossebau wrote:
I would prefer KAppTemplate as standalone as it's also used by KDevelop.
I tried to make the rules at some point but the app was previously a 
bash script and I did not know how to include this history as well.

+1 and thanks!

Anne-Marie

Re: Migration of KDESDK to git, finally? :)

Vishesh Yadav — 2012-05-08T16:06:14

As far as plug-ins are concerned, I think it would be better to have one
repo per group. I don't see much benefit of having separate repository
for each plug-in. Thing about plug-ins is that there can be many of
them, and it would result into many repositories if go for other option.

Regards,
Vishesh

On 05/08/2012 08:41 PM, Friedrich W. H. Kossebau wrote:

Migration of KDESDK to git, finally? :)

Friedrich W. H. Kossebau — 2012-05-08T15:11:51

Hi,

KDESDK currently is still in svn. At least for Okteta I would like to have
a move from svn to git as soon as possible.

While there have been two threads about this on this list,
"migration of kdesdk to git - status?" from 18.12.2010 and
"Idea: Converting KDESDK incrementally" from 28.03.2011, so far
nothing has happened, besides Kate and kdesrc-build having moved out
of KDESDK to other modules. I would like to change that and have something
happening :)

The gist from the threads is that
* the KDESDK module should be split into separate repos, as the single
  submodules do not have anything in common, like libs or stuff
* the whole of KDESDK should be moved to git in one step, to reduce the mess
  for release managers, packagers and friends
Anyone disagrees?

Some brave people seem to have prepared set of rules for all the components
of the KDESDK module (thanks to them), see
https://projects.kde.org/projects/playground/sdk/kde-
ruleset/repository/revisions/master/show/kdesdk
What is the state of these rules? Can the result be checked somewhere?
Niko Sams, in the thread "migration of kdesdk to git - status?" as referenced
above you also talked about having prepared rules, are they in some way
integrated in what is in the repo linked above?

Who are the current maintainers of all the submodules in KDESDK? I tried to
put all in cc: which looked like the one, see also below who I listed
for each submodule.

Looking through KDESDK I wonder what should end up in a separate git repo
and what not. 

Standalone programs:
* cervisia - Christian Loose
* kcachegrind - Josef Weidendorfer
* kompare - Kevin Kofler
* lokalize - Nick Shaforostoff
* okteta - myself :)
* umbrello - umbrello devs
Surely one repo per program, right?


Plugins, grouped by type:
* dolphin-plugins
svn -Peter Penz
hg - Vishesh Yadav
git - Sebastian Doerner
bazaar - Jonathan Riddell
* kioslave
perldoc - Michael Pyne?
svn - Mickael Marchand?
* strigi-analyzer
diff - Laurent Montel/Jakub Stachowski
po - Montel Laurent/Nick Shaforostoff/Jos van den Oever
ts - Montel Laurent/Jakub Stachowski
xlf - Albert Astals Cid
One repo per plugin? One repo per type?


Development utils for KDE developers:
* kapptemplate - Anne-Marie Mahfouf
* kdeaccounts-plugin - Carsten Pfeiffer?
* kdepalettes - ? (and still useful? nothing build/installed here)
* kmtrace - seems unmaintained
* kpartloader - David Faure
* kprofilemethod - David Faure
* kstartperf - Geert Jansen
* kuiviewer - Benjamin C. Meyer
* poxml - uh, no license headers! (Albert Astals Cid)
* scripts - lots of kde devs
Lots of small tools/helpers, basically not useful for anyone outside
KDE development. Dump in one repo?

I also wonder if these utilities here should not be split out into a separate
module, or the other way round, if all the "real" programs and plugins
should not make up a new module called "devtools"/"kdedev" or whatever,
so the module with the "real" products can be better promoted to users
outside of the group of KDE developers.
And kapptemplate could also move to the module kdeexamples perhaps, as kind
of code-to-copy/start-from?


Completely excluded from build are:
* kspy - Richard Moore
* kunittest - Jeroen Wijnhout
* scheck - Maksim Orlovich/Ryan Cumming
These should be moved to tags/unmaintained in svn in any case?


And while I have the attention of lots of KDESDK developers, would you mind
if I take over the role as coordinator of KDESDK from Matt (in case his offer
is still up) and mess^Wtry to clean-up the module a little?

Cheers
Friedrich

coordinator of module kdesdk (was: Re: migrationof kdesdk to git - status?)

Friedrich W. H. Kossebau — 2012-05-08T14:36:38

Am Freitag, 17. Dezember 2010, 21:57:40 schrieb Matt Rogers:

Is that still the state? If so, I would be willing to take over the role as 
coordinator of kdesdk.

Cheers
Friedrich

svn2git: Representing old work that does not have a direct connection to current master

Stefan Majewsky — 2012-03-11T21:32:03

Hi,

I'm working on kdegames/palapeli-rules. Palapeli lived in
playground/games for a very long time. 1.5 years into its development,
I decided to rewrite it from scratch using the lessons I learned over
the time.

So I moved the directory trunk/playground/games/palapeli to
trunk/playground/games/palapeli.old and started development of the
rewrite at the old path trunk/playground/games/palapeli. I kept the
old source code in the "palapeli.old" directory for a month to use it
as a reference when writing the new code. (I did not know about "svn
checkout -R" back then.)

In the rules, I'm thinking of

1. using the parentmap to make the first commit on the new Palapeli
(1028102) the parent of the last commit of the old Palapeli (1024816)
and

2. omitting those commits which move the old code to "palapeli.old"
(1028097) and delete this directory a month later (1043580).

This should maintain temporal and contextual order without introducing
additional branches. Is this a good idea? If not, what do you suggest?

Greetings
Stefan

Re: superbuild: git clone dir gets removed when rebuilding cache

Valentin Rusu — 2011-12-17T19:10:58

... and this may become quite problematic with big repositories like the 
one of calligra. The cloning time is quite impressive.

Valentin

superbuild: git clone dir gets removed whenrebuilding cache

Valentin Rusu — 2011-12-17T10:47:57

Hello Alex,

Looking for a hint to better superbuild.
Here is my case (once again :) )

I configured superbuild to get the sources in a separate, global, 
directory. I added this into the GlobalSuperbuildOptions.cmake:

set(SB_SRC_CLONE_DIR $ENV{KDEDIR}/src)
(please see my last commit 3ec2909821e408fad6, which introduces this 
variable)

I then do this:
cd kdesupport/
mkdir build
cd build
cmake ..
cmake-gui .. [then I configure the build]
make

Please note that before doing this, my KDEDIR/src already has clones of 
the ldesupport components.
However, doing make would delete the corresponding directories, then 
re-clone them.
Here is an example of the output for LibStreamAnalyzer

Scanning dependencies of target LibStreamAnalyzer
[ 50%] Creating directories for 'LibStreamAnalyzer'
[ 50%] Performing download step (git clone) for 'LibStreamAnalyzer'
Cloning into 'LibStreamAnalyzer'...
remote: Counting objects: 24940, done.
remote: Compressing objects: 100% (5085/5085), done.
remote: Total 24940 (delta 19797), reused 24940 (delta 19797)
Receiving objects: 100% (24940/24940), 4.69 MiB | 1.82 MiB/s, done.
Resolving deltas: 100% (19797/19797), done.
Already on 'master'
[ 50%] [ 50%] No patch step for 'LibStreamAnalyzer'
Performing update step for 'LibStreamAnalyzer'
Already up-to-date.
[ 50%] Performing configure step for 'LibStreamAnalyzer'

Now, suppose I have done some work into LibStreamAnalyzer. In fact I 
did, as it's FindCLucene1.cmake uses pkgconfig, and the clucene-core.pc 
is broken (I fix that, but that's another point).

After doing
rm -rf kdesupport/build/*
I executed the steps above and my local modification were gone!

cd $KDEDIR/src
cd LibStreamAnalyzer
git status
# On branch master
nothing to commit (working directory clean)

So here is my problem with superbuild: I need to find a method to keep 
it removing clone directory if it's already existing. E.g. it should 
only do "git pull" into the existing $KDEDIR/src/LibStreamAnalyzer, then 
continue as usual.

Any hint, please?

Cheers,