From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 27 15:14:47 2024 Received: (at submit) by debbugs.gnu.org; 27 Aug 2024 19:14:47 +0000 Received: from localhost ([127.0.0.1]:47579 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sj1eQ-00065n-Dj for submit@debbugs.gnu.org; Tue, 27 Aug 2024 15:14:47 -0400 Received: from lists.gnu.org ([209.51.188.17]:45144) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sj1eL-00065d-Uv for submit@debbugs.gnu.org; Tue, 27 Aug 2024 15:14:45 -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 1sj1dT-0005XJ-E2 for guix-patches@gnu.org; Tue, 27 Aug 2024 15:13:48 -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 1sj1dS-0001nJ-1c; Tue, 27 Aug 2024 15:13:46 -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=jnMqw2rN1/YB6a Pz2ikt0uu7ffOjHinUPW+hh87d36SzuTeJEprrvOUi/VXHsDbP02KynUr6oMY7Tx8duMVY0Z3Rv0Z KJYjIPKqIDaOTtwnPTMSO6JjQJRpXlyHHsik3FxoNFicqxgN7rEoLBdYjwA3bjLuCDdU75mkWvV7o efMr23pS5QBPNWVWAThNbYrxt6hoxhx4syccnpb+8oEEPccDUJlJm6S0WWt12UvQlhDSM/o7KvOrf yljJqswAbBZZJYo4iNAjZQPbgRxjL0oSXZukUi5xXQFhBRHRDsVNyikpR4u8X8uogB5jdfW0b8vPM mbxXwiLHDU1G/ESlrCDg==; 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:13:09 +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 unknown Fri Jun 20 05:29:14 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 Fri Sep 13 12:43:14 2024 Received: (at 72839) by debbugs.gnu.org; 13 Sep 2024 16:43:14 +0000 Received: from localhost ([127.0.0.1]:44168 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sp9O6-0002Gi-G1 for submit@debbugs.gnu.org; Fri, 13 Sep 2024 12:43:14 -0400 Received: from mail-wm1-f46.google.com ([209.85.128.46]:59663) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sp9O4-0002GQ-Tc for 72839@debbugs.gnu.org; Fri, 13 Sep 2024 12:43:13 -0400 Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-42cba0dc922so19352865e9.3 for <72839@debbugs.gnu.org>; Fri, 13 Sep 2024 09:43:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726245718; x=1726850518; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=dPPsDQZZ3/BA+iK8+swFtux9fBgQPJTUZYOYGPHobbU=; b=jIpNbMGcWV4Vgrz2SSsXoSMSrrBKz3VmQ8MS5VmFhbSFBwgfwVRYRjMT8dfaoSfrnO /gRPrHzTX5UK4SEoMsGG3EYkX0dmNCgBBL/hMRiK87YakKC1yEmgAIkWry921pSGqlsv CQn8sNcxGQpPeDkqXQ+dV4YTmpCeRtf276lel0K/6J9atqe22XdGV6OwDKh6bk12PXKU K56sgeGYEcVIWjJ3Vm2EUtKW4bvj7ivM3hByH0oVfl2J1DkxmsE6zEAuEQzpUxk3SG91 infpLACfcLxeLqFXsOD8C4oSW5tUh7lradLQDsrwTpvbl2dVh1RJpyAY7UySPliCtjZE pzHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726245718; x=1726850518; h=content-transfer-encoding:mime-version: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=dPPsDQZZ3/BA+iK8+swFtux9fBgQPJTUZYOYGPHobbU=; b=qKT80IoLts88NW/nEeEBCOs3Zop+Z2HkLmgeWyfSfJCNTW5xV23f4xqdrHK7TvhRfD 58E+ilvAvKL4J7ZjOfN9acgZ2CwNgsl3wtXt3VlxxjBnhPvAxXnzTARGH//lozVRhPCw eYK6rnei8cGyt4/B8xW5AVoLya6+YM3mccMDptdGneoH2bbUZ+ubH8k+vvcABU0XOuyV gFV/fjJRPshJvlQlhcHZlq2UzCk9oJtUroHKiuKPnHTRNREVEBFO1eEEvT8tdj6eFnZH GydWkOhNqsv6p2V9s5fw+k3v/jss2AaNeg612GNETaiorfrKWFit4IRd7zjs3M1onVDU hyGQ== X-Forwarded-Encrypted: i=1; AJvYcCVMzUCGyEPHB2hiMHZRf+rg/0JhyLC31gM94XZOFhDpdfiFCBF/8vYiX3ASTLKobyQ63JR3yA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyhwW75yVkwQlihGs0W13HmTzyYyZ68wOdWMlPXu5kbta7rlskI NoaOrDEcjbvzirNlLbIpePRxOpIvxem3f3vIXBf9Tjb4budC5GFO X-Google-Smtp-Source: AGHT+IHIc6k2eyrzHodJnFqtuZ+YlIGA4Muo1Wkh7d7Io/LnVQ8w/DXcLMDXe8Inhsm+xom5cuvl1g== X-Received: by 2002:a05:600c:1c88:b0:426:5e91:3920 with SMTP id 5b1f17b1804b1-42cdb5708a6mr59292705e9.29.1726245717416; Fri, 13 Sep 2024 09:41:57 -0700 (PDT) Received: from lili (roam-nat-fw-prg-194-254-61-41.net.univ-paris-diderot.fr. [194.254.61.41]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42d9b19493bsm31521445e9.45.2024.09.13.09.41.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Sep 2024 09:41:56 -0700 (PDT) From: Simon Tournier To: Ludovic =?utf-8?Q?Court=C3=A8s?= , 72839@debbugs.gnu.org Subject: Using RFC process? (was Re: [bug#72839] [PATCH RFC] DRAFT doc: Add =?utf-8?Q?=E2=80=9CDeprecation_Policy=E2=80=9D?= section.) In-Reply-To: <80f8b603ecd73cb9f46b1ea43797e143f16d2f17.1724785788.git.ludo@gnu.org> References: <80f8b603ecd73cb9f46b1ea43797e143f16d2f17.1724785788.git.ludo@gnu.org> Date: Fri, 13 Sep 2024 18:41:50 +0200 Message-ID: <874j6jv73l.fsf@gmail.com> 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: 72839 Cc: Ludovic =?utf-8?Q?Court=C3=A8s?= , Maxim Cournoyer , Florian Pelz , Matthew Trzcinski 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 (-) Hey! Cool but=E2=80=A6 On Tue, 27 Aug 2024 at 21:13, Ludovic Court=C3=A8s wrote: > Let=E2=80=99s discuss it with the goal of checking in an initial revision= by > next month. =E2=80=A6Well, I=E2=80=99m just aware of this only now =E2=80=93 thanks mas= todon! Why only guix-patches and not guix-devel? Or do I also missed it? BTW, that=E2=80=99s the typical subject for a RFC [1], IMHO. :-) 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 Cheers, simon From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 13 13:38:21 2024 Received: (at 72839) by debbugs.gnu.org; 13 Sep 2024 17:38:21 +0000 Received: from localhost ([127.0.0.1]:44221 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1spAFR-0005e6-7c 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: 72839 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:06 2024 Received: (at 72839) by debbugs.gnu.org; 13 Sep 2024 18:13:06 +0000 Received: from localhost ([127.0.0.1]:44236 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1spAn4-0007fh-Bk for submit@debbugs.gnu.org; Fri, 13 Sep 2024 14:13:06 -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: 72839 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 unknown Fri Jun 20 05:29:14 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