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

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

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

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

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,

Moving a directory from one KDE repository toanother

David Jarvie — 2011-10-17T23:49:43

What is the best way to move a directory from one KDE repository to another, while preserving history? Is the sequence of commands in http://lists.kde.org/?l=kde-scm-interest&m=129019711601449&w=2 a good way? I wonder whether the --tag-name-filter option to git filter-branch should also be used to preserve tags.

Deactivating this list

Thiago Macieira — 2011-10-14T08:18:38

Hello

The Git conversion of the KDE repositories is almost complete. There have been 
a grand total of 2 emails in the past 30 days on this mailing list. Meanwhile, 
the spam traffic has increased quite considerably (> 1 spam per day).

I'd like to propose this list be deactivated on Dec 1st. That gives us 45 days 
to wrap up any subjects pending.

Any objections?

Git User's Survey 2011

Eike Hein — 2011-09-23T17:28:30

Go forth and participate: https://www.survs.com/survey/VCAGZA8CT5

Moving code across repositories

Sune Vuorela — 2011-08-11T16:57:11

Hi

I think we need a nice howto on how to move code from one repository to
another.

I at least need some code from kde-runtime over in kdelibs for the
frameworks effort, and is a bit unsure how to actually do that.

Any help, ideas and nice scripts are welcome.

/Sune

pushing rebased shared branches

Marcel Wiesweg — 2011-08-08T10:39:02

Hi,

I have been fixing branches of SoK students, removing some dirty manual merges 
and branch mixups, by interactive rebase.
I'm fully aware of the implications of rewriting history. 

I had the recollection we could now force-push branches, but:

remote: + refs/heads/sok/presentation digikam mwiesweg DENIED by fallthru
remote: error: hook declined to update refs/heads/sok/presentation
To ssh://git-50bAvAUIC9NAfugRpC6u6w< at >public.gmane.org/digikam
 ! [remote rejected] presentation -> sok/presentation (hook declined)

Missing something here?

I believe I can delete branches, so the alternative procedure would be to 
delete the branch and recreate it under the same name?

Marcel

git BoF

Ian Monroe — 2011-06-23T19:13:01

I'm thinking we should have a KDE Git transition BoF. One thought is that
the Git BoF happen after the release team BoF so that they can be given the
opportunity to add stuff to our agenda.

I could use another co-host, anyone want to help?

Ian

GSoc branch best practices

Marcel Wiesweg — 2011-04-30T19:39:55

Hi all,

I would be interested on best practices with git branches for our gsoc 
students, assuming the students do not work on master.

With SVN, we always had one dedicated branch for all students, regularly 
synced with trunk. With git, I see some more possibilities:

1) One branch per student
1a) regularly rebased on master
1b) changes regularly merged from master, merged to master at finish
2) One branch for all students, merged at finish

Any KDE projects with experience from last year? Plans for this year?

(Btw, is it now possible to rebase branches in KDE git like 1a?)

Marcel

Idea: Converting KDESDK incrementally

Sebastian Dörner — 2011-03-28T20:48:11

Hi,

KDESDK is still using svn up to now and there doesn't seem to be much
progress to make the transition for the whole repository. Also see the
brief discussion on December 18th on kde-scm-interest.
I guess one of the reasons is that KDESDK is rather an ensemble of
individual sub-projects than one coherent module, so there is nobody who
knows all the code and its history (correct me if wrong). Also, as
stated in the a. m. discussion, the current maintainer doesn't have time
to do it.

I wonder if it would be feasible/sensible to do the conversion
incrementally. In this model, people feeling responsible for parts of
KDESDK write rules for their part and move the part to git individually.
This would require them to know the history only for their part (which
they certainly do) instead of knowing the history of whole kdesdk (which
they less likely do).
E.g. I would feel competent to write rules for kdesdk/dolphin-plugins,
but don't know anything about the rest.

Is there anything that makes this proposal a bad idea? How does it align
with release management? Possibly, at the time of 4.7 parts of KDESDK
would be in git and other parts still in svn.

(Immediate cause for this mail is upcoming GSoC, where I would prefer
dolphin-plugins in a git repository for consistency with rest of dolphin
and for easier branching.)

Cheers,
Sebastian

GSoC coding workflow

Anne-Marie Mahfouf — 2011-03-27T16:39:55

Hi,

I feel some guidelines need to be established in order to have a nice workflow 
from GSoC students. Below are some points I think should help, I propose to 
put them on a Community wiki page if you all agree about them.

Code
- for additional features to Foo project still in svn, develop the GSoC in a 
svn branch  (naming convention?)
- for additional features to Foo project in Git, develop the GSoC in a Git 
branch of foo (naming convention?)
- for new code, use a Git personal repository as described here 
http://community.kde.org/Sysadmin/GitFAQ#Personal_scratch_repositories and 
when the code is mature and stable enough, move it to git playground.

Licencing
- all coded files should have a licence header as explained in 
http://techbase.kde.org/Policies/Licensing_Policy

(I saw student code without proper licencing so I think this needs to be 
clear)

Anything else? Is that OK?

Best regards,

Anne-Marie

moving code from a KDE project to another one...

Gilles Caulier — 2011-03-24T14:42:28

Hi all,

I would to move wikimedia kipi-plugin source code from this place :

https://projects.kde.org/projects/playground/base/silk/repository/revisions/master/show/mediawiki/kipi-plugin

to this place :

https://projects.kde.org/projects/extragear/graphics/kipi-plugins/repository

How to do it without to lost Git history ?

Thanks in advance

Gilles Caulier

svn2git playground publictransport

Friedrich Pülz — 2011-02-25T15:01:08

Hi,

I want to move my PublicTransport Plasma data engines, applet and runner from 
SVN playground to git, into a single repository.
I already have a "publictransport-rules" file, that moves the stuff into 
"scratch/fkpulz/publictransport".

- Should I move it to "scratch/fkpulz/publictransport" or to "publictransport" 
as playground repository? It should be quite stable and was in SVN playground 
since 2009.

- I'm unsure about one rule. It movest 
"/trunk/playground/base/plasma/applets/publictransport/" to 
"scratch/fkpulz/publictransport/plasma-applet-publictransport". The 
subdirectory in SVN named 
"/trunk/playground/base/plasma/applets/publictransport/publictransporthelper" 
gets moved to "scratch/fkpulz/publictransport/libpublictransporthelper" by 
another rule. Does the first one also move the subdirectory to 
"scratch/fkpulz/publictransport/plasma-applet-publictransport"? If not, 
everything should be fine. Otherwise I want to ignore the subdirectory in that 
rule..

- Do I really need to download the ~65GB as described in techbase "Using 
Svn2Git" or may someone who has everything in place already be so kind to try 
my "publictransport-rules" file? :) 

- I already created that repository actually (scratch/fkpulz/publictransport) 
for testing out git, but will remove it again before the move.

- Please CC me, because I'm not subscribed to this mailing list.

Thanks in advance,
Friedrich Pülz (fkpulz)
#
# Created by Friedrich Pülz (fkpulz) <fpuelz-Mmb7MZpHnFY< at >public.gmane.org>
#

# PublicTransport was developed in KDE SVN from beginning
# It was never branched or tagged, but consists of multiple
# components like data engines, a runner and an applet.

declare REPO=scratch/fkpulz/publictransport

# Create the PublicTransport repository
create repository ${REPO}
end repository

# PublicTransport applet from SVN playground
match /trunk/playground/base/plasma/applets/publictransport/
    repository ${REPO}
    prefix plasma-applet-publictransport/
    branch master
end match

# PublicTransport helper library from applet subdir in SVN playground
match /trunk/playground/base/plasma/applets/publictransport/publictransporthelper
    repository ${REPO}
    prefix libpublictransporthelper/
    branch master
end match

# PublicTransport runner from SVN playground
match /trunk/playground/base/plasma/runners/publictransport/
    repository ${REPO}
    prefix plasma-runner-publictransport/
    branch master
end match

# PublicTransport data engine from SVN playground
match /trunk/playground/base/plasma/dataengines/publictransport/
    repository ${REPO}
    prefix plasma-engine-publictransport/
    branch master
end match

# OpenStreetMap data engine from SVN playground
match /trunk/playground/base/plasma/dataengines/openstreetmap/
    repository ${REPO}
    prefix plasma-engine-openstreetmap/
    branch master
end match

# Ignore the rest
match /
end match

My proposal for a git workflow

Stephen Kelly — 2011-02-15T23:12:16

Hi,

I've added a section for proposed workflows. I think eean wants to create a 
couple of proposals too.

http://community.kde.org/20110213_GitWorkflowAgenda#Proposed_workflows

Please poke holes in mine and let me know if something just won't work in 
it:

http://community.kde.org/20110213_GitWorkflowAgenda/StevesIdea

All the best,

Steve.

kde-edu git repos to validate

Ian Monroe — 2011-02-07T22:35:56

I've only done a basic look over on each repo (looked at branches,
made sure each only had one parentless commit), plan on doing more
tonight. But really it helps to know the history of the code  to know
if everything looks right. Also if folks could do build tests that
would be helpful.

The repos are dated from the 13th or so.

You can see them under scratch/ianmonroe at http://quickweb.kde.org

To clone them all, launch `ruby`, copy the following code and end on a
newline + ctrl-d.

[
"blinken",
"cantor",
"kalgebra",
"kalzium",
"kanagram",
"kbruch",
"kgeography",
"khangman",
"kig",
"kiten",
"klettres",
"kmplot",
"kstars",
"ktouch",
"kturtle",
"kwordquiz",
"libkdeedu",
"marble",
"parley",
"rocs",
"step"
].each { |project|
`git clone git://anongit.kde.org/scratch/ianmonroe/#{project}`
}

odd kdeedu conversion crashes

Ian Monroe — 2011-02-07T16:32:47

I could use another pair of eyes to help diagnose what is going wrong
with most of the kdeedu repository conversions. They crash on:
"fatal: Invalid ref name or SHA1 expression: refs/tags/v4.6.0"
but when I go through and look at the logs, everything seems to be
fine. The logs talk about creating a 4.6 branch and then creating a
tag out of it. I suspect that there is nothing wrong with the v4.6.0
tag in particular, it just happens to be the last tag.

I was having lots of trouble, including '00000000000' commits related
to the 4.4.85 tag. First it was tagged, untagged and then retagged
from a different branch. But now I've ignored the original tagging, so
I don't see errors related to it anymore.

I've put a tar of all the logs and the aborted repo of Step at:
http://kollide.net/~eean/step-svn2gitcrash.tar.bz2

The rules are in the kde-ruleset repo, under the kdeedu sub-directory.

The following repos do not crash (all others do):
rocs
marble (which uses a completely different set of rules)
kwordquiz
kstars
kalzium
kalgebra
cantor
...in case thats somehow enlightening.

Thanks,
Ian

KDE/ branch prefixes missing from kdepimlibs andplasma-addons

Will Stephenson — 2011-02-04T08:46:43

I notice that the remote branches for kdepimlibs and plasma-addons do not have 
the "KDE/" prefix for the "official" 4.x branches.  Is this a known issue?

WIll

problem pushing to kdelibs

Николай Шафоростов — 2011-02-03T15:32:19

Hi. I wanted to push some fixes for kross (this would be my first git push), but ran into the following problem:

[nick< at >mepis1 kross]$ git push origin
Counting objects: 13, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 775 bytes, done.
Total 7 (delta 6), reused 0 (delta 0)
remote: Audit failure - Commit 4029cca96e04d7435c41922dafca61820cece260 - Email Address - nick< at >mepis1.(none)
remote: Push declined - commits failed audit
remote: error: hook declined to update refs/heads/master
To ssh://git-50bAvAUIC9NAfugRpC6u6w< at >public.gmane.org/kdelibs
 ! [remote rejected] master -> master (hook declined)
error: failed to push some refs to 'ssh://git-50bAvAUIC9NAfugRpC6u6w< at >public.gmane.org/kdelibs'

what should i do to pass the audit?