[Kde-scm-interest] Kopete git migration

Jeremy Whiting jpwhiting at kde.org
Wed Apr 17 17:40:11 UTC 2013


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>
> 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>
>>
>> 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>
>>
>> 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-scm-interest/attachments/20130417/246a79b1/attachment.html>


More information about the Kde-scm-interest mailing list