[Kde-scm-interest] Kopete git migration

[Urs Wolfer]

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 <uwolfer at 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