From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id C5D78138350 for ; Sun, 19 Jan 2020 10:52:16 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D258FE08F9; Sun, 19 Jan 2020 10:52:15 +0000 (UTC) Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 933F7E08F9 for ; Sun, 19 Jan 2020 10:52:15 +0000 (UTC) Received: from oystercatcher.gentoo.org (unknown [IPv6:2a01:4f8:202:4333:225:90ff:fed9:fc84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id DB35934E26C for ; Sun, 19 Jan 2020 10:52:13 +0000 (UTC) Received: from localhost.localdomain (localhost [IPv6:::1]) by oystercatcher.gentoo.org (Postfix) with ESMTP id C8BF5D7 for ; Sun, 19 Jan 2020 10:52:11 +0000 (UTC) From: "Michał Górny" To: gentoo-commits@lists.gentoo.org Content-Transfer-Encoding: 8bit Content-type: text/plain; charset=UTF-8 Reply-To: gentoo-dev@lists.gentoo.org, "Michał Górny" Message-ID: <1579431093.e8c1bf40fb65daf1e90112a21296cb61e06b1fbb.mgorny@gentoo> Subject: [gentoo-commits] proj/policy-guide:master commit in: / X-VCS-Repository: proj/policy-guide X-VCS-Files: keywords.rst X-VCS-Directories: / X-VCS-Committer: mgorny X-VCS-Committer-Name: Michał Górny X-VCS-Revision: e8c1bf40fb65daf1e90112a21296cb61e06b1fbb X-VCS-Branch: master Date: Sun, 19 Jan 2020 10:52:11 +0000 (UTC) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-commits@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply X-Archives-Salt: 41516b3b-2405-4d51-89e8-310e277c55d1 X-Archives-Hash: 66f341599d32d31afb53370a245637dc commit: e8c1bf40fb65daf1e90112a21296cb61e06b1fbb Author: Michał Górny gentoo org> AuthorDate: Sun Jan 12 07:17:58 2020 +0000 Commit: Michał Górny gentoo org> CommitDate: Sun Jan 19 10:51:33 2020 +0000 URL: https://gitweb.gentoo.org/proj/policy-guide.git/commit/?id=e8c1bf40 Rekeywording & stabilization rules Closes: https://bugs.gentoo.org/705474 Closes: https://github.com/gentoo/policy-guide/pull/2 Signed-off-by: Michał Górny gentoo.org> keywords.rst | 45 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) diff --git a/keywords.rst b/keywords.rst index 5dcbc77..272dca4 100644 --- a/keywords.rst +++ b/keywords.rst @@ -1,6 +1,51 @@ Keywording and stabilization ============================ +.. index:: keywords; rekeywording + +Rekeywording on dropped keywords +-------------------------------- +:Source: QA +:Reported: by pkgcheck and repoman + +The developer removing keywords from a package (e.g. due to new +dependencies) must file a rekeywording bug asking for the package being +retested. This rule can be exempted if the package is known not to work +(anymore) on the arch in question. + +*Rationale*: rekeywording on minor architectures often takes a long +time. If a developer neglects to request it immediately, it negatively +affects other developers who in the future either want to stabilize +a new version or to remove an old version. + + +.. index:: keywords; stabilizing new versions + +Stabilizing new versions +------------------------ +:Source: QA +:Reported: by pkgcheck + +Whenever requesting a stabilization of a new version of the package, +the developer must CC *all* arches that had at least one previous stable +version of the package in question, and that still have ~arch keywords +in the stabilized version. This applies to experimental architectures +as well. + +The stabilization request can be closed and old stable version removed +once all non-experimental architectures have processed the stabilization +request. However, the remaining arch teams should be kept CC-ed in case +they wanted to process the bug. + +*Rationale*: there were some cases of developers requesting +stabilization only of a subset of architectures they were personally +interested in. This meant some other developer had to independently +request stabilization on remaining architectures which only meant +a duplication of effort and unnecessary confusion over which version +is stable and whether arch teams are slacking or stabilization was not +requested on remaining architectures in the first place. + + .. index:: keywords; removing stable Removing stable keywords