From unknown Sat Jun 21 03:09:13 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#72840 <72840@debbugs.gnu.org> To: bug#72840 <72840@debbugs.gnu.org> Subject: Status: [PATCH RFC] DRAFT doc: Add =?UTF-8?Q?=E2=80=9CDeprecation_?= =?UTF-8?Q?Policy=E2=80=9D?= section. Reply-To: bug#72840 <72840@debbugs.gnu.org> Date: Sat, 21 Jun 2025 10:09:13 +0000 retitle 72840 [PATCH RFC] DRAFT doc: Add =E2=80=9CDeprecation Policy=E2=80= =9D section. reassign 72840 guix-patches submitter 72840 Ludovic Court=C3=A8s severity 72840 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 27 15:31:55 2024 Received: (at submit) by debbugs.gnu.org; 27 Aug 2024 19:31:55 +0000 Received: from localhost ([127.0.0.1]:47616 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sj1v0-0006dQ-RN for submit@debbugs.gnu.org; Tue, 27 Aug 2024 15:31:55 -0400 Received: from lists.gnu.org ([209.51.188.17]:58456) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sj1ux-0006dG-IK for submit@debbugs.gnu.org; Tue, 27 Aug 2024 15:31:53 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sj1u6-0006kn-34 for guix-patches@gnu.org; Tue, 27 Aug 2024 15:30:58 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sj1u1-0003aY-Sr; Tue, 27 Aug 2024 15:30:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:Subject:To:From:in-reply-to: references; bh=O5/FG3x20uxwMrYiSYdQb/POiFZXq+vkLRhOuzuuP6A=; b=QgtdtnhLOHSDYU vFHrcjPk1gjRVhyWHWVUaTSCNJgs8gEw3cwAxt3Xen/cTKYru/D8sMfedAzb1rsMke9x3/Eh0LwcH AvfIORj2EBsxBxGuDw0/T0gTfdp9gUYcD4QY3KHfTTVF6DnqOOMteLeYGKNmgHMR3kSe/x16ipJLO wEjlv2jb+D+mfGudF+uJVjlYgRXKtFm4+3LRfYdDyHrOkjRpVMx+/RSZqcLv6F0JpHILk/bivXjpI QUso7+kYSzo4wd1E2wfbTxg+VLrYshLJ9t2CI33RDUsHnm6xsGdw/f8bRHO+S08o0Ad8vKEcKGJ8d zKuj5i7g/lB+THEBU5xA==; From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= To: guix-patches@gnu.org Subject: [PATCH RFC] =?UTF-8?q?DRAFT=20doc:=20Add=20=E2=80=9CDeprecation?= =?UTF-8?q?=20Policy=E2=80=9D=20section.?= Date: Tue, 27 Aug 2024 21:30:35 +0200 Message-ID: <80f8b603ecd73cb9f46b1ea43797e143f16d2f17.1724785788.git.ludo@gnu.org> X-Mailer: git-send-email 2.45.2 X-Debbugs-Cc: guix-devel@gnu.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Debbugs-Cc: Florian Pelz , Ludovic Courtès , Matthew Trzcinski , Maxim Cournoyer Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: submit Cc: =?UTF-8?q?Ludovic=20Court=C3=A8s?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) DRAFT: This is a starting point submitted for discussion. * doc/contributing.texi (Deprecation Policy): New node. Change-Id: I5d095559920a3d9b791b5d919aab4e2f2a0c2dee --- doc/contributing.texi | 176 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 176 insertions(+) Hello! As promised long ago, here is an attempt to formalize a deprecation policy, based on current unwritten practice. Let’s discuss it with the goal of checking in an initial revision by next month. Thanks, Ludo’. diff --git a/doc/contributing.texi b/doc/contributing.texi index 73f7addbef..3c386f6510 100644 --- a/doc/contributing.texi +++ b/doc/contributing.texi @@ -34,6 +34,7 @@ Contributing * Commit Access:: Pushing to the official repository. * Reviewing the Work of Others:: Some guidelines for sharing reviews. * Updating the Guix Package:: Updating the Guix package definition. +* Deprecation Policy:: Commitments and tools for deprecation. * Writing Documentation:: Improving documentation in GNU Guix. * Translating Guix:: Make Guix speak your native language. @end menu @@ -3030,6 +3031,181 @@ Updating the Guix Package this variable is set, the updated package source is also added to the store. This is used as part of the release process of Guix. +@node Deprecation Policy +@section Deprecation Policy + +@cindex deprecation policy +As any lively project with a broad scope, Guix changes all the time and +all levels. Because it's user-extensible and programmable, incompatible +changes can directly impact users and make their life harder. It is +thus important to reduce user-visible incompatible changes to a minimum +and, when such changes are deemed necessary, to clearly communicate them +through a @dfn{deprecation period} so everyone can adapt with minimum +hassle. This section defines the project's commitments for smooth +deprecation and describes procedures and mechanisms to honor them. + +There are several ways to use Guix; how to handle deprecation will +depend on each use case. Those can be roughly categorized like this: + +@itemize +@item +package management exclusively through the command line; + +@item +advanced package management using the manifest and package interfaces; + +@item +Home and System management, using the @code{operating-system} and/or +@code{home-environment} interfaces together with the service interfaces; + +@item +development of external tools that use programming interfaces such as +the @code{(guix ...)} modules. +@end itemize + +These use cases form a spectrum with varying degrees of coupling---from +``distant'' to tightly coupled. Based on this insight, we define the +following @dfn{deprecation policies} that we consider suitable for each +of these levels. + +@table @asis +@item Command-line tools +Guix sub-commands should be thought of as remaining available +``forever''. Once a Guix sub-command is to be removed, it should be +deprecated first, and then remain available for at least one year after +the first release that deprecated it. + +Deprecation should first be announced in the manual and as an entry in +@file{etc/news.scm}; additional communication such as a blog post +explaining the rationale is welcome. Months before the scheduled +removal date, the command should print a warning explaining how to +migrate. An example of this is the replacement of @command{guix +environment} by @command{guix shell}, started in October +2021@footnote{For more details on the @command{guix shell} transition, +see +@uref{https://guix.gnu.org/en/blog/2021/from-guix-environment-to-guix-shell/}.}. + +Because of the broad impact of such a change, we recommend conducting a +user survey before enacting a plan. + +@cindex package deprecation +@item Package name changes +When a package name changes, it must remain available under its old name +for at least one year. For example, @code{go-ipfs} was renamed to +@code{kubo} following a decision made upstream; to communicate the name +change to users, the package module provided this definition: + +@findex deprecated-package +@lisp +(define-public go-ipfs + (deprecated-package "go-ipfs" kubo)) +@end lisp + +That way, someone running @command{guix install go-ipfs} or similar sees +a deprecation warning mentioning the new name. + +@item Package removal +Packages that their upstream developers have declared as having reach +``end of life'' or being unmaintained may be removed. There is no +formal deprecation mechanism for this case, unless a replacement exists, +in which case the @code{deprecated-package} procedure mentioned above +can be used. + +If the package being removed is a ``leaf'' (no other packages depend on +it), it may be removed after a one-month review period of the patch +removing it. + +If it has many dependent packages---as is the case for example with +Python version@tie{}2---the relevant team must propose a deprecation +removal agenda and seek consensus with other packagers for at least one +month. It may also invite feedback from the broader user community, for +example through a survey. Removal of all impacted packages may be +gradual, spanning multiple months, to accommodate all use cases. + +When the package being removed is considered popular, whether or not it +is a leaf, its deprecation must be announced as an entry in +@code{etc/news.scm}. + +@cindex service deprecation +@item Services +Changes to services for Guix Home and Guix System have a direct impact +on user configuration. For a user, adjusting to interface changes is +rarely rewarding, which is why any such change must be clearly +communicated in advance through deprecation warnings and documentation. + +Renaming of variables related to service, home, or system configuration +must be communicated for at least six months before removal using the +@code{(guix deprecation)} mechanisms. For example, renaming of +@code{murmur-configuration} to @code{mumble-server-configuration} was +communicated through a series of definitions like this one: + +@findex define-deprecated/public-alias +@lisp +(define-deprecated/public-alias + murmur-configuration + mumble-server-configuration) +@end lisp + +Procedures slated for removal may be defined like this: + +@findex define-deprecated +@lisp +(define-deprecated (elogind-service #:key (config (elogind-configuration))) + elogind-service-type + (service elogind-service-type config)) +@end lisp + +Record fields, notably fields of service configuration records, must +follow a similar deprecation period. This is usually achieved through +@i{ad hoc} means though. For example, the @code{hosts-file} field of +@code{operating-system} was deprecated by adding a @code{sanitized} +property that would emit a warning: + +@lisp +(define-record-type* + ;; @dots{} + (hosts-file %operating-system-hosts-file ;deprecated + (default #f) + (sanitize warn-hosts-file-field-deprecation))) + +(define-deprecated (operating-system-hosts-file os) + hosts-service-type + (%operating-system-hosts-file os)) +@end lisp + +When deprecating interfaces in @code{operating-system}, +@code{home-environment}, @code{(gnu services)}, or any popular service, +the deprecation must come with an entry in @code{etc/news.scm}. + +@cindex deprecation of programming interfaces +@item Core interfaces +Core programming interfaces, in particular the @code{(guix ...)} +modules, may be relied on by a variety of external tools and channels. +Any incompatible change must be formally deprecated with +@code{define-deprecated}, as shown above, for at least one year before +removal. The manual must clearly document the new interface and, except +in obvious cases, explain how to migrate from the old one. + +As an example, the @code{build-expression->derivation} procedure was +superseded by @code{gexp->derivation} and remained available as a +deprecated symbol: + +@lisp +(define-deprecated (build-expression->derivation store name exp + #:key @dots{}) + gexp->derivation + @dots{}) +@end lisp + +Sometimes bindings are moved from one module to another. In those +cases, bindings must be reexported from the original module for at least +one year. +@end table + +This section does not cover all possible situations but hopefully allows +users to know what to expect and developers to stick to its spirit. +Please email @email{guix-devel@@gnu.org} for any questions. + @cindex documentation @node Writing Documentation @section Writing Documentation base-commit: a1d367d6ee8c1783ef94cebbc5f2ae3b7a08078d -- 2.45.2 From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 28 10:32:49 2024 Received: (at control) by debbugs.gnu.org; 28 Aug 2024 14:32:49 +0000 Received: from localhost ([127.0.0.1]:49504 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sjJj6-0006LG-GQ for submit@debbugs.gnu.org; Wed, 28 Aug 2024 10:32:49 -0400 Received: from eggs.gnu.org ([209.51.188.92]:56328) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sjJj5-0006L0-1B for control@debbugs.gnu.org; Wed, 28 Aug 2024 10:32:47 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sjJi7-0007iN-M3 for control@debbugs.gnu.org; Wed, 28 Aug 2024 10:31:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:Subject:From:To:Date:in-reply-to: references; bh=FygPLF5lLrQVbUmQURFbkhSnbfB3nkafSVJnMjtef3Q=; b=V9eoQOe/r4Gyz3 Y2gLIr8gjXcWM66tJ6EBLFojpYPU4zrv3I7EkpJUgFhSUzgIxcvArnCGqaZjaXe0qVuzNQVi2tPsX e60hvL2y8sw0WvKgChBcn9nMcha9FIrxLHAetfhQQVv5+R0/z71FieJeTIgYanQo0ZGUeuZ1sbOLG jaLAymo2ZurEbzXFYdVC8LUwio9AZ3Da0AeiXUg3uSxCD8Ly1V5saKREp1I0qNrT2UtV5rimefk+r fT3FdCrMJG4AhfmS+96ulZL1WpeeAigrOnaOqjxpPIzSBBlZ3Fg60LSkzV+CQ67yxgbuaEreAehHg sTKM4zgTHLs9hI30gTVQ==; Date: Wed, 28 Aug 2024 16:31:46 +0200 Message-Id: <87zfowk9bh.fsf@gnu.org> To: control@debbugs.gnu.org From: =?utf-8?Q?Ludovic_Court=C3=A8s?= Subject: control message for bug #72839 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) merge 72839 72840 quit From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 02 07:54:48 2024 Received: (at 72840) by debbugs.gnu.org; 2 Sep 2024 11:54:48 +0000 Received: from localhost ([127.0.0.1]:46820 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sl5dv-0008AN-Ue for submit@debbugs.gnu.org; Mon, 02 Sep 2024 07:54:48 -0400 Received: from relay.yourmailgateway.de ([188.68.63.102]:37637) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sl5ds-00089v-MD for 72840@debbugs.gnu.org; Mon, 02 Sep 2024 07:54:46 -0400 Received: from mors-relay-2502.netcup.net (localhost [127.0.0.1]) by mors-relay-2502.netcup.net (Postfix) with ESMTPS id 4Wy6bV4R8xz61lS; Mon, 2 Sep 2024 13:53:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=pelzflorian.de; s=key2; t=1725278022; bh=Qgwn1svyM7qHlSdXPkuV6RAdFYiJBLlYWlmJsm/rQg0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Ddh6ftljxWLLHX+YRxMzUUQqZBRPAWy4dDX2SDBM/7IpfX0Tr/CHMFhSeb8z7QMJr iKqJgZoYNSJbCEpDCgPo9mewgZ/wORjjkOd9eHukhipNgRVyajZIv/6Hd/sYIqGeYd kDsBdyjs2T7O6PMSCVZsVWR4NlPYrpV9DfdFMV62q/jlPxSn5RInIZ5kIxstO4quWT TthMHqwuDgi6ZC1QUOY+edxc02EYFQcVjDMTPIDu0Q7DW9BiDqK/BBAIZH0t1R+7D3 LP91s6LDlfX4Fy5wH/0dWFtD+1NdRxQY+XsI+xUGgeyUlHenf/kEeoWSCPcK7CiBpe ozVS22EYPqYdQ== Received: from policy01-mors.netcup.net (unknown [46.38.225.35]) by mors-relay-2502.netcup.net (Postfix) with ESMTPS id 4Wy6bV3jmXz4xQc; Mon, 2 Sep 2024 13:53:42 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at policy01-mors.netcup.net X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 required=6.31 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Received: from mxe217.netcup.net (unknown [10.243.12.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by policy01-mors.netcup.net (Postfix) with ESMTPS id 4Wy6bS6F0fz8tYF; Mon, 2 Sep 2024 13:53:40 +0200 (CEST) Received: from florianhp (ipb2186896.dynamic.kabel-deutschland.de [178.24.104.150]) by mxe217.netcup.net (Postfix) with ESMTPSA id C3073840AB; Mon, 2 Sep 2024 13:53:32 +0200 (CEST) From: "pelzflorian (Florian Pelz)" To: Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: [bug#72840] [PATCH RFC] DRAFT doc: Add =?utf-8?Q?=E2=80=9CDep?= =?utf-8?Q?recation_Policy=E2=80=9D?= section. In-Reply-To: <80f8b603ecd73cb9f46b1ea43797e143f16d2f17.1724785788.git.ludo@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22's?= message of "Tue, 27 Aug 2024 21:30:35 +0200") References: <80f8b603ecd73cb9f46b1ea43797e143f16d2f17.1724785788.git.ludo@gnu.org> Date: Mon, 02 Sep 2024 13:53:32 +0200 Message-ID: <877cbunuf7.fsf@pelzflorian.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: C3073840AB X-Rspamd-Server: rspamd-worker-8404 X-NC-CID: 1HqIlGWemXlQAW6C+s42JaMNZ7aBx4w5G15sL4Crb3yf3pOvhlp3XCN/ X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 72840 Cc: Maxim Cournoyer , Matthew Trzcinski , 72840@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello Ludo. Having a deprecation policy clarifies things. Thank you for writing a good one! Ludovic Court=C3=A8s writes: > +@item Package removal > +Packages that their upstream developers have declared as having reach typo: reached > +``end of life'' or being unmaintained may be removed. There is no > +formal deprecation mechanism for this case, unless a replacement exists, > +in which case the @code{deprecated-package} procedure mentioned above > +can be used. > + > +If the package being removed is a ``leaf'' (no other packages depend on > +it), it may be removed after a one-month review period of the patch > +removing it. > + Could you also reference this one-month period in the Commit Access section, where policy is one or two weeks? Thinking of package removals for security reasons, it should be clearer that this one-month period applies even in this case. (IMHO some period should apply. It is the user=E2=80=99s decision to use software despite security problems. We all know web browsers=E2=80=99 security track record; not everone puts the web to use everywhere, but Guix thankfully does ship web browsers.) > [=E2=80=A6] > +@cindex deprecation of programming interfaces > +@item Core interfaces > +Core programming interfaces, in particular the @code{(guix ...)} > +modules, may be relied on by a variety of external tools and channels. > +Any incompatible change must be formally deprecated with > +@code{define-deprecated}, as shown above, for at least one year before > +removal. The manual must clearly document the new interface and, except > +in obvious cases, explain how to migrate from the old one. > + > +As an example, the @code{build-expression->derivation} procedure was > +superseded by @code{gexp->derivation} and remained available as a > +deprecated symbol: This cannot be an absolute truth. It is not always reasonable to make changes bacwards-compatible. For example, the switch from xz repacking to zstd repacking in recent core-updates did break guile-manual in doc/build.scm and perhaps did break outside code, but it was right nonetheless. Also Guix is in one big guix.git repository so that we can make changes. Regards, Florian From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 05 17:27:45 2024 Received: (at 72840-done) by debbugs.gnu.org; 5 Sep 2024 21:27:45 +0000 Received: from localhost ([127.0.0.1]:38404 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1smK12-0003bS-Pa for submit@debbugs.gnu.org; Thu, 05 Sep 2024 17:27:45 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43652) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1smK10-0003bD-1t for 72840-done@debbugs.gnu.org; Thu, 05 Sep 2024 17:27:43 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1smJzp-00027f-Vz; Thu, 05 Sep 2024 17:26:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=GKdoQjQuacinu7t9UWF4yEeZ0/sN4LxykfmR+Y557k4=; b=mzh6LrLpUN61vU/y1bWD zDLg9cOxgLJSVjnxhlaHbAeaplLcKTOVdrwAk7XSAowCFlGSajeI4cPtRP0EO0/Ip43Q9ZLqo+k/1 colxLaTnmXPkgaIrJSmNNkcP8wLc/zmHy2qEMj3tDCPjP8WhXP1WW7CaRKFe+azzkyWvmNrzksWMp 1CU+7gF06gml605XkMPXu3IKdhEJZa9Lm+/ypbkdzOKio5NfyBso8uUzmeT5up1dXyBtzCnIobOIz NJDs3XyA8Xwaot5XIhBrQsm9cFcOZrOdB9+u/7uduyzeon+AEubtE97DUN6T89UoKk9PulyIRtwJT Gh5z55RZ5Msj5Q==; From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: "pelzflorian (Florian Pelz)" Subject: Re: bug#72840: [PATCH RFC] DRAFT doc: Add =?utf-8?Q?=E2=80=9CDepr?= =?utf-8?Q?ecation_Policy=E2=80=9D?= section. In-Reply-To: <877cbunuf7.fsf@pelzflorian.de> (pelzflorian@pelzflorian.de's message of "Mon, 02 Sep 2024 13:53:32 +0200") References: <80f8b603ecd73cb9f46b1ea43797e143f16d2f17.1724785788.git.ludo@gnu.org> <877cbunuf7.fsf@pelzflorian.de> Date: Thu, 05 Sep 2024 23:26:25 +0200 Message-ID: <87frqd6bcu.fsf_-_@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 72840-done Cc: Matthew Trzcinski , Maxim Cournoyer , 72840-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hi Florian, "pelzflorian (Florian Pelz)" skribis: > Hello Ludo. Having a deprecation policy clarifies things. Thank you > for writing a good one! Thanks for taking a look! >> +If the package being removed is a ``leaf'' (no other packages depend on >> +it), it may be removed after a one-month review period of the patch >> +removing it. >> + > > Could you also reference this one-month period in the Commit Access secti= on, > where policy is one or two weeks? Sure, done in v2 (sent separately). > Thinking of package removals for security reasons, it should be > clearer that this one-month period applies even in this case. (IMHO > some period should apply. It is the user=E2=80=99s decision to use softw= are > despite security problems. We all know web browsers=E2=80=99 security tr= ack > record; not everone puts the web to use everywhere, but Guix > thankfully does ship web browsers.) Indeed; I tried to clarify that in v2. >> [=E2=80=A6] >> +@cindex deprecation of programming interfaces >> +@item Core interfaces >> +Core programming interfaces, in particular the @code{(guix ...)} >> +modules, may be relied on by a variety of external tools and channels. >> +Any incompatible change must be formally deprecated with >> +@code{define-deprecated}, as shown above, for at least one year before >> +removal. The manual must clearly document the new interface and, except >> +in obvious cases, explain how to migrate from the old one. [...] > This cannot be an absolute truth. It is not always reasonable to make > changes bacwards-compatible. For example, the switch from xz > repacking to zstd repacking in recent core-updates did break > guile-manual in doc/build.scm and perhaps did break outside code, but > it was right nonetheless. Also Guix is in one big guix.git repository > so that we can make changes. Yes, I agree. But note that this paragraph is concerned with programming interfaces, which would not cover the case you describe IMO (though I understand this is debatable). I thought about changing =E2=80=9Cmust be formally deprecated=E2=80=9D to = =E2=80=9Cmust be formally deprecated [=E2=80=A6] unless the cost of doing so is considered disproportionate=E2=80=9D. But then it sounds like inviting Guix developer= s to put their own interests first and significantly weakens this deprecation =E2=80=9Ccontract=E2=80=9D with users. Maybe there are other ways to phras= e it? Also, the section ends with: > This section does not cover all possible situations but hopefully allows > users to know what to expect and developers to stick to its spirit. =E2=80=A6 which in my mind would cover situations like what you describe. WDYT? Thanks again for your feedback. Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 05 17:33:02 2024 Received: (at 72840) by debbugs.gnu.org; 5 Sep 2024 21:33:02 +0000 Received: from localhost ([127.0.0.1]:38413 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1smK69-00041T-LF for submit@debbugs.gnu.org; Thu, 05 Sep 2024 17:33:02 -0400 Received: from eggs.gnu.org ([209.51.188.92]:50332) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1smK67-00041G-LW for 72840@debbugs.gnu.org; Thu, 05 Sep 2024 17:33:00 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1smK4y-0002la-SF; Thu, 05 Sep 2024 17:31:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:References:In-Reply-To:Date:Subject:To: From; bh=42LADpVb+ft8sCV1Q5a28K5KnD6jDcEyqilim5vg3Vo=; b=WeQKn94bt26w/097NGir jgksqhvECOjBFv/Y5vDpx+ruMo5B7s7FO7rkEEHpE+Jd377jLPm3lgJkBzfZSQdTsGVwcDSlopIG8 wLaC5JoIhCAP64GE378DXS0W8wwcdSzSBhJv94i+kDu/z5afrRpG/Bnwlqe5f+jMniXU9Cg+fcdIZ afMWbmgo1fF1DWm+OSNowWYcQG62Zl68apAFx1LJhaOTBS3CANQIt/M9mKHYriDISIBlwFkdGOGSi EnpZgXKug4aMDYrxKeCIg2++2Lav2WVbFwg0qo7y91VXuxiJcem61Hf/4MzOVotnpTQL2q+pYjiNN J6oNe6UetXptGA==; From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= To: 72840@debbugs.gnu.org Subject: [PATCH RFC v2] =?UTF-8?q?doc:=20Add=20=E2=80=9CDeprecation=20Poli?= =?UTF-8?q?cy=E2=80=9D=20section.?= Date: Thu, 5 Sep 2024 23:31:39 +0200 Message-ID: <53d897cec60ae13a22de486ba37604ab99e65fe8.1725571691.git.ludo@gnu.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <87frqd6bcu.fsf_-_@gnu.org> References: <87frqd6bcu.fsf_-_@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Debbugs-Cc: Florian Pelz , Ludovic Courtès , Maxim Cournoyer Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 72840 Cc: =?UTF-8?q?Ludovic=20Court=C3=A8s?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) * doc/contributing.texi (Deprecation Policy): New node. (Commit Access): Link to ‘package-removal-policy’. Change-Id: I5d095559920a3d9b791b5d919aab4e2f2a0c2dee --- doc/contributing.texi | 188 +++++++++++++++++++++++++++++++++++++++++- 1 file changed, 185 insertions(+), 3 deletions(-) Changes compared to v1: • Fixed typo reported by Florian; • Adding cross-reference in “Commit Access” section; • Typeset review/deprecation durations in boldface; • Clarified that the package removal policy also applies when removal is motivated by security reasons. Ludo’. diff --git a/doc/contributing.texi b/doc/contributing.texi index 73f7addbef..f8c2b5c245 100644 --- a/doc/contributing.texi +++ b/doc/contributing.texi @@ -34,6 +34,7 @@ Contributing * Commit Access:: Pushing to the official repository. * Reviewing the Work of Others:: Some guidelines for sharing reviews. * Updating the Guix Package:: Updating the Guix package definition. +* Deprecation Policy:: Commitments and tools for deprecation. * Writing Documentation:: Improving documentation in GNU Guix. * Translating Guix:: Make Guix speak your native language. @end menu @@ -2805,9 +2806,11 @@ Commit Access repository, especially for the @code{master} branch. If you're committing and pushing your own changes, try and wait at least -one week (two weeks for more significant changes) after you send them -for review. After this, if no one else is available to review them and -if you're confident about the changes, it's OK to commit. +one week (two weeks for more significant changes, up to one month for +changes such as removing a package---@pxref{package-removal-policy, +Package Removal}) after you send them for review. After this, if no one +else is available to review them and if you're confident about the +changes, it's OK to commit. When pushing a commit on behalf of somebody else, please add a @code{Signed-off-by} line at the end of the commit log message---e.g., @@ -3030,6 +3033,185 @@ Updating the Guix Package this variable is set, the updated package source is also added to the store. This is used as part of the release process of Guix. +@node Deprecation Policy +@section Deprecation Policy + +@cindex deprecation policy +As any lively project with a broad scope, Guix changes all the time and +all levels. Because it's user-extensible and programmable, incompatible +changes can directly impact users and make their life harder. It is +thus important to reduce user-visible incompatible changes to a minimum +and, when such changes are deemed necessary, to clearly communicate them +through a @dfn{deprecation period} so everyone can adapt with minimum +hassle. This section defines the project's commitments for smooth +deprecation and describes procedures and mechanisms to honor them. + +There are several ways to use Guix; how to handle deprecation will +depend on each use case. Those can be roughly categorized like this: + +@itemize +@item +package management exclusively through the command line; + +@item +advanced package management using the manifest and package interfaces; + +@item +Home and System management, using the @code{operating-system} and/or +@code{home-environment} interfaces together with the service interfaces; + +@item +development of external tools that use programming interfaces such as +the @code{(guix ...)} modules. +@end itemize + +These use cases form a spectrum with varying degrees of coupling---from +``distant'' to tightly coupled. Based on this insight, we define the +following @dfn{deprecation policies} that we consider suitable for each +of these levels. + +@table @asis +@item Command-line tools +Guix sub-commands should be thought of as remaining available +``forever''. Once a Guix sub-command is to be removed, it should be +deprecated first, and then remain available for @b{at least one year} +after the first release that deprecated it. + +Deprecation should first be announced in the manual and as an entry in +@file{etc/news.scm}; additional communication such as a blog post +explaining the rationale is welcome. Months before the scheduled +removal date, the command should print a warning explaining how to +migrate. An example of this is the replacement of @command{guix +environment} by @command{guix shell}, started in October +2021@footnote{For more details on the @command{guix shell} transition, +see +@uref{https://guix.gnu.org/en/blog/2021/from-guix-environment-to-guix-shell/}.}. + +Because of the broad impact of such a change, we recommend conducting a +user survey before enacting a plan. + +@cindex package deprecation +@item Package name changes +When a package name changes, it must remain available under its old name +for @b{at least one year}. For example, @code{go-ipfs} was renamed to +@code{kubo} following a decision made upstream; to communicate the name +change to users, the package module provided this definition: + +@findex deprecated-package +@lisp +(define-public go-ipfs + (deprecated-package "go-ipfs" kubo)) +@end lisp + +That way, someone running @command{guix install go-ipfs} or similar sees +a deprecation warning mentioning the new name. + +@cindex package removal policy +@anchor{package-removal-policy} +@item Package removal +Packages that their upstream developers have declared as having reached +``end of life'' or being unmaintained may be removed. There is no +formal deprecation mechanism for this case, unless a replacement exists, +in which case the @code{deprecated-package} procedure mentioned above +can be used. + +If the package being removed is a ``leaf'' (no other packages depend on +it), it may be removed after a @b{one-month review period} of the patch +removing it (this applies even when the removal has additional +motivations such as security problems affecting the package). + +If it has many dependent packages---as is the case for example with +Python version@tie{}2---the relevant team must propose a deprecation +removal agenda and seek consensus with other packagers for @b{at least +one month}. It may also invite feedback from the broader user +community, for example through a survey. Removal of all impacted +packages may be gradual, spanning multiple months, to accommodate all +use cases. + +When the package being removed is considered popular, whether or not it +is a leaf, its deprecation must be announced as an entry in +@code{etc/news.scm}. + +@cindex service deprecation +@item Services +Changes to services for Guix Home and Guix System have a direct impact +on user configuration. For a user, adjusting to interface changes is +rarely rewarding, which is why any such change must be clearly +communicated in advance through deprecation warnings and documentation. + +Renaming of variables related to service, home, or system configuration +must be communicated for at least six months before removal using the +@code{(guix deprecation)} mechanisms. For example, renaming of +@code{murmur-configuration} to @code{mumble-server-configuration} was +communicated through a series of definitions like this one: + +@findex define-deprecated/public-alias +@lisp +(define-deprecated/public-alias + murmur-configuration + mumble-server-configuration) +@end lisp + +Procedures slated for removal may be defined like this: + +@findex define-deprecated +@lisp +(define-deprecated (elogind-service #:key (config (elogind-configuration))) + elogind-service-type + (service elogind-service-type config)) +@end lisp + +Record fields, notably fields of service configuration records, must +follow a similar deprecation period. This is usually achieved through +@i{ad hoc} means though. For example, the @code{hosts-file} field of +@code{operating-system} was deprecated by adding a @code{sanitized} +property that would emit a warning: + +@lisp +(define-record-type* + ;; @dots{} + (hosts-file %operating-system-hosts-file ;deprecated + (default #f) + (sanitize warn-hosts-file-field-deprecation))) + +(define-deprecated (operating-system-hosts-file os) + hosts-service-type + (%operating-system-hosts-file os)) +@end lisp + +When deprecating interfaces in @code{operating-system}, +@code{home-environment}, @code{(gnu services)}, or any popular service, +the deprecation must come with an entry in @code{etc/news.scm}. + +@cindex deprecation of programming interfaces +@item Core interfaces +Core programming interfaces, in particular the @code{(guix ...)} +modules, may be relied on by a variety of external tools and channels. +Any incompatible change must be formally deprecated with +@code{define-deprecated}, as shown above, for @b{at least one year} +before removal. The manual must clearly document the new interface and, +except in obvious cases, explain how to migrate from the old one. + +As an example, the @code{build-expression->derivation} procedure was +superseded by @code{gexp->derivation} and remained available as a +deprecated symbol: + +@lisp +(define-deprecated (build-expression->derivation store name exp + #:key @dots{}) + gexp->derivation + @dots{}) +@end lisp + +Sometimes bindings are moved from one module to another. In those +cases, bindings must be reexported from the original module for at least +one year. +@end table + +This section does not cover all possible situations but hopefully allows +users to know what to expect and developers to stick to its spirit. +Please email @email{guix-devel@@gnu.org} for any questions. + @cindex documentation @node Writing Documentation @section Writing Documentation base-commit: 993d6d2e7be4dac738629c76a51058f4dc5bc449 -- 2.45.2 From unknown Sat Jun 21 03:09:13 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: Did not alter fixed versions and reopened. Date: Thu, 05 Sep 2024 21:34:02 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # Did not alter fixed versions and reopened. thanks # This fakemail brought to you by your local debbugs # administrator From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 05 17:33:44 2024 Received: (at control) by debbugs.gnu.org; 5 Sep 2024 21:33:44 +0000 Received: from localhost ([127.0.0.1]:38422 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1smK6p-00043l-VA for submit@debbugs.gnu.org; Thu, 05 Sep 2024 17:33:44 -0400 Received: from eggs.gnu.org ([209.51.188.92]:52226) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1smK6p-00043H-3V for control@debbugs.gnu.org; Thu, 05 Sep 2024 17:33:43 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1smK5g-0002nV-A3 for control@debbugs.gnu.org; Thu, 05 Sep 2024 17:32:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:Subject:From:To:Date:in-reply-to: references; bh=WishXFbw03QK2UtdGEQp2uV2Pfjv4SU+CtMYPlD/oR8=; b=mC6jME2/hWua0q uO8feoywRQu5y5+1DXws9BTpNmrgRPd+V7ff2S98j6vIktg1v5+PLuru2D5r7XeZNZUFPPIsLdHQD pJhAGwSOzshHbboq9stVyxaIK3MNjhL7cGypekIitMr+EJjQ6+e1Eew6rfwhKUgugDEjmzjpc+DOK +4ijXS8Zf7qfW30y+W8vCdO/7Hs1JR4L+oktn2cya1Dh+nSna8rvDtNUOpZYAkfO+9DJ00qhwNpBe nEA9Ox3C5h7fCDkQWxlhaWh7KwcmUR69yVmXbooHQ2RF5SfwrWNG3cXnjtNKM7QrKXAQlfP6i8Z/y i8VIpo72cvMKYXEKUtlw==; Date: Thu, 05 Sep 2024 23:32:30 +0200 Message-Id: <87bk116b2p.fsf@gnu.org> To: control@debbugs.gnu.org From: =?utf-8?Q?Ludovic_Court=C3=A8s?= Subject: control message for bug #72840 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) reopen 72840 tags 72840 - fixed patch quit From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 11 03:05:19 2024 Received: (at 72840) by debbugs.gnu.org; 11 Sep 2024 07:05:19 +0000 Received: from localhost ([127.0.0.1]:37718 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1soHPi-00088q-A6 for submit@debbugs.gnu.org; Wed, 11 Sep 2024 03:05:19 -0400 Received: from mail-pl1-f175.google.com ([209.85.214.175]:51543) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1soHPf-00082j-SZ for 72840@debbugs.gnu.org; Wed, 11 Sep 2024 03:05:16 -0400 Received: by mail-pl1-f175.google.com with SMTP id d9443c01a7336-2059112f0a7so58801685ad.3 for <72840@debbugs.gnu.org>; Wed, 11 Sep 2024 00:05:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726038244; x=1726643044; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=mecDS6nNUvdaZSbyA3s5fBeolubzh6Z9sQapvqTRCjk=; b=FY6YVsdM5kpbaKVW3/Md6KDlZqTwDLdPrbhQSFgjE7dNMBsv/rNg+EGeT+aTd3iZQS jhl69gNeTP7DIJ9Wwyin0gQkRjIdT8Hc5L/dbg4r7rrha8w06dRlR0x3GNor/2M1er/M uAvmrCDzXtvu8ACAzQJfPpG+zkfUiQeN+jAxQFF+eRJ0j3lwsvNv+4fdPgk229T/lMZa FKMWI6qbRfhKs0VFLf+l5vLC9jyPWZuS0iW9/otedcR6aZ2/4AV6heSFt7eeFjn7Se4T aOuErMPet2J3MIPMmvx7gWr5/R11OTkh8brghJpRM/HH6neHqRx+hL/3e1Bl3MGcwgTG QRvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726038244; x=1726643044; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=mecDS6nNUvdaZSbyA3s5fBeolubzh6Z9sQapvqTRCjk=; b=Jv5nias4qx+OngWN/vT5Y95pkgPK5VWhEP1IYSH82nGYBW4bio+KRvHdCJEPzOZsEu YRsmsxUCHlBpiZnOI6C4/F7JmHyRaHKQd+R35KNEfCXgRo6fDvSeDQzaiO3ESxNVQl22 xU1fRriU6rGUSA95mDMABjJ3KpAXM0liS2h8FCN7/QXNbN1F/lXFz1g0z7iDykzxnplP ye6VWWSopaWf3HSodOE3HiB648EPCsRIgtC9hHAsYakmP8UNpoi8PdCYwK2kU7tdSwof Q44bP7O5wxx5+nI6tIk2vICFFDNQ/ipbQNOIP/j293a7zbghZsSibuyG70dazFS2AWUn 1h5Q== X-Gm-Message-State: AOJu0YxB9SF1RyVsyuSN+zL3cDcNaXcS38Vbx6sE0uLCKF4omrF3sKtS G+Z0mMEuu5ofqWmymEAp/amBCgLeIq/vm5NIAVCKlTRepjowkA7W X-Google-Smtp-Source: AGHT+IF97DPz5AhbHkuB8eu36zjGksBg4AcqbCTSu+wfULXuQFl/cnyHoGhdhTwCJ/G/N0/TnoQ+pA== X-Received: by 2002:a17:903:11d2:b0:206:9536:9778 with SMTP id d9443c01a7336-2074c5d3daamr43709165ad.19.1726038243739; Wed, 11 Sep 2024 00:04:03 -0700 (PDT) Received: from hurd ([2405:6586:be0:0:c8ff:1707:9b9:af89]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-20710e15cfdsm57981535ad.6.2024.09.11.00.04.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Sep 2024 00:04:03 -0700 (PDT) From: Maxim Cournoyer To: Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: [bug#72840] [PATCH RFC v2] doc: Add =?utf-8?Q?=E2=80=9CDeprec?= =?utf-8?Q?ation_Policy=E2=80=9D?= section. In-Reply-To: <53d897cec60ae13a22de486ba37604ab99e65fe8.1725571691.git.ludo@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22's?= message of "Thu, 5 Sep 2024 23:31:39 +0200") References: <87frqd6bcu.fsf_-_@gnu.org> <53d897cec60ae13a22de486ba37604ab99e65fe8.1725571691.git.ludo@gnu.org> Date: Wed, 11 Sep 2024 16:04:00 +0900 Message-ID: <8734m63c4f.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 72840 Cc: Florian Pelz , 72840@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi Ludovic, Ludovic Court=C3=A8s writes: > * doc/contributing.texi (Deprecation Policy): New node. > (Commit Access): Link to =E2=80=98package-removal-policy=E2=80=99. > > Change-Id: I5d095559920a3d9b791b5d919aab4e2f2a0c2dee > --- > doc/contributing.texi | 188 +++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 185 insertions(+), 3 deletions(-) > > Changes compared to v1: > > =E2=80=A2 Fixed typo reported by Florian; > > =E2=80=A2 Adding cross-reference in =E2=80=9CCommit Access=E2=80=9D sec= tion; > > =E2=80=A2 Typeset review/deprecation durations in boldface; > > =E2=80=A2 Clarified that the package removal policy also applies when > removal is motivated by security reasons. > > Ludo=E2=80=99. > > diff --git a/doc/contributing.texi b/doc/contributing.texi > index 73f7addbef..f8c2b5c245 100644 > --- a/doc/contributing.texi > +++ b/doc/contributing.texi > @@ -34,6 +34,7 @@ Contributing > * Commit Access:: Pushing to the official repository. > * Reviewing the Work of Others:: Some guidelines for sharing reviews. > * Updating the Guix Package:: Updating the Guix package definition. > +* Deprecation Policy:: Commitments and tools for deprecation. > * Writing Documentation:: Improving documentation in GNU Guix. > * Translating Guix:: Make Guix speak your native language. > @end menu > @@ -2805,9 +2806,11 @@ Commit Access > repository, especially for the @code{master} branch. >=20=20 > If you're committing and pushing your own changes, try and wait at least > -one week (two weeks for more significant changes) after you send them > -for review. After this, if no one else is available to review them and > -if you're confident about the changes, it's OK to commit. > +one week (two weeks for more significant changes, up to one month for > +changes such as removing a package---@pxref{package-removal-policy, > +Package Removal}) after you send them for review. After this, if no one ^ two spaces convention =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20 > +else is available to review them and if you're confident about the > +changes, it's OK to commit. >=20=20 > When pushing a commit on behalf of somebody else, please add a > @code{Signed-off-by} line at the end of the commit log message---e.g., > @@ -3030,6 +3033,185 @@ Updating the Guix Package > this variable is set, the updated package source is also added to the > store. This is used as part of the release process of Guix. >=20=20 > +@node Deprecation Policy > +@section Deprecation Policy > + > +@cindex deprecation policy > +As any lively project with a broad scope, Guix changes all the time and > +all levels. Because it's user-extensible and programmable, incompatible Perhaps 'at all the time and *at* all levels' ? It reads better for me. > +changes can directly impact users and make their life harder. It is > +thus important to reduce user-visible incompatible changes to a minimum > +and, when such changes are deemed necessary, to clearly communicate them > +through a @dfn{deprecation period} so everyone can adapt with minimum > +hassle. This section defines the project's commitments for smooth > +deprecation and describes procedures and mechanisms to honor them. > + > +There are several ways to use Guix; how to handle deprecation will > +depend on each use case. Those can be roughly categorized like this: > + > +@itemize > +@item > +package management exclusively through the command line; > + > +@item > +advanced package management using the manifest and package interfaces; > + > +@item > +Home and System management, using the @code{operating-system} and/or > +@code{home-environment} interfaces together with the service interfaces; > + > +@item > +development of external tools that use programming interfaces such as > +the @code{(guix ...)} modules. > +@end itemize > + > +These use cases form a spectrum with varying degrees of coupling---from > +``distant'' to tightly coupled. Based on this insight, we define the > +following @dfn{deprecation policies} that we consider suitable for each > +of these levels. > + > +@table @asis > +@item Command-line tools > +Guix sub-commands should be thought of as remaining available > +``forever''. Once a Guix sub-command is to be removed, it should be > +deprecated first, and then remain available for @b{at least one year} > +after the first release that deprecated it. > + > +Deprecation should first be announced in the manual and as an entry in > +@file{etc/news.scm}; additional communication such as a blog post > +explaining the rationale is welcome. Months before the scheduled > +removal date, the command should print a warning explaining how to > +migrate. An example of this is the replacement of @command{guix > +environment} by @command{guix shell}, started in October > +2021@footnote{For more details on the @command{guix shell} transition, > +see > +@uref{https://guix.gnu.org/en/blog/2021/from-guix-environment-to-guix-sh= ell/}.}. > + > +Because of the broad impact of such a change, we recommend conducting a > +user survey before enacting a plan. > + > +@cindex package deprecation > +@item Package name changes > +When a package name changes, it must remain available under its old name > +for @b{at least one year}. For example, @code{go-ipfs} was renamed to > +@code{kubo} following a decision made upstream; to communicate the name > +change to users, the package module provided this definition: > + > +@findex deprecated-package > +@lisp > +(define-public go-ipfs > + (deprecated-package "go-ipfs" kubo)) > +@end lisp > + > +That way, someone running @command{guix install go-ipfs} or similar sees > +a deprecation warning mentioning the new name. > + > +@cindex package removal policy > +@anchor{package-removal-policy} > +@item Package removal > +Packages that their upstream developers have declared as having reached s/that their/whose/ > +``end of life'' or being unmaintained may be removed. There is no > +formal deprecation mechanism for this case, unless a replacement exists, > +in which case the @code{deprecated-package} procedure mentioned above > +can be used. > + > +If the package being removed is a ``leaf'' (no other packages depend on > +it), it may be removed after a @b{one-month review period} of the patch > +removing it (this applies even when the removal has additional > +motivations such as security problems affecting the package). > + > +If it has many dependent packages---as is the case for example with > +Python version@tie{}2---the relevant team must propose a deprecation > +removal agenda and seek consensus with other packagers for @b{at least > +one month}. It may also invite feedback from the broader user > +community, for example through a survey. Removal of all impacted > +packages may be gradual, spanning multiple months, to accommodate all > +use cases. > + > +When the package being removed is considered popular, whether or not it > +is a leaf, its deprecation must be announced as an entry in > +@code{etc/news.scm}. > + > +@cindex service deprecation > +@item Services > +Changes to services for Guix Home and Guix System have a direct impact > +on user configuration. For a user, adjusting to interface changes is > +rarely rewarding, which is why any such change must be clearly > +communicated in advance through deprecation warnings and documentation. > + > +Renaming of variables related to service, home, or system configuration > +must be communicated for at least six months before removal using the > +@code{(guix deprecation)} mechanisms. For example, renaming of > +@code{murmur-configuration} to @code{mumble-server-configuration} was > +communicated through a series of definitions like this one: > + > +@findex define-deprecated/public-alias > +@lisp > +(define-deprecated/public-alias > + murmur-configuration > + mumble-server-configuration) > +@end lisp > + > +Procedures slated for removal may be defined like this: > + > +@findex define-deprecated > +@lisp > +(define-deprecated (elogind-service #:key (config (elogind-configuration= ))) > + elogind-service-type > + (service elogind-service-type config)) > +@end lisp > + > +Record fields, notably fields of service configuration records, must > +follow a similar deprecation period. This is usually achieved through > +@i{ad hoc} means though. For example, the @code{hosts-file} field of > +@code{operating-system} was deprecated by adding a @code{sanitized} > +property that would emit a warning: > + > +@lisp > +(define-record-type* > + ;; @dots{} > + (hosts-file %operating-system-hosts-file ;deprecated > + (default #f) > + (sanitize warn-hosts-file-field-deprecation))) > + > +(define-deprecated (operating-system-hosts-file os) > + hosts-service-type > + (%operating-system-hosts-file os)) > +@end lisp > + > +When deprecating interfaces in @code{operating-system}, > +@code{home-environment}, @code{(gnu services)}, or any popular service, > +the deprecation must come with an entry in @code{etc/news.scm}. > + > +@cindex deprecation of programming interfaces > +@item Core interfaces > +Core programming interfaces, in particular the @code{(guix ...)} > +modules, may be relied on by a variety of external tools and channels. > +Any incompatible change must be formally deprecated with > +@code{define-deprecated}, as shown above, for @b{at least one year} > +before removal. The manual must clearly document the new interface and, > +except in obvious cases, explain how to migrate from the old one. > + > +As an example, the @code{build-expression->derivation} procedure was > +superseded by @code{gexp->derivation} and remained available as a > +deprecated symbol: > + > +@lisp > +(define-deprecated (build-expression->derivation store name exp > + #:key @dots{}) > + gexp->derivation > + @dots{}) > +@end lisp > + > +Sometimes bindings are moved from one module to another. In those > +cases, bindings must be reexported from the original module for at least > +one year. > +@end table > + > +This section does not cover all possible situations but hopefully allows > +users to know what to expect and developers to stick to its spirit. > +Please email @email{guix-devel@@gnu.org} for any questions. Thanks for taking the time to write this down. It'll be useful to many I'm sure, including myself. Apart from the small things I've spotted above, it looks like a pretty good starting ground for a deprecation policy. One thought I'm having right now is that it would be cool if all these deprecation mechanism offered in the (guix deprecation) module were fully documented in our manual, and could be referred to from the above section/text for extra information; but this can be done in the future. --=20 Thanks, Maxim From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 11 06:11:51 2024 Received: (at 72840) by debbugs.gnu.org; 11 Sep 2024 10:11:51 +0000 Received: from localhost ([127.0.0.1]:37821 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1soKKE-0000Wh-Pp for submit@debbugs.gnu.org; Wed, 11 Sep 2024 06:11:51 -0400 Received: from eggs.gnu.org ([209.51.188.92]:37572) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1soKKC-0000WS-NX for 72840@debbugs.gnu.org; Wed, 11 Sep 2024 06:11:49 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1soKJz-0000pg-U2; Wed, 11 Sep 2024 06:11:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:References:In-Reply-To:Date:Subject:To: From; bh=utezWsfemszQx6e5D3hH/LfmPhO5v7laBfPDxVs4KpA=; b=W+P34Kjwg6BDl/3+omDn 15NEI2aeCgAgvITyIu79NlCDVrxnqGE94uN9O74yXY9zFar4JIfbpMMVrD5JXoWdODl/eJRWgK502 1FTu9PgeOa25Gy/t4lrolB2Vh23sATDDEnUPBNs9G6Zuz6p6zbuGP2rmdrA0wPQENriBySCyGbkfA 8DGiRjSpDxAcYaKSMEP45Z9Zy+Lrbamg6qmUeIE31sQSXQv7igzyqKVP0rsmsE1qgUuO6VF/paG/m akTkugH1MUdliKH2P4oVdHsSN/QSbahIcSZz+NNiDlIpocNcelia7MdMtqemzLTc55I2dxUupNlUG m7xExIRX2MmFeg==; From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= To: 72840@debbugs.gnu.org Subject: [PATCH RFC v3] =?UTF-8?q?doc:=20Add=20=E2=80=9CDeprecation=20Poli?= =?UTF-8?q?cy=E2=80=9D=20section.?= Date: Wed, 11 Sep 2024 12:11:22 +0200 Message-ID: <902c544b5298617c2ed45af8d672130bc9b1a2e3.1726049102.git.ludo@gnu.org> X-Mailer: git-send-email 2.46.0 In-Reply-To: <8734m63c4f.fsf@gmail.com> References: <8734m63c4f.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Debbugs-Cc: Florian Pelz , Ludovic Courtès , Maxim Cournoyer Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 72840 Cc: =?UTF-8?q?Ludovic=20Court=C3=A8s?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) * doc/contributing.texi (Deprecation Policy): New node. (Commit Access): Link to ‘package-removal-policy’. Change-Id: I5d095559920a3d9b791b5d919aab4e2f2a0c2dee --- doc/contributing.texi | 189 +++++++++++++++++++++++++++++++++++++++++- 1 file changed, 186 insertions(+), 3 deletions(-) Changes compared to v2: fixed typos reported by Maxim Cournoyer. diff --git a/doc/contributing.texi b/doc/contributing.texi index 73f7addbef..f713765357 100644 --- a/doc/contributing.texi +++ b/doc/contributing.texi @@ -34,6 +34,7 @@ Contributing * Commit Access:: Pushing to the official repository. * Reviewing the Work of Others:: Some guidelines for sharing reviews. * Updating the Guix Package:: Updating the Guix package definition. +* Deprecation Policy:: Commitments and tools for deprecation. * Writing Documentation:: Improving documentation in GNU Guix. * Translating Guix:: Make Guix speak your native language. @end menu @@ -2805,9 +2806,11 @@ Commit Access repository, especially for the @code{master} branch. If you're committing and pushing your own changes, try and wait at least -one week (two weeks for more significant changes) after you send them -for review. After this, if no one else is available to review them and -if you're confident about the changes, it's OK to commit. +one week (two weeks for more significant changes, up to one month for +changes such as removing a package---@pxref{package-removal-policy, +Package Removal}) after you send them for review. After this, if no one +else is available to review them and if you're confident about the +changes, it's OK to commit. When pushing a commit on behalf of somebody else, please add a @code{Signed-off-by} line at the end of the commit log message---e.g., @@ -3030,6 +3033,186 @@ Updating the Guix Package this variable is set, the updated package source is also added to the store. This is used as part of the release process of Guix. +@node Deprecation Policy +@section Deprecation Policy + +@cindex deprecation policy +As any lively project with a broad scope, Guix changes all the time and +at all levels. Because it's user-extensible and programmable, +incompatible changes can directly impact users and make their life +harder. It is thus important to reduce user-visible incompatible +changes to a minimum and, when such changes are deemed necessary, to +clearly communicate them through a @dfn{deprecation period} so everyone +can adapt with minimum hassle. This section defines the project's +commitments for smooth deprecation and describes procedures and +mechanisms to honor them. + +There are several ways to use Guix; how to handle deprecation will +depend on each use case. Those can be roughly categorized like this: + +@itemize +@item +package management exclusively through the command line; + +@item +advanced package management using the manifest and package interfaces; + +@item +Home and System management, using the @code{operating-system} and/or +@code{home-environment} interfaces together with the service interfaces; + +@item +development of external tools that use programming interfaces such as +the @code{(guix ...)} modules. +@end itemize + +These use cases form a spectrum with varying degrees of coupling---from +``distant'' to tightly coupled. Based on this insight, we define the +following @dfn{deprecation policies} that we consider suitable for each +of these levels. + +@table @asis +@item Command-line tools +Guix sub-commands should be thought of as remaining available +``forever''. Once a Guix sub-command is to be removed, it should be +deprecated first, and then remain available for @b{at least one year} +after the first release that deprecated it. + +Deprecation should first be announced in the manual and as an entry in +@file{etc/news.scm}; additional communication such as a blog post +explaining the rationale is welcome. Months before the scheduled +removal date, the command should print a warning explaining how to +migrate. An example of this is the replacement of @command{guix +environment} by @command{guix shell}, started in October +2021@footnote{For more details on the @command{guix shell} transition, +see +@uref{https://guix.gnu.org/en/blog/2021/from-guix-environment-to-guix-shell/}.}. + +Because of the broad impact of such a change, we recommend conducting a +user survey before enacting a plan. + +@cindex package deprecation +@item Package name changes +When a package name changes, it must remain available under its old name +for @b{at least one year}. For example, @code{go-ipfs} was renamed to +@code{kubo} following a decision made upstream; to communicate the name +change to users, the package module provided this definition: + +@findex deprecated-package +@lisp +(define-public go-ipfs + (deprecated-package "go-ipfs" kubo)) +@end lisp + +That way, someone running @command{guix install go-ipfs} or similar sees +a deprecation warning mentioning the new name. + +@cindex package removal policy +@anchor{package-removal-policy} +@item Package removal +Packages whose upstream developers have declared as having reached ``end +of life'' or being unmaintained may be removed. There is no formal +deprecation mechanism for this case, unless a replacement exists, in +which case the @code{deprecated-package} procedure mentioned above can +be used. + +If the package being removed is a ``leaf'' (no other packages depend on +it), it may be removed after a @b{one-month review period} of the patch +removing it (this applies even when the removal has additional +motivations such as security problems affecting the package). + +If it has many dependent packages---as is the case for example with +Python version@tie{}2---the relevant team must propose a deprecation +removal agenda and seek consensus with other packagers for @b{at least +one month}. It may also invite feedback from the broader user +community, for example through a survey. Removal of all impacted +packages may be gradual, spanning multiple months, to accommodate all +use cases. + +When the package being removed is considered popular, whether or not it +is a leaf, its deprecation must be announced as an entry in +@code{etc/news.scm}. + +@cindex service deprecation +@item Services +Changes to services for Guix Home and Guix System have a direct impact +on user configuration. For a user, adjusting to interface changes is +rarely rewarding, which is why any such change must be clearly +communicated in advance through deprecation warnings and documentation. + +Renaming of variables related to service, home, or system configuration +must be communicated for at least six months before removal using the +@code{(guix deprecation)} mechanisms. For example, renaming of +@code{murmur-configuration} to @code{mumble-server-configuration} was +communicated through a series of definitions like this one: + +@findex define-deprecated/public-alias +@lisp +(define-deprecated/public-alias + murmur-configuration + mumble-server-configuration) +@end lisp + +Procedures slated for removal may be defined like this: + +@findex define-deprecated +@lisp +(define-deprecated (elogind-service #:key (config (elogind-configuration))) + elogind-service-type + (service elogind-service-type config)) +@end lisp + +Record fields, notably fields of service configuration records, must +follow a similar deprecation period. This is usually achieved through +@i{ad hoc} means though. For example, the @code{hosts-file} field of +@code{operating-system} was deprecated by adding a @code{sanitized} +property that would emit a warning: + +@lisp +(define-record-type* + ;; @dots{} + (hosts-file %operating-system-hosts-file ;deprecated + (default #f) + (sanitize warn-hosts-file-field-deprecation))) + +(define-deprecated (operating-system-hosts-file os) + hosts-service-type + (%operating-system-hosts-file os)) +@end lisp + +When deprecating interfaces in @code{operating-system}, +@code{home-environment}, @code{(gnu services)}, or any popular service, +the deprecation must come with an entry in @code{etc/news.scm}. + +@cindex deprecation of programming interfaces +@item Core interfaces +Core programming interfaces, in particular the @code{(guix ...)} +modules, may be relied on by a variety of external tools and channels. +Any incompatible change must be formally deprecated with +@code{define-deprecated}, as shown above, for @b{at least one year} +before removal. The manual must clearly document the new interface and, +except in obvious cases, explain how to migrate from the old one. + +As an example, the @code{build-expression->derivation} procedure was +superseded by @code{gexp->derivation} and remained available as a +deprecated symbol: + +@lisp +(define-deprecated (build-expression->derivation store name exp + #:key @dots{}) + gexp->derivation + @dots{}) +@end lisp + +Sometimes bindings are moved from one module to another. In those +cases, bindings must be reexported from the original module for at least +one year. +@end table + +This section does not cover all possible situations but hopefully allows +users to know what to expect and developers to stick to its spirit. +Please email @email{guix-devel@@gnu.org} for any questions. + @cindex documentation @node Writing Documentation @section Writing Documentation base-commit: 637ca78f513fac15284403c0d3af64492ea832a1 -- 2.46.0 From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 11 06:12:08 2024 Received: (at 72840) by debbugs.gnu.org; 11 Sep 2024 10:12:08 +0000 Received: from localhost ([127.0.0.1]:37829 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1soKKV-0000Xi-U9 for submit@debbugs.gnu.org; Wed, 11 Sep 2024 06:12:08 -0400 Received: from eggs.gnu.org ([209.51.188.92]:34624) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1soKKV-0000XB-2R for 72840@debbugs.gnu.org; Wed, 11 Sep 2024 06:12:07 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1soKKJ-0000sf-19; Wed, 11 Sep 2024 06:11:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=dIaKeiFrgKOC3uwHOXcGUCm9K0sznq03WF8JpC28VCQ=; b=EF1hZWPGTGs1FAUeEFcJ Ytw40nUkG+IoEE+lcwBUxOWF6/4KLpOuZaCktuuE0awUnuIvNUSkUnBDeHfphPubcGrrRotnl5IZF Rol+Fd8KaeQxEOdsvCL3cQ0bHNKj2JxVGyFUrd8kLSDKJkQgrRqqi3AjRMadgvqj+fOiWa7V9k49j 3AuPN0lNyrFtUeZfeFvTO5xi2XJde75hM8euY6VgyGGlZ005fsHLsfnlTxlf+mcGyBKFC0dZJKzXO AfKf0VFGKD6JXA3TsU/t24dXBX/XfW8fBOUqtju9/5sxs3HCADDF7oJi7R9g4ikzNtaBkOQreVWCz m+DHTaMn7J71UQ==; From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Maxim Cournoyer Subject: Re: bug#72840: [PATCH RFC] DRAFT doc: Add =?utf-8?Q?=E2=80=9CDepr?= =?utf-8?Q?ecation_Policy=E2=80=9D?= section. In-Reply-To: <8734m63c4f.fsf@gmail.com> (Maxim Cournoyer's message of "Wed, 11 Sep 2024 16:04:00 +0900") References: <87frqd6bcu.fsf_-_@gnu.org> <53d897cec60ae13a22de486ba37604ab99e65fe8.1725571691.git.ludo@gnu.org> <8734m63c4f.fsf@gmail.com> Date: Wed, 11 Sep 2024 12:11:53 +0200 Message-ID: <8734m67b4m.fsf_-_@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 72840 Cc: Florian Pelz , 72840@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hello, Maxim Cournoyer skribis: > Thanks for taking the time to write this down. It'll be useful to many > I'm sure, including myself. > > Apart from the small things I've spotted above, it looks like a pretty > good starting ground for a deprecation policy. Coolio. I=E2=80=99ve sent v3 fixing the typos you reported. Let=E2=80=99s wait for another week or so to give people a chance to commen= t. > One thought I'm having right now is that it would be cool if all these > deprecation mechanism offered in the (guix deprecation) module were > fully documented in our manual, and could be referred to from the above > section/text for extra information; but this can be done in the future. Right. At least =E2=80=98deprecated-package=E2=80=99, =E2=80=98define-depr= ecated=E2=80=99, etc. will now have an index entry. Thanks for taking the time to comment! Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 11 14:32:46 2024 Received: (at 72840) by debbugs.gnu.org; 11 Sep 2024 18:32:46 +0000 Received: from localhost ([127.0.0.1]:39552 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1soS90-0001Uo-2n for submit@debbugs.gnu.org; Wed, 11 Sep 2024 14:32:46 -0400 Received: from smtp.domeneshop.no ([194.63.252.55]:45271) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1soS8w-0001UZ-F8 for 72840@debbugs.gnu.org; Wed, 11 Sep 2024 14:32:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xn--no-cja.eu; s=ds202402; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Subject:To:From:From:Sender:Reply-To:Subject: Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=/Jxy2ZKkgKWnoSGfNdkdpzT1aDKTkxFSYdv6R26FY/E=; b=jRMsVrUiLn6qm5n3yGqeuztn/M C7y843iIgR0bvorg5JqEAB8rQ/gBKGisthPfDuYm+rujs8tlYeG3mEoCYGD28btUNUCyT4ex6e0+V 7PQweWxtIMgBby4zy+Fu8OY9Tle9zswCrh0YIYmseLKFSZBHQgtIN+xLSdZIpA239LWctef5F5ywk L3o8IoE73UJr7raBrE1mPIe2RoGAVFwhMdwbuwgymgmMjTYatGD5rBOG5rrnLOu8v7VDgO9aheFiR P72PKmHbPpB7BG8HEm0zeDg4crnWMIsLO2jnZ73rUHhVIalF9Jnko+RTAyBYC+blXG92N27cIRea4 s3+7jw6w==; Received: from [2a01:e0a:990:a960:b62e:99ff:fe08:7e05] (port=33638 helo=navi) by smtp.domeneshop.no with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1soS6c-00ATok-Tn for 72840@debbugs.gnu.org; Wed, 11 Sep 2024 20:30:19 +0200 From: =?utf-8?Q?No=C3=A9_Lopez?= To: 72840@debbugs.gnu.org Subject: [PATCH RFC] DRAFT doc: Add =?utf-8?Q?=E2=80=9CDeprecation__Policy?= =?utf-8?Q?=E2=80=9D?= section. Date: Wed, 11 Sep 2024 20:30:17 +0200 Message-ID: <87mskexcue.fsf@> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Thanks for writing this, A few things come to mind: – How do we remember to delete something after one year of deprecation? Should the deprecation date be noted with the deprecation to easily see? Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 0.0 RCVD_IN_MSPIKE_H4 RBL: Very Good reputation (+4) [194.63.252.55 listed in wl.mailspike.net] 1.2 INVALID_MSGID Message-Id is not valid, according to RFC 2822 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders -0.0 T_SCC_BODY_TEXT_LINE No description available. X-Debbugs-Envelope-To: 72840 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) Thanks for writing this, A few things come to mind: =E2=80=93 How do we remember to delete something after one year of deprecat= ion? Should the deprecation date be noted with the deprecation to easily see? =E2=80=93 There is no policy for updating packages through major versions, = IMO this should be the same as deleting and the previous version should be kept for a while, at least for the time for dependencies to update upstream. >+If the package being removed is a ``leaf'' (no other packages depend on >+it), it may be removed after a @b{one-month review period} of the patch >+removing it (this applies even when the removal has additional >+motivations such as security problems affecting the package). =E2=80=93 Why do =C2=AB=C2=A0leaves=C2=A0=C2=BB get removed at all? The dep= endents could be users that installed it in their profiles or manifests, one month seems very low. Overall it makes sense so thanks again for documenting this, No=C3=A9 PS: RFCs don=E2=80=99t get announced to guix-devel? I only found out about = this from mastodon. From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 11 15:49:43 2024 Received: (at 72840) by debbugs.gnu.org; 11 Sep 2024 19:49:44 +0000 Received: from localhost ([127.0.0.1]:39617 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1soTLT-0005QB-Hv for submit@debbugs.gnu.org; Wed, 11 Sep 2024 15:49:43 -0400 Received: from fout1-smtp.messagingengine.com ([103.168.172.144]:45079) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1soTLR-0005Pw-4v for 72840@debbugs.gnu.org; Wed, 11 Sep 2024 15:49:42 -0400 Received: from phl-compute-10.internal (phl-compute-10.phl.internal [10.202.2.50]) by mailfout.phl.internal (Postfix) with ESMTP id CC9141380231; Wed, 11 Sep 2024 15:49:28 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-10.internal (MEProxy); Wed, 11 Sep 2024 15:49:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.net; h= cc:content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:message-id:mime-version:reply-to:subject :subject:to:to; s=fm1; t=1726084168; x=1726170568; bh=dU+tsjE6pg hl72f984+gPCWhC6OkXGcYsHz5CzaLREE=; b=TtJXHtVKkDOGTCRJM/wDkH0+7N XG1Z5apj0CiD7wFzBwlGXgYmAyxDhvyCX2fIjYOzI2rGVqOLoXcehGzyoieUmgQr 1WpAaukEI8Xt5MotrJuRtOzT48jlfR7fMQBif9LSilH1Gw0J20lqyJi6So1vvEI0 o+9VDOAiivhW1+Z0uq2g3g1iOiV63fzB+gL9xRBP2vXIJ7e9xz8JUhivjnBe8iO7 Eu/yhdEuY1yKP95SwcU17cQjRD0SMQuQ89zX0FiPP57XOT/7DIRk+BNOJbIUQwcr A2oAzNcMjZHOfV+lxUWtAKxBgwdgUDaBwr/ghZ5KVHoeG9EB4dPnwnkiQfAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:message-id:mime-version:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1726084168; x=1726170568; bh=dU+tsjE6pghl72f984+gPCWhC6Ok XGcYsHz5CzaLREE=; b=I2j8bic1JDFiCWhbcZYbKywEPXJlXCv1tzpV3/wlTXwM HtxfONpdrJIHHoo79ptFube26g9SDekNxhrUV5ElAotgNvJzfqbWwmTMEZgFe8+R 0mqBx5h+6hf2VxabyqFfyE4hDf2VtccDxm87HYUYnNaphohoiX42BinPATvAMQlx BMEBrS0ykPrpyV1vA+3ieIeRLaaTHzJGJn7hew1Sw+GuQKW8Wbo4avQoqrhDwhp5 kSIh9IXc5Htc5MTO76705n1k17Q+hwW0nSy2nzPiyOZKeVZAjqWhMCRXCWx6T4Tj w+LJs+D3lfVWLYAuJnHpgJ08xRt1t9ByVtlpYjI64g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudejuddgudegtdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecunecujfgurhephffvuf ffkfggtgfgsehtqhertddttdejnecuhfhrohhmpefmohhnrhgrugcujfhinhhsvghnuceo khhonhhrrggurdhhihhnshgvnhesfhgrshhtmhgrihhlrdhnvghtqeenucggtffrrghtth gvrhhnpeeljefhkeetjeelteelhefghedvgfeiieeileelueelieehhfeikeefteeifedt tdenucffohhmrghinhepghhuihigrdhinhhfohenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpehkohhnrhgrugdrhhhinhhsvghnsehfrghsthhm rghilhdrnhgvthdpnhgspghrtghpthhtohepvddpmhhouggvpehsmhhtphhouhhtpdhrtg hpthhtohepsggttgeskhhhihhnshgvnhdrfhgrshhtmhgrihhlrdhnvghtpdhrtghpthht ohepjedvkeegtdesuggvsggsuhhgshdrghhnuhdrohhrgh X-ME-Proxy: Feedback-ID: i184641e2:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 11 Sep 2024 15:49:27 -0400 (EDT) From: Konrad Hinsen To: 72840@debbugs.gnu.org Subject: Deprecation policy Date: Wed, 11 Sep 2024 21:49:26 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 72840 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Hi everyone, It's good to have an explicit deprecation policy, thanks for writing this! Overall it looks good. I share No=C3=A9's concerns about breaking changes in packages. If removing a package is subject to the deprecation policy, then updating a package to an incompatible version should be handled the same way. But it is of course much more difficult to detect, for the packager and even more so for the Guix maintainers. There's also a use case missing in the list in the beginning: Guix as a dependency of some other software, which in the worst case is no longer maintained. Users of such software may not even be aware of depending on Guix, and thus not follow Guix news at all. The number of such programs is probably close to zero right now, but I bet it won't remain zero. Every piece of software becomes someone else's dependency one day, at the latest during the next metasystem transition (see the last part of my talk in Montpellier last year (https://hpc.guix.info/events/2023/workshop/program/#caring-for-your-enviro= nment-s-) This is certainly not an urgent problem, but an interesting one, so worth thinking about. Finally, I wonder about the practicalities. Who will watch out for potential violations of this policy, and how? It doesn't look like an easy task. In particular detecting "user-visible incompatible changes". Cheers, Konrad. From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 11 20:41:41 2024 Received: (at 72840) by debbugs.gnu.org; 12 Sep 2024 00:41:41 +0000 Received: from localhost ([127.0.0.1]:39765 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1soXu1-0003iW-AC for submit@debbugs.gnu.org; Wed, 11 Sep 2024 20:41:41 -0400 Received: from mail-pg1-f178.google.com ([209.85.215.178]:44113) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1soXtz-0003iJ-7w for 72840@debbugs.gnu.org; Wed, 11 Sep 2024 20:41:39 -0400 Received: by mail-pg1-f178.google.com with SMTP id 41be03b00d2f7-7cd8803fe0aso316751a12.0 for <72840@debbugs.gnu.org>; Wed, 11 Sep 2024 17:41:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726101626; x=1726706426; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=8uBkRyJneTW61d81wJp/IuP5f/TWZphKiEUyxwk/iNs=; b=m5g1lhaGYbjbLA4+Xpn4gzEPqJGboAHl4xPU442v53NOENKZxJwINrEfNvDHw7zs5h OPOB9U3u8QJ8iuMeX1HHO65bSGvCSUnUEb7bLxIISZ5vaBBoL0hbj7rC/3ogBdKDH0fH BsZ8YVWf03p7tN3uwplwROpS/PjXI/oo+/2LH0ploLePrC/S+QJq3JT5x7vVnxNwJJUK WgMcgXTH0tgRPnFxOD7KCpcaNiKto3Wo7Lt0gynhWbkZo4fQ6MXzHy/PFCdFhwnB146T tzJGhxmdtAKPDWE8OF27/R4h2B0BqoBJE1/n20So9wRKl8OXXPjYKt0vBgPIkJHEF+on 95tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726101626; x=1726706426; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=8uBkRyJneTW61d81wJp/IuP5f/TWZphKiEUyxwk/iNs=; b=nIapAhqLs3ftmBeslYWISOgwELzVtY/wHdnb68fFSghU5nDrDth2KlzfD3H73krCw/ 9aItZW6rps/mC+WJxHHLzws2Yd2h8DSkVVFSRNtqSaJWaaKbiqEWD1G5R3l0w3CCRemw ZqSaOgJ4YQ2RA+0rbIG9wKNOwImPepiNLEEMcrAqWSZHTUG9n53cR4oCYlPydSj72otI daC+4YqTrIM/YK2mnTB9ZM8R5jP9YRv3bZHDTm9AtBhc410Pv/aQ+duSKE3OwBg3uKMP bum1lBzzaWmLbQpSgRzrzqjmjGPMUziU2q92qe04VRjva6eD/k9weFeej2pzaj0iik+G xvYg== X-Gm-Message-State: AOJu0Yw+pd/+52blAmH9VyTvhtkJ9ExRYlKbvKPu6d7gwws/c2ynUgNt v4Z9tmyJxGsNEOPdQmRM83i1dd34QNpS0CwaGl+WE4hKHpthlYxuOOiTqRkD X-Google-Smtp-Source: AGHT+IH0qQDKYsL4fcCincPNxHWkdWVCWsGnfTJ3ck3y1Bsc8UIfeGjw3/A+5SR/cdDRQo80kOFX9g== X-Received: by 2002:a05:6a20:e687:b0:1cf:32d1:48f with SMTP id adf61e73a8af0-1cf761f9851mr1412046637.36.1726101626286; Wed, 11 Sep 2024 17:40:26 -0700 (PDT) Received: from hurd ([2405:6586:be0:0:c8ff:1707:9b9:af89]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-71908fe2657sm3536583b3a.63.2024.09.11.17.40.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Sep 2024 17:40:25 -0700 (PDT) From: Maxim Cournoyer To: Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: [bug#72840] [PATCH RFC v3] doc: Add =?utf-8?Q?=E2=80=9CDeprec?= =?utf-8?Q?ation_Policy=E2=80=9D?= section. In-Reply-To: <902c544b5298617c2ed45af8d672130bc9b1a2e3.1726049102.git.ludo@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22's?= message of "Wed, 11 Sep 2024 12:11:22 +0200") References: <8734m63c4f.fsf@gmail.com> <902c544b5298617c2ed45af8d672130bc9b1a2e3.1726049102.git.ludo@gnu.org> Date: Thu, 12 Sep 2024 09:40:23 +0900 Message-ID: <87o74tyaa0.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 72840 Cc: Florian Pelz , 72840@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi, Ludovic Court=C3=A8s writes: > * doc/contributing.texi (Deprecation Policy): New node. > (Commit Access): Link to =E2=80=98package-removal-policy=E2=80=99. > > Change-Id: I5d095559920a3d9b791b5d919aab4e2f2a0c2dee Reviewed-by: Maxim Cournoyer --=20 Thanks, Maxim From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 12 11:41:26 2024 Received: (at 72840) by debbugs.gnu.org; 12 Sep 2024 15:41:26 +0000 Received: from localhost ([127.0.0.1]:41704 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1solwj-0000lD-Tj for submit@debbugs.gnu.org; Thu, 12 Sep 2024 11:41:26 -0400 Received: from mail-ot1-f46.google.com ([209.85.210.46]:45222) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1solwh-0000kv-A1 for 72840@debbugs.gnu.org; Thu, 12 Sep 2024 11:41:24 -0400 Received: by mail-ot1-f46.google.com with SMTP id 46e09a7af769-710daaadd9bso617941a34.2 for <72840@debbugs.gnu.org>; Thu, 12 Sep 2024 08:41:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=greghogan-com.20230601.gappssmtp.com; s=20230601; t=1726155609; x=1726760409; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=hsadmXojDYNWrpfGmt8VJ60w7qSdZPpB5MuWFgsZO7w=; b=qMRvdEuJySqLulVPkIldgaxxBrObpLqEVX2B6kJivveLOOxATvU7n3qidUzocAaeR4 QNLXMaY+C/VqQwVqYj59vLXomK45Ux6H8F2cQsGxNh7qVvgsO7ssHszFFAinpoFPV9tb RJFapkcXgO99Umo0BD4xc6KQIHdavEn2itPUXGWHD8RGDPOK7E4PsCDIr8YG//ENAnyp zh43XoHaFj/rivDYtGVt7G9Dyu0l1lqJigehYsUkH2gtPIq0+HgNVcJmY4OOLXcxXZqz tuRb3McREhRyR9Dsx+UHgzWxrCmmi7eGR695/7nKNIDsI4apC0nKNd+x7fybK5bVLOjD qxWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726155609; x=1726760409; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=hsadmXojDYNWrpfGmt8VJ60w7qSdZPpB5MuWFgsZO7w=; b=NQBipKR1SPTIZiCdLakIDBSrkRTOsNAjg/1vYaftoU+5WkhhwtLEehPcnbH8yEFlnM EP1100mKSYWS9iGhjz6padvmy2X5MID36l5S1HYVhHQFFuX1QHTpMrBijimaGUrA+pw5 QlL0KnxmTCY8YRBa2cSy+j8UbhnH/4D4KVOQmeXsxBNZGRh59O7AfTqnbCLUoLZRGDyi 2Fl4H3AolqMTZKHFHt7H9aj1gDwE+SUrIKYjL4infMitbp0W7es5+tg1Q6sQ2h0+RHlR dlaJAm3soQnYB2hghpRG9IaMhvasxmAtVa29Jc2kjq511lZmu3/Lms256qK6TH5xyFyz yfNg== X-Gm-Message-State: AOJu0YwPublng6LtGdNvvRorPCUXT2Y9kEUpJgRcupVOUKBJKZhdNscq oPOteosYEwo7mBv/CyX4E8X1ii2aldzCMP0C3rMDP9Mcfm28Ezj58HSUMCvEjXnoC9qbQqm8A3w bNywfjfVs3KNZH5cnJ5VUEdPM+TEIlWnNkTpdJQ== X-Google-Smtp-Source: AGHT+IGi0HU5ZtqXts8HFYXAX2+1pBZ+6u91YISdE9c8ERHUIce6qOnHF1Ym02sfxxv3QQ31wAX4jsma7CDXbsp0J3o= X-Received: by 2002:a05:6830:2802:b0:70a:98d8:34a with SMTP id 46e09a7af769-7110946185cmr3690586a34.1.1726155609421; Thu, 12 Sep 2024 08:40:09 -0700 (PDT) MIME-Version: 1.0 References: <80f8b603ecd73cb9f46b1ea43797e143f16d2f17.1724785788.git.ludo@gnu.org> <66e1e26e.050a0220.2c8e9.9533SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: <66e1e26e.050a0220.2c8e9.9533SMTPIN_ADDED_BROKEN@mx.google.com> From: Greg Hogan Date: Thu, 12 Sep 2024 11:39:58 -0400 Message-ID: Subject: =?UTF-8?B?UmU6IFtidWcjNzI4NDBdIFtQQVRDSCBSRkNdIERSQUZUIGRvYzogQWRkIOKAnERlcHJlYw==?= =?UTF-8?B?YXRpb24gUG9saWN54oCdIHNlY3Rpb24u?= To: =?UTF-8?Q?No=C3=A9_Lopez?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 72840 Cc: 72840@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Wed, Sep 11, 2024 at 2:33=E2=80=AFPM No=C3=A9 Lopez via Guix-patches via wrote: > > =E2=80=93 There is no policy for updating packages through major versions= , IMO > this should be the same as deleting and the previous version should be > kept for a while, at least for the time for dependencies to update > upstream. Internal package conflicts result in broken builds. External dependent projects can simply remain on their current Guix commit and delay upgrading until compatible with the updated API. > >+If the package being removed is a ``leaf'' (no other packages depend on > >+it), it may be removed after a @b{one-month review period} of the patch > >+removing it (this applies even when the removal has additional > >+motivations such as security problems affecting the package). > > =E2=80=93 Why do =C2=AB leaves =C2=BB get removed at all? The dependents = could be > users that installed it in their profiles or manifests, one month > seems very low. If a package has failed to build for and not been updated in a long time then who would be using it? The package source will be available in the git history in case someone would like to resurrect it at a later time. Greg From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 13 13:24:22 2024 Received: (at 72840) by debbugs.gnu.org; 13 Sep 2024 17:24:22 +0000 Received: from localhost ([127.0.0.1]:44202 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1spA1u-0004lz-3y for submit@debbugs.gnu.org; Fri, 13 Sep 2024 13:24:22 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44112) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1spA1s-0004lc-HC for 72840@debbugs.gnu.org; Fri, 13 Sep 2024 13:24:21 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1spA1Z-0005IY-NJ; Fri, 13 Sep 2024 13:24:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=6I3L0qeeuQ6NSCgCzc127mo2h+1TG+sHQ0eoM7MvP9g=; b=AjLUvB0vKdEChJeFWPo6 627xzwMdGX8UZn8fTpTF4ds7Gcn0OFIRiAuivFlYtLvoxDrsVZogafREFmVaXRRMUO23fsQdkGe3o AG1JL/kmONqvHd2p+y2BeP4ODPAnUXDltgEA7p2iKarddWPyaUEsqfU3vrdMPZ+b2x9xAezKEddPv vTU67EyQeRakeDWeK80zmsI7TkhLvRDjvDsoNLjbLdhBVwJxr3hT2JZWIijytkwRzz646Iir8TZG0 iMmmpyrXKgTOooLHMXPiJQCcnmg8zI+fyZhW6O4Ji64sRXXS0iN3Y6cxxPcihGzZtPa353BQWMZ4D TPeqycrQCK1rqQ==; From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: =?utf-8?Q?No=C3=A9?= Lopez Subject: Re: bug#72840: [PATCH RFC] DRAFT doc: Add =?utf-8?Q?=E2=80=9CDepr?= =?utf-8?Q?ecation_Policy=E2=80=9D?= section. In-Reply-To: <87mskexcue.fsf@> (=?utf-8?Q?=22No=C3=A9?= Lopez"'s message of "Wed, 11 Sep 2024 20:30:17 +0200") References: <80f8b603ecd73cb9f46b1ea43797e143f16d2f17.1724785788.git.ludo@gnu.org> Date: Fri, 13 Sep 2024 19:23:38 +0200 Message-ID: <87plp7fox1.fsf_-_@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 72840 Cc: 72840@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hi, No=C3=A9 Lopez skribis: > =E2=80=93 How do we remember to delete something after one year of deprec= ation? > Should the deprecation date be noted with the deprecation to easily see? What I and probably others did in the past was to =E2=80=98git annotate=E2= =80=99 files to see when a deprecation was added and whether it could =E2=80=9Creasonabl= y=E2=80=9D be deleted (though we had no formal rule). We can always do that, but adding a comment as you suggest is even better. > =E2=80=93 There is no policy for updating packages through major versions= , IMO > this should be the same as deleting and the previous version should be > kept for a while, at least for the time for dependencies to update > upstream. Interesting point. For many packages, a major version upgrade goes unnoticed and a deprecation period of the previous major series wouldn=E2=80=99t be useful. But for some (interpreters and compilers, =E2=80=9Cbig=E2=80=9D libraries/f= rameworks like Qt or GTK, and perhaps a few applications), there=E2=80=99s definitely going to be a need for both the old and new major series for some time. I=E2=80=99m not sure how to codify that though. Maybe the best we can do i= s to state that different situations exist and that =E2=80=9Csome=E2=80=9D major= package upgrades may require a deprecation period for the older major series? >>+If the package being removed is a ``leaf'' (no other packages depend on >>+it), it may be removed after a @b{one-month review period} of the patch >>+removing it (this applies even when the removal has additional >>+motivations such as security problems affecting the package). > > =E2=80=93 Why do =C2=AB=C2=A0leaves=C2=A0=C2=BB get removed at all? The d= ependents could be > users that installed it in their profiles or manifests, one month > seems very low. This paragraph talks about packages that are unmaintained or EOL upstream. What it says is that such packages could be removed, at the soonest, one month after they have become umaintained/EOL upstream. The reasons we=E2=80=99d want to remove such packages is to clean up the pa= ckage collection (every package adds to the overall maintenance cost) and to avoid steering users towards unmaintained and possibly insecure software. Is one-month after upstream too short? I=E2=80=99d say =E2=80=9Cno=E2=80= =9D, but we can discuss. Two things to keep in mind in this discussion: (1) the policy does not state an obligation to remove those packages, and (2) packages remain available =E2=80=9Cforever=E2=80=9D for those who need it via =E2=80=98time= -machine=E2=80=99. > PS: RFCs don=E2=80=99t get announced to guix-devel? I only found out abou= t this > from mastodon. My bad! I thought I had Cc=E2=80=99d guix-devel, but apparently not? (Did t= he =E2=80=98send-email=E2=80=99 hook override the =E2=80=98Cc:=E2=80=99 or =E2= =80=98X-Debbugs-Cc:=E2=80=99 header I had put?) Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 13 13:32:56 2024 Received: (at 72840) by debbugs.gnu.org; 13 Sep 2024 17:32:56 +0000 Received: from localhost ([127.0.0.1]:44214 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1spAAB-0005LH-W3 for submit@debbugs.gnu.org; Fri, 13 Sep 2024 13:32:56 -0400 Received: from eggs.gnu.org ([209.51.188.92]:40372) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1spAA9-0005Ky-Oa for 72840@debbugs.gnu.org; Fri, 13 Sep 2024 13:32:54 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1spA9u-0006ZU-Hr; Fri, 13 Sep 2024 13:32:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=iBI+psYGcq170vXzgMNAOSCAq8IPMXedIpqZKTDLvVI=; b=QHqfjBDD5hrM8t46YCAN 2UAgbZxe/O84rwsKRsbzl0MHKpjfPPirVH4X0ga1bq65apn27TAsP2rfFJSadDN+0oSgDYwmTvDEE DNbwz1trebVhbTKvmahiKK3lN343XPM2t8TeTn/m7L3jWMyPCWbPidGlA1kRyhlwFaqe5kXHAkZES 3L2MG5/WBPfRjpZqOe009aJXMmeYEzlUQuOtzgFGfWa+wlqJQ19HEifhT/a2efvc4ZpC1720MSZ/Z VZU8po3YZPgAgUIOzLmAqzxTJjS0bvBcPJYnv5F92qPY2LFB9io5lIVfnDvHw26XeeBVHLGIFksfC qVysdmU0Rka2CQ==; From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Konrad Hinsen Subject: Re: bug#72840: [PATCH RFC] DRAFT doc: Add =?utf-8?Q?=E2=80=9CDepr?= =?utf-8?Q?ecation_Policy=E2=80=9D?= section. In-Reply-To: (Konrad Hinsen's message of "Wed, 11 Sep 2024 21:49:26 +0200") References: <80f8b603ecd73cb9f46b1ea43797e143f16d2f17.1724785788.git.ludo@gnu.org> Date: Fri, 13 Sep 2024 19:32:34 +0200 Message-ID: <87frq3foi5.fsf_-_@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 72840 Cc: 72840@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hi Konrad, Konrad Hinsen skribis: > Overall it looks good. I share No=C3=A9's concerns about breaking changes= in > packages. If removing a package is subject to the deprecation policy, > then updating a package to an incompatible version should be handled the > same way. But it is of course much more difficult to detect, for the > packager and even more so for the Guix maintainers. Right; I agree this should be mentioned. > There's also a use case missing in the list in the beginning: Guix as a > dependency of some other software, which in the worst case is no longer > maintained. Users of such software may not even be aware of depending on > Guix, and thus not follow Guix news at all. The number of such programs > is probably close to zero right now, but I bet it won't remain > zero. Every piece of software becomes someone else's dependency one day, > at the latest during the next metasystem transition (see the last part > of my talk in Montpellier last year > (https://hpc.guix.info/events/2023/workshop/program/#caring-for-your-envi= ronment-s-) I think this is covered by the last point: +development of external tools that use programming interfaces such as +the @code{(guix ...)} modules. There are quite a few actually: the CI/QA tools, package browsers like hpcguix-web, the Guix Workflow Language, Guix-Jupyter, rde, etc. [...] > Finally, I wonder about the practicalities. Who will watch out for > potential violations of this policy, and how? It doesn't look like an > easy task. In particular detecting "user-visible incompatible changes". As drafted here, there=E2=80=99s no enforcement and nobody having the duty = of looking for violations and taking action. I view it as binding though. If a user complains that their favorite package as been removed in violation of the policy, then we as a community should review the claim and reinstate the package, unless it violates =E2=80=9Chigher principles=E2=80=9D in the project (that would nee= d to be more clearly defined too, but one of them would be: we mistakenly packaged non-free software or material that we=E2=80=99re not allowed to distribute = for some reason). I=E2=80=99ll think about ways to word it, but I=E2=80=99m happy to take oth= er people=E2=80=99s suggestions. Thanks for your feedback, Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 13 13:38:21 2024 Received: (at 72840) by debbugs.gnu.org; 13 Sep 2024 17:38:21 +0000 Received: from localhost ([127.0.0.1]:44219 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1spAFQ-0005e3-T1 for submit@debbugs.gnu.org; Fri, 13 Sep 2024 13:38:21 -0400 Received: from eggs.gnu.org ([209.51.188.92]:54092) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1spAFP-0005df-0g; Fri, 13 Sep 2024 13:38:19 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1spAF9-0007Cu-1R; Fri, 13 Sep 2024 13:38:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=KXo8bNzZRDamsmpVQ1ohWvTrg5ck1HjOHaIGm9OFIzU=; b=gRUulp78Ta2KuNSu6md0 Gvijk854hs0bYc76G0I+4jc0NjA057XUk2Ko9+B4nxm6OVJrIB3y1TpCXeAGm5LZT8Kt5PdlzOWov KP3wm+VON4/Mr9DHmhcFs0fE57qgCMXJBSi29kYP0OsRDCfOKy5gpbM7/IBu5316OkccyrrmmNaPw rnm1xIGTKPDnJRfPgmVP87kfcctMhx8vVltjxpqYI2ng81DkBaYL/Z7cRedqIPqIuxbqI8UtmYfIr uVwpli6A6l1f/HzBq6yH57gU+xujX8XG9t64B7Mg0P4oOf5RU3JOZRvniqJKj0QaQY7Uq58xKA2Dm qnsoCiKxIXzvVQ==; From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Simon Tournier Subject: Re: bug#72840: [PATCH RFC] DRAFT doc: Add =?utf-8?Q?=E2=80=9CDepr?= =?utf-8?Q?ecation_Policy=E2=80=9D?= section. In-Reply-To: <874j6jv73l.fsf@gmail.com> (Simon Tournier's message of "Fri, 13 Sep 2024 18:41:50 +0200") References: <80f8b603ecd73cb9f46b1ea43797e143f16d2f17.1724785788.git.ludo@gnu.org> <874j6jv73l.fsf@gmail.com> Date: Fri, 13 Sep 2024 19:38:00 +0200 Message-ID: <87zfobe9on.fsf_-_@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 72840 Cc: Matthew Trzcinski , 72839@debbugs.gnu.org, Maxim Cournoyer , 72840@debbugs.gnu.org, Florian Pelz X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hi Simon, Simon Tournier skribis: > =E2=80=A6Well, I=E2=80=99m just aware of this only now =E2=80=93 thanks m= astodon! Why only > guix-patches and not guix-devel? Or do I also missed it? My bad; as I told No=C3=A9, I thought I did advertise it on guix-devel, but apparently not. > BTW, that=E2=80=99s the typical subject for a RFC [1], IMHO. :-) Sure. > Why not try to push for crossing the final line of the RFC process first > and make this as the first? ;-) > > 1: https://issues.guix.gnu.org/66844 That=E2=80=99s a question for you no? I like to push things past the finish line in a timely fashion, so I wouldn=E2=80=99t want this to be blocked by the RFC process definition proc= ess (the process of defining the process=E2=80=A6). I already commented on the proposed RFC process. I=E2=80=99m happy to furt= her contribute or even take the lead eventually when time permits, if you=E2=80= =99d like to pass it on. It=E2=80=99s clearly the missing piece here. We=E2=80= =99ll get there! Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 13 14:13:07 2024 Received: (at 72840) by debbugs.gnu.org; 13 Sep 2024 18:13:07 +0000 Received: from localhost ([127.0.0.1]:44238 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1spAn4-0007fj-Pd for submit@debbugs.gnu.org; Fri, 13 Sep 2024 14:13:07 -0400 Received: from mail-qv1-f50.google.com ([209.85.219.50]:56466) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1spAn1-0007ez-Hl; Fri, 13 Sep 2024 14:13:04 -0400 Received: by mail-qv1-f50.google.com with SMTP id 6a1803df08f44-6c354091616so18421786d6.0; Fri, 13 Sep 2024 11:12:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726251108; x=1726855908; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=E93sgKggVOBaz2G33x6hPfW1wL/+8d64ikYlal04Y8Y=; b=XzLHaO19i7bXq1iNmDQS2OFxrXOMSe3CbbLb/oNDtVVC6PYhFbJW50K/f6gUNkfWh9 YtZadKEqW8uFrB1oV4d98eCN3PdPc6OiporJrsHfjxWVffJM4OF08cFG7/YOA4s+vzjl JcmVrxT7RKspqHfxgFtA0KBYmvcYTDTGFM1Nkgq7p5JOGez85cbe1fK4vSwQjI1R/MS9 vd5D1AL373RVIfyPCFS52zg2yOxVyV1rezBOm7zOXU+PBLMNBxotuSEk75vZ1YzfGDMm XFkmLKNV09t2PRqJuwYixYBMCKVMRNFUA80SAqyuW465TBcHbtime8M/GQ+2GrLoIgYc K3bQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726251108; x=1726855908; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=E93sgKggVOBaz2G33x6hPfW1wL/+8d64ikYlal04Y8Y=; b=rzRoXSL1n38AfQh9xk2GS/ynW/oFVajlXTCwdiL8clgogy666DoJU8N36vTHDlDcE3 5JiBJe4+jXjQgeGyY4F3q2BFNYS+OFnEWDUfGte8r3B0XekT783RCriDPtKUxwx7+gFU 7nlSpVJ0NxM7ytS+SQA3X7/G76xC4esClaUsfiVHC86PZi4BWAs09fPPfYi+BgI0d8XI e6BKQT32xew6a7oURvwLGCYxp0BNHshPgXvNCTGXp4f7YPFDwS11wsIg/MRj3iyYms2h LRZyu3KmOQA/Jp/jGyNkxZkLt0r/1+iKdU7IYq8yp5qoaYyvS47KJQKtX+Q2D2Uux00m Ax+A== X-Forwarded-Encrypted: i=1; AJvYcCVoq8M4u4l+bd9ujbUqh6OmdeMQN2d2BVvQyLkXbursidufC5kNnU19EtFG4gRq+jWou2uSpw==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yzsuw2PPKVWve8AQGN/B5+4kzIOtrucY7o2/I0wj9ufrzvT2tk9 AR/3BOpaDj8GoAvm9l0VAQXAIjWIsFaWQTyxe8lALmPiwei4hy2FOMwQMgszgJN41M6+BS1blzs lBRePp6GsiiDlphIufTU2LpLj910= X-Google-Smtp-Source: AGHT+IEQTvNR1FfoTD24Z1/A274q6UIkFcMd7w+bK2n77i5GEOOcwJLSlRHmP+a09qgaZiSNr7nSlBdXmCqDJ6sEw6I= X-Received: by 2002:a05:6214:4519:b0:6b0:75bd:7fb with SMTP id 6a1803df08f44-6c573570bedmr121281676d6.40.1726251108527; Fri, 13 Sep 2024 11:11:48 -0700 (PDT) MIME-Version: 1.0 References: <80f8b603ecd73cb9f46b1ea43797e143f16d2f17.1724785788.git.ludo@gnu.org> <874j6jv73l.fsf@gmail.com> <87zfobe9on.fsf_-_@gnu.org> In-Reply-To: <87zfobe9on.fsf_-_@gnu.org> From: Simon Tournier Date: Fri, 13 Sep 2024 20:11:35 +0200 Message-ID: Subject: =?UTF-8?B?UmU6IGJ1ZyM3Mjg0MDogW1BBVENIIFJGQ10gRFJBRlQgZG9jOiBBZGQg4oCcRGVwcmVjYQ==?= =?UTF-8?B?dGlvbiBQb2xpY3nigJ0gc2VjdGlvbi4=?= To: =?UTF-8?Q?Ludovic_Court=C3=A8s?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 72840 Cc: Matthew Trzcinski , 72839@debbugs.gnu.org, Maxim Cournoyer , 72840@debbugs.gnu.org, Florian Pelz X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi Ludo, On Fri, 13 Sept 2024 at 19:38, Ludovic Court=C3=A8s wrote: > That=E2=80=99s a question for you no? Yes and no. :-) Yes because I sent the first draft, so it's partly my duty. No because changes and especially collective practices are not only on the shoulders of one. Is the motivation, time or energy of only one person the bottleneck of a common willing? Anyway. > I already commented on the proposed RFC process. I=E2=80=99m happy to fu= rther > contribute or even take the lead eventually when time permits, if you=E2= =80=99d > like to pass it on. It=E2=80=99s clearly the missing piece here. We=E2= =80=99ll get > there! It is a good example why Co-Supporter(s) as described by the RFC process is a strong requirement. ;-) And there is none... Anyway, I will do my best for resuming. Cheers, simon From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 13 16:57:26 2024 Received: (at 72840) by debbugs.gnu.org; 13 Sep 2024 20:57:26 +0000 Received: from localhost ([127.0.0.1]:44347 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1spDM6-0000Ih-4T for submit@debbugs.gnu.org; Fri, 13 Sep 2024 16:57:26 -0400 Received: from libre.brussels ([144.76.234.112]:48726) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1spDM3-0000IJ-RS for 72840@debbugs.gnu.org; Fri, 13 Sep 2024 16:57:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=libre.brussels; s=mail; t=1726261027; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=A/TlLB67Tth5nDKUpuI3S6/WJFVarSaB9qz/Icsa5lc=; b=AAKpWOdo+y9MfXeqoa9HvEuJbvGk0GUG7qZC7m7ypxaqGPKS77qz97j+QH9xJIM2tS+Ppz 3kzUevdF1ICWFn6lTZ2p9kmxNCiIysP6C377NyPMRx3L08uRfMrmnalMIZsJF99EdgYAMp TJdCNF/cOJIuoNI7xingExnZtBw4QlA= MIME-Version: 1.0 Date: Fri, 13 Sep 2024 20:57:07 +0000 From: indieterminacy To: 72840@debbugs.gnu.org Subject: =?UTF-8?Q?=5BPATCH_RFC=5D_DRAFT_doc=3A_Add_=E2=80=9CDeprecation_?= =?UTF-8?Q?Policy=E2=80=9D_section=2E?= Message-ID: <3130f45aaef0b424689f4c91a8dde943@libre.brussels> X-Sender: indieterminacy@libre.brussels Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 72840 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) It may be that Im lacking a little experience, but Id assume that the categories outlined earlier probably require different timeframes: https://issues.guix.gnu.org/72840#0-lineno49 A year feels a little arbitrary. For example, Ive found it a little frustrating using randomly scoured Guix snippets - only to then find that at the moment of utilization that I get a WARNING without much context. Am I the only one who feels undermined and demotivated by information which hits me over the head with WARNINGS? Ive had this using elogin-service (cited before): https://issues.guix.gnu.org/72840#0-lineno155 Perhaps additionally there need to be pointers to real VCS repos, pinpointing a commit providing the migration inside a living repo/infrastructure? Such examples would be constructively showing how the change is achievable, and could be empowering through assurance and learning. And if such /Appreciations/ cannot be found in the wild and covering enough common adaptations, then perhaps a Depreciation is too soon? Heck, a REASSURANCE printed following a reconfigure would be gravy! Even better, Guix promising me a LIMERICK if I adapted off foobar within 24 hours would work. Additionally, its worth pointing out that Im slowly adapting my parsing approaches to be more commensurate with a form of modern hermeneutics. I have been intrigued by how the language inside a setup like Guix adapts over time. As such, the topic of how Guix grammars evolve would be worth documenting. Practically, this could one day result in very old discourse from out of date mailinglist or Debugs conversations being transformed into more recent grammars to solve contemporary issues or suggest precedent when evaluating a patch. Regards, Jonathan From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 14 03:14:45 2024 Received: (at 72840) by debbugs.gnu.org; 14 Sep 2024 07:14:45 +0000 Received: from localhost ([127.0.0.1]:44610 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1spMzV-0001WM-BX for submit@debbugs.gnu.org; Sat, 14 Sep 2024 03:14:45 -0400 Received: from eggs.gnu.org ([209.51.188.92]:45026) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1spMzS-0001W4-UK for 72840@debbugs.gnu.org; Sat, 14 Sep 2024 03:14:43 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1spMzB-00071W-V3; Sat, 14 Sep 2024 03:14:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=wfMF9p5mYIJ/WrSRtn117wyuRrpW0FqR8l4Gay59i/8=; b=c9cdIyVGMG7DjSyiEIWh 1+h0i+b5YclGcms/M9ibos0YNj3So47U3twRJQQLpW11gbgP00sPs4v62Ndp6uWz1Y3pOTuP6p32v ++tF7fXJQ+gzjqE67ys/RXtnKLcLZKmDBu3tQpLK1C0T2tl1oe/VnU516G14G+OX5s/QsFEvrRWZV hrWWi2tfL0B57HPfAqVqAIuojA10q8utjMXL9Ae+rUAJX5TTJmxu8NnD0PrPw1gfQJM2rAt4Sd84H EC3nnVgK6DeCmbHtm945HXnVUg45ZgeDyb2EiXH7RRbo28/25bp8RvxAAnYeVwdfv3iyfFEyW1wA0 o2I1aqiiwmj8Dg==; From: Janneke Nieuwenhuizen To: Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: [PATCH RFC] DRAFT doc: Add =?utf-8?Q?=E2=80=9CDeprecation_Pol?= =?utf-8?Q?icy=E2=80=9D?= section. In-Reply-To: <87a5gbe9eh.fsf@inria.fr> ("Ludovic =?utf-8?Q?Court=C3=A8s=22?= =?utf-8?Q?'s?= message of "Fri, 13 Sep 2024 19:44:06 +0200") Organization: AvatarAcademy.nl References: <87a5gbe9eh.fsf@inria.fr> X-Url: http://AvatarAcademy.nl Date: Sat, 14 Sep 2024 09:14:21 +0200 Message-ID: <87ed5m7lma.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 72840 Cc: guix-devel , 72840@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Ludovic Court=C3=A8s writes: Hi! > I realize I did not advertise the =E2=80=9CDeprecation Policy=E2=80=9D pr= oposal here, > which is a mistake because it=E2=80=99s relevant to all of us as develope= rs and > packagers, and it=E2=80=99s also a key element of our relation with the b= roader > user base. > > So please, consider reading the proposal and joining the discussion: > > https://issues.guix.gnu.org/72840 Thanks, looks good to me! As a side remark: It would be nice if upgrading of config.scm / home.scm could be automated. Anyway, I do have a vaguely related question. The Dezyne package comes with a `guix.scm' that uses a package description in guix/pack/dezyne.scm, which uses `%gnu-build-system-modules'. Recently, %gnu-build-system-modules was deprecated in --8<---------------cut here---------------start------------->8--- 28dbfdb38f52f5814fb4cba9c02831d2ab0dc079 build-system/gnu: Introduce =E2=80=98%gnu-build-system-modules=E2=80=99 dep= recated alias. 9e4ce281dbd92e3c52b831824ebb1f77023c960c build-systems: gnu: Export %default-gnu-imported-modules and %default-gnu-m= odules. --8<---------------cut here---------------end--------------->8--- Although the `guix.scm' has a comment like --8<---------------cut here---------------start------------->8--- ;; To use the canonical commit that has everything prebuilt: ;; ;; guix time-machine --commit=3D918b7d102c2051c3d6c6ba54c8d265affec5282c = -- shell --8<---------------cut here---------------end--------------->8--- documenting a commit that can be used for building the package and has substitutes available, usage of the commit is not enforced. After a recent `guix pull', we now get this warning --8<---------------cut here---------------start------------->8--- pack/dezyne.scm:69:20: warning: '%gnu-build-system-modules' is deprecated, = use '%default-gnu-imported-modules' instead --8<---------------cut here---------------end--------------->8--- and I'm wondering what the best moment would be to change the package description. Upgrading sooner (i.e., now) means that a future guix that has this deprecated feature removed will be able to build more hystorical releases of the package simply by doing `guix shell', so that's probably the best choice? It would mean that all developers have to upgrade now (or use the time machine). Of course, we can always(?) build hystorical release by doing $(grep -o 'guix time.*' guix.scm) but you'd have to know about that and it probably only works for the Dezyne package. Is there a better way or should something like this be advertised/recommended in the documentation? Greetings Janneke --=20 Janneke Nieuwenhuizen | GNU LilyPond https://LilyPond.org Freelance IT https://www.JoyOfSource.com | Avatar=C2=AE https://AvatarAcade= my.com From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 15 04:22:29 2024 Received: (at 72840) by debbugs.gnu.org; 15 Sep 2024 08:22:30 +0000 Received: from localhost ([127.0.0.1]:48303 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1spkWb-0003w9-HE for submit@debbugs.gnu.org; Sun, 15 Sep 2024 04:22:29 -0400 Received: from fhigh1-smtp.messagingengine.com ([103.168.172.152]:42161) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1spkWY-0003vt-Fm for 72840@debbugs.gnu.org; Sun, 15 Sep 2024 04:22:27 -0400 Received: from phl-compute-04.internal (phl-compute-04.phl.internal [10.202.2.44]) by mailfhigh.phl.internal (Postfix) with ESMTP id 8EF3D11401C8; Sun, 15 Sep 2024 04:22:08 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-04.internal (MEProxy); Sun, 15 Sep 2024 04:22:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1726388528; x=1726474928; bh=jgTBPtsSxIICeMxyFC8d0HVAZ07LLdT5IV7LQAIIQhc=; b= WNo6L3xgPXRr8aTXUfLUcfcQoBxh0SLFtvPqApfvZWrdi5LLaCSUoFGXfxA1ggRq yt18MVsEYjlzw4EJJKOH5X4Ew9NrW23ZvQ46B2td1I9aZLhUAv6oaZ1zVzGQBsxH 1knMEmw2xbhInYnxiC1QyJJ/DOtMn8YKlhM9lnSsuwyUyHfCk3VVx/LIIOEPq3os kdBQPQTK5EV45Is0sLyDhOe8moOceZGSBmi9opqlFlcGEOAUMNNkw8NFYWYruwe2 0zG54HHIAT+DD6lsdCoO5Mme3BxcGnWFBJ7cXCKBMrmVwsdMaclJX89zO/UaG5u5 VsHLDhCRcdrZLg2LQs5RJQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1726388528; x= 1726474928; bh=jgTBPtsSxIICeMxyFC8d0HVAZ07LLdT5IV7LQAIIQhc=; b=i wv/IYyZqu/4Jb1vifcmAdWLXtOwZUbb03oSIW061nXW7tnsQ8ig4i/QR9i3ZqDx3 NKaivsYeAHTLiXP/QCBBjTzwcyMtaF4noLJTht2kwPdMjlVYoszvTJXgJjriKGiz 7MkwLnX8bFmxOmBOwpB+HmGubOApPGFGVadPebWFYjAQ6fkwlO8ktB+vwAIXfa9k yMhTlz6VuW8PjmJbVFS1+RwcNPJ8PU8gz3+0gdJwo6cZKPqrUrsfWK3E4/1qVXgf aFLd4mF9TU4H71DupElimzGd3gueu1iPhFi8V7J5XU8go2y7OT7VuQfFe8cgUlGQ PODrdnePZMurrIl54qPIg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudekfedgtddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhephffvvefujghffffkgggtgfesthhqredttddtjeen ucfhrhhomhepmfhonhhrrgguucfjihhnshgvnhcuoehkohhnrhgrugdrhhhinhhsvghnse hfrghsthhmrghilhdrnhgvtheqnecuggftrfgrthhtvghrnhephfevveelveejvdehueek tdffjeetfefgteefjeefhedvieeliedufedugffhvdehnecuffhomhgrihhnpehgihhthh husgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr ohhmpehkohhnrhgrugdrhhhinhhsvghnsehfrghsthhmrghilhdrnhgvthdpnhgspghrtg hpthhtohepfedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepsggttgeskhhhihhn shgvnhdrfhgrshhtmhgrihhlrdhnvghtpdhrtghpthhtohepjedvkeegtdesuggvsggsuh hgshdrghhnuhdrohhrghdprhgtphhtthhopehluhguohesghhnuhdrohhrgh X-ME-Proxy: Feedback-ID: i184641e2:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 15 Sep 2024 04:22:07 -0400 (EDT) From: Konrad Hinsen To: Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: bug#72840: [PATCH RFC] DRAFT doc: Add =?utf-8?Q?=E2=80=9CDepr?= =?utf-8?Q?ecation_Policy=E2=80=9D?= section. In-Reply-To: <87frq3foi5.fsf_-_@gnu.org> References: <80f8b603ecd73cb9f46b1ea43797e143f16d2f17.1724785788.git.ludo@gnu.org> <87frq3foi5.fsf_-_@gnu.org> Date: Sun, 15 Sep 2024 10:22:05 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 72840 Cc: 72840@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Hi Ludo, >> There's also a use case missing in the list in the beginning: Guix as a >> dependency of some other software, which in the worst case is no longer >> ... > I think this is covered by the last point: > > +development of external tools that use programming interfaces such as > +the @code{(guix ...)} modules. Yes and no. I see external tools as two distinct use cases: - their development - their application The missing case is application. > There are quite a few actually: the CI/QA tools, package browsers like > hpcguix-web, the Guix Workflow Language, Guix-Jupyter, rde, etc. All those are add-on tools to the Guix CLI. I doubt these tools have any user who wouldn't also use the Guix CLI. Meaning that they have a good chance to learn about deprecations. I am aware of a single tool that depends on Guix but whose functionality is unrelated to Guix and could be implemented otherwise: https://github.com/khinsen/swh-checkout It's a Guile script that uses Guix as a library for accessing Software Heritage. And it's a mere proof-of-concept implementation. I don't advertise it for general use. But I do expect more such tools to appear over time, including some with more substantial dependence on Guix. > As drafted here, there=E2=80=99s no enforcement and nobody having the dut= y of > looking for violations and taking action. > > I view it as binding though. If a user complains that their favorite > package as been removed in violation of the policy, then we as a > community should review the claim and reinstate the package, unless it OK, that sounds good enough! Cheers, Konrad. From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 16 09:44:13 2024 Received: (at 72840) by debbugs.gnu.org; 16 Sep 2024 13:44:13 +0000 Received: from localhost ([127.0.0.1]:51339 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sqC1V-0000a6-B1 for submit@debbugs.gnu.org; Mon, 16 Sep 2024 09:44:13 -0400 Received: from hera.aquilenet.fr ([185.233.100.1]:48334) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sqC1U-0000Zt-5C for 72840@debbugs.gnu.org; Mon, 16 Sep 2024 09:44:12 -0400 Received: from localhost (localhost [127.0.0.1]) by hera.aquilenet.fr (Postfix) with ESMTP id 14F46F6D; Mon, 16 Sep 2024 15:43:53 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at hera.aquilenet.fr Received: from hera.aquilenet.fr ([127.0.0.1]) by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxtyiIlO47qU; Mon, 16 Sep 2024 15:43:52 +0200 (CEST) Received: from jurong (unknown [IPv6:2001:861:c4:f2f0::c64]) by hera.aquilenet.fr (Postfix) with ESMTPSA id 79510364; Mon, 16 Sep 2024 15:43:52 +0200 (CEST) Date: Mon, 16 Sep 2024 15:43:51 +0200 From: Andreas Enge To: Ludovic =?iso-8859-15?Q?Court=E8s?= Subject: Re: Input welcome on the proposed deprecation policy Message-ID: References: <87a5gbe9eh.fsf@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87a5gbe9eh.fsf@inria.fr> X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 72840 Cc: 72840@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, I think we should not only remove packages that are unmaintained upstream, but also packages that do not build. Concretely I am thinking of a number of related packages that we have in a version of 2019, and which has had releases since then. The project does not build any more, just upgrading the source is not enough, and the package definition is very complex. I have called out for help, but not received any reply. While I might be able to update the project, it feels like a waste of time, since apparently no Guix user is interested in it right now. A one-month notice period sounds appropriate to me for this. So maybe replace: Packages that their upstream developers have declared as having reached ``end of life'' or being unmaintained may be removed. by Packages that their upstream developers have declared as having reached ``end of life'' or being unmaintained, or that do not build in Guix, may be removed. This may be a bit brutal (I would normally argue that one should try an update first); but if during one month nobody steps in to carry out the update, that is telling. Andreas From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 17 08:21:42 2024 Received: (at 72840) by debbugs.gnu.org; 17 Sep 2024 12:21:42 +0000 Received: from localhost ([127.0.0.1]:54161 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sqXDB-0000tM-Rc for submit@debbugs.gnu.org; Tue, 17 Sep 2024 08:21:42 -0400 Received: from fout4-smtp.messagingengine.com ([103.168.172.147]:39491) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sqXD9-0000t6-DO for 72840@debbugs.gnu.org; Tue, 17 Sep 2024 08:21:40 -0400 Received: from phl-compute-05.internal (phl-compute-05.phl.internal [10.202.2.45]) by mailfout.phl.internal (Postfix) with ESMTP id E862D138017E; Tue, 17 Sep 2024 08:21:18 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-05.internal (MEProxy); Tue, 17 Sep 2024 08:21:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.net; h= cc:content-type:content-type:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:subject:subject:to:to; s=fm1; t=1726575678; x=1726662078; bh=eFfPv9yb9o8lUYfQxzYG6lxKgaC3IkmB TUiVKeoycpE=; b=ZSBkL7Vr0GFMExCdZy44Sjm79fkc2M41n77PMfCELj9tDAY2 PWxl1FpXmILJG+hEvcwVZnAsrINmJOfS+u9dvlPriGsMrZcIdmAyYeOgm+qnms87 kjemP/rOhSWRPQCdZ35twyXEryxlKQdkrjY26BnoWgwnz8rtSMsIIWEagp3oDh0F SzW12eFDkddcXC2MFD4cbdsxdn/Igo098rtCQ0bApGBUF7ZrblMxFSas0SPLihc2 9zfiyVOKd3MUe7mDttNXyMh3TpZ86oCVtBEC/fq5D6yoH9mx+e1cCiAjvE6fnhen rUjgVDSD6EilFAQ1Y138Qy5o7oRdNvIKHZGr9w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1726575678; x=1726662078; bh=eFfPv9yb9o8lUYfQxzYG6lxKgaC3IkmBTUi VKeoycpE=; b=OrR6IIh+LDTzmMfQfZltuH10wvnCsWSHNZVUzWHzcL3r1jLdOc8 4WJBdPdrSFSlkCPQaYQj9D9AJk3Rfte59X8JiJAVUWR1MP9bFHBIMCFi8V4feX4D PU22OgAfMhG5NuyuthikXWhiCNF7pRJkg1CGOIpRs2qN1wSiURv8+vIZRQ3/0fwm GZqMGWAt9Dd+kfR0eCmMBONJkx5NidUehKTBvnWwj3xz3EsctqQIuEfTHRixucca YyH+yesEsGsJ9giIOLATuwRpvup4HzvZSCqvaz3G0obtOJEUaqgejFTMJaptQ0m/ QbOttM9x/++J7rGxLKX7m891KfbsE2C75dA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudekjedgheduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpefhvffuff fkgggtsehttdertddttddtnecuhfhrohhmpefmohhnrhgrugcujfhinhhsvghnuceokhho nhhrrggurdhhihhnshgvnhesfhgrshhtmhgrihhlrdhnvghtqeenucggtffrrghtthgvrh hnpeevfeevuedtiedtteetgfeghedvudeileekgfehkeehudetveehgeeuteeuveejheen ucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehkohhnrh grugdrhhhinhhsvghnsehfrghsthhmrghilhdrnhgvthdpnhgspghrtghpthhtohepvddp mhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepsggttgeskhhhihhnshgvnhdrfhgrsh htmhgrihhlrdhnvghtpdhrtghpthhtohepjedvkeegtdesuggvsggsuhhgshdrghhnuhdr ohhrgh X-ME-Proxy: Feedback-ID: i184641e2:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 17 Sep 2024 08:21:17 -0400 (EDT) From: Konrad Hinsen To: 72840@debbugs.gnu.org Subject: Orphaned packages Date: Tue, 17 Sep 2024 14:21:15 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 72840 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Hi Andreas (et al.), Debian has the status of "orphaned" packages for the situations that you describe. Maybe Guix should have that as well? The main interest I see is keeping a list of "software we had but can't handle any more", ideally with a pointer to the last working state in Guix, e.g. the last commit for which CI could build the package. I'd even like such packages to show up in answers to "guix search", so that I know the difference between "not packaged yet" and "tough case we gave up on". > if during one month nobody steps in to carry out the update, that is > telling. I don't know on which time scales other Guix users live, but for me, one month is the average delay between two "guix pull". In other words, one month is my notion of "immediately" when it comes to Guix. Cheers, Konrad. From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 23 17:47:43 2024 Received: (at 72840) by debbugs.gnu.org; 23 Sep 2024 21:47:43 +0000 Received: from localhost ([127.0.0.1]:44799 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ssquF-0008Us-1A for submit@debbugs.gnu.org; Mon, 23 Sep 2024 17:47:43 -0400 Received: from eggs.gnu.org ([209.51.188.92]:53556) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ssquD-0008Ue-Ef for 72840@debbugs.gnu.org; Mon, 23 Sep 2024 17:47:42 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ssqrc-00076R-OU; Mon, 23 Sep 2024 17:45:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=xPbk8UzIHxylsG8cuU2QtIPccjOz14XPMTbKy3jdsdw=; b=jg482tSAIcSqs1XWOGDz /QLYprCJd3Xj+b9S7YaEwqGGbQ8Qx44Dd0ZVA08N6idoPYAFQlljsDolS722ogjusLODbDZrgTa6c AaEYqcVEhQKQngFLIunKGOwwiIsc11RLxRcDFVJBQyAzzzaSGPOZUI6VOL3Jvl2LjNOXMKO0wpDcH 3sJHOvMu3UjA+8wxBP4Ol0XA3H+0PbMdrC3nsGRtNXpovpcn4ZoMQTk994hw6Qb6oRfmXjAT0R7Je 6RLHcPdAVOMgw103dKDj6oG4Q5nBGXQpGvwNDAsgyKZPmKFCEv/byUXbuPnpgF9A1G0QQ/t1IO2zO QYn6B6VeBOHACw==; From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: indieterminacy Subject: Re: bug#72840: [PATCH RFC] DRAFT doc: Add =?utf-8?Q?=E2=80=9CDepr?= =?utf-8?Q?ecation_Policy=E2=80=9D?= section. In-Reply-To: <3130f45aaef0b424689f4c91a8dde943@libre.brussels> (indieterminacy@libre.brussels's message of "Fri, 13 Sep 2024 20:57:07 +0000") References: <80f8b603ecd73cb9f46b1ea43797e143f16d2f17.1724785788.git.ludo@gnu.org> <3130f45aaef0b424689f4c91a8dde943@libre.brussels> Date: Mon, 23 Sep 2024 23:44:57 +0200 Message-ID: <87msjyyrhi.fsf_-_@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 72840 Cc: 72840@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hey there! indieterminacy skribis: > It may be that Im lacking a little experience, > but Id assume that the categories outlined earlier probably require > different timeframes: > https://issues.guix.gnu.org/72840#0-lineno49 > > A year feels a little arbitrary. It=E2=80=99s necessarily arbitrary, but I think we have to set expectations= for users and provide guidelines for contributors; we can=E2=80=99t just say =E2=80=9Ceventually=E2=80=9D. [...] > Am I the only one who feels undermined and demotivated by information > which hits me over the head with WARNINGS? > > Ive had this using elogin-service (cited before): > https://issues.guix.gnu.org/72840#0-lineno155 > > Perhaps additionally there need to be pointers to real VCS repos, > pinpointing a commit providing the migration inside a living > repo/infrastructure? > > Such examples would be constructively showing how the change is > achievable, > and could be empowering through assurance and learning. I agree. I mean, those warnings could be accompanied with a diff showing how to change the source (GCC does that these days in some cases), and/or it could point to examples in the manual. This is something we should consider, but I think it shouldn=E2=80=99t block a first version of the policy. Thanks, Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 23 17:49:52 2024 Received: (at 72840) by debbugs.gnu.org; 23 Sep 2024 21:49:53 +0000 Received: from localhost ([127.0.0.1]:44806 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ssqwK-00007A-J6 for submit@debbugs.gnu.org; Mon, 23 Sep 2024 17:49:52 -0400 Received: from eggs.gnu.org ([209.51.188.92]:53748) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ssqwI-00006p-DQ for 72840@debbugs.gnu.org; Mon, 23 Sep 2024 17:49:51 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ssqtk-0007P1-3e; Mon, 23 Sep 2024 17:47:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=ENygpBOKTtbDiOrZFvVO/wEtcfA05WG1NNLubdWs9g4=; b=LGHkIVsz1AfHsyBwTz9C ANVN2Pv6U0CU3wG3Wkja/pCNBIL6ZmbSZeLD8hHPimLQDl7srBBF8OikTpPQqAbvBU2nYRt1VFsD0 M2SVGWngdqj01+iDhfhAN78Ny+5fo6T0tphQqwDg5kcekbi3rjG3U8intuXV7jo5AJy94uzsDQOBA FtudbRUtHInRpTaX516nypjj9+gB+1U7WuK/UhXkgug2NpfkQS5YPhhr5youMQnhNAmlhQ7jTrE0O G3kO/vX0W8zEfm+UtcZ9dXs+lXtE9J4793I4O+aU89zooF3EWujxBfVzCK0sqwh62+v8F3wRPtH15 /h12FWa9TpiRMg==; From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Konrad Hinsen Subject: Re: bug#72840: [PATCH RFC] DRAFT doc: Add =?utf-8?Q?=E2=80=9CDepr?= =?utf-8?Q?ecation_Policy=E2=80=9D?= section. In-Reply-To: (Konrad Hinsen's message of "Tue, 17 Sep 2024 14:21:15 +0200") References: <80f8b603ecd73cb9f46b1ea43797e143f16d2f17.1724785788.git.ludo@gnu.org> Date: Mon, 23 Sep 2024 23:47:08 +0200 Message-ID: <87frpqyrdv.fsf_-_@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 72840 Cc: 72840@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hi, Konrad Hinsen skribis: > Debian has the status of "orphaned" packages for the situations that you > describe. Maybe Guix should have that as well? The main interest I see > is keeping a list of "software we had but can't handle any more", > ideally with a pointer to the last working state in Guix, e.g. the last > commit for which CI could build the package. I'd even like such packages > to show up in answers to "guix search", so that I know the difference > between "not packaged yet" and "tough case we gave up on". Sounds like a good idea. This could be achieved with a package property, maybe. I=E2=80=99d like this to not block version 1 of the policy though. >> if during one month nobody steps in to carry out the update, that is >> telling. > > I don't know on which time scales other Guix users live, but for me, one > month is the average delay between two "guix pull". In other words, one > month is my notion of "immediately" when it comes to Guix. Agreed. Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 23 18:12:01 2024 Received: (at 72840) by debbugs.gnu.org; 23 Sep 2024 22:12:01 +0000 Received: from localhost ([127.0.0.1]:44836 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ssrHk-0001Ok-6Z for submit@debbugs.gnu.org; Mon, 23 Sep 2024 18:12:00 -0400 Received: from eggs.gnu.org ([209.51.188.92]:45778) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ssrHh-0001OQ-L8 for 72840@debbugs.gnu.org; Mon, 23 Sep 2024 18:11:58 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ssrHD-0001QO-Pt; Mon, 23 Sep 2024 18:11:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:References:In-Reply-To:Date:Subject:To: From; bh=0ZDyhNd0qVGkFSpy7SkW95JaBKD5kEo0zJ5NE5qP1Dc=; b=e6K2ttFZeI8Ck8C7jx48 gT22wGmSfNXFderzefrIFVeV7AKUEJm7wPzAP0BGwmvwUdIhj3A0h5QmsgEmpVAczj1pphwyf1BJL BKp7M5JV1EKRrBRo/Td98k67FdntiHtUXcYvEBFF2mk6QIrkikm/O7TjUotHmCp0QYunCQ0xH6J8V L9scKQOS85diH232hKQKhyV/VTG/EHD1fPMl48WiPOgkClA76nY4OKWmIBAmRQefAg20rSqz3s91I E5QpBQRtsxo++iIwHTwBjQAEFu8svEQRH+XQn5bYo18l94KlhuN71lcL63XXOofy5eBnJkigt7QDT Kddjolt5KpWAuQ==; From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= To: 72840@debbugs.gnu.org Subject: [PATCH RFC v4] =?UTF-8?q?doc:=20Add=20=E2=80=9CDeprecation=20Poli?= =?UTF-8?q?cy=E2=80=9D=20section.?= Date: Tue, 24 Sep 2024 00:11:19 +0200 Message-ID: <7b092101ad70b100c147b7dacb6efc3393f6cb06.1727129087.git.ludo@gnu.org> X-Mailer: git-send-email 2.46.0 In-Reply-To: <902c544b5298617c2ed45af8d672130bc9b1a2e3.1726049102.git.ludo@gnu.org> References: <902c544b5298617c2ed45af8d672130bc9b1a2e3.1726049102.git.ludo@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Debbugs-Cc: Florian Pelz , Ludovic Courtès , Maxim Cournoyer Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 72840 Cc: =?UTF-8?q?No=C3=A9=20Lopez?= , =?UTF-8?q?Ludovic=20Court=C3=A8s?= , Konrad Hinsen , andreas@enge.fr X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) * doc/contributing.texi (Deprecation Policy): New node. (Commit Access): Link to ‘package-removal-policy’. Change-Id: I5d095559920a3d9b791b5d919aab4e2f2a0c2dee --- doc/contributing.texi | 199 +++++++++++++++++++++++++++++++++++++++++- 1 file changed, 196 insertions(+), 3 deletions(-) Changes since v3: • Mention “development *or use* of external tools” (Konrad) in the list of use cases. • Mark upgrade as potentially equivalent to removal (Noé, Konrad). • Mark packages “failing to build for two months or more” as candidates for removal (Andreas). That makes it a total of at least 3 months before removal. The last point is probably the most contentious. Anything else? Ludo’. diff --git a/doc/contributing.texi b/doc/contributing.texi index 73f7addbef..d6a684306c 100644 --- a/doc/contributing.texi +++ b/doc/contributing.texi @@ -34,6 +34,7 @@ Contributing * Commit Access:: Pushing to the official repository. * Reviewing the Work of Others:: Some guidelines for sharing reviews. * Updating the Guix Package:: Updating the Guix package definition. +* Deprecation Policy:: Commitments and tools for deprecation. * Writing Documentation:: Improving documentation in GNU Guix. * Translating Guix:: Make Guix speak your native language. @end menu @@ -2805,9 +2806,11 @@ Commit Access repository, especially for the @code{master} branch. If you're committing and pushing your own changes, try and wait at least -one week (two weeks for more significant changes) after you send them -for review. After this, if no one else is available to review them and -if you're confident about the changes, it's OK to commit. +one week (two weeks for more significant changes, up to one month for +changes such as removing a package---@pxref{package-removal-policy, +Package Removal}) after you send them for review. After this, if no one +else is available to review them and if you're confident about the +changes, it's OK to commit. When pushing a commit on behalf of somebody else, please add a @code{Signed-off-by} line at the end of the commit log message---e.g., @@ -3030,6 +3033,196 @@ Updating the Guix Package this variable is set, the updated package source is also added to the store. This is used as part of the release process of Guix. +@node Deprecation Policy +@section Deprecation Policy + +@cindex deprecation policy +As any lively project with a broad scope, Guix changes all the time and +at all levels. Because it's user-extensible and programmable, +incompatible changes can directly impact users and make their life +harder. It is thus important to reduce user-visible incompatible +changes to a minimum and, when such changes are deemed necessary, to +clearly communicate them through a @dfn{deprecation period} so everyone +can adapt with minimum hassle. This section defines the project's +commitments for smooth deprecation and describes procedures and +mechanisms to honor them. + +There are several ways to use Guix; how to handle deprecation will +depend on each use case. Those can be roughly categorized like this: + +@itemize +@item +package management exclusively through the command line; + +@item +advanced package management using the manifest and package interfaces; + +@item +Home and System management, using the @code{operating-system} and/or +@code{home-environment} interfaces together with the service interfaces; + +@item +development or use of external tools that use programming interfaces +such as the @code{(guix ...)} modules. +@end itemize + +These use cases form a spectrum with varying degrees of coupling---from +``distant'' to tightly coupled. Based on this insight, we define the +following @dfn{deprecation policies} that we consider suitable for each +of these levels. + +@table @asis +@item Command-line tools +Guix sub-commands should be thought of as remaining available +``forever''. Once a Guix sub-command is to be removed, it should be +deprecated first, and then remain available for @b{at least one year} +after the first release that deprecated it. + +Deprecation should first be announced in the manual and as an entry in +@file{etc/news.scm}; additional communication such as a blog post +explaining the rationale is welcome. Months before the scheduled +removal date, the command should print a warning explaining how to +migrate. An example of this is the replacement of @command{guix +environment} by @command{guix shell}, started in October +2021@footnote{For more details on the @command{guix shell} transition, +see +@uref{https://guix.gnu.org/en/blog/2021/from-guix-environment-to-guix-shell/}.}. + +Because of the broad impact of such a change, we recommend conducting a +user survey before enacting a plan. + +@cindex package deprecation +@item Package name changes +When a package name changes, it must remain available under its old name +for @b{at least one year}. For example, @code{go-ipfs} was renamed to +@code{kubo} following a decision made upstream; to communicate the name +change to users, the package module provided this definition: + +@findex deprecated-package +@lisp +(define-public go-ipfs + (deprecated-package "go-ipfs" kubo)) +@end lisp + +That way, someone running @command{guix install go-ipfs} or similar sees +a deprecation warning mentioning the new name. + +@cindex package removal policy +@anchor{package-removal-policy} +@item Package removal +Packages whose upstream developers have declared as having reached ``end +of life'' or being unmaintained may be removed; likewise, packages that +have been @b{failing to build for two months or more} may be removed. + +There is no formal deprecation mechanism for this case, unless a +replacement exists, in which case the @code{deprecated-package} +procedure mentioned above can be used. + +If the package being removed is a ``leaf'' (no other packages depend on +it), it may be removed after a @b{one-month review period} of the patch +removing it (this applies even when the removal has additional +motivations such as security problems affecting the package). + +If it has many dependent packages---as is the case for example with +Python version@tie{}2---the relevant team must propose a deprecation +removal agenda and seek consensus with other packagers for @b{at least +one month}. It may also invite feedback from the broader user +community, for example through a survey. Removal of all impacted +packages may be gradual, spanning multiple months, to accommodate all +use cases. + +When the package being removed is considered popular, whether or not it +is a leaf, its deprecation must be announced as an entry in +@code{etc/news.scm}. + +@item Package upgrade +In the case of packages with many dependents and/or many users, an +upgrade may be treated like the @emph{removal} of the previous version. + +Examples include major version upgrades of programming language +implementations, as we've seen above with Python, and major upgrades of +``big'' libraries such as Qt or GTK. + +@cindex service deprecation +@item Services +Changes to services for Guix Home and Guix System have a direct impact +on user configuration. For a user, adjusting to interface changes is +rarely rewarding, which is why any such change must be clearly +communicated in advance through deprecation warnings and documentation. + +Renaming of variables related to service, home, or system configuration +must be communicated for at least six months before removal using the +@code{(guix deprecation)} mechanisms. For example, renaming of +@code{murmur-configuration} to @code{mumble-server-configuration} was +communicated through a series of definitions like this one: + +@findex define-deprecated/public-alias +@lisp +(define-deprecated/public-alias + murmur-configuration + mumble-server-configuration) +@end lisp + +Procedures slated for removal may be defined like this: + +@findex define-deprecated +@lisp +(define-deprecated (elogind-service #:key (config (elogind-configuration))) + elogind-service-type + (service elogind-service-type config)) +@end lisp + +Record fields, notably fields of service configuration records, must +follow a similar deprecation period. This is usually achieved through +@i{ad hoc} means though. For example, the @code{hosts-file} field of +@code{operating-system} was deprecated by adding a @code{sanitized} +property that would emit a warning: + +@lisp +(define-record-type* + ;; @dots{} + (hosts-file %operating-system-hosts-file ;deprecated + (default #f) + (sanitize warn-hosts-file-field-deprecation))) + +(define-deprecated (operating-system-hosts-file os) + hosts-service-type + (%operating-system-hosts-file os)) +@end lisp + +When deprecating interfaces in @code{operating-system}, +@code{home-environment}, @code{(gnu services)}, or any popular service, +the deprecation must come with an entry in @code{etc/news.scm}. + +@cindex deprecation of programming interfaces +@item Core interfaces +Core programming interfaces, in particular the @code{(guix ...)} +modules, may be relied on by a variety of external tools and channels. +Any incompatible change must be formally deprecated with +@code{define-deprecated}, as shown above, for @b{at least one year} +before removal. The manual must clearly document the new interface and, +except in obvious cases, explain how to migrate from the old one. + +As an example, the @code{build-expression->derivation} procedure was +superseded by @code{gexp->derivation} and remained available as a +deprecated symbol: + +@lisp +(define-deprecated (build-expression->derivation store name exp + #:key @dots{}) + gexp->derivation + @dots{}) +@end lisp + +Sometimes bindings are moved from one module to another. In those +cases, bindings must be reexported from the original module for at least +one year. +@end table + +This section does not cover all possible situations but hopefully allows +users to know what to expect and developers to stick to its spirit. +Please email @email{guix-devel@@gnu.org} for any questions. + @cindex documentation @node Writing Documentation @section Writing Documentation base-commit: 637ca78f513fac15284403c0d3af64492ea832a1 -- 2.46.0 From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 23 18:17:29 2024 Received: (at 72840) by debbugs.gnu.org; 23 Sep 2024 22:17:29 +0000 Received: from localhost ([127.0.0.1]:44850 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ssrN2-0001i1-S3 for submit@debbugs.gnu.org; Mon, 23 Sep 2024 18:17:29 -0400 Received: from eggs.gnu.org ([209.51.188.92]:46170) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ssrN0-0001hk-Ll for 72840@debbugs.gnu.org; Mon, 23 Sep 2024 18:17:27 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ssrMX-0001sb-Q3; Mon, 23 Sep 2024 18:16:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=71/UsfQI4si0a0YrMPM1NLV4u9Z/ZszQSP1PUWJvDZs=; b=pMhbjGcjG8e0T+ZeaBxq BwUhZ227IEq9KiqOpLTbBBOPRShTN2yrLt9nAijksBtP9+xKq76VqPyvFx+x/JnlN6EBn116A7Utt MzmRGrfmhC5isfGkTt/DmjmTJ1hnQw0MAWhyTg6oGTT1ynw8Mf7ObiVLi9npmG5oqBTFvcAOEcbun aA7mNjlpkh4LDfOrRXzUpObpF4psgcslids3oD9SxDv1aKScB/mtMnU3YXzzy6SelHlYws1P5cZSd aqDxFEsLqQMzvWfMQhoCuWS1im0QUN1fsk7Ff/luxASefE8kqZCIlKvsAxsoEMm0AcuXUi5IBJoRV y45tBWH4bs+HNg==; From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: 72840@debbugs.gnu.org Subject: Re: bug#72840: [PATCH RFC] DRAFT doc: Add =?utf-8?Q?=E2=80=9CDepr?= =?utf-8?Q?ecation_Policy=E2=80=9D?= section. In-Reply-To: <87zfowk9bh.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Wed, 28 Aug 2024 16:31:46 +0200") References: <87zfowk9bh.fsf@gnu.org> Date: Tue, 24 Sep 2024 00:16:52 +0200 Message-ID: <87wmj2vwvf.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 72840 Cc: Konrad Hinsen , =?utf-8?Q?=22No=C3=A9?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --=-=-= Content-Type: text/plain The v3 -> v4 diff for clarity: --=-=-= Content-Type: text/x-patch Content-Disposition: inline diff --git a/doc/contributing.texi b/doc/contributing.texi index f713765357..d6a684306c 100644 --- a/doc/contributing.texi +++ b/doc/contributing.texi @@ -3062,8 +3062,8 @@ Deprecation Policy @code{home-environment} interfaces together with the service interfaces; @item -development of external tools that use programming interfaces such as -the @code{(guix ...)} modules. +development or use of external tools that use programming interfaces +such as the @code{(guix ...)} modules. @end itemize These use cases form a spectrum with varying degrees of coupling---from @@ -3111,10 +3111,12 @@ Deprecation Policy @anchor{package-removal-policy} @item Package removal Packages whose upstream developers have declared as having reached ``end -of life'' or being unmaintained may be removed. There is no formal -deprecation mechanism for this case, unless a replacement exists, in -which case the @code{deprecated-package} procedure mentioned above can -be used. +of life'' or being unmaintained may be removed; likewise, packages that +have been @b{failing to build for two months or more} may be removed. + +There is no formal deprecation mechanism for this case, unless a +replacement exists, in which case the @code{deprecated-package} +procedure mentioned above can be used. If the package being removed is a ``leaf'' (no other packages depend on it), it may be removed after a @b{one-month review period} of the patch @@ -3133,6 +3135,14 @@ Deprecation Policy is a leaf, its deprecation must be announced as an entry in @code{etc/news.scm}. +@item Package upgrade +In the case of packages with many dependents and/or many users, an +upgrade may be treated like the @emph{removal} of the previous version. + +Examples include major version upgrades of programming language +implementations, as we've seen above with Python, and major upgrades of +``big'' libraries such as Qt or GTK. + @cindex service deprecation @item Services Changes to services for Guix Home and Guix System have a direct impact --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 24 01:22:20 2024 Received: (at 72840) by debbugs.gnu.org; 24 Sep 2024 05:22:20 +0000 Received: from localhost ([127.0.0.1]:45044 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ssy0C-00085y-Hy for submit@debbugs.gnu.org; Tue, 24 Sep 2024 01:22:20 -0400 Received: from fout-a7-smtp.messagingengine.com ([103.168.172.150]:35883) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ssy0A-00085c-1w for 72840@debbugs.gnu.org; Tue, 24 Sep 2024 01:22:19 -0400 Received: from phl-compute-11.internal (phl-compute-11.phl.internal [10.202.2.51]) by mailfout.phl.internal (Postfix) with ESMTP id 61F63138029C; Tue, 24 Sep 2024 01:21:48 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-11.internal (MEProxy); Tue, 24 Sep 2024 01:21:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1727155308; x=1727241708; bh=G+5qY3dg823Xz1IRVASfvIHDzWf6GQ7ESgY6b6bCVKw=; b= hRgaOewIpVJ7boN+fyqDBRYHOqeJThVhcnqAD718Jkh2y7k1nVM+7hEMQrYxx6WO iyXEv9aefEbzH96VlHebELlawPqVsNUPhy/LlLUoiSYtDHwQLjUGnC6INY2wTSl7 vudltFetMx2n78E6Eqa35/rN6a3cVYUB3gdGZTh3380dZn+wT0d81dyubHxuZHP+ XEJFHDHxhFST8JF2d84xbItcTbOnusiIPNTW/JVU2/iq3qx19q3Ns7FeqGcZoMqI oBlumWzshBsugzcZRxWLc2lAwCUAYaOmBSEPVRT8Ei6OteLr/gCnCZDcj8yhc0c8 k8Rz3CYpVBCgMy5hPZjR2g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1727155308; x= 1727241708; bh=G+5qY3dg823Xz1IRVASfvIHDzWf6GQ7ESgY6b6bCVKw=; b=e iscxiksy40CfWw2gu2bgGfm5C/ivi5YTBUQL7jXsemiWtcR2SBT+pamowQW9+hJT ZRHVXrGaEqH0Zv77oIuD3W8hddMk+a14NZaPckilE7WAG98VzvBWKllxyBhUwxb7 0Kj8FMnMAKhQrYuzhtICVQkV60qTODkFkAakZYiLGRaTux7LnAIpsniOr68lFfvJ KLq/Xij4ezO4J6fZB+Efi1iVOEVTbexwyT3R+beAHZ28v5gOFtsB8a2yK34IEU6A DHp8c/AAOXozT/GVBBdt//3M+MLOYaRMyT1E979oSniLExcMKBLq1+JuZ/+aAUH2 qVcypnQlPXBpqR221aZKg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvddtuddgieefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhephffvvefujghffffkgggtgfesthhqredttddtjeen ucfhrhhomhepmfhonhhrrgguucfjihhnshgvnhcuoehkohhnrhgrugdrhhhinhhsvghnse hfrghsthhmrghilhdrnhgvtheqnecuggftrfgrthhtvghrnhepieehvdelhedujeejvdef udehieeifeegueeiieegteehffduleelgfegueeifeelnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepkhhonhhrrggurdhhihhnshgvnhesfhgr shhtmhgrihhlrdhnvghtpdhnsggprhgtphhtthhopeefpdhmohguvgepshhmthhpohhuth dprhgtphhtthhopegstggtsehkhhhinhhsvghnrdhfrghsthhmrghilhdrnhgvthdprhgt phhtthhopeejvdekgedtseguvggssghughhsrdhgnhhurdhorhhgpdhrtghpthhtoheplh huughosehgnhhurdhorhhg X-ME-Proxy: Feedback-ID: i184641e2:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 24 Sep 2024 01:21:47 -0400 (EDT) From: Konrad Hinsen To: Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: bug#72840: [PATCH RFC] DRAFT doc: Add =?utf-8?Q?=E2=80=9CDepr?= =?utf-8?Q?ecation_Policy=E2=80=9D?= section. In-Reply-To: <87frpqyrdv.fsf_-_@gnu.org> References: <80f8b603ecd73cb9f46b1ea43797e143f16d2f17.1724785788.git.ludo@gnu.org> <87frpqyrdv.fsf_-_@gnu.org> Date: Tue, 24 Sep 2024 07:21:45 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 72840 Cc: 72840@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Hi Ludo, > Sounds like a good idea. This could be achieved with a package > property, maybe. > > I=E2=80=99d like this to not block version 1 of the policy though. Certainly not! That said, a convention for commit messages related to the cases described in the deprecation policy would be a good start. Not just "deprecated" or "removed", but also a keyword stating the reason. Cheers, Konrad. From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 24 12:34:38 2024 Received: (at 72840) by debbugs.gnu.org; 24 Sep 2024 16:34:38 +0000 Received: from localhost ([127.0.0.1]:54039 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1st8Un-0005eV-JW for submit@debbugs.gnu.org; Tue, 24 Sep 2024 12:34:38 -0400 Received: from mail-oo1-f54.google.com ([209.85.161.54]:54609) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1st8Ul-0005e4-Uw for 72840@debbugs.gnu.org; Tue, 24 Sep 2024 12:34:36 -0400 Received: by mail-oo1-f54.google.com with SMTP id 006d021491bc7-5e1cdfe241eso2247275eaf.1 for <72840@debbugs.gnu.org>; Tue, 24 Sep 2024 09:34:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=greghogan-com.20230601.gappssmtp.com; s=20230601; t=1727195585; x=1727800385; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=qRnGuIkloGjWcWdydBgbwh682zsVR8SKjwkfQTX7Mbc=; b=09cfTbLCitJRJHGA0xWDTEem0rHh25m63dDbPb81zpCrIY3nGjfdoXks7x7i15uggQ vltJ2nBDArkzaPMUuAbku1pmPUr2KIbEJXHd8EYV6S2/oDxqPyPLeI+Y4LZJ+0TTwdoU bFcHYrA0Qb0/SuHPQJS7Wv1JlBA3S3n6CbSzyyV3loI+adbec062tUch+b7v8W5Z2Tis YPKs9vYP+jJGD/Hy6Mo654EuJM8aBaC9ulcT6RcrWnvO3CaDefnbxRa5+Jm7Z9FuqzNi rgznUv5fpMMEzOcR6IXXqGN97AyQ6Z//4FGVkUIU63hrQkJzjb2hivW5VZvUAu3Nw5Wm Y9yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727195585; x=1727800385; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=qRnGuIkloGjWcWdydBgbwh682zsVR8SKjwkfQTX7Mbc=; b=V5ru5weiZzhjpkEUCE8TCCW70uVlebXkVB6lQwTjvzRhkdwfhMuok/HXceq8/HWCkY z1a5aC5t92bgzyS0Pgdox59xNf96s62JBV/KTj5HZoq8dHpf3W0KFei19DDsjzwTODeN GmqDfvA9O3shBAzGg5LStTgjciX8eiyx/F50TJXWbHX2eAOzQrYoDql9dPiK0UeXCJ+Y /GcHYvf8YU1t6zuj33Luwe2FPDlSa51L6tzzeY9bSHfAnSCescvfhT9bDMz5hkgsLKa1 iwoGlHlvXbloEHxkqYaaLYWpEw2zME/QODj4ee1/pHIb/0EXn3+LoLSA0W36hwmWYq7Q WxzA== X-Gm-Message-State: AOJu0YxxXLsxMWUittwwSQ60eRZv5fwVTkryzeamBpqRmEQ3cm5H90Z4 W0k6aLIbxFrlOJr2nFwY1mVaUBT+JTZ1AtzPXwi/tNg4l66/TOvt17/Ag6vPJlQLpVan6eJAKWc U9fCay8aocsnLy9ClqEdkdVAuLLXmDM/kfA+I1g== X-Google-Smtp-Source: AGHT+IEMhhgnmSfQoOQ6/XJfvv14TSjd8Pv9KjAKtPG8IDBvyRv919UhPr2Y7n8+iEFm7DbG5DK3xRopO//9roGt3u4= X-Received: by 2002:a05:6871:82a:b0:24f:d178:d48d with SMTP id 586e51a60fabf-2803a784e5dmr10103224fac.31.1727195585448; Tue, 24 Sep 2024 09:33:05 -0700 (PDT) MIME-Version: 1.0 References: <902c544b5298617c2ed45af8d672130bc9b1a2e3.1726049102.git.ludo@gnu.org> <7b092101ad70b100c147b7dacb6efc3393f6cb06.1727129087.git.ludo@gnu.org> In-Reply-To: <7b092101ad70b100c147b7dacb6efc3393f6cb06.1727129087.git.ludo@gnu.org> From: Greg Hogan Date: Tue, 24 Sep 2024 12:32:53 -0400 Message-ID: Subject: =?UTF-8?B?UmU6IFtidWcjNzI4NDBdIFtQQVRDSCBSRkMgdjRdIGRvYzogQWRkIOKAnERlcHJlY2F0aQ==?= =?UTF-8?B?b24gUG9saWN54oCdIHNlY3Rpb24u?= To: =?UTF-8?Q?Ludovic_Court=C3=A8s?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 72840 Cc: Konrad Hinsen , 72840@debbugs.gnu.org, Maxim Cournoyer , =?UTF-8?Q?No=C3=A9_Lopez?= , Florian Pelz , andreas@enge.fr X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Mon, Sep 23, 2024 at 6:11=E2=80=AFPM Ludovic Court=C3=A8s = wrote: > > +@item Package removal > +Packages whose upstream developers have declared as having reached ``end > +of life'' or being unmaintained may be removed; likewise, packages that > +have been @b{failing to build for two months or more} may be removed. > + > +There is no formal deprecation mechanism for this case, unless a > +replacement exists, in which case the @code{deprecated-package} > +procedure mentioned above can be used. > + > +If the package being removed is a ``leaf'' (no other packages depend on > +it), it may be removed after a @b{one-month review period} of the patch > +removing it (this applies even when the removal has additional > +motivations such as security problems affecting the package). > + > +If it has many dependent packages---as is the case for example with > +Python version@tie{}2---the relevant team must propose a deprecation > +removal agenda and seek consensus with other packagers for @b{at least > +one month}. It may also invite feedback from the broader user > +community, for example through a survey. Removal of all impacted > +packages may be gradual, spanning multiple months, to accommodate all > +use cases. > + > +When the package being removed is considered popular, whether or not it > +is a leaf, its deprecation must be announced as an entry in > +@code{etc/news.scm}. Hi Ludo', Is the intent for the news entry to pre-announce the removal of a popular package, as specified for other kinds of deprecation and removal? Otherwise, even though we have extended the review period, we are expecting users to track the mailing lists. Greg From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 25 04:48:07 2024 Received: (at 72840) by debbugs.gnu.org; 25 Sep 2024 08:48:07 +0000 Received: from localhost ([127.0.0.1]:47641 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1stNgt-00078h-0a for submit@debbugs.gnu.org; Wed, 25 Sep 2024 04:48:07 -0400 Received: from hera.aquilenet.fr ([185.233.100.1]:48106) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1stNgr-000780-5i for 72840@debbugs.gnu.org; Wed, 25 Sep 2024 04:48:05 -0400 Received: from localhost (localhost [127.0.0.1]) by hera.aquilenet.fr (Postfix) with ESMTP id 2BBBE1B0; Wed, 25 Sep 2024 10:47:34 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at hera.aquilenet.fr Received: from hera.aquilenet.fr ([127.0.0.1]) by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcGORU7bFaJX; Wed, 25 Sep 2024 10:47:33 +0200 (CEST) Received: from jurong (unknown [IPv6:2001:861:c4:f2f0::c64]) by hera.aquilenet.fr (Postfix) with ESMTPSA id 82902166; Wed, 25 Sep 2024 10:47:33 +0200 (CEST) Date: Wed, 25 Sep 2024 10:47:32 +0200 From: Andreas Enge To: Greg Hogan Subject: Re: [bug#72840] [PATCH RFC v4] =?utf-8?Q?d?= =?utf-8?B?b2M6IEFkZCDigJxEZXByZWNhdGlvbiBQb2xpY3nigJ0=?= section. Message-ID: References: <902c544b5298617c2ed45af8d672130bc9b1a2e3.1726049102.git.ludo@gnu.org> <7b092101ad70b100c147b7dacb6efc3393f6cb06.1727129087.git.ludo@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 72840 Cc: Konrad Hinsen , 72840@debbugs.gnu.org, Maxim Cournoyer , =?iso-8859-15?B?Tm/p?= Lopez , Ludovic =?iso-8859-15?Q?Court=E8s?= , Florian Pelz X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Am Tue, Sep 24, 2024 at 12:32:53PM -0400 schrieb Greg Hogan: > Is the intent for the news entry to pre-announce the removal of a > popular package, as specified for other kinds of deprecation and > removal? Otherwise, even though we have extended the review period, we > are expecting users to track the mailing lists. No, I think the idea is to do it after the removal, but so that "guix pull" prints a message. Then users can adapt. Andreas From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 26 09:17:43 2024 Received: (at 72840) by debbugs.gnu.org; 26 Sep 2024 13:17:43 +0000 Received: from localhost ([127.0.0.1]:33577 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1stoNL-0007IH-F3 for submit@debbugs.gnu.org; Thu, 26 Sep 2024 09:17:43 -0400 Received: from eggs.gnu.org ([209.51.188.92]:53824) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1stoNK-0007I3-B1 for 72840@debbugs.gnu.org; Thu, 26 Sep 2024 09:17:42 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1stoMk-00037o-6D; Thu, 26 Sep 2024 09:17:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=m35QRMxw0wqB+gKP8OKWWTEBL/JeIOeRQGnW4pCuyQE=; b=eAdC2CRFOf114t3JsDBx yKLQf++tkJfyomB3yM9HHveIbt7njZ1pYsiYV8wh1K7pDj4cv1aCuz0MnyrruX0E5Q24z4zoZRlgL +RhSABjEV+zvqGJX1ZGZd65VvAu7gs6SFF+NgTrXzEp7UinO6e6YKOGr18PkAdU6xI0em7ymaGYNF bGoHG3PfO+TrKqU6Qet5a2cPeRfQT8hRnwc33a4UrdxNtQkPEAJ5K2uyqAoKRe7GW5I3gXoTWA/hu RXdlDxKkb4wqE7twNNdhYtbA8g/WWOtvhuxy/Ulk+evGgy191uPsql2y8GCgPRafBpOMtEDHn+p73 mOEYqDVH2D1bAg==; From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Janneke Nieuwenhuizen Subject: Re: [PATCH RFC] DRAFT doc: Add =?utf-8?Q?=E2=80=9CDeprecation_Pol?= =?utf-8?Q?icy=E2=80=9D?= section. In-Reply-To: <87ed5m7lma.fsf@gnu.org> (Janneke Nieuwenhuizen's message of "Sat, 14 Sep 2024 09:14:21 +0200") References: <87a5gbe9eh.fsf@inria.fr> <87ed5m7lma.fsf@gnu.org> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: Quintidi 5 =?utf-8?Q?Vend=C3=A9miaire?= an 233 de la =?utf-8?Q?R=C3=A9volution=2C?= jour du Cheval X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Thu, 26 Sep 2024 15:16:58 +0200 Message-ID: <87ldzeo8qd.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 72840 Cc: guix-devel , 72840@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hi Janneke, Janneke Nieuwenhuizen skribis: >> https://issues.guix.gnu.org/72840 > > Thanks, looks good to me! As a side remark: It would be nice if > upgrading of config.scm / home.scm could be automated. It would be great, indeed. > Anyway, I do have a vaguely related question. The Dezyne package comes > with a `guix.scm' that uses a package description in > guix/pack/dezyne.scm, which uses `%gnu-build-system-modules'. > > Recently, %gnu-build-system-modules was deprecated in > > 28dbfdb38f52f5814fb4cba9c02831d2ab0dc079 > build-system/gnu: Introduce =E2=80=98%gnu-build-system-modules=E2=80=99 d= eprecated alias. > > 9e4ce281dbd92e3c52b831824ebb1f77023c960c > build-systems: gnu: Export %default-gnu-imported-modules and %default-gnu= -modules. I=E2=80=99m not convinced this was a worthwhile change BTW, looking at the intended clarity improvement vs. cost ratio. > Although the `guix.scm' has a comment like > > ;; To use the canonical commit that has everything prebuilt: > ;; > ;; guix time-machine --commit=3D918b7d102c2051c3d6c6ba54c8d265affec5282= c -- shell > > > documenting a commit that can be used for building the package and has > substitutes available, usage of the commit is not enforced. After a > recent `guix pull', we now get this warning > > pack/dezyne.scm:69:20: warning: '%gnu-build-system-modules' is deprecated= , use '%default-gnu-imported-modules' instead > > and I'm wondering what the best moment would be to change the package > description. Upgrading sooner (i.e., now) means that a future guix that > has this deprecated feature removed will be able to build more > hystorical releases of the package simply by doing `guix shell', so > that's probably the best choice? It would mean that all developers have > to upgrade now (or use the time machine). Yeah, that=E2=80=99s always a difficult choice, and I don=E2=80=99t have a = good answer. What=E2=80=99s sure is that the deprecated name will remain available for a relatively long time, so there=E2=80=99s no urgency at this point. > but you'd have to know about that and it probably only works for the > Dezyne package. Is there a better way or should something like this be > advertised/recommended in the documentation? I=E2=80=99m not sure we could recommend one approach that would work for everyone because it really depends on the use case (for instance whether building with an older Guix is important for your project. But at least, by setting expectations, the deprecation policy lets users making informed decisions. Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 02 12:20:27 2024 Received: (at 72840) by debbugs.gnu.org; 2 Oct 2024 16:20:27 +0000 Received: from localhost ([127.0.0.1]:59086 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sw25T-0001uo-7E for submit@debbugs.gnu.org; Wed, 02 Oct 2024 12:20:27 -0400 Received: from eggs.gnu.org ([209.51.188.92]:48514) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sw25R-0001ub-6o for 72840@debbugs.gnu.org; Wed, 02 Oct 2024 12:20:25 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sw25H-00043t-8w; Wed, 02 Oct 2024 12:20:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=fvcYyuncllfxWpTzGzlo+19rf4zx2OXWBSU3v6bKB24=; b=bYq66vtmE3rjBvb2S9Q/ LOZD2p106ZmeqHh9g/MO0T8wKnxOQMgZk/hPLjNUViOe3QAx8/zYT+pEpF62mdL4Av6NMNL20wZDZ 4JqOvc+tX835wpRCXf6TlCWNALzYIm8zzMJihD4rwSAul0XYKrk/EZMMxNMqnwF4TIh0Odg5qSYBd C/6ROhgcTRAKV3OWg7gSch737MykHOBU1YFjls8l2hFdMEDgXaNeov1t6qX+9JadYaCH6wMD5N9AM Rvxqe5hZqVaUXtYsGAxN240cy05tUsqpHgYStYLe+K7sTd+V6VadlyamuOabiLfLz0hWY4tmd1q1H RmFZLaVLuulE2A==; From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Greg Hogan Subject: Re: bug#72840: [PATCH RFC] DRAFT doc: Add =?utf-8?Q?=E2=80=9CDepr?= =?utf-8?Q?ecation_Policy=E2=80=9D?= section. In-Reply-To: (Greg Hogan's message of "Tue, 24 Sep 2024 12:32:53 -0400") References: <902c544b5298617c2ed45af8d672130bc9b1a2e3.1726049102.git.ludo@gnu.org> <7b092101ad70b100c147b7dacb6efc3393f6cb06.1727129087.git.ludo@gnu.org> Date: Wed, 02 Oct 2024 18:20:12 +0200 Message-ID: <87y136v5mr.fsf_-_@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 72840 Cc: Konrad Hinsen , 72840@debbugs.gnu.org, Maxim Cournoyer , =?utf-8?Q?No=C3=A9?= Lopez , Florian Pelz , andreas@enge.fr X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Greg Hogan skribis: > On Mon, Sep 23, 2024 at 6:11=E2=80=AFPM Ludovic Court=C3=A8s wrote: [...] >> +If it has many dependent packages---as is the case for example with >> +Python version@tie{}2---the relevant team must propose a deprecation >> +removal agenda and seek consensus with other packagers for @b{at least >> +one month}. It may also invite feedback from the broader user >> +community, for example through a survey. Removal of all impacted >> +packages may be gradual, spanning multiple months, to accommodate all >> +use cases. >> + >> +When the package being removed is considered popular, whether or not it >> +is a leaf, its deprecation must be announced as an entry in >> +@code{etc/news.scm}. > > Hi Ludo', > > Is the intent for the news entry to pre-announce the removal of a > popular package, as specified for other kinds of deprecation and > removal? What the paragraph above means is that a news entry is published when the popular package is deprecated, which could be months before it is removed. Does that make sense? Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 12 14:40:17 2024 Received: (at 72840-done) by debbugs.gnu.org; 12 Oct 2024 18:40:17 +0000 Received: from localhost ([127.0.0.1]:56659 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1szh2H-0002VT-A3 for submit@debbugs.gnu.org; Sat, 12 Oct 2024 14:40:17 -0400 Received: from eggs.gnu.org ([209.51.188.92]:42794) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1szh2A-0002Th-D5 for 72840-done@debbugs.gnu.org; Sat, 12 Oct 2024 14:40:10 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1szgKS-0002vC-54; Sat, 12 Oct 2024 13:55:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=/HmPP81PIC4nTlPhZA5ZbE7Jc2I3erBhCqMgg91dpSc=; b=cMPz5D1J3INGkxIdNJNR Um1l4Nj2e6AYo9N/YD/vAur4WGjeicoTjCZjFiMCqzG+2pjn69hLou/GIc7dQHSpR0FhoZqA5Wo86 uEybKO/hFcEGycTDVV2oJzI0xBJVPH+bVFn844sbLD5MjqXcVCQgRBUjkCWtTCnXEBH6Nno2XCrVd wOYNUaa9+HyAi2HBfCRsM472VhL29kPdqegEspwgJzgqFEGNibf6xx45XYbedQ6MFoNoGkQhIKeea RkB/iCIq1PbiDNLhrIjlz50uSbRFPJKEpWdr0sEt/l6hNYnrKa9IeVe/pFsH6fu4j0AtXyaX3g2Nt /xCMh5JQLWNOKA==; From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: 72840-done@debbugs.gnu.org Subject: Re: bug#72840: [PATCH RFC] DRAFT doc: Add =?utf-8?Q?=E2=80=9CDepr?= =?utf-8?Q?ecation_Policy=E2=80=9D?= section. In-Reply-To: <7b092101ad70b100c147b7dacb6efc3393f6cb06.1727129087.git.ludo@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22's?= message of "Tue, 24 Sep 2024 00:11:19 +0200") References: <902c544b5298617c2ed45af8d672130bc9b1a2e3.1726049102.git.ludo@gnu.org> <7b092101ad70b100c147b7dacb6efc3393f6cb06.1727129087.git.ludo@gnu.org> Date: Sat, 12 Oct 2024 19:54:56 +0200 Message-ID: <87wmidqk9b.fsf_-_@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 72840-done Cc: Konrad Hinsen , Maxim Cournoyer , =?utf-8?Q?No=C3=A9?= Lopez , Florian Pelz , Greg Hogan , andreas@enge.fr X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hello, Ludovic Court=C3=A8s skribis: > * doc/contributing.texi (Deprecation Policy): New node. > (Commit Access): Link to =E2=80=98package-removal-policy=E2=80=99. > > Change-Id: I5d095559920a3d9b791b5d919aab4e2f2a0c2dee The discussion had dried up so I pushed this version (v4) as commit 9d1b97d7a4ab9c0dbd5808e7859d52cff338f377. Let=E2=80=99s not consider it set in stone though: if there are suggestions= to improve this section, please go ahead, but bear in mind that time is needed so everyone interested gets a chance to participate. (As Simon noted, documenting an RFC process will help us clarify that.) Ludo=E2=80=99. From unknown Sat Jun 21 03:09:13 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 10 Nov 2024 12:24:07 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator