[rkward-devel] Moving to KDE.org

[Jeremy Whiting]

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 <kde-ml at unormal.org> 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 accountname at 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, and fully merged development branches, or
>> should these simply be dropped in the import? Or would they be dropped
>> _after_ the import, in order to keep full commit history?
>> - Beyond this, there is quite a bit of inconsistency regarding naming of
>> branches and tags. I'd like to fix that. Is that best to be done before,
>> during, or after the import?
>
> Ok, not much I can help other than finding people with knowledge about this.

Ok, some information about doing svn to git migrations can be found
here: https://techbase.kde.org/Projects/MoveToGit/UsingSvn2Git how
we've done it in kde is to have a sync of the subversion repository
itself (not just a checkout, but a copy of what's on the server, I
guess you/we can get that from SF?) Then rules are made and the
svn2git program reads the rules, and creates git repository(ies) and
puts the commits into the git repositories. For this to work it needs
to have some account map of the committers to the svn repository, so
if all those that have contributed to rkward in the past aren't
interested in creating/getting identity.kde.org accounts we can either
add their e-mail addresses to an address map file or add all of their
names/email addresses to one e-mail address (accountname at users.sf.net)
or something as needed.
Once a conversion is ran, we push to git scratch space on git.kde.org
so the conversion can be reviewed by anyone interested to make sure we
got all history and branches/tags, etc. look ok. It should be pretty
straightforward to filter out any branches into separate git
repositories or whatnot if wanted. Then after the git repos look ok we
can ask sysadmin to create a real git repo for them and push to there.

>
>> - Finally, I'm not sure, whether there are any uniform push-rules for git
>> repositories on KDE.org. Mario? We certainly want to block
>> non-fast-forwarded commits. But beyond this I don't really have a clue on
>> git administration. Anybody?
>
> The KDE sysadmin will help you and tell about our infrastructure with their
> hooks and possibilities.
>
>> Well, enough to chew on for one mail. We'll worry about steps 4 and up,
>> later.
>
> So I hope my information is of some help, don't hesitate to ask and write me
> and let's bring this great R IDE to KDE.
>
>> Regards
>> Thomas
>
> Best regards
> Mario

Hope that information helps. Let me know if you need any help in rule
writing, running a conversion, or whatnot.

thanks,
Jeremy