diff options
Diffstat (limited to 'Documentation/CODE')
| -rw-r--r-- | Documentation/CODE | 171 |
1 files changed, 2 insertions, 169 deletions
diff --git a/Documentation/CODE b/Documentation/CODE index 250046153d7..112b5f79ac5 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! |