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://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.
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
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 http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
