Hi! 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 "frameworks").
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 thus 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 lists). It would be nice to keep the archive at http://email@example.com/ 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. 6. Downloads 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. Regards Thomas
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 http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________ RKWard-devel mailing list RKWardfirstname.lastname@example.org https://lists.sourceforge.net/lists/listinfo/rkward-devel