Infrastructure/Get a Developer Account: Difference between revisions

From KDE Community Wiki
(Create a section for HTTPS configuration tips and do the same for the SSH configuration)
(Re-add mention of translators, who also can benefit from having a developer accounts)
 
(60 intermediate revisions by 31 users not shown)
Line 1: Line 1:
{{Template:I18n/Language Navigation Bar|Contribute/Get a SVN Account}}
{{Info|You do not need a KDE Developer account to browse source code, log into https://invent.kde.org, submit merge requests, or participate in other normal development activities.  Instead, all you need is a normal '''KDE Identity Account'''; see [[Infrastructure/GitLab|GitLab]] instead.}}
This tutorial is about how to apply for a SVN account for KDE.


== Notations ==
When you have been doing development work in KDE for some time and many of your merge requests or translations have been merged without drama, you may be encouraged to apply for a '''KDE Developer account.''' This will grant you the ability to do the following:


* The word ''SVN'' applies to all SVN servers.
# Formally approve other people's merge requests
* The phrase ''KDE SVN'' refers only to KDE's SVN server.
# Set and change milestones and labels on merge requests and issues
* The phrase ''anonymous SVN'' means KDE's anonymous SVN mirrors.
# Merge other people's approved merge requests, or your own
# Directly push commits to change files in almost all of KDE's git and svn repositories


== What is KDE SVN? ==
Before you apply for a KDE Developer account, you must read, understand, and accept [[Policies/Commit Policy|the KDE commit policy]] when using your future KDE Developer account. Please also familiarize yourself with the [http://www.kde.org/code-of-conduct/ KDE Code of Conduct] which describes the social foundations within KDE, and the [https://manifesto.kde.org/ KDE Manifesto] that describes KDE's values. Holders of KDE Developer accounts are expected to uphold the highest ethical standards and not abuse the privileges they have been granted by committing controversial or un-approved changes.


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.)
Once you plan to contribute to KDE over the long term, and are ready to assume these responsibilities, visit the [https://identity.kde.org/index.php?r=developerApplication Developer Application page] to submit your application.


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''.)
The form there will ask you a series of questions, including ''Why do you want an account?'', where you can explain what you want to do with your future KDE Developer account and why it's not enough to let other people merge your merge requests for you. List your sponsor who encouraged you to apply. They will also get an email to verify your request.


'''Note''': you can see the accounts in [http://websvn.kde.org/trunk/kde-common/accounts kde-common/accounts]. That is the list of all accounts. Yes, '''the account list is public''', for example on [http://websvn.kde.org WebSVN].
KDE's sysadmins have the last word about whether or not to approve a KDE Developer account for somebody.
 
To access the main KDE SVN, you have two possibilities, with different ways to encrypt transmitted data:
* using HTTPS
* using SSH
 
If you have never used ssh before, you might prefer ''HTTPS'', it's a bit simpler to set up.
 
However it seems that currently svn-over-ssh is really much faster than svn-over-https, so that is a good reason for using ssh.
 
The password you will need to create depends on the above:
* a normal password for accessing by HTTPS, or
* a SSH public key for accessing by SSH
 
A KDE SVN account allows you to write to nearly anywhere in the KDE SVN. However, there are exceptions:
* the KDE SVN internals
* the admin directory
* the www module (exceptions can be made for this.)
 
== Who Can Apply For a KDE SVN Account? ==
 
Normally, any developer who has done some work on KDE can apply for a KDE SVN 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 [[Policies/SVN Commit Policy|read the KDE SVN commit policy]]. You must accept these rules when using your future KDE SVN account.
 
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 [mailto:[email protected] KDE's sysadmins] have the last word about whether or not to create a KDE SVN account for somebody''.
 
== Access via HTTPS ==
 
=== Choosing a Password ===
 
First of all, you have to choose a password. If possible, one that you do not use for anything else on your computer (as the SVN account has nothing to do with any other account on your computer.)
 
In any case, please use ''common precautions'' about passwords.
 
Strong passwords:
* have both upper and lower case letters.
* have digits and/or punctuation characters as well as letters.
* are easy to remember, so they do not have to be written down.
* are at least eight characters long.
 
A strong password is '''not''':
 
* Personal information such as your name, phone number, social security number, birth date or address. Even names of acquaintances and the like should not be used.
* Any word in the dictionary, or based closely on such a word (such as a word spelled backwards).
* A word with letters simply replaced by digits. For example, bl0wf1sh is not a strong password.
* Easy to spot while you're typing them in. Passwords like 12345, qwerty (i.e., all keys right next to each other), or nnnnnn should be avoided.
 
All the rules are not here to annoy you but to guarantee a certain level of security for the KDE SVN server.
 
=== Getting the Encoded Password ===
 
Now that you have your password, you need to encode it, not to have to send it in clear. (Note: this encryption is the same type of encryption used by many Linux distributions for their {{path|/etc/shadow}} file.)
 
If your password is 8 characters long, one way to do this would be using Perl: <!-- <code>perl -e "print crypt('&lt;your password&gt;','xy'),\"\n\";"</code> -->
<nowiki>perl -e 'print crypt("<your password>","\$1\$xyz\$")."\n";'</nowiki>
where &lt;your password&gt; has to be replaced with your password and ''xyz'' with 3 to 8 random characters of your choice. Leave the \$1\$ before it and the \$ after it.
 
(Hint: $ must be "escaped" with a backslash. For instance: If your password is "abc$123" you have to replace &lt;your password&gt; with "abc\$123". )
 
'''Note''': do not worry to find your choice of &lt;xyz&gt; at the start of the encoded password, it is meant to be so.
 
Another solution is to create a dummy account on a Unix system where you have administrator access. You can use the built-in user management programs of your distribution and search for the account in your file {{path|/etc/shadow}} or you can use the following code:
useradd dummy; passwd dummy; grep dummy /etc/passwd /etc/shadow; userdel dummy
 
In any case, the password is then the part between the first ':' and the second ':'. (Note: not a star! (*) That means that it is not the password!)
 
'''Note''': This might not work anymore with newer systems because they encrypt the password with a hash algorithm that is not (yet) supported by the kde server. To be save, use the perl script
 
Save the encoded password so that you can use it later in the application.
 
== Access via SSH ==
 
=== Getting the SSH keys ===
 
Please refer to a SSH documentation or book to see how to create a pair of SSH keys, the short version is <code bash>ssh-keygen -t dsa</code>
The '-t dsa' indicates that 'dsa' type keys should be created. Dsa and rsa keys are used in the version 2 of the SSH protocol, whereas rsa keys are used in version 1. See the  [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-keygen ssh documentation] for more. Accept the default filename and the default of no passphrase.
 
You '''need''' a SSH public key. Don't send us a GPG (OpenPGP) key, that is completely unrelated!
 
The password in the sense of this documentation is the '''public key''' that you are creating. The public key can usually be found at {{path|$HOME/.ssh/id_dsa.pub}}.
 
Do '''not''' send the private key at {{path|$HOME/.ssh/id_dsa}}, it has to remain a secret.
 
You should also set up <tt>ssh-agent</tt> so you do not have to type the password every time. There are several tutorials available explaining how to do this, for example [http://mah.everybody.org/docs/ssh this one].
 
'''Note''': if you already have an ssh key, you can just use the extisting 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 <tt>$HOME/.ssh/id_dsa.pub</tt> and <tt>$HOME/.ssh/id_dsa</tt> to the other user's <tt>$HOME/.ssh</tt> directory.
 
You should probably also backup those files.
}}
 
=== Setting up 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 <tt>~/.ssh/config</tt> file. Replace USERNAME with yours.
 
<pre>
Host *.kde.org
        User USERNAME
        IdentityFile ~/.ssh/id_dsa
</pre>
 
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 (<tt>*.pub</tt>).
 
== Apply for an account ==
 
Now that you have a password, you need a username for your KDE SVN account. Normally your family name is used. Let us call it ''username'' for this example.
 
You can propose something else if you want. But be careful that one day, you could ask for a KDE email address and this would be the base for your address. For example: <tt>[email protected]</tt>. (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, [http://www.kdemail.net KDE Mail] was created for if you need a permanent address.)
 
So now you have a username and a password. Now the email address: you have to use your own (be it a normal address or a KDE Mail address). Of course, do not forget that this '''email address becomes public''' (at least by [http://websvn.kde.org WebSVN]) so you will unfortunately get spam.
 
Also note that this email address should be the same one that you use on [http://bugs.kde.org bugs.kde.org]. If you don't have one, please create it 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 [http://bugs.kde.org bugs.kde.org] accounts match.
 
Now you are ready to apply for for a KDE SVN account.
Go to [https://sysadmin.kde.org/svnaccount/ https://sysadmin.kde.org/svnaccount/] and fill out the form. It should be easy to do now.
 
After filling out the form, you will receive an email with a link to click on. This is done to verify your email address. The application is not complete before you click on it.
 
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.
 
The form also holds a field ''justification'', here you can explain what you want to do with your future KDE SVN account, like for examples developing a certain application, making documentations, being team leader of a translation...
 
== 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 [[Infrastructure/First Steps with your Contributor Account|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 [http://commit-digest.org/data/ Commit Digest data page] so that the Commit Digest can accurately reflect who is working where.

Latest revision as of 16:15, 1 April 2024

Information

You do not need a KDE Developer account to browse source code, log into https://invent.kde.org, submit merge requests, or participate in other normal development activities. Instead, all you need is a normal KDE Identity Account; see GitLab instead.


When you have been doing development work in KDE for some time and many of your merge requests or translations have been merged without drama, you may be encouraged to apply for a KDE Developer account. This will grant you the ability to do the following:

  1. Formally approve other people's merge requests
  2. Set and change milestones and labels on merge requests and issues
  3. Merge other people's approved merge requests, or your own
  4. Directly push commits to change files in almost all of KDE's git and svn repositories

Before you apply for a KDE Developer account, you must read, understand, and accept the KDE commit policy when using your future KDE Developer account. Please also familiarize yourself with the KDE Code of Conduct which describes the social foundations within KDE, and the KDE Manifesto that describes KDE's values. Holders of KDE Developer accounts are expected to uphold the highest ethical standards and not abuse the privileges they have been granted by committing controversial or un-approved changes.

Once you plan to contribute to KDE over the long term, and are ready to assume these responsibilities, visit the Developer Application page to submit your application.

The form there will ask you a series of questions, including Why do you want an account?, where you can explain what you want to do with your future KDE Developer account and why it's not enough to let other people merge your merge requests for you. List your sponsor who encouraged you to apply. They will also get an email to verify your request.

KDE's sysadmins have the last word about whether or not to approve a KDE Developer account for somebody.