[rkward-devel] Moving to KDE.org
Thomas Friedrichsmeier
thomas.friedrichsmeier at ruhr-uni-bochum.de
Sat Oct 25 11:16:51 UTC 2014
Hi all, hi Mario!
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!
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.
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.
For the rest, the plan is roughly as follows, I think:
1. Prepare any required formalities. Mario, please comment.
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?
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.
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.
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?
- 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?
Well, enough to chew on for one mail. We'll worry about steps 4 and up, later.
Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20141025/f27fced0/attachment.sig>
More information about the Rkward-devel
mailing list