Thomas,
Hello, I'm one of the guys that has helped with svn to git migrations
in KDE and have some help I may offer here. Comments below.
On Thu, Nov 6, 2014 at 3:10 PM, Mario Fux wrote:
> Am Samstag, 25. Oktober 2014, 13.16:51 schrieb Thomas Friedrichsmeier:
>> Hi all, hi Mario!
>
> Good morning Thomas and all
>
> Sorry for the delay in answering this email but the flu season is starting and
> my family and me already won two times ;-).
>
>> I think the time has come to pin this down, and declare that the RKWard
>> project is going to move to KDE.org, and the KDE community!
>
> Great. Let me be the first to tell you: Welcome to KDE :-).
>
>> This is not going to be completed in a week or two, but we'll try to make
>> the transition as smooth as possible. The key point of this mail is to lay
>> out a rough plan, and start thinking about the first steps.
>
> And I setup an incubator page for Rkward:
> https://community.kde.org/Incubator/Projects/Rkward
>
> Don't hesitate to add stuff, items or information (it's a wiki after all) or
> ask me for help.
>
>> One small exception to our move to KDE is that we intend to establish a
>> small side-kick project on github.com, as a semi-official place to develop
>> "external plugins", i.e. those that are not (or not yet) targetted to be
>> included in the official releases. This would need a separate git
>> repository in the first place, and the idea is that this is a bit "closer
>> to the R community" (but also matches well with the whole concept of
>> external plugins). Not sure, whether this would strictly fall under the
>> "continuity requirement" of KDE.org, but it certainly should not be a
>> problem to give KDE sysadmins admin access to this.
>
> If I understand it correctly you plan to move the source code to KDE's git
> repos and have another close/copy of the repo on github.com. I don't see a
> problem. How will you merge features? You might as well use
> reviewboard.kde.org to encourage contributions by people that don't yet have a
> KDE developer account.
>
>> For the rest, the plan is roughly as follows, I think:
>>
>> 1. Prepare any required formalities. Mario, please comment.
>
> I don't see much formalitites so: done ;-).
>
>> 2. Give KDE sysadmins admin access to the SF-project, in order to ensure
>> continuity in case we diasppear in the middle of the transition. Mario, I'm
>> sure, there is an SF-account for this, already. Which?
>
> Get in contact with the KDE sysadmins via http://sysadmin.kde.org/tickets/
>
>> 3. Have our SVN-repo imported to a git-repo on git.kde.org. This is going
>> to require a bit of preparation - see below.
>
> People like Nivolás Alvarez (PovAddict(W)) or Jeremy Whiting (jwhiting) might
> help. They are used to migrate SVN repos to Git. In paranthesis you find their
> nicknames on IRC. Mine is unormal btw. Don't hesitate to ping me if you need
> anything. Oh and I CC: these guys ;-).
>
>> 4. Move translations from launchpad?
>> 5. In no particular order, move website, mailing lists, and downloads to
>> KDE.org. Also forums, although, for those, it should be good enough to
>> archive existing posts, statically, and simply open new forum(s) on
>> forum.kde.org. 6. Move bug tracker. This one should not happen too early,
>> as there are non- redirecting links to the bug tracker in all RKWard
>> versions up to 0.6.1.
>
> Sounds reasonable.
>
>> Well, 1 and 2 should not take much time, I hope. For moving to git, here
>> are some things we need to take care of / decide:
>>
>> - SVN author accounts have to be converted to git format, i.e. full name
>> and email address. For those planning or considering to commit in the
>> future, this should match the email used for your identity.kde.org account
>> (if you don't have one, yet, get one, now!). Even if you do not plan to
>> register at identity.kde.org (yet), it may still make sense to provide a
>> current email address. I'll contact all past and present committers, and
>> will fall back to accountn...@users.sf.net.
>> - branches/external_plugins needs to be split out, somehow, as it is not
>> really a branch in the git-sense. As noted above, it probably makes sense
>> to import this branch to github.com. In fact, there is little reason not
>> to go ahead on this one, yet. Volunteers?
>> - branches/jss_dec_10 needs to be split, out, too. This branch is
>> interesting for archiving, only.
>> - Seasoned git users, please advise: Is there any point in keeping
>> obsoleted release-branches, an
