[Kde-scm-interest] Kopete git migration

Fri May 17 15:01:02 UTC 2013

On Thu, May 16, 2013 at 11:48 PM, Urs Wolfer <uwolfer at kde.org> wrote:

> 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.

Yes, I think it's in very good shape.  If you could get maintainers to
check their repos that would be great.  And update the table in the wiki
page accordingly.

BR,
Jeremy

>
> 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<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<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<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<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<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<https://projects.kde.org/projects/playground/sdk/kde-ruleset/repository/revisions/kopete/show/kdenetwork>[4] [4]
>> [3] http://community.kde.org/**KDENETWORK/Git_Migration<http://community.kde.org/KDENETWORK/Git_Migration>[2] [2]
>>
>> Links:
>> ------
>> [1] http://websvn.kde.org/?view=**revision&revision=200868<http://websvn.kde.org/?view=revision&revision=200868>[1]
>> [2] http://community.kde.org/**KDENETWORK/Git_Migration<http://community.kde.org/KDENETWORK/Git_Migration>[2]
>> [3]
>> 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>[3]
>> [4]
>> 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>[4]
>>
>>
>>
>>
>> Links:
>> ------
>> [1] http://websvn.kde.org/?view=**revision&revision=200868<http://websvn.kde.org/?view=revision&revision=200868>
>> [2] http://community.kde.org/**KDENETWORK/Git_Migration<http://community.kde.org/KDENETWORK/Git_Migration>
>> [3]
>> 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>
>> [4]
>> 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>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-scm-interest/attachments/20130517/fb62e29d/attachment.html>