<div dir="ltr">Looks like kdepim got the contents of what was in kdenetwork/kfile-plugins/rfc822 at least, but not it's history. I don't think we need that in kdenetwork-strigi-analyzers, but adding all the rules to make it ignore it is a bit tricky (need to add ignore rules for tags, branches, and trunk) we probably should just remove those commits in post processing I believe. I defer to nicolas to suggest the best way to do that though.<div>
<br></div><div style>BR,</div><div style>Jeremy</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 7, 2013 at 5:20 PM, Jeremy Whiting <span dir="ltr"><<a href="mailto:jpwhiting@kde.org" target="_blank">jpwhiting@kde.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Urs,<div><br></div><div>I just spent a few minutes looking at the kdenetwork-strigi-filters which was broken and found there was a delete in svn of kfile-plugins after it was moved/renamed to strigi-analyzer, so adding an ignore of the deletion revision fixed that. However there's also some old history of a kfile-plugin/rfc822 that was moved to kdepim as shown here: <a href="http://websvn.kde.org/?view=revision&revision=200868" target="_blank">http://websvn.kde.org/?view=revision&revision=200868</a> do we need that in the kdenetwork-strigi-analyzers repo? (I'll check now if it's already been made part of the kdepim repo).</div>
<div><br></div><div>thanks,</div><div>Jeremy</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 18, 2013 at 1:33 PM, Jeremy Whiting <span dir="ltr"><<a href="mailto:jpwhiting@kde.org" target="_blank">jpwhiting@kde.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div>On Thu, Apr 18, 2013 at 2:41 AM, Urs Wolfer <span dir="ltr"><<a href="mailto:uwolfer@kde.org" target="_blank">uwolfer@kde.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Jeremy<br>
<br>
Thanks a lot for your work! :)<br></blockquote><div><br></div></div><div>No problem, glad to help. <br></div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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?<br>
</blockquote><div><br></div></div><div>Yeah, should be able to convert it to use the include common-kdenetwork-rules or alternatively expand that into krdc-rules and change the branch names for the old revisions. We did similarly for one or two kdesdk apps if I recall correctly. <br>
</div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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?<br></blockquote><div><br></div></div><div>Maintainers can look now, but the strigi-analyzers at least has some interesting history towards the top of master branch I'd like to fix before that gets too many eyes on it. The more eyes we can get on these repos the more accurate they will be when we do the real conversion though. I'll take a look at it, probably not until the weekend though.<br>
</div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Do you think I should start backport the standalone fixes / docs moving the the 4.10 branch now?<br></blockquote><div><br></div></div><div>The simplest way to do that is after the migration to git by simply going into each git repo and doing a git cherry-pick -x of the commit on master on the KDE/4.10 branch. <br>
<br></div><div>By the way the post processing of kopete takes quite some time, as does the svn-all-fast-export run, even with a revlist to make it fast it took about 30 mins here. I guess that's just how kopete is since it has so much history, but I think we probably ought to not include so many unused things in the main kopete repo in my opinion. It's not a problem, but it sure makes kopete look messy in gitk and such to have so many branches lying around.<br>
<br></div><div>BR,<br></div><div>Jeremy<br></div><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Bye<br>
urs<div><br>
<br>
On 2013-04-17 19:40, Jeremy Whiting wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
Urs, Pali,<br>
<br>
I spent a bit of time looking at the existing kdenetwork-rules file<br>
today. I also moved it into kdenetwork folder and split it into one<br>
rules file per git repository. I intentionally left out kopete since<br>
those rules are on Pali's branch. I suggest we merge that into master<br>
branch so all the work goes in one place. Pali, if you could move that<br>
that'd be great, otherwise I can if you want.<br>
<br>
The rules look ok so far, I changed most of them to use the<br>
common-kdenetwork-rules I created based on the common-kdesdk-rules we<br>
used for kdesdk. but didn't do krdc-rules as the existing ones are a<br>
bit complex. This means krdc is the one conversion currently that<br>
only has master branch, the others have normal kde X.Y branches and<br>
tags already, but need a bit of looking over before they are "final" <br>
I'll push up the existing rules conversions to scratch/whiting/blah<br>
for you to look over when you have a chance.<br>
<br>
BR,<br>
Jeremy<br>
<br>
On Sat, Apr 13, 2013 at 6:12 AM, Urs Wolfer <<a href="mailto:uwolfer@kde.org" target="_blank">uwolfer@kde.org</a>> wrote:<br>
<br>
I have created an initial version of the wiki page:<br>
</div><a href="http://community.kde.org/KDENETWORK/Git_Migration" target="_blank">http://community.kde.org/<u></u>KDENETWORK/Git_Migration</a> [3]<div><br>
Feel free to complete / improve it. The "last" table on this page need most work.<br>
<br>
Also I have two comments for the current ruleset:<br>
- isn't this line required? "include common-kde-ignores" (or even somem ore "common" stuff?)<br>
- KGet got completely rewritten for KDE 4.0 in branch "branches/work/make_kget_cool/<u></u>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<br>
<br>
It would be great if somebody with knowledge could review the existing ruleset and comment on what is missing / needs to be better.<br>
<br>
Bye<br>
urs<br>
<br>
On 2013-04-13 12:30, Urs Wolfer wrote:<br>
<br>
Jeremy, thanks a lot for your reply. :)<br>
<br>
I think such a wiki page is a good idea. I have collected / prepared<br>
almost all information already some months ago - I will setup this<br>
page in the next days.<br>
<br>
I will also merge the standalone build changes from master for all of<br>
kdenetwork apps to the 4.10 branch once we have fully working<br>
migration scripts.<br>
<br>
About the migration scripts: There are now two "parts" available:<br>
For all of kdenetwork:<br>
</div><a href="https://projects.kde.org/projects/playground/sdk/kde-ruleset/repository/revisions/master/entry/kdenetwork-rules" target="_blank">https://projects.kde.org/<u></u>projects/playground/sdk/kde-<u></u>ruleset/repository/revisions/<u></u>master/entry/kdenetwork-rules</a> [1]<br>
<br>
And for Kopete:<br>
<a href="https://projects.kde.org/projects/playground/sdk/kde-ruleset/repository/revisions/kopete/show/kdenetwork" target="_blank">https://projects.kde.org/<u></u>projects/playground/sdk/kde-<u></u>ruleset/repository/revisions/<u></u>kopete/show/kdenetwork</a> [2]<div>
<div><br>
<br>
Do you have an idea how this will work together? Do we need to create<br>
such detailed scripts for all parts of kdenetwork like Pali has done<br>
for Kopete? Or are the ones for all of kdenetwork almost okay? I<br>
cannot decide here because of my knowledge.<br>
<br>
For Kopete plugins in extragear: I think Pali needs to decide. If<br>
plugins are in a good shape, you can include it. Or you could include<br>
it in branches.<br>
<br>
Thanks for your help.<br>
<br>
Bye<br>
urs<br>
<br>
On 2013-04-12 21:49, Jeremy Whiting wrote:<br>
Ok, awesome. I suggest we coordinate this effort like we did with<br>
kdesdk. Urs since you are the module coordinator we need some<br>
decisions, either from you, or you can ask application maintainers<br>
also. First of all I guess the idea is to split kdenetwork into one<br>
git repo per application like has been done in other modules? If so<br>
what should we name each, the strigi-analyzers in kdesdk we named<br>
kdesdk-strigi-analyzers, so the ones in kdenetwork should probably be<br>
kdenetwork-strigi-analyzers. Urs, what kind of time do you have to<br>
help with this effort? We need to copy the KDESDK/Git_Migration<br>
community page to something for kdenetwork which shows who each app<br>
should be maintained by, what each git repo should be called, etc.<br>
<br>
Another question I have is if we should put all the kopete stuff from<br>
extragear and playground into the kopete git repo. I believe all the<br>
stuff from extragear is already included in what Pali put together, is<br>
that right? What about plugins/etc. from playground? is that included<br>
on branches also?<br>
<br>
BR,<br>
Jeremy<br>
<br>
<br>
<br></div></div>
Links:<br>
------<br>
[1]<br>
<a href="https://projects.kde.org/projects/playground/sdk/kde-ruleset/repository/revisions/master/entry/kdenetwork-rules" target="_blank">https://projects.kde.org/<u></u>projects/playground/sdk/kde-<u></u>ruleset/repository/revisions/<u></u>master/entry/kdenetwork-rules</a><br>
[2]<br>
<a href="https://projects.kde.org/projects/playground/sdk/kde-ruleset/repository/revisions/kopete/show/kdenetwork" target="_blank">https://projects.kde.org/<u></u>projects/playground/sdk/kde-<u></u>ruleset/repository/revisions/<u></u>kopete/show/kdenetwork</a><br>
[3] <a href="http://community.kde.org/KDENETWORK/Git_Migration" target="_blank">http://community.kde.org/<u></u>KDENETWORK/Git_Migration</a><br>
</blockquote>
</blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>