From: "Johannes Huber" <johu@gentoo.org>
To: gentoo-commits@lists.gentoo.org
Subject: [gentoo-commits] proj/kde:master commit in: Documentation/
Date: Thu, 30 Aug 2012 10:52:49 +0000 (UTC) [thread overview]
Message-ID: <1346323883.22cf7cc8746dd18f455a93e3292e7b16af5b8180.johu@gentoo> (raw)
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!
next reply other threads:[~2012-08-30 10:53 UTC|newest]
Thread overview: 132+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-30 10:52 Johannes Huber [this message]
-- strict thread matches above, loose matches on Subject: below --
2024-11-12 18:33 [gentoo-commits] proj/kde:master commit in: Documentation/ Nowa Ammerlaan
2024-04-20 15:06 Andreas Sturmlechner
2024-03-02 10:35 Andreas Sturmlechner
2024-02-01 21:19 Andreas Sturmlechner
2023-12-18 11:24 Andreas Sturmlechner
2023-12-16 22:02 Andreas Sturmlechner
2023-12-12 20:03 Andreas Sturmlechner
2023-11-11 20:35 Andreas Sturmlechner
2023-09-16 16:53 Andreas Sturmlechner
2023-08-21 19:49 Andreas Sturmlechner
2023-05-27 10:40 Andreas Sturmlechner
2023-03-23 19:33 Andreas Sturmlechner
2023-03-04 12:56 Andreas Sturmlechner
2022-12-10 11:50 Andreas Sturmlechner
2022-09-17 14:09 Andreas Sturmlechner
2022-09-14 14:13 Andreas Sturmlechner
2022-07-16 15:30 Andreas Sturmlechner
2021-11-03 10:51 Andreas Sturmlechner
2021-09-14 14:24 Andreas Sturmlechner
2021-07-22 20:20 Andreas Sturmlechner
2021-06-30 6:07 Andreas Sturmlechner
2021-05-14 19:45 Andreas Sturmlechner
2021-05-05 8:37 Andreas Sturmlechner
2021-04-24 8:08 Andreas Sturmlechner
2021-02-24 22:38 Andreas Sturmlechner
2021-01-13 23:24 Andreas Sturmlechner
2020-11-30 22:27 Andreas Sturmlechner
2020-11-23 23:40 Andreas Sturmlechner
2020-09-03 12:52 Andreas Sturmlechner
2020-05-20 19:28 Andreas Sturmlechner
2020-05-14 17:25 Andreas Sturmlechner
2020-04-29 16:10 Andreas Sturmlechner
2020-03-01 12:33 Andreas Sturmlechner
2020-02-19 13:35 Andreas Sturmlechner
2020-01-26 10:39 Andreas Sturmlechner
2019-11-03 18:35 Andreas Sturmlechner
2019-11-02 9:58 Andreas Sturmlechner
2019-09-08 8:31 Andreas Sturmlechner
2019-02-28 13:19 Andreas Sturmlechner
2018-11-10 18:50 Andreas Sturmlechner
2018-09-13 18:17 Andreas Sturmlechner
2018-05-18 10:18 Andreas Sturmlechner
2018-04-12 18:41 Andreas Sturmlechner
2018-03-29 22:39 Andreas Sturmlechner
2018-03-23 18:52 Andreas Sturmlechner
2018-03-03 14:29 Andreas Sturmlechner
2018-02-06 10:15 Andreas Sturmlechner
2018-01-31 19:37 Andreas Sturmlechner
2017-12-31 21:23 Andreas Sturmlechner
2017-10-07 22:19 Andreas Sturmlechner
2017-08-02 23:59 Andreas Sturmlechner
2017-07-12 19:45 Andreas Sturmlechner
2017-05-17 20:58 Andreas Sturmlechner
2017-03-18 20:08 Johannes Huber
2017-02-25 20:02 Johannes Huber
2017-02-12 20:08 Johannes Huber
2017-02-05 13:50 Andreas Sturmlechner
2017-02-05 6:58 Johannes Huber
2017-01-25 20:08 Johannes Huber
2017-01-06 14:21 Johannes Huber
2017-01-01 20:14 Johannes Huber
2016-10-14 8:28 Johannes Huber
2016-07-25 15:32 Michael Palimaka
2016-06-02 14:11 Johannes Huber
2016-05-26 8:17 Johannes Huber
2016-05-17 7:06 Johannes Huber
2016-05-05 10:28 Johannes Huber
2016-04-16 17:23 Johannes Huber
2016-04-14 20:19 Johannes Huber
2016-04-07 19:30 Johannes Huber
2016-04-04 17:46 Johannes Huber
2016-04-04 17:43 Johannes Huber
2016-03-31 18:16 Johannes Huber
2016-03-26 10:43 Johannes Huber
2016-03-02 17:37 Johannes Huber
2016-02-14 15:28 Michael Palimaka
2016-02-09 10:55 Michael Palimaka
2015-12-10 6:41 Michael Palimaka
2015-12-06 9:49 Michael Palimaka
2015-11-19 16:23 Michael Palimaka
2015-11-13 16:30 Michael Palimaka
2015-10-27 16:03 Michael Palimaka
2015-10-15 16:32 Michael Palimaka
2015-10-10 12:26 Michael Palimaka
2015-06-11 16:48 Johannes Huber
2015-06-05 17:46 Michael Palimaka
2015-05-29 20:07 Johannes Huber
2015-04-28 13:00 Michael Palimaka
2015-04-08 19:28 Johannes Huber
2015-03-28 22:05 Johannes Huber
2015-01-28 21:59 Johannes Huber
2015-01-09 16:31 Manuel Rüger
2015-01-04 10:12 Johannes Huber
2014-10-10 16:09 Michael Palimaka
2014-09-14 10:46 Johannes Huber
2014-08-24 8:46 Michael Palimaka
2014-08-14 15:29 Johannes Huber
2014-08-09 19:57 Johannes Huber
2014-08-06 15:47 Johannes Huber
2014-07-15 17:51 Johannes Huber
2014-05-25 14:41 Johannes Huber
2014-04-28 14:38 Michael Palimaka
2014-04-28 14:01 Michael Palimaka
2011-08-01 11:14 Theo Chatzimichos
2011-06-28 19:10 Andreas Hüttel
2011-04-27 20:05 Andreas K. Huettel
2011-04-27 20:05 Andreas K. Huettel
2011-04-27 17:30 Andreas K. Huettel
2011-04-27 16:01 Andreas K. Huettel
2011-04-25 19:19 Andreas K. Huettel
2011-04-24 12:54 Andreas K. Huettel
2011-04-23 20:38 Andreas K. Huettel
2011-04-23 20:38 Andreas K. Huettel
2011-04-23 18:01 Christian Schmitt
2011-04-23 16:43 Andreas K. Huettel
2011-04-22 23:13 Andreas K. Huettel
2011-04-22 22:08 Andreas K. Huettel
2011-04-22 20:18 Andreas K. Huettel
2011-04-22 18:33 Andreas K. Huettel
2011-04-19 22:20 Andreas K. Huettel
2011-04-19 21:53 Andreas K. Huettel
2011-04-18 11:20 Andreas K. Huettel
2011-04-17 22:45 Andreas K. Huettel
2011-04-17 20:30 Theo Chatzimichos
2011-04-10 22:50 Alexey Shvetsov
2011-03-12 17:45 Jonathan Callen
2011-02-27 9:45 Andreas K. Huettel
2011-02-11 9:39 Dennis Schridde
2011-02-11 9:34 Dennis Schridde
2011-02-09 14:29 Steffen Stramm
2011-02-07 23:22 Manuel Nickschas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1346323883.22cf7cc8746dd18f455a93e3292e7b16af5b8180.johu@gentoo \
--to=johu@gentoo.org \
--cc=gentoo-commits@lists.gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox