Recently, there has been more than one reason to be not-so-happy with our 
current project hosting (i.e. SourceForge.net). At the same time the "git" 
version control system gains more and more friends, and some people have 
suggested switching from SVN to git. Furthermore, KDE has become a much less 
monolithical environment (especially, but not only, in its new instantiation 

All of these are good reasons to re-consider our hosting options. I think, the 
most obvious choices would be:
- Staying on SF, and keeping everything as is
- Staying on SF, but switching to a git repository
- Moving project hosting to github.com
        - Advantage of having a rapidly growing community
- Moving project hosting to kde.org
        - Advantage of being the community working on the same platform, and 
having the most obvious potential for synergies.

Well, the point of this mail is not really to discuss the pros and cons of 
each of these options. That _is_ a discussion worth having, but right now, my 
goal is to explore what hosting requirements we have, and how we would go 
about migrating in order to ensure a mostly smooth transition.

I'll let you know that I'm currently leaning towards kde.org, though. Please 
feel free to start a debate on this, esp. if you would favor another solution.


So: What services do we use, and what should we keep in mind about each:

1. Version control: Our needs here are fairly straight-forward. However, some 
things to consider when migrating.
- Links to SVN location are at a bunch of places:
        - Our wiki
        - MacPorts port file
        - Windows emerge build file
        - (Purely informational also in Debian/Ubuntu package)
        - Possibly other packages, we are not directly involved with
- Some people build from SVN, regularly
- Our Ubuntu daily builds on launchpad use a mirror of our SVN
- Launchpad translations syncs the message template from our SVN

Some of this may become obsolete when migrating (at least the launchpad 
translations, when migrating to kde.org). However, to ensure a somewhat smooth 
transition, we will probably have to make sure to keep our SVN at SF.net alive 
for quite a while, probably as a mirror of our primary VCS, then.

2. Wiki and Web: Our "project web", i.e. the pages under http://rkward.sf.net 
mostly consist of a MediaWiki installation. I think that still makes a lot of 
sense, so we'll want to migrate that 1:1. Further we have a few plain HTML-
files (importantly the building-plugins docu), and some PDFs. Also an apt-
gettable repository of Debian packages.

References to our project pages are all over the place, including compiled 
into RKWard itself. So we absolutely want to set up some sensible redirects, 
and these should be active for quite some time.

3. Bug and feature tracker: These are a custom brew by SF.net ("Allura"). I 
don't know, whether there is a smooth migration path to bugzilla, yet. If 
possible, we'd like to migrate both open and closed bugs. Even closed tickets 
are still valuable for later reference, at times.

In this respect, there is a further problem to solve: A bunch of comments in 
the code, and commit messages references bug tickets. There should always be a 
way to resolve these to an existing URL (this needs not be a really user-
friendly way, though).

The location of our bug tracker compiled into RKWard is now an automatic 
redirect. However, non-redirecting links will be found in the wiki, and 
probably other places.

4. Mailing lists
Anyone with experience in migrating mailing lists (mailman) to a new hostname? 

Links to the rkward-de...@sf.net list are all over the net, I'm afraid, and 
also compiled into RKWard. Thus the old address(es) should remain active for a 
fair amount of time to come (but could be forwarding to the new mailing 

It would be nice to keep the archive at 
http://www.mail-archive.com/rkward-devel@lists.sourceforge.net/ functional. As 
with bug tickets, many code 
comments and commit messages contain references to mails. Links to mails in 
the archive will also be found in the wiki.

5. Forums
The public forums were never too active. But they were used for discussing 
issues at times. Preserving those discussions for reference would be really 
nice, although this could be achieved with a simple HTML-mirror. A "true" 
import into another forum software is probably not necessary.

Obviously we need to offer file downloads. This includes some pretty large 
files, esp. for the bundled binary releases (~150MB for Windows, ~400MB for 
MAC, source bundles up to 800MB). We even have one file of 2.7GB for download, 
currently (Windows build environment). These will probably get smaller, but 
not small after porting to KF5 (aka KDE 5).


Please fill in the bits I forgot. To sum it up, migrating to a new hosting is 
going to require a good deal of work. Some of you have been wondering, why 
I've taken a rather conservative stance on the matter. I guess you'll have a 
better idea, now. And, if you think the whole idea of migrating is just too 
crazy, now is the time to speak up.

Of course we do not have to take care of all things at once, and in fact, 
realistically we'll probably start by migrating the VCS, and completing all 
other bits is going to take a rather longish time. Importantly, however, the 
long term goal will be not to spread hosting across more sites than necessary.


Attachment: signature.asc
Description: This is a digitally signed message part.

Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
RKWard-devel mailing list

Reply via email to