[Kde-scm-interest] Kopete git migration

Tue May 7 23:20:48 UTC 2013

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 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<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<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<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<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<https://projects.kde.org/projects/playground/sdk/kde-ruleset/repository/revisions/kopete/show/kdenetwork>
>>> [3] http://community.kde.org/**KDENETWORK/Git_Migration<http://community.kde.org/KDENETWORK/Git_Migration>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-scm-interest/attachments/20130507/ca6f0f65/attachment.html>