Difference between revisions of "Development/FAQs/General FAQ/ja"

Jump to: navigation, search
(Updating to match new version of source page)
(Updating to match new version of source page)
 
Line 7: Line 7:
 
どの分野に助けが必要か知るには、[http://www.kde.org/jobs/ このページ]をチェックしてください。
 
どの分野に助けが必要か知るには、[http://www.kde.org/jobs/ このページ]をチェックしてください。
  
 +
<span class="mw-translate-fuzzy">
 
新しいアプリケーションを書き始める前に、[http://www.kde-apps.org/ KDE-Apps.org] をチェックしたり、[https://mail.kde.org/mailman/listinfo/kde-devel kde-devel@kde.org] のメーリングリストで聞くなどして、誰かが似たようなプロジェクトをしていないかどうか確かるのは良いことです。
 
新しいアプリケーションを書き始める前に、[http://www.kde-apps.org/ KDE-Apps.org] をチェックしたり、[https://mail.kde.org/mailman/listinfo/kde-devel kde-devel@kde.org] のメーリングリストで聞くなどして、誰かが似たようなプロジェクトをしていないかどうか確かるのは良いことです。
 +
</span>
  
 
==私は開発者です。どうすれば KDE に貢献できますか?==
 
==私は開発者です。どうすれば KDE に貢献できますか?==
Line 33: Line 35:
 
It was posted to artist.kde.org before that site ceased to be updated.
 
It was posted to artist.kde.org before that site ceased to be updated.
  
Further images are on [http://kde.org/stuff/clipart.php KDE merchandise].
+
Further images are on [http://kde.org/stuff/clipart.php KDE merchandise]. Also you can find some  unofficial Konqi images and models from [http://forum.kde.org/viewforum.php?f=254 Create Konqi with Krita Contest] and [http://sourceforge.net/projects/supertuxkart/ SuperTuxKart] game.
  
 
==KDE に貢献するのに必要なスキルのレベルはどの程度ですか? 何を学んでおくべきですか? 何を読んでおくべきですか?==
 
==KDE に貢献するのに必要なスキルのレベルはどの程度ですか? 何を学んでおくべきですか? 何を読んでおくべきですか?==
Line 45: Line 47:
 
==KDE の git や SVN のリポジトリーから KDE ソフトウェアを取得するにはどうすれば良いですか?==
 
==KDE の git や SVN のリポジトリーから KDE ソフトウェアを取得するにはどうすれば良いですか?==
  
 +
<span class="mw-translate-fuzzy">
 
[[Special:myLanguage/Getting_Started|Getting_Started]] ページの "Building and Running KDE Software From Source" (ソースから KDE ソフトウェアをビルドして実行する) セクションを確認して下さい。
 
[[Special:myLanguage/Getting_Started|Getting_Started]] ページの "Building and Running KDE Software From Source" (ソースから KDE ソフトウェアをビルドして実行する) セクションを確認して下さい。
 +
</span>
  
 
==KDE のソースコードに Web ブラウザからアクセスすることは出来ますか?==
 
==KDE のソースコードに Web ブラウザからアクセスすることは出来ますか?==
  
 +
<span class="mw-translate-fuzzy">
 
はい。
 
はい。
 
* http://websvn.kde.org/ や https://projects.kde.org/ からブラウズする
 
* http://websvn.kde.org/ や https://projects.kde.org/ からブラウズする
Line 54: Line 59:
 
* http://api.kde.org/ で、ソースコードから生成された API ドキュメントを閲覧する
 
* http://api.kde.org/ で、ソースコードから生成された API ドキュメントを閲覧する
 
などの方法があります。
 
などの方法があります。
 +
</span>
  
 
==.subversion/config にはどのように記述すべきでしょう?==
 
==.subversion/config にはどのように記述すべきでしょう?==
  
 +
<span class="mw-translate-fuzzy">
 
<syntaxhighlight lang="text">[miscellany]
 
<syntaxhighlight lang="text">[miscellany]
 
global-ignores = *.moc *.moc.cc *.moc.cpp config.log config.status \
 
global-ignores = *.moc *.moc.cc *.moc.cpp config.log config.status \
Line 69: Line 76:
 
diff-cmd = /usr/local/bin/_svndiff</syntaxhighlight>
 
diff-cmd = /usr/local/bin/_svndiff</syntaxhighlight>
 
と記述します。
 
と記述します。
 +
</span>
  
 +
And to make svn diff ignore whitespace, and print function names:
 +
 +
<syntaxhighlight lang="bash">
 +
[helpers]
 +
diff-cmd = /usr/local/bin/_svndiff
 +
</syntaxhighlight>
 +
 +
<span class="mw-translate-fuzzy">
 
そして {{path|/usr/local/bin/_svndiff}} に、
 
そして {{path|/usr/local/bin/_svndiff}} に、
 
<syntaxhighlight lang="text">#!/bin/sh
 
<syntaxhighlight lang="text">#!/bin/sh
 
exec /usr/bin/diff -b -u -p "$@"</syntaxhighlight>
 
exec /usr/bin/diff -b -u -p "$@"</syntaxhighlight>
 
と付け加えます。
 
と付け加えます。
 +
</span>
 +
 +
<syntaxhighlight lang="bash">
 +
#!/bin/sh
 +
exec /usr/bin/diff -b -u -p "$@"
 +
</syntaxhighlight>
  
 
{{path|/usr/local/bin/_svndiff}} に実行パーミッションを与えるのをお忘れなく。
 
{{path|/usr/local/bin/_svndiff}} に実行パーミッションを与えるのをお忘れなく。
Line 79: Line 101:
 
==自分のアプリケーションを KDE に含めるにはどうすればよいでしょうか?==
 
==自分のアプリケーションを KDE に含めるにはどうすればよいでしょうか?==
  
 +
<span class="mw-translate-fuzzy">
 
三つの必要条件があります。  
 
三つの必要条件があります。  
 
* KDE の (git master または SVN trunk上にある) 最新バージョンでコンパイルできること。
 
* KDE の (git master または SVN trunk上にある) 最新バージョンでコンパイルできること。
Line 84: Line 107:
 
* メンテナンスされること。あなたは多くのバグレポートや要望を受け取ることになるでしょう。バグの修正や、要望の実装が求められます。
 
* メンテナンスされること。あなたは多くのバグレポートや要望を受け取ることになるでしょう。バグの修正や、要望の実装が求められます。
 
次の質問も確認して下さい。
 
次の質問も確認して下さい。
 +
</span>
  
 
==KDE の内部と外部どちらを開発したほうがいいでしょうか?==
 
==KDE の内部と外部どちらを開発したほうがいいでしょうか?==
Line 90: Line 114:
 
<blockquote>
 
<blockquote>
 
Being part of KDE means that you have to work together with others. Such cooperation brings along advantages but it also brings along responsibilities.
 
Being part of KDE means that you have to work together with others. Such cooperation brings along advantages but it also brings along responsibilities.
 +
<br /><br />
  
:Some of those advantages are: your code ends up on all distro's, people might fix your bugs, you get free translations and documentation, you get tons of bugreports.
+
Some of those advantages are: your code ends up on all distro's, people might fix your bugs, you get free translations and documentation, you get tons of bugreports.
 +
<br /><br />
  
 
On the other side there are disadvantages and responsibilities: you will have to communicate with other developers about your work, other people might make changes to your code, you will have to respect release freezes, you get tons of bugreports and people actually expect that you fix them as well (what are they smoking?), people expect you to maintain your code.
 
On the other side there are disadvantages and responsibilities: you will have to communicate with other developers about your work, other people might make changes to your code, you will have to respect release freezes, you get tons of bugreports and people actually expect that you fix them as well (what are they smoking?), people expect you to maintain your code.
 +
<br /><br />
  
 
You can't chose for the advantages and ignore the responsibilities that come with it, it's a complete package, it's both or nothing.
 
You can't chose for the advantages and ignore the responsibilities that come with it, it's a complete package, it's both or nothing.
 +
<br /><br />
  
 
In general it should be the author of a piece of software that chooses to put his application in KDE's repositories. We usually don't put software in KDE's repositories unless the author wishes to do so. The other way around, if the author prefers to work on his application elsewhere then that's his right as well. Unless there is a split in the actual group of people working on the application it makes no sense to fork the development of an application because of that.
 
In general it should be the author of a piece of software that chooses to put his application in KDE's repositories. We usually don't put software in KDE's repositories unless the author wishes to do so. The other way around, if the author prefers to work on his application elsewhere then that's his right as well. Unless there is a split in the actual group of people working on the application it makes no sense to fork the development of an application because of that.
 +
<br /><br />
  
 
'''BUT'''... by putting your code under and open source license and putting it in a KDE repository you give the world at large, as well as KDE in particular, the irrevocable right to use your code. And KDE will use that right at its discretion to protect the interests of KDE, even if that goes against the wishes of the author at that point in time.
 
'''BUT'''... by putting your code under and open source license and putting it in a KDE repository you give the world at large, as well as KDE in particular, the irrevocable right to use your code. And KDE will use that right at its discretion to protect the interests of KDE, even if that goes against the wishes of the author at that point in time.
Line 106: Line 135:
 
==KDE のリポジトリへのアクセスを得るにはどうすればよいでしょうか?==
 
==KDE のリポジトリへのアクセスを得るにはどうすればよいでしょうか?==
  
 +
<span class="mw-translate-fuzzy">
 
詳細については [[Special:myLanguage/Contribute/Get_a_Contributor_Account|貢献する > KDE のコントリビューターアカウントを取得する]] をご覧ください。
 
詳細については [[Special:myLanguage/Contribute/Get_a_Contributor_Account|貢献する > KDE のコントリビューターアカウントを取得する]] をご覧ください。
 +
</span>
  
 +
<span class="mw-translate-fuzzy">
 
[[http://identity.kde.org KDE Identity]] に進み、フォームを記入し、アクセス権限の必要な理由を記述してください。フルネームとメールアドレスを記述するのも忘れないで下さい。
 
[[http://identity.kde.org KDE Identity]] に進み、フォームを記入し、アクセス権限の必要な理由を記述してください。フルネームとメールアドレスを記述するのも忘れないで下さい。
 +
</span>
  
Please also include the name of your bugs.kde.org account, if non-existent please create one so that it can be given usual developer rights. Closing bugs.kde.org reports with keywords in commit comments only works if the email address of your KDE Identity and bugs.kde.org accounts match. You can change your bugs.kde.org address in the Bugzilla user settings.
+
Please also include the name of your [https://bugs.kde.org/ bugs.kde.org] account, if non-existent please create one so that it can be given usual developer rights. Closing bugs.kde.org reports with keywords in commit comments only works if the email address of your KDE Identity and bugs.kde.org accounts match. You can change your bugs.kde.org address in the Bugzilla user settings.
  
 
Git requires use of an ssh key, and new accounts for SVN must also choose the svn+ssh protocol. Send a public ssh key (e.g. {{path|~/.ssh/id_dsa.pub}})
 
Git requires use of an ssh key, and new accounts for SVN must also choose the svn+ssh protocol. Send a public ssh key (e.g. {{path|~/.ssh/id_dsa.pub}})
Line 118: Line 151:
 
If you are contributing to an application that is not yours, it is a good idea to first submitting your coding as patches to the author and let him apply them. If the author is not maintaining his application, you might become the new maintainer...
 
If you are contributing to an application that is not yours, it is a good idea to first submitting your coding as patches to the author and let him apply them. If the author is not maintaining his application, you might become the new maintainer...
  
Although there are few restrictions on repository commit rights, we expect you not to disrupt other developers' code without their consent. You must also respect the feature freezes of the release schedule (published on developer.kde.org)
+
Although there are few restrictions on repository commit rights, we expect you not to disrupt other developers' code without their consent. You must also respect the feature freezes of the release schedule (published on [[Schedules]] page)
  
 
A detailed list of rules you should follow when committing to KDE repositories are listed in the [[Special:myLanguage/Policies/SVN_Commit_Policy|KDE  Commit Policy]].
 
A detailed list of rules you should follow when committing to KDE repositories are listed in the [[Special:myLanguage/Policies/SVN_Commit_Policy|KDE  Commit Policy]].
Line 140: Line 173:
 
==stable な KDE と unstable な KDE をひとつのコンピュータに共存させることは可能ですか?==
 
==stable な KDE と unstable な KDE をひとつのコンピュータに共存させることは可能ですか?==
  
できます。Building 2 Versions document をチェックして下さい。  
+
<span class="mw-translate-fuzzy">
 +
できます。Building 2 Versions document をチェックして下さい。
 +
</span>
  
 
==使用している Qt/KDE のバージョンの調べ方を教えてください==
 
==使用している Qt/KDE のバージョンの調べ方を教えてください==
  
 +
<span class="mw-translate-fuzzy">
 
<tt>kde-config</tt> と全ての KDE プログラムは引数として --version を受け付けます。
 
<tt>kde-config</tt> と全ての KDE プログラムは引数として --version を受け付けます。
 +
</span>
  
 +
<span class="mw-translate-fuzzy">
 
==Qt-copy か qt.nokia.com の Qt、trunk のクリーンビルドを行うならば、どちらが良いでしょうか?==
 
==Qt-copy か qt.nokia.com の Qt、trunk のクリーンビルドを行うならば、どちらが良いでしょうか?==
 +
</span>
  
 
どちらでもかまいません。どちらも上位/下位両方でバイナリ互換です。しかし、qt-copy は最新の Qt へのバグフィックスを少し含むかもしれません。qt-copy からビルドする場合は、apply-patches スクリプトの実行を忘れないで下さい。
 
どちらでもかまいません。どちらも上位/下位両方でバイナリ互換です。しかし、qt-copy は最新の Qt へのバグフィックスを少し含むかもしれません。qt-copy からビルドする場合は、apply-patches スクリプトの実行を忘れないで下さい。

Latest revision as of 11:30, 30 May 2013

Other languages:Greek 14% • ‎English 100% • ‎Japanese 44% • ‎Dutch 55% • ‎Polish 27% • ‎Brazilian Portuguese 79% • ‎Turkish 8% • ‎Chinese (China) 54%

Contents

[edit] 新しいアプリケーションを書き始めたいのですが、何かアドバイスはありますか?

新たに書かなければいけない KDE アプリケーションがたくさんあるのは間違いありません。しかし、 あなたの助けを必要とする既存の KDE アプリケーションがたくさんあるのも確かです。

どの分野に助けが必要か知るには、このページをチェックしてください。

新しいアプリケーションを書き始める前に、KDE-Apps.org をチェックしたり、kde-devel@kde.org のメーリングリストで聞くなどして、誰かが似たようなプロジェクトをしていないかどうか確かるのは良いことです。

[edit] 私は開発者です。どうすれば KDE に貢献できますか?

KOffice や KDevelop は高く評価されているにもかかわらず、開発者がとても少ないので、そのあたりをチェックすると良いかも知れません。KDE のプロジェクトを手助けするのに、KDE のコアの開発者になる必要はありません。KDE は非常にうまくモジュール化されているので、全体のシステムがどうなっているか知らなくても、1つの分野を改良することができます。

また、kde-devel メーリングリストで、誰かがアプリケーション上での手助けを必要としているか質問することができます。 最新の KDE を使い必要とされていることを見付けて下さい。テーマジェネレーター? Konsole のスキーマエディタ? ゲームの改良? ちょっとした機能不足は常にあるものです。実装してしまいましょう!

特定の分野に関してくわしかったり、興味があったりしますか? あなたの手助けが役に立つその分野に関連するアプリケーションがないかチェックして下さい。もしくはそのようなアプリを書いて下さい。KDE には、もっと一般ユーザー向けのアプリケーションが必要です。

[edit] 私は開発者ではありません。どうすればお手伝いできますか?

開発者のスキルを必要としない仕事がたくさんあります。アプリケーションのレビューの執筆による KDE の宣伝 (kde-promo メーリングリストを参照)、ドキュメント作成 (i18n.kde.org/doc 参照)、翻訳 (i18n.kde.org 参照)、新規バグのフィルタリング (bugs.kde.org 参照) などです。

[edit] Konqui the dragon の画像はどこで手に入れることができますか?

The Konqi for some people SDK is at ftp.kde.org/pub/kde/devel/konqi_sdk.tar.bz2
It was posted to artist.kde.org before that site ceased to be updated.

Further images are on KDE merchandise. Also you can find some unofficial Konqi images and models from Create Konqi with Krita Contest and SuperTuxKart game.

[edit] KDE に貢献するのに必要なスキルのレベルはどの程度ですか? 何を学んでおくべきですか? 何を読んでおくべきですか?

C++ について知っている必要があります。Qt で何が可能か知るためにQt チュートリアルを読み、 Qt ドキュメントを拾い読みしてください。そして、KDE チュートリアルを読んで、アーキテクチャやドキュメントを斜め読みしてください。また KDE Book を読んでも良いかも知れません。損にはならないはずです。しかし、KDE の開発者になるのに、KDE 全体のアーキテクチャについて詳しくなる必要はありません。KDE のテクノロジーを利用することはとても簡単なので、本当にあなたが必要とするところだけに集中してください。他の部分については後で学べます。 KDE TechBasedoc.qt.nokia.com ($QTDIR/doc/html にもあります) は計り知れない程の情報源です。これらを利用してください。 その後、ソースを読んで、examples ディレクトリを探して、他人がそれらのアプリケーションをどのようにコーディングしているか見て下さい。コードを読み、書くことはいちばん良い学習方法です。

[edit] KDE の git や SVN のリポジトリーから KDE ソフトウェアを取得するにはどうすれば良いですか?

Getting_Started ページの "Building and Running KDE Software From Source" (ソースから KDE ソフトウェアをビルドして実行する) セクションを確認して下さい。

[edit] KDE のソースコードに Web ブラウザからアクセスすることは出来ますか?

はい。

などの方法があります。

[edit] .subversion/config にはどのように記述すべきでしょう?

[miscellany]
global-ignores = *.moc *.moc.cc *.moc.cpp config.log config.status \
config.cache *.gmo .deps .libs SunWS_cache *.lo *.la *.rpo *.la.closure \
*_la_closure.cpp *_la_closure.cc *_la_closure.cxx *.all_cc.cc *.all_cpp.cpp \
*.all_C.C *.all_cxx.cxx *_meta_unload.cc *_meta_unload.h *_meta_unload.cpp \
*_meta_unload.C *_meta_unload.cxx index.cache.bz2 .memdump Makefile.rules.in \
Makefile.calls.in Makefile.rules Makefile.calls autom4te.cache *.kidl \
*.o *.lo *.la #*# .*.rej *.rej *.pyc

それから、svn diff にスペースを無視させ、また、関数名を表示させるために、

[helpers]
diff-cmd = /usr/local/bin/_svndiff

と記述します。

And to make svn diff ignore whitespace, and print function names:

[helpers]
diff-cmd = /usr/local/bin/_svndiff

そして /usr/local/bin/_svndiff に、

#!/bin/sh
exec /usr/bin/diff -b -u -p "$@"

と付け加えます。

#!/bin/sh
exec /usr/bin/diff -b -u -p "$@"

/usr/local/bin/_svndiff に実行パーミッションを与えるのをお忘れなく。

[edit] 自分のアプリケーションを KDE に含めるにはどうすればよいでしょうか?

三つの必要条件があります。

  • KDE の (git master または SVN trunk上にある) 最新バージョンでコンパイルできること。
  • 安定していること
  • メンテナンスされること。あなたは多くのバグレポートや要望を受け取ることになるでしょう。バグの修正や、要望の実装が求められます。

次の質問も確認して下さい。

[edit] KDE の内部と外部どちらを開発したほうがいいでしょうか?

As core developer Waldo Bastian explains in a copyrighted mail:

Being part of KDE means that you have to work together with others. Such cooperation brings along advantages but it also brings along responsibilities.

Some of those advantages are: your code ends up on all distro's, people might fix your bugs, you get free translations and documentation, you get tons of bugreports.

On the other side there are disadvantages and responsibilities: you will have to communicate with other developers about your work, other people might make changes to your code, you will have to respect release freezes, you get tons of bugreports and people actually expect that you fix them as well (what are they smoking?), people expect you to maintain your code.

You can't chose for the advantages and ignore the responsibilities that come with it, it's a complete package, it's both or nothing.

In general it should be the author of a piece of software that chooses to put his application in KDE's repositories. We usually don't put software in KDE's repositories unless the author wishes to do so. The other way around, if the author prefers to work on his application elsewhere then that's his right as well. Unless there is a split in the actual group of people working on the application it makes no sense to fork the development of an application because of that.

BUT... by putting your code under and open source license and putting it in a KDE repository you give the world at large, as well as KDE in particular, the irrevocable right to use your code. And KDE will use that right at its discretion to protect the interests of KDE, even if that goes against the wishes of the author at that point in time.

It is important to know that but don't be afraid. Usually, things work very well. In 5 years, it has only happened once that a developer had his work put kept in KDE while he wanted to remove it.

[edit] KDE のリポジトリへのアクセスを得るにはどうすればよいでしょうか?

詳細については 貢献する > KDE のコントリビューターアカウントを取得する をご覧ください。

[KDE Identity] に進み、フォームを記入し、アクセス権限の必要な理由を記述してください。フルネームとメールアドレスを記述するのも忘れないで下さい。

Please also include the name of your bugs.kde.org account, if non-existent please create one so that it can be given usual developer rights. Closing bugs.kde.org reports with keywords in commit comments only works if the email address of your KDE Identity and bugs.kde.org accounts match. You can change your bugs.kde.org address in the Bugzilla user settings.

Git requires use of an ssh key, and new accounts for SVN must also choose the svn+ssh protocol. Send a public ssh key (e.g. ~/.ssh/id_dsa.pub)

See also #How do I create a SSH key?

If you are contributing to an application that is not yours, it is a good idea to first submitting your coding as patches to the author and let him apply them. If the author is not maintaining his application, you might become the new maintainer...

Although there are few restrictions on repository commit rights, we expect you not to disrupt other developers' code without their consent. You must also respect the feature freezes of the release schedule (published on Schedules page)

A detailed list of rules you should follow when committing to KDE repositories are listed in the KDE Commit Policy.

[edit] 私の作ったアプリケーションは stable ではありません。それでも KDE に含めることはできますか?

最初のステップとして、原則的に "kde-alpha" として扱われる、playground に置くことができます。そこで開発を進め、準備ができたら適切な KDE パッケージ、もしくは extragear モジュールに含めるよう、依頼を出して下さい。

[edit] SVN の履歴を失いたくないのですが、どうしたらいいでしょうか?

これは現在不可能です。将来サーバーがアップグレードされ、それが可能になる可能性はあります。git については、問題なく保持することができます。

[edit] kdebindings とは何でしょうか?

Qt のクラスを Ruby、PHP、C# から使ったり、KDE のクラスを Ruby、C#、python から使うためのバインディング、非 KDE アプリを KPart として扱うための XParts が含まれています。バインディングのページ を確認してください。

[edit] playground で機能の凍結 (feature freeze) は行われるのでしょうか?

いいえ、 playground はリリースされないパッケージ群です。kdereview と extragearについても同じで、凍結されたりリリースされたりすることはありません。しかし、あなたのアプリケーションをパッケージに移動させたい場合は、ベータリリースより前に依頼することで、含めることができます。

[edit] stable な KDE と unstable な KDE をひとつのコンピュータに共存させることは可能ですか?

できます。Building 2 Versions document をチェックして下さい。

[edit] 使用している Qt/KDE のバージョンの調べ方を教えてください

kde-config と全ての KDE プログラムは引数として --version を受け付けます。

[edit] Qt-copy か qt.nokia.com の Qt、trunk のクリーンビルドを行うならば、どちらが良いでしょうか?

どちらでもかまいません。どちらも上位/下位両方でバイナリ互換です。しかし、qt-copy は最新の Qt へのバグフィックスを少し含むかもしれません。qt-copy からビルドする場合は、apply-patches スクリプトの実行を忘れないで下さい。

[edit] How can I checkout a single directory from a SVN module?

Checkout the top-level dir with 'svn co -N /modulename', 'cd modulename', 'svn up admin' to get the admin/ dir and then finally checkout the dir you want with 'svn up subdir'

For instance, to get only reaktivate from playground/utils: svn co -N /playground/utils; svn up reaktivate Then compile as usual.

The same answer applies to the question "How do I get a single language out of kde-i18n?".

If you don't know the name of the directory you want to check out, you can browse websvn.kde.org to find it.

[edit] KDE のアプリケーションのひとつをスタンドアローンの tar ball にするにはどうしたら良いですか?

kdesdk/scripts/svn2dist が KDE のソースツリーからアプリケーションを抽出し、スタンドアローンなアプリケーションとしてパッケージ化するスクリプトです。

[edit] 自分が出したバグレポートをクローズするにはどうすればよいですか?

If you reported a bug that is fixed in a new release of KDE but is still reported as open, you can close it. It might happen because your bug is the same as another one, or simply because the developer fixed something without noticing that it would correct your bug.

You can do that from your Subversion commit. To do so, append to your commit message a line like this:

BUG: XXXXX where XXXXX is the bug report you want to close. If the report you're closing is adding a new feature, you can use FEATURE instead of BUG.

Managing a bug list is a huge task for the developers and they usually have a lot of bugs listed, some being fixed already without their knowledge, some being unreproducible, some without enough information to be corrected, etc. If you can help by managing and updating the list of outstanding bugs, you will be gladly welcome. And you will receive an even happier welcome if you provide a patch.

[edit] How do I create a SSH key?

SSH makes use of two keys: a private key and a public key. You should keep the private key secret at all times and only place it on machines over which you have direct control. Public, shared, and community machines are not suitable environments to store SSH private keys. Take action to help prevent theft of your SSH private key data. Setting a password on your SSH private key will help reduce the risks involved with private key theft.

Generate a key pair for each major location you work from. This helps to reduce the impact when your key gets stolen. When someone obtains access to your private key, your key can be abused in attempts to compromise KDE servers. Well known open source projects have been compromised this way in the past, YOU must help us to make sure that this doesn't happen with KDE servers as well. For that reason it is important to notify sysadmin (at) kde (dot) org immediately when you notice that someone may have had access to your private key for example when a computer on which it was stored has been hacked or infected with a virus, worm or trojan.

If you choose to make a backup of your SSH private key data, please ensure that any such backup is stored in a secure manner as well.

For the practical part, the following command can be used to generate a SSH private/public key pair with ssh-keygen -t dsa This will create a private key as ~/.ssh/id_dsa and a public key as ~/.ssh/id_dsa.pub.

There are times when you may want to use a key of a different name to the default, perhaps to use separate keys for different projects. To let SSH know which key you want to use for KDE.org, you can keep a list of servers and their corresponding keys in ~/.ssh/config. For example,

Host svn.kde.org 
IdentityFile ~/.ssh/id_dsa_kde

In order to use SSH to access KDE servers you need to send your public key to sysadmin (at) kde (dot) org.

[edit] How can I monitor changes made by others?

The kde-commits mailinglist carries automatic notifications for all changes made in the KDE repositories. The KDE-Commits mailinglist is very high traffic. An alternative is CommitFilter which allows you to get notification for only those areas that interest you.


This page was last modified on 30 May 2013, at 11:30. This page has been accessed 3,207 times. Content is available under Creative Commons License SA 3.0 as well as the GNU Free Documentation License 1.2.
KDE® and the K Desktop Environment® logo are registered trademarks of KDE e.V.Legal