Jump to content

Infrastructure/Get a Developer Account

From KDE Community Wiki

Template:I18n/Language Navigation Bar This tutorial is about how to apply for a SVN or GIT account for KDE.

The short answer: how to get read-write developer access

KDE developer accounts are managed through KDE Identity. You can request Developer Access in the website's menu upon registering and logging into your account.

The rest of this page is a bit outdated and talks mostly about SVN, although many things (e.g. details on SSH keys) are still applicable for GIT.

What is KDE SVN?

To have write access to KDE SVN, you have to use the main SVN server of KDE. (Anonymous SVN uses mirrors of this server. SVN does not allow you to read from one server and write to another.)

To be able to use the main KDE SVN server, you need an account there. An account is made up of a username (normally your family name), a password and an email address. The username is for getting in, the password for authenticating and the email address for knowing who to contact if another developer wants to contact the account holder. (The username is sometimes known also as the login.)

A KDE SVN account allows you to write to nearly anywhere in the KDE SVN. However, there are exceptions:

  • the KDE SVN internals
  • the www module (exceptions can be made for this.)

Note: you can see the accounts in kde-common/accounts. That is the list of all accounts. Yes, the account list is public, for example on WebSVN.

Who Can Apply For a KDE Contributor Account?

Normally, any developer who has done some work on KDE can apply for a KDE Contributor account.

Translators should get approval from their team leader so that they can organize how the work is being done in his/her team. Please mention the approval from the team leader when requesting the account.

Please also read the KDE SVN commit policy. You must accept these rules when using your future KDE SVN account. Please also familiarize yourself with the KDE Code of Conduct which describes the social foundations within KDE.

Also please apply for an account only if you think that you will work on KDE for a somewhat longer time. If you know that you will only work for a couple of weeks and then never again, please consider not applying for a KDE SVN account but still, do continue to send patches.

The limitations are not there to exclude anyone - they are there to ensure that the maintenance of accounts remains reasonable.

Of course, to be clear: the KDE's sysadmins have the last word about whether or not to create a KDE SVN account for somebody.

SSH

You need a SSH public key in order to access your KDE SVN account. If you already have one, you can skip the next subsection and go to Setting up the SVN+SSH protocol.

Generating the SSH keys

To be able to use your KDE SVN account with SSH, you need a SSH public key. Please notice that it is not a GPG (OpenPGP) key, which is completely unrelated!

The password in the sense of this documentation is the public key that you are creating.

For more information on how to create a pair o SSH keys, please refer to a SSH documentation or book.

In short, the command to create a pair of keys is ssh-keygen and it requires the type of key you will create, either DSA or RSA - both are fine.

To create a new pair of keys, use

ssh-keygen -t dsa</code> or <syntaxhighlight lang="bash">ssh-keygen -t rsa

There is also a type called RSA1 which was used in version 1 of the SSH protocol. See the ssh documentation for more details.

You can then accept the default filename for your key (either $HOME/.ssh/id_dsa or $HOME/.ssh/id_rsa, depending on the type of key you have chosen). After that, a passphrase is asked. It is recommended that you do not leave it blank.

Now that you are finished generating your key pair, you will have two files: a private key and a public key. If you have accepted the default filename, they will be respectively $HOME/.ssh/id_dsa and $HOME/.ssh/id_dsa.pub or $HOME/.ssh/id_rsa and $HOME/.ssh/id_rsa.pub, depending on the type of key you have specified.

The private key must remain secret, do not publish it to anyone under any circumstance.

The public key can be published and shall be sent when you are applying for a KDE SVN account.

You should also set up ssh-agent so you do not have to type the password every time you connect via SSH. There are several tutorials available explaining how to do this, for example this one. Keychain is a program that makes this task easier.

Note: if you already have an ssh key, you can just use the existing key instead of creating a new one.

 
Tip
If you want to use SVN with SSH with another user than the one who created the keys, you need to copy $HOME/.ssh/id_dsa.pub and $HOME/.ssh/id_dsa or $HOME/.ssh/id_rsa.pub and $HOME/.ssh/id_rsa to the other user's $HOME/.ssh directory. You should probably also backup those files.


Setting up the SVN+SSH protocol

Once you created your key, you'll have to tell SSH that this one should be used for all connections to KDE sites. Add the following lines to the ~/.ssh/config file. Replace USERNAME with yours.

Host *.kde.org
        User USERNAME
        IdentityFile ~/.ssh/id_dsa

The linked IdentityFile must belong to the public key you send in when applying for the SVN account. But it is not the public key (*.pub).

Apply for an account

Now you are ready to apply for for a KDE SVN account. Go to https://identity.kde.org/svnaccount/ and create an account if you don't have one already. If you already have an account, you can use that. After you entered the site you will find a form which you can fill in to apply for an account.

When you register on identity.kde.org, you will need to enter your name and an e-mail address, which has to be your own (a normal address or a KDE Mail address). Of course, do not forget that this email address becomes public (at least by WebSVN) so you will unfortunately get spam.

Also note that this email address should be the same one that you use on bugs.kde.org. If you don't have an account in bugs.kde.org, please create one so that it can be given usual developer rights. Closing bug reports with keywords in commit comments only works if the email address of your Subversion and bugs.kde.org accounts match.

After that, you must choose a username for your KDE SVN account between the suggestions presented to you. Please notice it is not possible to propose something else such as a nickname, as the username must be as close as possible to someone's real name.

If you ask for a KDE email address one day, this will be the base for your address. For example: [email protected]. (Note, however, that KDE email addresses are not granted so easily anymore, as too many people have ranted with a KDE address and other people thought that it was the official position of the KDE Team. In the meantime, KDE Mail was created for if you need a permanent address.)

When applying for developer access you have to provide your public key. This key will be added to your profile. You can always add more keys, delete keys you don't use anymore from your profile page on identity.kde.org.

The form also holds a field Why do you want an account?, where you can explain what you want to do with your future KDE SVN account, like for example developing a certain application, making documentations or being the team leader of a translation.

Also note that the form will ask you who has encouraged you to apply. He or she will also get an email to verify your request.

Updating Existing Account

If you already have a KDE SVN account but want to update the ssh key, you should go to identity.kde.org and change the keys in your profile.

And Now?

After having sent the form and clicking the link in the email, you have to wait for the answer (typically within two or three days).

Once you have confirmation that your account has been created, you need to adapt your local copy to the new server. See the next tutorial for your first steps with your new account.

Please add your geographical location (what country are you in?) and other details at the Commit Digest data page so that the Commit Digest can accurately reflect who is working where.