[Kde-scm-interest] Kopete git migration

Fri May 17 05:48:08 UTC 2013

Hi Jeremy

I have had a look at KRDC and it looks really good. I have found no 
issues so far.

So, what's next? Do you think the scripts are almost ready? If yes, I 
think I will notify all maintainers again to check their converted 
repos.

Bye
urs

On 2013-05-10 21:59, Jeremy Whiting wrote:
> Urs,
> 
> On Thu, May 9, 2013 at 2:46 AM, Urs Wolfer <uwolfer at kde.org> wrote:
> 
> I cannot decide on the rfc822 plugin. If it's only in the history, it 
> should not hurt. I think you could go here the easier way.
> 
> I talked to Allen Winter(s?) the other day and that history is so old
> he agreed we don't need to worri about it. 
> 
> I have got feedback from the filesharing maintainer: he told me that 
> the conversion looks good.
> 
> Ok, awesome.
>  
> 
> Any news about the KRDC migration?
> 
> I took a look at krdc today and fixed the rules and pushed them.  The
> conversion looks pretty good to me.  I'll push the new repos to my
> scratch space and add links to them in the wiki page tonight or
> tomorrow.
> 
> BR,
> Jeremy
>  
> 
> Bye
> urs
> 
> On 2013-05-08 01:49, Jeremy Whiting wrote:
> 
> 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.
> 
> BR,
> Jeremy
> 
> On Tue, May 7, 2013 at 5:20 PM, Jeremy Whiting <jpwhiting at kde.org> 
> wrote:
> 
> Urs,
> 
> 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: http://websvn.kde.org/?view=revision&revision=200868 [1] [1] 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).
> 
> thanks,
> Jeremy
> 
> On Thu, Apr 18, 2013 at 1:33 PM, Jeremy Whiting <jpwhiting at kde.org> 
> wrote:
> 
> On Thu, Apr 18, 2013 at 2:41 AM, Urs Wolfer <uwolfer at kde.org> wrote:
> Hi Jeremy
> 
> Thanks a lot for your work! :)
> 
> No problem, glad to help.
> 
> 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?
> 
> 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.
> 
> 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?
> 
> 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.
> 
> Do you think I should start backport the standalone fixes / docs moving 
> the the 4.10 branch now?
> 
> 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.
> 
> 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,
> 
> Jeremy
> 
> 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 <uwolfer at kde.org> wrote:
> 
> I have created an initial version of the wiki page:
> http://community.kde.org/KDENETWORK/Git_Migration [2] [2] [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 
> [3] [3] [1]
> 
> And for Kopete:
> https://projects.kde.org/projects/playground/sdk/kde-ruleset/repository/revisions/kopete/show/kdenetwork 
> [4] [4] [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 
> [3] [3]
> [2]
> https://projects.kde.org/projects/playground/sdk/kde-ruleset/repository/revisions/kopete/show/kdenetwork 
> [4] [4]
> [3] http://community.kde.org/KDENETWORK/Git_Migration [2] [2]
> 
> Links:
> ------
> [1] http://websvn.kde.org/?view=revision&revision=200868 [1]
> [2] http://community.kde.org/KDENETWORK/Git_Migration [2]
> [3]
> https://projects.kde.org/projects/playground/sdk/kde-ruleset/repository/revisions/master/entry/kdenetwork-rules 
> [3]
> [4]
> https://projects.kde.org/projects/playground/sdk/kde-ruleset/repository/revisions/kopete/show/kdenetwork 
> [4]
> 
> 
> 
> Links:
> ------
> [1] http://websvn.kde.org/?view=revision&revision=200868
> [2] http://community.kde.org/KDENETWORK/Git_Migration
> [3]
> https://projects.kde.org/projects/playground/sdk/kde-ruleset/repository/revisions/master/entry/kdenetwork-rules
> [4]
> https://projects.kde.org/projects/playground/sdk/kde-ruleset/repository/revisions/kopete/show/kdenetwork