Hi Jeremy
Thanks a lot for your work! :)
About the KRDC stuff: it's not that complicated: there was one version
until KDE 4.0, then for KDE 4.0 I have completely rewritten KRDC,
started from scratch. At the moment the old version is in the branch
"original". If you could keep the branches / tags from 4.0 it would also
be okay. Do you think you can fix this?
I have shorty checked the kget repo and it looks quite good. I will
check more later. When should I notify the maintainers to check their
repos?
Do you think I should start backport the standalone fixes / docs moving
the the 4.10 branch now?
Bye
urs
On 2013-04-17 19:40, Jeremy Whiting wrote:
Urs, Pali,
I spent a bit of time looking at the existing kdenetwork-rules file
today. I also moved it into kdenetwork folder and split it into one
rules file per git repository. I intentionally left out kopete since
those rules are on Pali's branch. I suggest we merge that into master
branch so all the work goes in one place. Pali, if you could move that
that'd be great, otherwise I can if you want.
The rules look ok so far, I changed most of them to use the
common-kdenetwork-rules I created based on the common-kdesdk-rules we
used for kdesdk. but didn't do krdc-rules as the existing ones are a
bit complex. This means krdc is the one conversion currently that
only has master branch, the others have normal kde X.Y branches and
tags already, but need a bit of looking over before they are "final"
I'll push up the existing rules conversions to scratch/whiting/blah
for you to look over when you have a chance.
BR,
Jeremy
On Sat, Apr 13, 2013 at 6:12 AM, Urs Wolfer <uwol...@kde.org> wrote:
I have created an initial version of the wiki page:
http://community.kde.org/KDENETWORK/Git_Migration [3]
Feel free to complete / improve it. The "last" table on this page need
most work.
Also I have two comments for the current ruleset:
- isn't this line required? "include common-kde-ignores" (or even somem
ore "common" stuff?)
- KGet got completely rewritten for KDE 4.0 in branch
"branches/work/make_kget_cool/kget"; I think we can move the old (i.e.
until 4.0) KGet into the branch "original" (like KRDC), and put the new
one which got copied to trunk later into master
It would be great if somebody with knowledge could review the existing
ruleset and comment on what is missing / needs to be better.
Bye
urs
On 2013-04-13 12:30, Urs Wolfer wrote:
Jeremy, thanks a lot for your reply. :)
I think such a wiki page is a good idea. I have collected / prepared
almost all information already some months ago - I will setup this
page in the next days.
I will also merge the standalone build changes from master for all of
kdenetwork apps to the 4.10 branch once we have fully working
migration scripts.
About the migration scripts: There are now two "parts" available:
For all of kdenetwork:
https://projects.kde.org/projects/playground/sdk/kde-ruleset/repository/revisions/master/entry/kdenetwork-rules
[1]
And for Kopete:
https://projects.kde.org/projects/playground/sdk/kde-ruleset/repository/revisions/kopete/show/kdenetwork
[2]
Do you have an idea how this will work together? Do we need to create
such detailed scripts for all parts of kdenetwork like Pali has done
for Kopete? Or are the ones for all of kdenetwork almost okay? I
cannot decide here because of my knowledge.
For Kopete plugins in extragear: I think Pali needs to decide. If
plugins are in a good shape, you can include it. Or you could include
it in branches.
Thanks for your help.
Bye
urs
On 2013-04-12 21:49, Jeremy Whiting wrote:
Ok, awesome. I suggest we coordinate this effort like we did with
kdesdk. Urs since you are the module coordinator we need some
decisions, either from you, or you can ask application maintainers
also. First of all I guess the idea is to split kdenetwork into one
git repo per application like has been done in other modules? If so
what should we name each, the strigi-analyzers in kdesdk we named
kdesdk-strigi-analyzers, so the ones in kdenetwork should probably be
kdenetwork-strigi-analyzers. Urs, what kind of time do you have to
help with this effort? We need to copy the KDESDK/Git_Migration
community page to something for kdenetwork which shows who each app
should be maintained by, what each git repo should be called, etc.
Another question I have is if we should put all the kopete stuff from
extragear and playground into the kopete git repo. I believe all the
stuff from extragear is already included in what Pali put together, is
that right? What about plugins/etc. from playground? is that included
on branches also?
BR,
Jeremy
Links:
------
[1]
https://projects.kde.org/projects/playground/sdk/kde-ruleset/repository/revisions/master/entry/kdenetwork-rules
[2]
https://projects.kde.org/projects/playground/sdk/kde-ruleset/repository/revisions/kopete/show/kdenetwork
[3] http://community.kde.org/KDENETWORK/Git_Migration
_______________________________________________
Kde-scm-interest mailing list
Kde-scm-interest@kde.org
https://mail.kde.org/mailman/listinfo/kde-scm-interest
