[Kde-scm-interest] Kopete git migration

[Jeremy Whiting]

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/20130418/988f3ce7/attachment.html>