[gentoo-commits] proj/kde:master commit in: Documentation/

[Johannes Huber]

commit:     22cf7cc8746dd18f455a93e3292e7b16af5b8180
Author:     Johannes Huber <johu <AT> gentoo <DOT> org>
AuthorDate: Thu Aug 30 10:51:23 2012 +0000
Commit:     Johannes Huber <johu <AT> gentoo <DOT> org>
CommitDate: Thu Aug 30 10:51:23 2012 +0000
URL:        http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=commit;h=22cf7cc8

[Documentation] CODE moved to the wiki, removed duplicated content.

---
 Documentation/CODE |  171 +---------------------------------------------------
 1 files changed, 2 insertions(+), 169 deletions(-)

diff --git a/Documentation/CODE b/Documentation/CODE
index 2500461..112b5f7 100644
--- a/Documentation/CODE
+++ b/Documentation/CODE
@@ -1,174 +1,7 @@
 WHAT RULES I SHOULD FOLLOW WHEN I WANT TO WORK ON SOMETHING FOR KDE TEAM?
-If you asked this question you are reading the right file.
-
-KDE4 policies:
-
- - NEVER EVER COMMIT NEW REVBUMPS NOR MAJOR CHANGES TO TREE DIRECTLY - ALWAYS USE overlay
-   first so that more pairs of eyes can spot issues. Especially anything in kde-base.
-
- - append valid metadata.xml - not necessarily with <herd>kde</herd> if you're proxy
-   maintaining some ebuild. Never append ChangeLog because file/folder history is determined by commit log.
-
- - NEVER EVER commit anything that can break metadata cache. Check every commit at least with repoman -v -d full!
-
- - always separate DEPEND and RDEPEND properly (adding COMMON_DEPEND if needed)
-
- - always use kde4-* eclasses. kde4-base for applications with main CMakeLists.txt in toplevel
-   source directory, kde4-meta for applications hidden deeper in source code directory structure
-   and requiring common CMakeLists.txt from toplevel directory.
-   See also KMEXTRA, KMEXTRACTONLY, KMCOMPILEONLY eclass variables.
-   NEVER FORGET TO INVOKE kde4-{base,meta}_${phase_function} when overriding ebuild phase!
-
- - always report CMake issues about everything directly to upstream and backport their fix.
-
- - never use -j1 in ebuilds. Always report the issue upstream and wait for the resolution or fix yourself
-
- - double check handbook support in your package. For kde4-meta style ebuilds - look for doc/${PN}
-   or similar directory. Sometimes application handbooks are not trivial to assign (for example
-   kde-base/khelpcenter ebuild), in such case ask Gentoo KDE team/HT members or contact upstream.
-   To enable handbook support, set KDE_HANDBOOK=1 before inheriting kde eclasses.
-
- - think about adding debug USE flag to your package. Do not add debug USE flag for artwork-only and
-   python-only KDE packages. And don't forget to write metadata.xml entries for new local USE flags.
-
- - do not enable USE flags by default (IUSE="+useflag") with no *good* reason. "Because I use it" is
-   not enough. If uncertain - discuss it with the rest of the team. USE flags that are considered as
-   commonly used, known to work and not pulling any dependencies, can be enabled by default right away.
-
- - always check for linguas and add them to the KDE_LINGUAS variable.
-
- - always fix automagic packages with macro_optional_ prefixing and report it upstream with patch.
-
- - check your apps deps with dynlink-scanner in Documentation/maintainers folder. Be aware, that this tool does not
-   return complete runtime dependency chain, still it will find most automagic linking dependencies.
-
- - if you want our herd in the application and you are not Gentoo KDE team/HT member - ask us first.
-
- - all kde4 and kde-live misc applications should be in SLOT="4". Feel free to fix packages that don't
-   follow this, and always add the correct blockers (be carefull not to block kde3 packages)
-
- - if you revbump some snapshots of yet-not-released packages (like phonon, soprano, eigen etc), always ensure
-   it's visible *only* for those users that really need it and not for every ~arch users. For KDE dependencies,
-   there are kdedeps-${SLOT} sets created for this purpose. regenerate-files tool will mask those ebuilds
-   for everyone except those using kde-${SLOT} umask file helper, so those dependencies will be available
-   only for them.
-
- - use the add_blocker function to add blocks. This ensures that the blocks are only added to RDEPEND.
-
-Examples:
-
-   # Block all versions of kdelibs <=4.1.80
-   add_blocker kdelibs 4.1.80
-
-   # Block all versions of kdelibs <4.2.0
-   add_blocker kdelibs '<4.2.0'
-
-   # Block all versions of kde-menu (replaced by kdebase-menu)
-   add_blocker kde-menu
-
-   # Block all versions of kdelibs in KDE 4.1 or prior
-   add_blocker kdelibs 4.1.50
-
-   For more details, read the comments in kde4-functions.eclass
-
- - comment any new blockers you add
-
-
-Commiting:
-
- - always run repoman full on ebuild subtree you're working on before commiting *anything*
-
- - try to keep one commit per change if possible. If more appropriate - one commit per feature.
-
- - all commit messages must look like this:
-
-   [<category/pn>] <detailed message describing what you did>
-   Also append package version, when needed.
-
-Examples:
-
-   [kde-base/kdelibs-4.2.3] Synced with tree: fixed bug #333452, removed unnecessary solid patch, added debug to IUSE.
-
-   [kde-base/kdelibs-4.2.3] Moved to tree.
-
- - when you commit something related to existing bugzilla bug, add inOverlay to keywords to that bug,
-   so that developers know about it. Also add [overlay-name] to bug summary.
-
- - if you refactor ebuild names in kde-base, *always* synchronize those changes in following locations
-   if applicable:
-
-   * sets/
-
-   * Documentation/package.keywords/
-
-   * Documentation/package.unmask/
-
-   Remember to do not edit autogenerated files, as your changes will be lost in next
-   regenerate-files tool run.
-
-QA:
-
-   - keep ebuilds clean, look at recommended ebuild formatting rules below (obligatory for kde-base).
-     Use existing ebuilds (like kdelibs) for reference.
-
-   * sort dependencies alphabetically - it makes it easier to manage them later
-
-	>=app-misc/strigi-0.6.3[dbus,qt4]
-	dev-libs/libpcre
-	dev-libs/libxml2
-
-   * try to separate KEYWORDS and IUSE with some usually invariant variable (like LICENSE) - it makes
-     it easier to merge changes between live and tagged ebuilds using GUI diff/merge tools.
-     Always *avoid* merging/synchronizing ebuilds manually if possible - it's error prone.
-     Use kompare <srcfile> <destfile> for it.
-
-KEYWORDS="~amd64 ~x86"
-LICENSE="LGPL-2.1"
-IUSE="3dnow acl alsa altivec bindist +bzip2 debug doc fam jpeg2k kerberos
-mmx nls openexr +semantic-desktop spell sse sse2 ssl zeroconf"
-
-   * put blocks at the begin of RDEPEND section, !useflag? ( ) preferably before useflag? ( ) -
-     - it's easier to spot them when they're in expected location
-
-RDEPEND="${DEPEND}
-	!kdeprefix? ( !dev-libs/libconvert )
-"
-
-   * put optional dependencies after obligatory ones - again - improves readability
-
-	x11-proto/renderproto
-	xinerama? ( x11-proto/xineramaproto )
-
-   * avoid single line expressions - they are utterly unreadable
-
-	ssl? ( dev-libs/openssl )
-	zeroconf? (
-		|| (
-			net-dns/avahi[mdnsresponder-compat]
-			!bindist? ( net-misc/mDNSResponder )
-		)
-	)
-
-   * always indent dependencies with <tab> characters from new line (including other variable like
-     ${COMMONDEPEND} may be exception here) and always break line *after* dependency - it makes it easier to
-     synchronize such deps semi-automatically between ebuilds using GUI diff/merge tools (less conflicts).
-     The same applies to PATCHES as well.
-
-COMMONDEPEND="
-	>=app-misc/strigi-0.6.3[dbus,qt4]
-"
-# sth? ( dev/foo ) - re-add when in tree
-DEPEND="${COMMONDEPEND}
-	doc? ( app-doc/doxygen )
-	nls? ( virtual/libintl )
-"
-
-PATCHES=(
-	"${FILESDIR}/dist/09_disable_debug_messages_if_not_explicitly_enabled.patch"
-	"${FILESDIR}/dist/20_use_dejavu_as_default_font.patch"
-	"${FILESDIR}/dist/23_solid_no_double_build.patch"
-)
+If you asked this question, you want to read:
 
+http://wiki.gentoo.org/wiki/Project:KDE/Coding_style 
 
 # NOT FOLLOWING THESE RULES WILL BE PUNISHED!
 # No cookies for week!