GNU logs - #57598, boring messages

Message sent to guix-patches@HIDDEN:

Subject: [bug#57598] [PATCH] doc: Update contribution guidelines on patches, etc.
Resent-From: Maxime Devos <maximedevos@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Mon, 05 Sep 2022 16:02:02 +0000
Resent-Message-ID: <handler.57598.B.166239366711180 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 57598 <at> debbugs.gnu.org
Cc: Maxime Devos <maximedevos@HIDDEN>
From: Maxime Devos <maximedevos@HIDDEN>
Date: Mon,  5 Sep 2022 18:00:48 +0200
Message-Id: <20220905160048.18173-1-maximedevos@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Received-SPF: pass client-ip=2a02:1800:110:4::f00:19;
 envelope-from=maximedevos@HIDDEN; helo=laurent.telenet-ops.be
X-Spam_score_int: -27
X-Spam_score: -2.8
X-Spam_bar: --
X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
 T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 0.1 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

* doc/contributing.texi (Modifying Sources): Replaced with ...
("Modifying Sources"): ... this.  List more use cases and some principles.

This patch incorporates some tet written by Liliana Marie Prikler.  The
structure is based on a proposal by Julien Lepiller.  The text has been
revised based on reviews by David Larsson and blake.
---
 doc/contributing.texi | 141 +++++++++++++++++++++++++++++++++++++-----
 doc/guix.texi         |   2 +-
 2 files changed, 127 insertions(+), 16 deletions(-)

diff --git a/doc/contributing.texi b/doc/contributing.texi
index 02c7c5ae59..f6bdb8a441 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -441,7 +441,7 @@ needed is to review and apply the patch.
 * Package Naming::              What's in a name?
 * Version Numbers::             When the name is not enough.
 * Synopses and Descriptions::   Helping users find the right package.
-* Snippets versus Phases::      Whether to use a snippet, or a build phase.
+* Modifying Sources::           Whether to use a snippet, or a build phase.
 * Emacs Packages::              Your Elisp fix.
 * Python Modules::              A touch of British comedy.
 * Perl Modules::                Little pearls.
@@ -698,20 +698,131 @@ Gettext}):
 for the X11 resize-and-rotate (RandR) extension. @dots{}")
 @end lisp
 
-@node Snippets versus Phases
-@subsection Snippets versus Phases
-
-@cindex snippets, when to use
-The boundary between using an origin snippet versus a build phase to
-modify the sources of a package can be elusive.  Origin snippets are
-typically used to remove unwanted files such as bundled libraries,
-nonfree sources, or to apply simple substitutions.  The source derived
-from an origin should produce a source that can be used to build the
-package on any system that the upstream package supports (i.e., act as
-the corresponding source).  In particular, origin snippets must not
-embed store items in the sources; such patching should rather be done
-using build phases.  Refer to the @code{origin} record documentation for
-more information (@pxref{origin Reference}).
+@node Modifying Sources
+@subsection Modifying Sources
+
+Guix has tree main ways of modifying the source code of a package, that
+you as a packager may use.  These are patches, snippets and phases.
+Each one has its strengths and drawbacks.  To decide between the tree,
+there are a few guiding principles that to satisfy simultanuously where
+possible:
+
+@itemize
+@item
+In principle, Guix only has free software; when the upstream source
+contains some non-free software, it has to be removed such that
+@command{guix build --source} returns the ‘freed’ source code rather than
+the unmodified upstream source (@pxref{Software Freedom}).
+@item
+The source of the package needs to correspond to what is actually built
+(i.e., act as the corresponding source), to fulfill our ethical and
+legal obligations.
+@item
+It is convenient for the source derived from an origin to build on any
+system that the upstream package supports.
+@item
+The source needs to actually work, not only on your Guix system but also
+for other systems; this requires some care for substitutions involving
+store items and other architecture-specific changes.
+@item
+When there is more than one way to do something, choose whichever method
+is the simplest.  Sometimes this is subjective, which is also fine.
+What matters is that you use techniques that are common within the
+community (i.e., patterns that appear throughout @code{gnu/packages/...})
+and are thus clearly legible for reviewers.
+@end itemize
+
+To make things more concrete and to resolve conflicts between the
+principles, a few cases have been worked out:
+
+@subsubsection Removing non-free software
+Non-free software has to be removed in snippets; the reason is that
+patches or phases will not work.
+
+For patches, the problem is that a patch removing a non-free file
+automatically contains the non-free file@footnote{It has been noted that
+git patches support removing files without including the file in the
+patch in
+@url{https://yhetil.org/guix/8b13e899-eb60-490b-a268-639249698c81@@www.fastmail.com/}. If
+it is verified that the @command{patch} utility supports such patches,
+this method can be used and this policy adjusted appropriately.}, and we
+do not want anything non-free in Guix even if only in its patches.
+
+For phases, the problem is that phases do not influence the result of
+@command{guix build --source}.
+
+@subsubsection Removing bundled libraries
+Bundled libraries should not be removed with patches, because then the
+patch would contain the full bundled library, which can be large. They
+can be removed either in snippets or phases, often using the procedure
+@code{delete-file-recursively}. There are a few benefits for snippets here:
+
+When using snippets, the bundled library does not occur in the source
+returned by @code{guix build --source}, so users and reviewers do not
+have to worry about whether the bundled library contains malware,
+whether it is non-free, if it contains pre-compiled binaries ... There
+are also less licensing concerns: if the bundled libraries are removed,
+it becomes less likely that the licensing conditions apply to people
+sharing the source returned by @command{guix build --source}, especially if
+the bundled library is not actually used on Guix systems.@footnote{This
+is @emph{not} a claim that you can simply ignore the licenses of
+libraries when they are unbundled and replaced by Guix packages -- there
+are less concerns, not none.}
+
+As such, snippets are recommended here.
+
+@subsubsection Fixing technical issues (compilation errors, test failures, other bugs ...)
+Usually, a bug fix comes in the form of a patch copied from upstream or
+another distribution.  In that case, simply adding the patch to the
+@code{patches} field is the most convenient and usually does not cause
+any problems; there is no need to rewrite it as a snippet or a phase.
+
+If no ready-made patch already exists, then choosing between a patch or
+a snippet is a matter of convenience. However, there are two things to
+keep in mind:
+
+First, when the fix is not Guix-specific, upstreaming the fix is
+strongly desired to avoid the additional maintenance cost to Guix.  As
+upstreams cannot accept snippets, writing a patch can be a more
+efficient use of time.  Secondly, if the fix of a technical issue embeds
+a store file name, then it has to be a phase.  Otherwise, if the store
+file name were embedded in the source, the result of @command{guix build
+--source} would be unusable on non-Guix systems and also likely unusable
+on Guix systems of another architecture.
+
+@subsubsection Adding new functionality
+To add new functionality, a patch is almost always the most convenient
+choice of the three -- patches are usually multi-line changes, which are
+convenient to do with patches and inconvenient to do with phases or
+snippets.  This choice is usually also compatible with all the guiding
+principles.  As such, patches are preferred.  However, as with bug
+fixes, upstreaming the new functionality is desired.
+
+@subsection How to add patches
+Refer to the @code{origin} record documentation (particularly the fields
+@code{patches}, @code{patch-inputs}, and @code{patch-flags}) for
+information on how to use patches (@pxref{origin Reference}).  When
+adding a patch, do not forget to also list it in @code{dist_patch_DATA}
+of @file{gnu/local.mk}.
+
+@subsection How to add files
+New source files can be added in phases or snippets, by using
+@b{auxiliarry files}.  Auxiliary files are stored in the
+@file{gnu/packages/aux-files} directory and can be retrieved (in a
+snippet or a phase) with @code{search-auxiliary-file}.  When adding an
+auxiliary file, do not forget to also list it in @code{AUX_FILES} of
+@file{Makefile.am}.
+
+Another option for adding new files, is to use procedures such as
+@code{display}, @code{format} and @code{call-with-output-file}.  As a
+matter of principle, auxiliary files ought to be preferred over an
+equivalent @code{call-with-output-file} when creating non-trivil files,
+as that makes them easier to edit.  The exact threshold for a
+non-trivial file might be subjective, though it should lie somewhere
+between 10--20 lines.
+
+Currently, there is no policy on deciding between phase and snippets for
+adding new files, except for the guiding principles.
 
 @node Emacs Packages
 @subsection Emacs Packages
diff --git a/doc/guix.texi b/doc/guix.texi
index 7bce8a567c..042ab3bd8a 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -70,7 +70,7 @@ Copyright @copyright{} 2019 Jakob L. Kreuze@*
 Copyright @copyright{} 2019 Kyle Andrews@*
 Copyright @copyright{} 2019 Alex Griffin@*
 Copyright @copyright{} 2019, 2020, 2021, 2022 Guillaume Le Vaillant@*
-Copyright @copyright{} 2020 Liliana Marie Prikler@*
+Copyright @copyright{} 2020, 2022 Liliana Marie Prikler@*
 Copyright @copyright{} 2019, 2020, 2021, 2022 Simon Tournier@*
 Copyright @copyright{} 2020 Wiktor Żelazny@*
 Copyright @copyright{} 2020 Damien Cassou@*

base-commit: 57f8f69562e942557e3331bb81c7e4acd973d189
prerequisite-patch-id: 78c06b38a189109a5108a157d39ffe7eab8be109
prerequisite-patch-id: aaf0731113d36df901ed2186975e3bb872ec22c0
prerequisite-patch-id: 28e8223cfd59adf84007db9ceefd8a78c41fd10d
prerequisite-patch-id: fb73228d99c36f50e2959c2303c7c707460fd147
prerequisite-patch-id: 7626f1464f4926416fb13daf3d846176aa93f51b
prerequisite-patch-id: 445c6f624e99627959f2e54a6ee97337c44d9ea6
prerequisite-patch-id: 7a16c500faec9d58700a2b50b26bded079e9c3ac
prerequisite-patch-id: f7d406c61e069c04c3b7da453192f51c04763db1
prerequisite-patch-id: 4674bf40052d97215f837c9dfd4e7e1ae999492d
prerequisite-patch-id: 6259468375bfa157277521b17fdd97d6ab0748b7
prerequisite-patch-id: 9d14b38a33b68883c43d6b26dcdbdf7c28e417e7
prerequisite-patch-id: f0e3faffe768e9c660b0a9340042acfa0f790308
prerequisite-patch-id: 550485506255a67c0a1cb9ede7778d4d538b6e2a
prerequisite-patch-id: 9282e95ff076cc2c742be8d2fede83ac14006f6f
prerequisite-patch-id: 1503aa5c698f72ee47b7a987a95c0919efb203c4
prerequisite-patch-id: 24297940086a3780fd7e2e7fa345f262b12efb6f
prerequisite-patch-id: c5f647b5472465666328b123f0f314a6138d6293
prerequisite-patch-id: 56386c4df9130221cad664ec161d1ad9713f4dc3
prerequisite-patch-id: f09ccfb7e53bc7934326af603a197344f4ef53f3
prerequisite-patch-id: 0c18c83d1f2da4639b43861103a028706a147022
prerequisite-patch-id: 066bfca8bf0c3d3bc57a14b48aa1e241555c1e86
prerequisite-patch-id: 13d9ac7b0fadc92b9351409df26b41443497a964
prerequisite-patch-id: ad831a04543475288aba1c938078dcc5ad05870e
prerequisite-patch-id: ed9ec2d0bea23c2c2dbfa4c62290893f1a938f7f
prerequisite-patch-id: 335ce9dbbb2b36b960203a79fdc8f6033ebda2fb
prerequisite-patch-id: f2ca362056369913d0b8319187a8f46ea78b6dc7
prerequisite-patch-id: c02a17479ad4e01837fc307cf6defe0ae92e2435
prerequisite-patch-id: 3a794307f3bbd3641023d978f4b359eb2f5a46e4
prerequisite-patch-id: c545007535db365a29dc3a86e10866f5eef7b7d5
prerequisite-patch-id: 8b8fd18762282129e2d034f7cdceb368f53295d6
prerequisite-patch-id: d435d42bafa65f14049740a3d6cf1a163f855f97
prerequisite-patch-id: 27da1b857019b217b25b6795b84577fdc992a84c
prerequisite-patch-id: aef95e76144ae5e92a41f81b11e84ddc7ececd91
prerequisite-patch-id: 95aa6b45d93026e4375b53a471f0f96e2016914e
prerequisite-patch-id: 715d2bb93fe711e72388458846a0afde6babdc97
prerequisite-patch-id: 63422b710539c3eeac249bf0201107914a215d16
prerequisite-patch-id: 53c9d2236538f9a9009b5b7b2455ef4875d0e31a
prerequisite-patch-id: 37df0e9658435e0a5e2b49fe54a69b91385fb596
prerequisite-patch-id: d2ecaf3439d153de1d53f608e7f5815c73d7b93c
-- 
2.37.2

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Maxime Devos <maximedevos@HIDDEN>
Subject: bug#57598: Acknowledgement ([PATCH] doc: Update contribution
 guidelines on patches, etc.)
Message-ID: <handler.57598.B.166239366711180.ack <at> debbugs.gnu.org>
References: <20220905160048.18173-1-maximedevos@HIDDEN>
X-Gnu-PR-Message: ack 57598
X-Gnu-PR-Package: guix-patches
X-Gnu-PR-Keywords: patch
Reply-To: 57598 <at> debbugs.gnu.org
Date: Mon, 05 Sep 2022 16:02:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 guix-patches@HIDDEN

If you wish to submit further information on this problem, please
send it to 57598 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
57598: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D57598
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to guix-patches@HIDDEN:

Subject: [bug#57598] [PATCH] doc: Update contribution guidelines on patches, etc.
Resent-From: Maxime Devos <maximedevos@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Mon, 05 Sep 2022 16:05:01 +0000
Resent-Message-ID: <handler.57598.B57598.166239387611600 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 57598 <at> debbugs.gnu.org
Message-ID: <af31b3f4-b3da-6037-0232-ce18cc315847@HIDDEN>
Date: Mon, 5 Sep 2022 18:04:32 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.12.0
Content-Language: en-US
References: <20220905160048.18173-1-maximedevos@HIDDEN>
From: Maxime Devos <maximedevos@HIDDEN>
In-Reply-To: <20220905160048.18173-1-maximedevos@HIDDEN>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------9PE0NeYvpkrEq4ClQkcSqD9K"
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------9PE0NeYvpkrEq4ClQkcSqD9K
Content-Type: multipart/mixed; boundary="------------imrO1rPoHPpkXkVxDoogeyWv";
 protected-headers="v1"
From: Maxime Devos <maximedevos@HIDDEN>
To: 57598 <at> debbugs.gnu.org
Message-ID: <af31b3f4-b3da-6037-0232-ce18cc315847@HIDDEN>
Subject: Re: [PATCH] doc: Update contribution guidelines on patches, etc.
References: <20220905160048.18173-1-maximedevos@HIDDEN>
In-Reply-To: <20220905160048.18173-1-maximedevos@HIDDEN>

--------------imrO1rPoHPpkXkVxDoogeyWv
Content-Type: multipart/mixed; boundary="------------HS8VwQD1bKu4RzpvrCKxNxhV"

--------------HS8VwQD1bKu4RzpvrCKxNxhV
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

U2VlIHRoZSB0aHJlYWQgDQo8aHR0cHM6Ly95aGV0aWwub3JnL2d1aXgvMDNhMjgyNjItMzE2
ZC0yMGZjLWVhOTEtNTM3OWM3NDM2MmIxQHRlbGVuZXQuYmUvPi4NCg0KVGhlcmUgaXMgYWxz
byBhbm90aGVyIHBhdGNoIA0KPGh0dHBzOi8veWhldGlsLm9yZy9ndWl4LzFkY2NhNTc1NTgw
NjI0ZGRjYzIwODg4M2VlNjJkOGM3NWY5MDgxMzkuY2FtZWxAZ21haWwuY29tLz4sIA0Kd2hp
Y2ggZG9jdW1lbnRzIHRoZSBzYW1lIHRoaW5nLCBidXQgZGlmZmVyZW50bHkuDQoNCkdyZWV0
aW5ncywNCk1heGltZQ0K
--------------HS8VwQD1bKu4RzpvrCKxNxhV
Content-Type: application/pgp-keys; name="OpenPGP_0x49E3EE22191725EE.asc"
Content-Disposition: attachment; filename="OpenPGP_0x49E3EE22191725EE.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xjMEX4ch6BYJKwYBBAHaRw8BAQdANPb/d6MrGnGi5HyvODCkBUJPRjiFQcRU5V+m
xvMaAa/NL01heGltZSBEZXZvcyA8bWF4aW1lLmRldm9zQHN0dWRlbnQua3VsZXV2
ZW4uYmU+wpAEExYIADgWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCX4ch6AIbAwUL
CQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRBJ4+4iGRcl7japAQC3opZ2KGWzWmRc
/gIWSu0AAcfMwyinFEEPa/QhUt2CogD/e2RdF4CYAgaRHJJmZ9WU7piKbLZ7llB4
LzgezVDHggzNJU1heGltZSBEZXZvcyA8bWF4aW1lZGV2b3NAdGVsZW5ldC5iZT7C
kAQTFggAOBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJf56ycAhsDBQsJCAcDBRUK
CQgLBRYCAwEAAh4BAheAAAoJEEnj7iIZFyXujpQBAKV1SwDDl4f24rXciDlB9L8W
ycZt30CgbewMSRQk4mvbAP9dFMbVVixYBd6C8cfhR+NsOBGiOJnQABlUmgNuqGFJ
Dc44BF+HIegSCisGAQQBl1UBBQEBB0BOlzIWiJzgobMF6/cqwLaLk7jIcFSZ++c0
k9cCNT6YXwMBCAfCeAQYFggAIBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJfhyHo
AhsMAAoJEEnj7iIZFyXuMr0BAJc8cl5PGvVmVuSQVKjleNl4DK1/XAaPAYPe34AE
fZJPAP9IqLCQhH/FeJanHqBP8gNdGNI2qn8RnnLVfRJgUjZ1BA=3D=3D
=3DOVqp
-----END PGP PUBLIC KEY BLOCK-----

--------------HS8VwQD1bKu4RzpvrCKxNxhV--

--------------imrO1rPoHPpkXkVxDoogeyWv--

--------------9PE0NeYvpkrEq4ClQkcSqD9K
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wnsEABYIACMWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYxYeEAUDAAAAAAAKCRBJ4+4iGRcl7kJR
AQD2D1RcH32u+syWAHDP91rOjDdvl8g+gokXNnISDiEOVwD9FRq8sVXqerK2QdLjKUU8Cu6rdjMy
mM0ojNtvoj/8aQI=
=k2zR
-----END PGP SIGNATURE-----

--------------9PE0NeYvpkrEq4ClQkcSqD9K--

Message sent to guix-patches@HIDDEN:

Subject: [bug#57598] [PATCH] doc: Update contribution guidelines on patches, etc.
Resent-From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Tue, 06 Sep 2022 11:35:02 +0000
Resent-Message-ID: <handler.57598.B57598.166246405211485 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Maxime Devos <maximedevos@HIDDEN>, 57598 <at> debbugs.gnu.org
Message-ID: <0f78953d57d8f66a934baf518b7c9e3247b580fd.camel@HIDDEN>
From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
Date: Tue, 06 Sep 2022 13:33:49 +0200
In-Reply-To: <20220905160048.18173-1-maximedevos@HIDDEN>
References: <20220905160048.18173-1-maximedevos@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.1 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Am Montag, dem 05.09.2022 um 18:00 +0200 schrieb Maxime Devos:
> +Guix has tree main ways of modifying the source code of a package,
> that
> +you as a packager may use.  These are patches, snippets and phases.
> +Each one has its strengths and drawbacks.  To decide between the tree,
three
> +there are a few guiding principles that to satisfy simultanuously
> where
> +possible:
"there are a few guiding principles to satisfy simultaneously",
"there are some guiding principles, of which as many as possible should
be satisfied".
> +
> +@itemize
> +@item
> +In principle, Guix only has free software; when the upstream source
> +contains some non-free software, it has to be removed such that
> +@command{guix build --source} returns the ‘freed’ source code rather
> than
> +the unmodified upstream source (@pxref{Software Freedom}).
If the latter wording above is chosen, this is not a "guiding
principle", because it is non-negotiable.
> +@item
> +The source of the package needs to correspond to what is actually
> built
> +(i.e., act as the corresponding source), to fulfill our ethical and
> +legal obligations.
> +@item
> +It is convenient for the source derived from an origin to build on any
> +system that the upstream package supports.
> +@item
> +The source needs to actually work, not only on your Guix system but
> also
> +for other systems; this requires some care for substitutions involving
> +store items and other architecture-specific changes.
If you embed store items, it won't even work on Guix System 😛️

Also, this appears to be a rather convenient rewording of the previous
item, does it not?
> +@item
> +When there is more than one way to do something, choose whichever
> method
> +is the simplest.  Sometimes this is subjective, which is also fine.
> +What matters is that you use techniques that are common within the
> +community (i.e., patterns that appear throughout
> @code{gnu/packages/...})
> +and are thus clearly legible for reviewers.
> +@end itemize
> +
> +To make things more concrete and to resolve conflicts between the
> +principles, a few cases have been worked out:
> +
> +@subsubsection Removing non-free software
> +Non-free software has to be removed in snippets; the reason is that
> +patches or phases will not work.
> +
> +For patches, the problem is that a patch removing a non-free file
> +automatically contains the non-free file@footnote{It has been noted
> that
> +git patches support removing files without including the file in the
> +patch in
> +@url{
> https://yhetil.org/guix/8b13e899-eb60-490b-a268-639249698c81@@www.fastmail.com/
> }. If
> +it is verified that the @command{patch} utility supports such patches,
> +this method can be used and this policy adjusted appropriately.}, and
> we
> +do not want anything non-free in Guix even if only in its patches.
We also avoid spelling out the non-free filename where possible,
preferring keep lists over remove lists, which this kind of patches
would be.

> +For phases, the problem is that phases do not influence the result of
> +@command{guix build --source}.
> +
> +@subsubsection Removing bundled libraries
> +Bundled libraries should not be removed with patches, because then the
> +patch would contain the full bundled library, which can be large. They
> +can be removed either in snippets or phases, often using the procedure
> +@code{delete-file-recursively}. There are a few benefits for snippets
> here:
> +
> +When using snippets, the bundled library does not occur in the source
> +returned by @code{guix build --source}, so users and reviewers do not
> +have to worry about whether the bundled library contains malware,
> +whether it is non-free, if it contains pre-compiled binaries ... There
> +are also less licensing concerns: if the bundled libraries are
> removed,
> +it becomes less likely that the licensing conditions apply to people
> +sharing the source returned by @command{guix build --source},
> especially if
> +the bundled library is not actually used on Guix
> systems.@footnote{This
> +is @emph{not} a claim that you can simply ignore the licenses of
> +libraries when they are unbundled and replaced by Guix packages --
> there
> +are less concerns, not none.}
> +
> +As such, snippets are recommended here.
> +
> +@subsubsection Fixing technical issues (compilation errors, test
> failures, other bugs ...)
> +Usually, a bug fix comes in the form of a patch copied from upstream
> or
> +another distribution.  In that case, simply adding the patch to the
> +@code{patches} field is the most convenient and usually does not cause
> +any problems; there is no need to rewrite it as a snippet or a phase.
> +
> +If no ready-made patch already exists, then choosing between a patch
> or
> +a snippet is a matter of convenience. However, there are two things to
> +keep in mind:
> +
> +First, when the fix is not Guix-specific, upstreaming the fix is
> +strongly desired to avoid the additional maintenance cost to Guix.  As
> +upstreams cannot accept snippets, writing a patch can be a more
> +efficient use of time.  Secondly, if the fix of a technical issue
> embeds
> +a store file name, then it has to be a phase.  
I am pretty sure that most of these are *not* done in snippets, but
rather phases, if they only affect Guix.  In particular, grep for
failing-tests and you will find a few phases disabling them.  In fact,
as far as files that will not be installed are concerned, I think
phases ought to be preferred, because they're easier to take away if an
actual fix is made.

For the store path embedding, that's a rather roundabout way of saying
that contributers *ought to* embed store paths of certaing things, such
as commands invoked via exec et al.

> Otherwise, if the store
> +file name were embedded in the source, the result of @command{guix
> build
> +--source} would be unusable on non-Guix systems and also likely
> unusable
> +on Guix systems of another architecture.
Why are you repeating a guiding principle?

> +@subsubsection Adding new functionality
> +To add new functionality, a patch is almost always the most convenient
> +choice of the three -- patches are usually multi-line changes, which
> are
> +convenient to do with patches and inconvenient to do with phases or
> +snippets.
Uhm, what?  Patches are the preferred form of patches?

>   This choice is usually also compatible with all the guiding
> +principles.  As such, patches are preferred.  However, as with bug
> +fixes, upstreaming the new functionality is desired.
> +
> +@subsection How to add patches
> +Refer to the @code{origin} record documentation (particularly the
> fields
> +@code{patches}, @code{patch-inputs}, and @code{patch-flags}) for
> +information on how to use patches (@pxref{origin Reference}).  When
> +adding a patch, do not forget to also list it in
> @code{dist_patch_DATA}
> +of @file{gnu/local.mk}.
I don't think this should be a subsection.

> +@subsection How to add files
> +New source files can be added in phases or snippets, by using
> +@b{auxiliarry files}.  Auxiliary files are stored in the
> +@file{gnu/packages/aux-files} directory and can be retrieved (in a
> +snippet or a phase) with @code{search-auxiliary-file}.  When adding an
> +auxiliary file, do not forget to also list it in @code{AUX_FILES} of
> +@file{Makefile.am}.
> +
> +Another option for adding new files, is to use procedures such as
> +@code{display}, @code{format} and @code{call-with-output-file}.  As a
> +matter of principle, auxiliary files ought to be preferred over an
> +equivalent @code{call-with-output-file} when creating non-trivil
> files,
> +as that makes them easier to edit.  The exact threshold for a
> +non-trivial file might be subjective, though it should lie somewhere
> +between 10--20 lines.
> +
> +Currently, there is no policy on deciding between phase and snippets
> for
> +adding new files, except for the guiding principles.
This should probably be a subsubsection after "Adding new
functionality" or explained within "Adding new functionality".

Overall, I'm not convinced that we have enough guiding principles to
call them that, which (along with its sheer length) is my main
complaint with the way you've phrased things.  Going down to
subsubsections just to find out where patches are appropriate, is imho
overkill.

Cheers

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#57598] [PATCH] doc: Update contribution guidelines on patches, etc.
Resent-From: Maxime Devos <maximedevos@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Tue, 06 Sep 2022 20:22:02 +0000
Resent-Message-ID: <handler.57598.B57598.16624956782084 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 57598
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Liliana Marie Prikler <liliana.prikler@HIDDEN>, 57598 <at> debbugs.gnu.org
Received: via spool by 57598-submit <at> debbugs.gnu.org id=B57598.16624956782084
          (code B ref 57598); Tue, 06 Sep 2022 20:22:02 +0000
Received: (at 57598) by debbugs.gnu.org; 6 Sep 2022 20:21:18 +0000
Received: from localhost ([127.0.0.1]:52801 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oVf4P-0000XW-2v
	for submit <at> debbugs.gnu.org; Tue, 06 Sep 2022 16:21:18 -0400
Received: from michel.telenet-ops.be ([195.130.137.88]:39050)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <maximedevos@HIDDEN>) id 1oVf4M-0000XM-9f
 for 57598 <at> debbugs.gnu.org; Tue, 06 Sep 2022 16:21:16 -0400
Received: from [IPV6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16]
 ([IPv6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16])
 by michel.telenet-ops.be with bizsmtp
 id GkMB2800H20ykKC06kMBVn; Tue, 06 Sep 2022 22:21:12 +0200
Message-ID: <d0a48b72-c62b-cc97-e399-22abc0af182d@HIDDEN>
Date: Tue, 6 Sep 2022 22:21:11 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.12.0
Content-Language: en-US
References: <20220905160048.18173-1-maximedevos@HIDDEN>
 <0f78953d57d8f66a934baf518b7c9e3247b580fd.camel@HIDDEN>
From: Maxime Devos <maximedevos@HIDDEN>
In-Reply-To: <0f78953d57d8f66a934baf518b7c9e3247b580fd.camel@HIDDEN>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------NLNRqI000ekw60aGGVxBGoXf"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r22;
 t=1662495672; bh=tr8EL3KA3vekhc/xYcxJ8meZq/gKoXYrOpKkpe/CptY=;
 h=Date:To:References:From:Subject:In-Reply-To;
 b=KMD1/DEbTAQ7r2FxcZHUlcqMOdVcFTMvPtyxJ6EQtXWSe+ASvR+U/kfPInNHximKt
 yqtkyMOyqE33UB/xtv75mwgKkhAMZKLodnFPPvAcmdoOk6Wv+B8VR0ZC/mMxTXyLwV
 qNg+f475gniCm3tLwLE0y9/06CyEaBh7oslbUvx6p8d6yssbYjdTNbdqv4fd4vxdJJ
 QJOqXPCBXkHIh0pZXr2YszmZOdDzbezwmYygQErU81L7BEWinGBF9NMz6wmPB1viy2
 X95ux8xGNHzXpSwO53JesOi1p3iKudzmpne1tsb50jk3OQGknj87eV9V4TRjRE6Yv2
 VQ1KOTCznpDhg==
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------NLNRqI000ekw60aGGVxBGoXf
Content-Type: multipart/mixed; boundary="------------mg1vH0aCGVVMzb0Ns8xAZUcB";
 protected-headers="v1"
From: Maxime Devos <maximedevos@HIDDEN>
To: Liliana Marie Prikler <liliana.prikler@HIDDEN>,
 57598 <at> debbugs.gnu.org
Message-ID: <d0a48b72-c62b-cc97-e399-22abc0af182d@HIDDEN>
Subject: Re: [PATCH] doc: Update contribution guidelines on patches, etc.
References: <20220905160048.18173-1-maximedevos@HIDDEN>
 <0f78953d57d8f66a934baf518b7c9e3247b580fd.camel@HIDDEN>
In-Reply-To: <0f78953d57d8f66a934baf518b7c9e3247b580fd.camel@HIDDEN>

--------------mg1vH0aCGVVMzb0Ns8xAZUcB
Content-Type: multipart/mixed; boundary="------------8K9TKb9cQWdHijgVuosbMcLl"

--------------8K9TKb9cQWdHijgVuosbMcLl
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMDYtMDktMjAyMiAxMzozMywgTGlsaWFuYSBNYXJpZSBQcmlrbGVyIHdyb3RlOg0KDQo+
IEFtIE1vbnRhZywgZGVtIDA1LjA5LjIwMjIgdW0gMTg6MDAgKzAyMDAgc2NocmllYiBNYXhp
bWUgRGV2b3M6DQo+PiArR3VpeCBoYXMgdHJlZSBtYWluIHdheXMgb2YgbW9kaWZ5aW5nIHRo
ZSBzb3VyY2UgY29kZSBvZiBhIHBhY2thZ2UsDQo+PiB0aGF0DQo+PiAreW91IGFzIGEgcGFj
a2FnZXIgbWF5IHVzZS7CoCBUaGVzZSBhcmUgcGF0Y2hlcywgc25pcHBldHMgYW5kIHBoYXNl
cy4NCj4+ICtFYWNoIG9uZSBoYXMgaXRzIHN0cmVuZ3RocyBhbmQgZHJhd2JhY2tzLsKgIFRv
IGRlY2lkZSBiZXR3ZWVuIHRoZSB0cmVlLA0KPiB0aHJlZQ0KUmlnaHQuDQo+PiArdGhlcmUg
YXJlIGEgZmV3IGd1aWRpbmcgcHJpbmNpcGxlcyB0aGF0IHRvIHNhdGlzZnkgc2ltdWx0YW51
b3VzbHkNCj4+IHdoZXJlDQo+PiArcG9zc2libGU6DQo+ICJ0aGVyZSBhcmUgYSBmZXcgZ3Vp
ZGluZyBwcmluY2lwbGVzIHRvIHNhdGlzZnkgc2ltdWx0YW5lb3VzbHkiLA0KPiAidGhlcmUg
YXJlIHNvbWUgZ3VpZGluZyBwcmluY2lwbGVzLCBvZiB3aGljaCBhcyBtYW55IGFzIHBvc3Np
YmxlIHNob3VsZA0KPiBiZSBzYXRpc2ZpZWQiLg0KPj4gKw0KPj4gK0BpdGVtaXplDQo+PiAr
QGl0ZW0NCj4+ICtJbiBwcmluY2lwbGUsIEd1aXggb25seSBoYXMgZnJlZSBzb2Z0d2FyZTsg
d2hlbiB0aGUgdXBzdHJlYW0gc291cmNlDQo+PiArY29udGFpbnMgc29tZSBub24tZnJlZSBz
b2Z0d2FyZSwgaXQgaGFzIHRvIGJlIHJlbW92ZWQgc3VjaCB0aGF0DQo+PiArQGNvbW1hbmR7
Z3VpeCBidWlsZCAtLXNvdXJjZX0gcmV0dXJucyB0aGUg4oCYZnJlZWTigJkgc291cmNlIGNv
ZGUgcmF0aGVyDQo+PiB0aGFuDQo+PiArdGhlIHVubW9kaWZpZWQgdXBzdHJlYW0gc291cmNl
IChAcHhyZWZ7U29mdHdhcmUgRnJlZWRvbX0pLg0KPiBJZiB0aGUgbGF0dGVyIHdvcmRpbmcg
YWJvdmUgaXMgY2hvc2VuLCB0aGlzIGlzIG5vdCBhICJndWlkaW5nDQo+IHByaW5jaXBsZSIs
IGJlY2F1c2UgaXQgaXMgbm9uLW5lZ290aWFibGUuDQpJJ2xsIGdvIGZvciBmaXJzdCBvcHRp
b24sICJ0aGVyZSBhcmUgYSBmZXcgZ3VpZGluZyBwcmluY2lwbGVzIHRvIHNhdGlzZnkNCnNp
bXVsdGFuZW91c2x5IHdoZXJlIHBvc3NpYmxlIiwgZHJvcHBpbmcgdGhlIG1pc3BsYWNlZCAi
dG8iLg0KPj4gK0BpdGVtDQo+PiArVGhlIHNvdXJjZSBvZiB0aGUgcGFja2FnZSBuZWVkcyB0
byBjb3JyZXNwb25kIHRvIHdoYXQgaXMgYWN0dWFsbHkNCj4+IGJ1aWx0DQo+PiArKGkuZS4s
IGFjdCBhcyB0aGUgY29ycmVzcG9uZGluZyBzb3VyY2UpLCB0byBmdWxmaWxsIG91ciBldGhp
Y2FsIGFuZA0KPj4gK2xlZ2FsIG9ibGlnYXRpb25zLg0KPj4gK0BpdGVtDQo+PiArSXQgaXMg
Y29udmVuaWVudCBmb3IgdGhlIHNvdXJjZSBkZXJpdmVkIGZyb20gYW4gb3JpZ2luIHRvIGJ1
aWxkIG9uIGFueQ0KPj4gK3N5c3RlbSB0aGF0IHRoZSB1cHN0cmVhbSBwYWNrYWdlIHN1cHBv
cnRzLg0KPj4gK0BpdGVtDQo+PiArVGhlIHNvdXJjZSBuZWVkcyB0byBhY3R1YWxseSB3b3Jr
LCBub3Qgb25seSBvbiB5b3VyIEd1aXggc3lzdGVtIGJ1dA0KPj4gYWxzbw0KPj4gK2ZvciBv
dGhlciBzeXN0ZW1zOyB0aGlzIHJlcXVpcmVzIHNvbWUgY2FyZSBmb3Igc3Vic3RpdHV0aW9u
cyBpbnZvbHZpbmcNCj4+ICtzdG9yZSBpdGVtcyBhbmQgb3RoZXIgYXJjaGl0ZWN0dXJlLXNw
ZWNpZmljIGNoYW5nZXMuDQo+IElmIHlvdSBlbWJlZCBzdG9yZSBpdGVtcywgaXQgd29uJ3Qg
ZXZlbiB3b3JrIG9uIEd1aXggU3lzdGVtIPCfmJvvuI8NCg0KSXQgZG9lcywgdGhvdWdoPyBD
b25kaXRpb25hbCBvbiBubyAtLXN5c3RlbSBhbmQgbm8gLS10YXJnZXQuIFRob3VnaCBnaXZl
bg0KdGhlIHRoaXJkIEBpdGVtLCBkb2Vzbid0IG1hdHRlci4NCg0KPiBBbHNvLCB0aGlzIGFw
cGVhcnMgdG8gYmUgYSByYXRoZXIgY29udmVuaWVudCByZXdvcmRpbmcgb2YgdGhlIHByZXZp
b3VzDQo+IGl0ZW0sIGRvZXMgaXQgbm90Pw0KSSB0aGluayB0aGF0IHdpdGggdGhlIGZpcnN0
LCBJIHJlZmVycmVkIHRvIHN5c3RlbXMgaW4gdGhlIHNlbnNlIG9mDQotLXN5c3RlbSAvIC0t
dGFyZ2V0LCBhbmQgdGhhdCB3aXRoIHRoZSBzZWNvbmQgSSBtZWFudCBkaXN0cmlidXRpb25z
LA0KdGhvdWdoIHllcy4gSSdsbCBsb29rIGludG8gdW5pZnlpbmcgdGhlIHR3by4NCj4+ICtA
aXRlbQ0KPj4gK1doZW4gdGhlcmUgaXMgbW9yZSB0aGFuIG9uZSB3YXkgdG8gZG8gc29tZXRo
aW5nLCBjaG9vc2Ugd2hpY2hldmVyDQo+PiBtZXRob2QNCj4+ICtpcyB0aGUgc2ltcGxlc3Qu
wqAgU29tZXRpbWVzIHRoaXMgaXMgc3ViamVjdGl2ZSwgd2hpY2ggaXMgYWxzbyBmaW5lLg0K
Pj4gK1doYXQgbWF0dGVycyBpcyB0aGF0IHlvdSB1c2UgdGVjaG5pcXVlcyB0aGF0IGFyZSBj
b21tb24gd2l0aGluIHRoZQ0KPj4gK2NvbW11bml0eSAoaS5lLiwgcGF0dGVybnMgdGhhdCBh
cHBlYXIgdGhyb3VnaG91dA0KPj4gQGNvZGV7Z251L3BhY2thZ2VzLy4uLn0pDQo+PiArYW5k
IGFyZSB0aHVzIGNsZWFybHkgbGVnaWJsZSBmb3IgcmV2aWV3ZXJzLg0KPj4gK0BlbmQgaXRl
bWl6ZQ0KPj4gKw0KPj4gK1RvIG1ha2UgdGhpbmdzIG1vcmUgY29uY3JldGUgYW5kIHRvIHJl
c29sdmUgY29uZmxpY3RzIGJldHdlZW4gdGhlDQo+PiArcHJpbmNpcGxlcywgYSBmZXcgY2Fz
ZXMgaGF2ZSBiZWVuIHdvcmtlZCBvdXQ6DQo+PiArDQo+PiArQHN1YnN1YnNlY3Rpb24gUmVt
b3Zpbmcgbm9uLWZyZWUgc29mdHdhcmUNCj4+ICtOb24tZnJlZSBzb2Z0d2FyZSBoYXMgdG8g
YmUgcmVtb3ZlZCBpbiBzbmlwcGV0czsgdGhlIHJlYXNvbiBpcyB0aGF0DQo+PiArcGF0Y2hl
cyBvciBwaGFzZXMgd2lsbCBub3Qgd29yay4NCj4+ICsNCj4+ICtGb3IgcGF0Y2hlcywgdGhl
IHByb2JsZW0gaXMgdGhhdCBhIHBhdGNoIHJlbW92aW5nIGEgbm9uLWZyZWUgZmlsZQ0KPj4g
K2F1dG9tYXRpY2FsbHkgY29udGFpbnMgdGhlIG5vbi1mcmVlIGZpbGVAZm9vdG5vdGV7SXQg
aGFzIGJlZW4gbm90ZWQNCj4+IHRoYXQNCj4+ICtnaXQgcGF0Y2hlcyBzdXBwb3J0IHJlbW92
aW5nIGZpbGVzIHdpdGhvdXQgaW5jbHVkaW5nIHRoZSBmaWxlIGluIHRoZQ0KPj4gK3BhdGNo
IGluDQo+PiArQHVybHsNCj4+IGh0dHBzOi8veWhldGlsLm9yZy9ndWl4LzhiMTNlODk5LWVi
NjAtNDkwYi1hMjY4LTYzOTI0OTY5OGM4MUBAd3d3LmZhc3RtYWlsLmNvbS8NCj4+IH0uIElm
DQo+PiAraXQgaXMgdmVyaWZpZWQgdGhhdCB0aGUgQGNvbW1hbmR7cGF0Y2h9IHV0aWxpdHkg
c3VwcG9ydHMgc3VjaCBwYXRjaGVzLA0KPj4gK3RoaXMgbWV0aG9kIGNhbiBiZSB1c2VkIGFu
ZCB0aGlzIHBvbGljeSBhZGp1c3RlZCBhcHByb3ByaWF0ZWx5Ln0sIGFuZA0KPj4gd2UNCj4+
ICtkbyBub3Qgd2FudCBhbnl0aGluZyBub24tZnJlZSBpbiBHdWl4IGV2ZW4gaWYgb25seSBp
biBpdHMgcGF0Y2hlcy4NCj4gV2UgYWxzbyBhdm9pZCBzcGVsbGluZyBvdXQgdGhlIG5vbi1m
cmVlIGZpbGVuYW1lIHdoZXJlIHBvc3NpYmxlLA0KPiBwcmVmZXJyaW5nIGtlZXAgbGlzdHMg
b3ZlciByZW1vdmUgbGlzdHMsIHdoaWNoIHRoaXMga2luZCBvZiBwYXRjaGVzDQo+IHdvdWxk
IGJlLg0KU2hvdWxkIHdlPyBJJ20gbm90IHNlZWluZyB0aGUgcG9pbnQgb2YgdGhhdC4gSSBo
YXZlIG5vdCBleHBlcmllbmNlZCBhbnkNCnN1Y2ggYXZvaWRhbmNlIG15c2VsZiwgc2VlIGUu
Zy4gJ3Rlbm5peCcsICduZXZlcmJhbGwnIGFuZCAnc2hvZ3VuJy4gSXQgaXMsDQp0byBteSBr
bm93bGVkZ2UsIG5vdCBmb3JiaWRkZW4gdG8gbWVudGlvbiBub24tZnJlZSBzb2Z0d2FyZSBi
eSBuYW1lDQppbiBjb2RlLCBhcyBsb25nIGFzIGl0cyBub3QgYSByZWNvbW1lbmRhdGlvbiAo
ZXhwbGljaXQgb3IgaW1wbGllZCkuDQo+PiArRm9yIHBoYXNlcywgdGhlIHByb2JsZW0gaXMg
dGhhdCBwaGFzZXMgZG8gbm90IGluZmx1ZW5jZSB0aGUgcmVzdWx0IG9mDQo+PiArQGNvbW1h
bmR7Z3VpeCBidWlsZCAtLXNvdXJjZX0uDQo+PiArDQo+PiArQHN1YnN1YnNlY3Rpb24gUmVt
b3ZpbmcgYnVuZGxlZCBsaWJyYXJpZXMNCj4+ICtCdW5kbGVkIGxpYnJhcmllcyBzaG91bGQg
bm90IGJlIHJlbW92ZWQgd2l0aCBwYXRjaGVzLCBiZWNhdXNlIHRoZW4gdGhlDQo+PiArcGF0
Y2ggd291bGQgY29udGFpbiB0aGUgZnVsbCBidW5kbGVkIGxpYnJhcnksIHdoaWNoIGNhbiBi
ZSBsYXJnZS4gVGhleQ0KPj4gK2NhbiBiZSByZW1vdmVkIGVpdGhlciBpbiBzbmlwcGV0cyBv
ciBwaGFzZXMsIG9mdGVuIHVzaW5nIHRoZSBwcm9jZWR1cmUNCj4+ICtAY29kZXtkZWxldGUt
ZmlsZS1yZWN1cnNpdmVseX0uIFRoZXJlIGFyZSBhIGZldyBiZW5lZml0cyBmb3Igc25pcHBl
dHMNCj4+IGhlcmU6DQo+PiArDQo+PiArV2hlbiB1c2luZyBzbmlwcGV0cywgdGhlIGJ1bmRs
ZWQgbGlicmFyeSBkb2VzIG5vdCBvY2N1ciBpbiB0aGUgc291cmNlDQo+PiArcmV0dXJuZWQg
YnkgQGNvZGV7Z3VpeCBidWlsZCAtLXNvdXJjZX0sIHNvIHVzZXJzIGFuZCByZXZpZXdlcnMg
ZG8gbm90DQo+PiAraGF2ZSB0byB3b3JyeSBhYm91dCB3aGV0aGVyIHRoZSBidW5kbGVkIGxp
YnJhcnkgY29udGFpbnMgbWFsd2FyZSwNCj4+ICt3aGV0aGVyIGl0IGlzIG5vbi1mcmVlLCBp
ZiBpdCBjb250YWlucyBwcmUtY29tcGlsZWQgYmluYXJpZXMgLi4uIFRoZXJlDQo+PiArYXJl
IGFsc28gbGVzcyBsaWNlbnNpbmcgY29uY2VybnM6IGlmIHRoZSBidW5kbGVkIGxpYnJhcmll
cyBhcmUNCj4+IHJlbW92ZWQsDQo+PiAraXQgYmVjb21lcyBsZXNzIGxpa2VseSB0aGF0IHRo
ZSBsaWNlbnNpbmcgY29uZGl0aW9ucyBhcHBseSB0byBwZW9wbGUNCj4+ICtzaGFyaW5nIHRo
ZSBzb3VyY2UgcmV0dXJuZWQgYnkgQGNvbW1hbmR7Z3VpeCBidWlsZCAtLXNvdXJjZX0sDQo+
PiBlc3BlY2lhbGx5IGlmDQo+PiArdGhlIGJ1bmRsZWQgbGlicmFyeSBpcyBub3QgYWN0dWFs
bHkgdXNlZCBvbiBHdWl4DQo+PiBzeXN0ZW1zLkBmb290bm90ZXtUaGlzDQo+PiAraXMgQGVt
cGh7bm90fSBhIGNsYWltIHRoYXQgeW91IGNhbiBzaW1wbHkgaWdub3JlIHRoZSBsaWNlbnNl
cyBvZg0KPj4gK2xpYnJhcmllcyB3aGVuIHRoZXkgYXJlIHVuYnVuZGxlZCBhbmQgcmVwbGFj
ZWQgYnkgR3VpeCBwYWNrYWdlcyAtLQ0KPj4gdGhlcmUNCj4+ICthcmUgbGVzcyBjb25jZXJu
cywgbm90IG5vbmUufQ0KPj4gKw0KPj4gK0FzIHN1Y2gsIHNuaXBwZXRzIGFyZSByZWNvbW1l
bmRlZCBoZXJlLg0KPj4gKw0KPj4gK0BzdWJzdWJzZWN0aW9uIEZpeGluZyB0ZWNobmljYWwg
aXNzdWVzIChjb21waWxhdGlvbiBlcnJvcnMsIHRlc3QNCj4+IGZhaWx1cmVzLCBvdGhlciBi
dWdzIC4uLikNCj4+ICtVc3VhbGx5LCBhIGJ1ZyBmaXggY29tZXMgaW4gdGhlIGZvcm0gb2Yg
YSBwYXRjaCBjb3BpZWQgZnJvbSB1cHN0cmVhbQ0KPj4gb3INCj4+ICthbm90aGVyIGRpc3Ry
aWJ1dGlvbi7CoCBJbiB0aGF0IGNhc2UsIHNpbXBseSBhZGRpbmcgdGhlIHBhdGNoIHRvIHRo
ZQ0KPj4gK0Bjb2Rle3BhdGNoZXN9IGZpZWxkIGlzIHRoZSBtb3N0IGNvbnZlbmllbnQgYW5k
IHVzdWFsbHkgZG9lcyBub3QgY2F1c2UNCj4+ICthbnkgcHJvYmxlbXM7IHRoZXJlIGlzIG5v
IG5lZWQgdG8gcmV3cml0ZSBpdCBhcyBhIHNuaXBwZXQgb3IgYSBwaGFzZS4NCj4+ICsNCj4+
ICtJZiBubyByZWFkeS1tYWRlIHBhdGNoIGFscmVhZHkgZXhpc3RzLCB0aGVuIGNob29zaW5n
IGJldHdlZW4gYSBwYXRjaA0KPj4gb3INCj4+ICthIHNuaXBwZXQgaXMgYSBtYXR0ZXIgb2Yg
Y29udmVuaWVuY2UuIEhvd2V2ZXIsIHRoZXJlIGFyZSB0d28gdGhpbmdzIHRvDQo+PiAra2Vl
cCBpbiBtaW5kOg0KPj4gKw0KPj4gK0ZpcnN0LCB3aGVuIHRoZSBmaXggaXMgbm90IEd1aXgt
c3BlY2lmaWMsIHVwc3RyZWFtaW5nIHRoZSBmaXggaXMNCj4+ICtzdHJvbmdseSBkZXNpcmVk
IHRvIGF2b2lkIHRoZSBhZGRpdGlvbmFsIG1haW50ZW5hbmNlIGNvc3QgdG8gR3VpeC7CoCBB
cw0KPj4gK3Vwc3RyZWFtcyBjYW5ub3QgYWNjZXB0IHNuaXBwZXRzLCB3cml0aW5nIGEgcGF0
Y2ggY2FuIGJlIGEgbW9yZQ0KPj4gK2VmZmljaWVudCB1c2Ugb2YgdGltZS7CoCBTZWNvbmRs
eSwgaWYgdGhlIGZpeCBvZiBhIHRlY2huaWNhbCBpc3N1ZQ0KPj4gZW1iZWRzDQo+PiArYSBz
dG9yZSBmaWxlIG5hbWUsIHRoZW4gaXQgaGFzIHRvIGJlIGEgcGhhc2UuDQo+IEkgYW0gcHJl
dHR5IHN1cmUgdGhhdCBtb3N0IG9mIHRoZXNlIGFyZSAqbm90KiBkb25lIGluIHNuaXBwZXRz
LCBidXQNCj4gcmF0aGVyIHBoYXNlcywgaWYgdGhleSBvbmx5IGFmZmVjdCBHdWl4LiAgSW4g
cGFydGljdWxhciwgZ3JlcCBmb3INCj4gZmFpbGluZy10ZXN0cyBhbmQgeW91IHdpbGwgZmlu
ZCBhIGZldyBwaGFzZXMgZGlzYWJsaW5nIHRoZW0uDQpJIGRvIG5vdCB0aGluayB0aGF0IGln
bm9yaW5nIGEgdGVzdCBjb3VudHMgYXMgYSBidWcgZml4LsKgIEknbGwgYWRkIGl0IHRvIA0K
dGhpcw0Kc3Vic3Vic2VjdGlvbiwgYXQgY29zdCBvZiBzb21lIGFkZGl0aW9uYWwgbGVuZ3Ro
Lg0KPiAgICBJbiBmYWN0LA0KPiBhcyBmYXIgYXMgZmlsZXMgdGhhdCB3aWxsIG5vdCBiZSBp
bnN0YWxsZWQgYXJlIGNvbmNlcm5lZCwgSSB0aGluaw0KPiBwaGFzZXMgb3VnaHQgdG8gYmUg
cHJlZmVycmVkLCBiZWNhdXNlIHRoZXkncmUgZWFzaWVyIHRvIHRha2UgYXdheSBpZiBhbg0K
PiBhY3R1YWwgZml4IGlzIG1hZGUuDQpJIGRvIG5vdCBzZWUgYSBkaWZmZXJlbmNlIGluIGhh
cmRuZXNzL2Vhc3luZXNzIGJldHdlZW4gcmVtb3ZpbmcgYQ0KcGhhc2UgYW5kIHJlbW92aW5n
IGEgc25pcHBldCAoYm90aCBhcmUganVzdCBhIG1hdHRlciBvZiBvcGVuaW5nDQphbiBlZGl0
b3IsIHBvaW50aW5nIGl0IGF0IGdudS9wYWNrYWdlcy8uLi4gYW5kIHJlbW92aW5nIGEgZmV3
IGxpbmVzKSwNCnRob3VnaCBJIGRvIGNvbnNpZGVyIHJlbW92aW5nIGEgcGF0Y2ggdG8gYmUg
c2xpZ2h0bHkgaGFyZGVyIChiZWNhdXNlDQpnbnUvbG9jYWwubWsgaXMgZWFzeSB0byBmb3Jn
ZXQpLg0KPiBGb3IgdGhlIHN0b3JlIHBhdGggZW1iZWRkaW5nLCB0aGF0J3MgYSByYXRoZXIg
cm91bmRhYm91dCB3YXkgb2Ygc2F5aW5nDQo+IHRoYXQgY29udHJpYnV0ZXJzICpvdWdodCB0
byogZW1iZWQgc3RvcmUgcGF0aHMgb2YgY2VydGFpbmcgdGhpbmdzLCBzdWNoDQo+IGFzIGNv
bW1hbmRzIGludm9rZWQgdmlhIGV4ZWMgZXQgYWwuDQoNCkl0J3Mgbm90PyBJdCdzIGtpbmQg
b2YgaW1wbGllZCwgeWVzLCBidXQgdGhlIHB1cnBvc2UgaXNuJ3QgYmVpbmcgYSAneW91DQpz
aG91bGQgZW1iZWQgc3RvcmUgcGF0aHMnIChzdWJzdWIpc2VjdGlvbiwgYnV0IHJhdGhlciwg
J2lmIHlvdSBnbyANCmVtYmVkZGluZyBzdG9yZQ0KcGF0aHMgKGF0IGxlYXN0IGZvciBmaXhp
bmcgYSB0ZWNobmljYWwgaXNzdWUpLCBkbyBpdCBpbiBhIHBoYXNlJy4NCg0KSSdtIG5vdCBm
b2xsb3dpbmcgd2hhdCB0aGUgY29tcGxhaW50IGlzLCBJIHN1cHBvc2UgYSBzZWN0aW9uIGNv
dWxkIGJlIGFkZGVkDQpzb21ld2hlcmUgdG8gcHJvcGVybHkgZG9jdW1lbnQgdGhlICdlbWJl
ZGRpbmcgc3RvcmUgZmlsZSBuYW1lcycgcHJhY3RpY2UsDQphbmQgaW5zZXJ0IGEgY3Jvc3Mt
cmVmZXJlbmNlLCBidXQgdGhhdCB3YXNuJ3QgdGhlIHB1cnBvc2Ugb2YgdGhlIHBhdGNoIGFu
ZA0KZ29pbmcgYnkgbGF0ZXIgcmVzcG9uc2VzLCB5b3Ugc2VlbSBvcHBvc2VkIHRvIG1ha2lu
ZyB0aGluZ3MgbG9uZ2VyLg0KDQpUaGUgYWx0ZXJuYXRpdmUgd291bGQgYmUgdG8gcmVtb3Zl
IHRoaXMgaW5mb3JtYXRpb24sIGJ1dCB0aGVuIHZhbHVhYmxlDQppbmZvcm1hdGlvbiB3b3Vs
ZCBiZSBsb3N0ICh0aGVyZSBoYWQgYmVlbiBzb21lIGNhc2VzIHdoZXJlIHN0b3JlIGZpbGUg
bmFtZXMNCndlcmUgZW1iZWRkZWQgaW4gb3JpZ2luKS4NCg0KPj4gT3RoZXJ3aXNlLCBpZiB0
aGUgc3RvcmUNCj4+ICtmaWxlIG5hbWUgd2VyZSBlbWJlZGRlZCBpbiB0aGUgc291cmNlLCB0
aGUgcmVzdWx0IG9mIEBjb21tYW5ke2d1aXgNCj4+IGJ1aWxkDQo+PiArLS1zb3VyY2V9IHdv
dWxkIGJlIHVudXNhYmxlIG9uIG5vbi1HdWl4IHN5c3RlbXMgYW5kIGFsc28gbGlrZWx5DQo+
PiB1bnVzYWJsZQ0KPj4gK29uIEd1aXggc3lzdGVtcyBvZiBhbm90aGVyIGFyY2hpdGVjdHVy
ZS4NCj4gV2h5IGFyZSB5b3UgcmVwZWF0aW5nIGEgZ3VpZGluZyBwcmluY2lwbGU/DQpJJ20g
c2hvd2luZyB3aHksIGluIHRoaXMgY2FzZSwgYSBwaGFzZSBtdXN0IGJlIHVzZWQsIGJ5IG5v
dGluZyB0aGF0DQpub3QgZG9pbmcgc28gd291bGQgYmUgY29udHJhcnkgdG8gb25lIG9mIHRo
ZSBwcmluY2lwbGVzLg0KDQpJZiBub3QgcmVwZWF0aW5nIHRoZSBwcmluY2lwbGUgaXMgZGVz
aXJlZCwgSSBjb3VsZCBwZXJoYXBzIG51bWJlciB0aGVtLCBhbmQNCnJlZmVyIHRvIHRoZSBw
cmluY2lwbGVzIGJ5IG51bWJlciBpbnN0ZWFkIG9mIHJlc3RhdGluZyB0aGVtPyBXb3VsZCBy
ZWR1Y2UNCnRoZSBsZW5ndGggYSBsaXR0bGUuDQoNCj4+ICtAc3Vic3Vic2VjdGlvbiBBZGRp
bmcgbmV3IGZ1bmN0aW9uYWxpdHkNCj4+ICtUbyBhZGQgbmV3IGZ1bmN0aW9uYWxpdHksIGEg
cGF0Y2ggaXMgYWxtb3N0IGFsd2F5cyB0aGUgbW9zdCBjb252ZW5pZW50DQo+PiArY2hvaWNl
IG9mIHRoZSB0aHJlZSAtLSBwYXRjaGVzIGFyZSB1c3VhbGx5IG11bHRpLWxpbmUgY2hhbmdl
cywgd2hpY2gNCj4+IGFyZQ0KPj4gK2NvbnZlbmllbnQgdG8gZG8gd2l0aCBwYXRjaGVzIGFu
ZCBpbmNvbnZlbmllbnQgdG8gZG8gd2l0aCBwaGFzZXMgb3INCj4+ICtzbmlwcGV0cy4NCj4g
VWhtLCB3aGF0PyAgUGF0Y2hlcyBhcmUgdGhlIHByZWZlcnJlZCBmb3JtIG9mIHBhdGNoZXM/
DQoNCk5vLCBJIG1lYW50IHRoYXQgcGF0Y2hlcyBhcmUgKHVzdWFsbHkpIHRoZSBwcmVmZXJy
ZWQgbWV0aG9kIGZvciBhZGRpbmcNCm5ldyBmdW5jdGlvbmFsaXR5LCBhbmQgdGhhdCBtdWx0
aS1saW5lIGNoYW5nZXMgYXJlIGNvbnZlbmllbnQgdG8gZG8gd2l0aA0KcGF0Y2hlcy7CoCDi
gJh3aGljaOKAmSByZWZlcnMgdG8gdGhlIOKAmG11bHRpLWxpbmUgY2hhbmdlc+KAmSBoZXJl
LCBub3Qg4oCYcGF0Y2hlc+KAmS4NCg0KPj4gIMKgIFRoaXMgY2hvaWNlIGlzIHVzdWFsbHkg
YWxzbyBjb21wYXRpYmxlIHdpdGggYWxsIHRoZSBndWlkaW5nDQo+PiArcHJpbmNpcGxlcy7C
oCBBcyBzdWNoLCBwYXRjaGVzIGFyZSBwcmVmZXJyZWQuwqAgSG93ZXZlciwgYXMgd2l0aCBi
dWcNCj4+ICtmaXhlcywgdXBzdHJlYW1pbmcgdGhlIG5ldyBmdW5jdGlvbmFsaXR5IGlzIGRl
c2lyZWQuDQo+PiArDQo+PiArQHN1YnNlY3Rpb24gSG93IHRvIGFkZCBwYXRjaGVzDQo+PiAr
UmVmZXIgdG8gdGhlIEBjb2Rle29yaWdpbn0gcmVjb3JkIGRvY3VtZW50YXRpb24gKHBhcnRp
Y3VsYXJseSB0aGUNCj4+IGZpZWxkcw0KPj4gK0Bjb2Rle3BhdGNoZXN9LCBAY29kZXtwYXRj
aC1pbnB1dHN9LCBhbmQgQGNvZGV7cGF0Y2gtZmxhZ3N9KSBmb3INCj4+ICtpbmZvcm1hdGlv
biBvbiBob3cgdG8gdXNlIHBhdGNoZXMgKEBweHJlZntvcmlnaW4gUmVmZXJlbmNlfSkuwqAg
V2hlbg0KPj4gK2FkZGluZyBhIHBhdGNoLCBkbyBub3QgZm9yZ2V0IHRvIGFsc28gbGlzdCBp
dCBpbg0KPj4gQGNvZGV7ZGlzdF9wYXRjaF9EQVRBfQ0KPj4gK29mIEBmaWxle2dudS9sb2Nh
bC5ta30uDQo+IEkgZG9uJ3QgdGhpbmsgdGhpcyBzaG91bGQgYmUgYSBzdWJzZWN0aW9uLg0K
UmlnaHQsIHNob3VsZCBoYXZlIGJlZW4gYSBzdWJzdWJzZWN0aW9uLg0KPj4gK0BzdWJzZWN0
aW9uIEhvdyB0byBhZGQgZmlsZXMNCj4+ICtOZXcgc291cmNlIGZpbGVzIGNhbiBiZSBhZGRl
ZCBpbiBwaGFzZXMgb3Igc25pcHBldHMsIGJ5IHVzaW5nDQo+PiArQGJ7YXV4aWxpYXJyeSBm
aWxlc30uwqAgQXV4aWxpYXJ5IGZpbGVzIGFyZSBzdG9yZWQgaW4gdGhlDQo+PiArQGZpbGV7
Z251L3BhY2thZ2VzL2F1eC1maWxlc30gZGlyZWN0b3J5IGFuZCBjYW4gYmUgcmV0cmlldmVk
IChpbiBhDQo+PiArc25pcHBldCBvciBhIHBoYXNlKSB3aXRoIEBjb2Rle3NlYXJjaC1hdXhp
bGlhcnktZmlsZX0uwqAgV2hlbiBhZGRpbmcgYW4NCj4+ICthdXhpbGlhcnkgZmlsZSwgZG8g
bm90IGZvcmdldCB0byBhbHNvIGxpc3QgaXQgaW4gQGNvZGV7QVVYX0ZJTEVTfSBvZg0KPj4g
K0BmaWxle01ha2VmaWxlLmFtfS4NCj4+ICsNCj4+ICtBbm90aGVyIG9wdGlvbiBmb3IgYWRk
aW5nIG5ldyBmaWxlcywgaXMgdG8gdXNlIHByb2NlZHVyZXMgc3VjaCBhcw0KPj4gK0Bjb2Rl
e2Rpc3BsYXl9LCBAY29kZXtmb3JtYXR9IGFuZCBAY29kZXtjYWxsLXdpdGgtb3V0cHV0LWZp
bGV9LsKgIEFzIGENCj4+ICttYXR0ZXIgb2YgcHJpbmNpcGxlLCBhdXhpbGlhcnkgZmlsZXMg
b3VnaHQgdG8gYmUgcHJlZmVycmVkIG92ZXIgYW4NCj4+ICtlcXVpdmFsZW50IEBjb2Rle2Nh
bGwtd2l0aC1vdXRwdXQtZmlsZX0gd2hlbiBjcmVhdGluZyBub24tdHJpdmlsDQo+PiBmaWxl
cywNCj4+ICthcyB0aGF0IG1ha2VzIHRoZW0gZWFzaWVyIHRvIGVkaXQuwqAgVGhlIGV4YWN0
IHRocmVzaG9sZCBmb3IgYQ0KPj4gK25vbi10cml2aWFsIGZpbGUgbWlnaHQgYmUgc3ViamVj
dGl2ZSwgdGhvdWdoIGl0IHNob3VsZCBsaWUgc29tZXdoZXJlDQo+PiArYmV0d2VlbiAxMC0t
MjAgbGluZXMuDQo+PiArDQo+PiArQ3VycmVudGx5LCB0aGVyZSBpcyBubyBwb2xpY3kgb24g
ZGVjaWRpbmcgYmV0d2VlbiBwaGFzZSBhbmQgc25pcHBldHMNCj4+IGZvcg0KPj4gK2FkZGlu
ZyBuZXcgZmlsZXMsIGV4Y2VwdCBmb3IgdGhlIGd1aWRpbmcgcHJpbmNpcGxlcy4NCj4gVGhp
cyBzaG91bGQgcHJvYmFibHkgYmUgYSBzdWJzdWJzZWN0aW9uIGFmdGVyICJBZGRpbmcgbmV3
DQo+IGZ1bmN0aW9uYWxpdHkiIG9yIGV4cGxhaW5lZCB3aXRoaW4gIkFkZGluZyBuZXcgZnVu
Y3Rpb25hbGl0eSIuDQo+DQo+IE92ZXJhbGwsIEknbSBub3QgY29udmluY2VkIHRoYXQgd2Ug
aGF2ZSBlbm91Z2ggZ3VpZGluZyBwcmluY2lwbGVzIHRvDQo+IGNhbGwgdGhlbSB0aGF0LA0K
DQpJIGRvbid0IHRoaW5rIHRoZXJlJ3MgYW55IGxvd2VyIGxpbWl0IG9uIGhvdyBtYW55IGd1
aWRpbmcgcHJpbmNpcGxlcw0KdG8gaGF2ZSwgZXhjZXB0IGZvciBwZXJoYXBzIDIgKGJlY2F1
c2Ugb3RoZXJ3aXNlIGl0IHNob3VsZCBoYXZlIGJlZW4NCnNpbmd1bGFyIG9yIHRoZXJlIGFy
ZW4ndCBhbnkpLsKgIEF0IGhvdyBmZXcgZ3VpZGluZyBwcmluY2lwbGVzIHN0b3ANCnRoZSBn
dWlkaW5nIHByaW5jaXBsZXMgZnJvbSBiZWluZyBndWlkaW5nIHByaW5jaXBsZXMgZm9yIHlv
dSwgYW5kIHdoeT8NCg0KRm9yIGV4YW1wbGUsIG9uIDxodHRwczovL3d3dy5nbnUub3JnL3Bo
aWxvc29waHkvZnJlZS1zdy5odG1sPiwgZm91ciANCmd1aWRpbmcgcHJpbmNpcGxlcyBhcmUg
bWVudGlvbmVkICh3aGljaCBhcmUgbmFtZWQgJ2Vzc2VudGlhbCBmcmVlZG9tcycgDQp0aGVy
ZSksIGFuZA0KPGh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0d1aWRpbmdfUHJpbmNp
cGxlcz4gaGFzIDUg4oCYR3VpZGluZyANClByaW5jaXBsZXPigJkuDQo+IHdoaWNoIChhbG9u
ZyB3aXRoIGl0cyBzaGVlciBsZW5ndGgpIGlzIG15IG1haW4NCj4gY29tcGxhaW50IHdpdGgg
dGhlIHdheSB5b3UndmUgcGhyYXNlZCB0aGluZ3MuDQoNCihJJ20gYXNzdW1pbmcgIml0cyA9
IHRoZSBwYXRjaCBhcyBhIHdob2xlIiBoZXJlKQ0KDQpJIGNvdWxkIHJlbW92ZSBhbm90aGVy
IHNlY3Rpb24gb2YgdGhlIG1hbnVhbCB0byBjb21wZW5zYXRlIGZvciB0aGUNCmFkZGl0aW9u
YWwgbGVuZ3RoLCBidXQgSSBkb3VidCB0aGF0J3Mgd2hhdCB5b3UgaW50ZW5kZWQuwqAgSSBk
byBub3Qgc2VlIHRoZQ0KcHJvYmxlbSB3aXRoIHRoZSBzaGVlciBsZW5ndGggLS0gd2UgaGF2
ZSBhIGJpdCBvZiBhIGRvY3VtZW50YXRpb24gcHJvYmxlbQ0KaW4gR3VpeCwgdGhlcmUgaXMg
bG90cyBvZiB1c2VmdWwgaW5mb3JtYXRpb24gdGhhdCBpcyBjdXJyZW50bHkgdW5kb2N1bWVu
dGVkLg0KSSBkbyBub3QgdGhpbmsgdGhlcmUgaGF2ZSBiZWVuIGFueSBjb21wbGFpbnRzIGFi
b3V0IHRoZSBtYW51YWwgYmVpbmcgdG9vIA0KbG9uZywNCmlmIGFueXRoaW5nLCBpdCdzIHRv
byBzaG9ydC4NCg0KSSd2ZSB3cml0dGVuIHNvbWUgZG9jdW1lbnRhdGlvbiwgaXQgd2FzIG9y
aWdpbmFsbHkgYSBiaXQgaGFyZCB0byBmb2xsb3cgc28NCmluIGEgbmV4dCB2ZXJzaW9uIEkn
dmUgcmVzdHJ1Y3R1cmVkIGl0IGEgYml0IGFuZCBleHBsYWluZWQgbW9yZSwgdGhpcw0KcmVz
dHJ1Y3R1cmluZyBhbmQgZXhwbGFuYXRpb24gZW50YWlsZWQgc29tZSBhZGRpdGlvbmFsIGxl
bmd0aC4NCg0KVGhlcmUgaGFkIGJlZW4gc29tZSBwcm9wb3NhbHMgZm9yIGFkZGl0aW9uYWwg
Y2FzZXMgdG8gZG9jdW1lbnQsIHNvIHRoZXkNCndlcmUgYWRkZWQsIGluY3JlYXNpbmcgdGhl
IGxlbmd0aC7CoCBZb3UgaGF2ZSBhZGRlZCBuZXcgaW5mb3JtYXRpb24gaXMgeW91cg0KcGF0
Y2gsIGl0IHdhcyBjb25zaWRlcmVkIHVzZWZ1bCBzbyBJJ3ZlIGludGVncmF0ZWQgc29tZSBv
ZiBpdCBpbiBteSBwYXRjaCwNCmluY3JlYXNpbmcgdGhlIGxlbmd0aC7CoCAoSSBkaWRuJ3Qg
aW50ZWdyYXRlIGFsbCBvZiB0aGUgbmV3IHBhcnRzLCBpZiBJIA0KZGlkLCBpdCB3b3VsZA0K
aW5jcmVhc2UgZXZlbiBmdXJ0aGVyLsKgIChJZiBkZXNpcmVkLCBpbiBjYW4gaW50ZWdyYXRl
IHRoZSByZXN0LCBhdCBjb3N0IA0Kb2Ygc29tZQ0KdGltZS4pKS4NCg0KSSBkbyBub3Qgc2Vl
IHdoYXQgdGhlIHByb2JsZW0gaXMgd2l0aCBhZGRpdGlvbmFsIGxlbmd0aCBhcyBsb25nIGFz
IHRoaXMNCmFkZGl0aW9uYWwgbGVuZ3RoIGNvbWVzIHdpdGggYWRkaXRpb25hbCB1c2VmdWwg
aW5mb3JtYXRpb24gYW5kIHRoZSBtYW51YWwNCmlzIHdlbGwtc3RydWN0dXJlZCAoZS5nLiB3
aXRoIChzdWIpKHN1YilzZWN0aW9ucywgY2hhcHRlcnMgYW5kIGluZGljZXMpIA0KLS0gd2UN
CmRvIG5vdCBoYXZlIGEgcGFnZSBsaW1pdC4NCg0KQXQgd29yc3QsIHBlcmhhcHMgdGhlIHNh
bWUgaW5mb3JtYXRpb24gY291bGQgcGVyaGFwcyBiZSBlbmNvZGVkIHdpdGgNCmZld2VyIHdv
cmRzPyBJIGNvdWxkIGNvbXBhcmUgdGhlIHR3byBwYXRjaGVzIHRvIHNlZSB3aGljaCBvbmUg
Zm9ybXVsYXRlcw0KY2VydGFpbiBpbmZvcm1hdGlvbiBpbiB0aGUgZmV3ZXN0IHdvcmRzLCBh
bmQgY2hvb3NlIHRoZSBsZWFzdCB2ZXJib3NlIG9mIHRoZQ0KdHdvIGZvciBlYWNoIHBpZWNl
IG9mIGluZm9ybWF0aW9uIHRoYXQgaXMgcHJlc2VudCBpbiBib3RoPw0KDQpBbHNvLCBjb21w
YXJpbmcgdGhlIHR3byBwYXRjaGVzLCBteSBwYXRjaCBoYXMgNDAgbW9yZSBsaW5lcywgYnV0
IGFib3V0DQoyNSBvZiB0aGVtIGFyZSBmb3Igbm90aW5nIHRoZSBndWlkaW5nIHByaW5jaXBs
ZXMgKHdoaWNoIGFyZSBhYnNlbnQgaW4gDQp5b3VyIHBhdGNoKS4NCkNvbXBlbnNhdGluZyBm
b3IgdGhhdCwgdGhlIHBhdGNoZXMgYXJlIGFib3V0IHRoZSBzYW1lIGxlbmd0aCwgc28gSSBk
byANCm5vdCB0aGluaw0KdGhhdCAnc2hlZXIgbGVuZ3RoJyBpcyBhY2N1cmF0ZSBoZXJlLg0K
DQo+IEdvaW5nIGRvd24gdG8NCj4gc3Vic3Vic2VjdGlvbnMganVzdCB0byBmaW5kIG91dCB3
aGVyZSBwYXRjaGVzIGFyZSBhcHByb3ByaWF0ZSwgaXMgaW1obw0KPiBvdmVya2lsbC4NCg0K
VGhlICdnb2luZyBkb3duIHRvIHN1YnN1YnNlY3Rpb24nIGlzIHRoZSBjYXNlIGZvciB5b3Vy
IHBhdGNoIHRvbywgdGhvdWdoPw0KSW4gbXkgY2FzZSwgaXQncyBhIHN1YnN1YnNlY3Rpb24s
IGluIHlvdXIgY2FzZSBpdCdzIGEgdGFibGUgZW50cnkgaW5zaWRlIGENCnN1YnNlY3Rpb24s
IGJvdGggYXJlIHRoZSBzYW1lIGxldmVsIG9mIG5lc3RpbmcuDQoNCkFsc28sIGl0J3MgYSBt
YXR0ZXIgb2YgZGlmZmVyZW50IHN0cnVjdHVyZSAtLSBpbiBteSB2MiBhbmQgdjMgcGF0Y2gs
IEkgDQpoYXZlIGENCidwcm9ibGVtIC0+IHNvbHV0aW9uJyBzdHJ1Y3R1cmUgLS0gdGhlIGlk
ZWEgaXMgdGhhdCB0aGUgcGFja2FnZXMgaGFzIGEgDQpwcm9ibGVtLA0KdGhleSBsb29rIGF0
IHRoZSBzZWN0aW9uLCB0aGV5IHJlYWQgdGhlIHN1YnN1YnNlY3Rpb24gbmFtZXMsIHNlbGVj
dCB0aGUNCnN1YnN1YnNlY3Rpb24gdGhhdCBtYXRjaGVzIHRoZWlyIHByb2JsZW0gYW5kIHJl
YWQgdGhlIHNvbHV0aW9uIC0tIGluIHNob3J0LA0KdGhlIGlkZWEgaXMgdG8gcHJvdmlkZSBh
IHNvbHV0aW9uIHRvIHRoZSBwcm9ibGVtLg0KDQpZb3VyIHN0cnVjdHVyZSBpcyB0aGUgb3Ro
ZXIgd2F5IGFyb3VuZCAtLSBmb3Igc29sdXRpb25zIChwYXRjaGVzLCBzbmlwcGV0cywNCnBo
YXNlcyksIGl0IGdpdmVzIHRoZSBwZXJtaXR0ZWQgcHJvYmxlbXMgdG8gYXBwbHkgaXQgdG8u
DQoNClNvIHllcywgeW91ciBwYXRjaCBpcyBtb3JlIGNvbnZlbmllbnQgZm9yIGZpbmRpbmcg
b3V0IHdoZXJlIHBhdGNoZXMgYXJlDQphcHByb3ByaWF0ZS7CoCBJIGRvIG5vdCBzZWUgdGhl
IGJlbmVmaXQgb2YgdGhhdCB0aG91Z2ggLS0gYSBuZXcgY29udHJpYnV0b3INCnBhY2thZ2lu
ZyBhIHRoaW5nIHdvdWxkbid0IGtub3cgaW4gYWR2YW5jZSB3aGljaCBzb2x1dGlvbnMgY291
bGQgYmUNCmFwcHJvcHJpYXRlIGZvciB0aGVtICh5b3VyICdzb2x1dGlvbiAtPiBwcm9ibGVt
JyBwYXRjaD8pLCByYXRoZXIsIHRoZXkgc3RhcnQNCndpdGggYSBwcm9ibGVtIGFuZCBhcmUg
c2VhcmNoaW5nIGZvciBhbiBhcHByb3ByaWF0ZSBzb2x1dGlvbiAobXkNCnByb2JsZW0tPnNv
bHV0aW9uIHBhdGNoKS4NCg0KR3JlZXRpbmdzLA0KTWF4aW1lLg0K
--------------8K9TKb9cQWdHijgVuosbMcLl
Content-Type: application/pgp-keys; name="OpenPGP_0x49E3EE22191725EE.asc"
Content-Disposition: attachment; filename="OpenPGP_0x49E3EE22191725EE.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xjMEX4ch6BYJKwYBBAHaRw8BAQdANPb/d6MrGnGi5HyvODCkBUJPRjiFQcRU5V+m
xvMaAa/NL01heGltZSBEZXZvcyA8bWF4aW1lLmRldm9zQHN0dWRlbnQua3VsZXV2
ZW4uYmU+wpAEExYIADgWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCX4ch6AIbAwUL
CQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRBJ4+4iGRcl7japAQC3opZ2KGWzWmRc
/gIWSu0AAcfMwyinFEEPa/QhUt2CogD/e2RdF4CYAgaRHJJmZ9WU7piKbLZ7llB4
LzgezVDHggzNJU1heGltZSBEZXZvcyA8bWF4aW1lZGV2b3NAdGVsZW5ldC5iZT7C
kAQTFggAOBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJf56ycAhsDBQsJCAcDBRUK
CQgLBRYCAwEAAh4BAheAAAoJEEnj7iIZFyXujpQBAKV1SwDDl4f24rXciDlB9L8W
ycZt30CgbewMSRQk4mvbAP9dFMbVVixYBd6C8cfhR+NsOBGiOJnQABlUmgNuqGFJ
Dc44BF+HIegSCisGAQQBl1UBBQEBB0BOlzIWiJzgobMF6/cqwLaLk7jIcFSZ++c0
k9cCNT6YXwMBCAfCeAQYFggAIBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJfhyHo
AhsMAAoJEEnj7iIZFyXuMr0BAJc8cl5PGvVmVuSQVKjleNl4DK1/XAaPAYPe34AE
fZJPAP9IqLCQhH/FeJanHqBP8gNdGNI2qn8RnnLVfRJgUjZ1BA=3D=3D
=3DOVqp
-----END PGP PUBLIC KEY BLOCK-----

--------------8K9TKb9cQWdHijgVuosbMcLl--

--------------mg1vH0aCGVVMzb0Ns8xAZUcB--

--------------NLNRqI000ekw60aGGVxBGoXf
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wnsEABYIACMWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYxertwUDAAAAAAAKCRBJ4+4iGRcl7gK1
AP404PUOiqiRh83oSZGTgC1xGaM3+Yf2cT2uo8ZE+T+0PwEAnTtBSLXNjkFAo8uoJ6MZJiJhWOSy
nX/roFyoAOueyQU=
=mpfU
-----END PGP SIGNATURE-----

--------------NLNRqI000ekw60aGGVxBGoXf--

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#57598] [PATCH] doc: Update contribution guidelines on patches, etc.
Resent-From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Wed, 07 Sep 2022 08:11:01 +0000
Resent-Message-ID: <handler.57598.B57598.16625382145465 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 57598
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Maxime Devos <maximedevos@HIDDEN>, 57598 <at> debbugs.gnu.org
Received: via spool by 57598-submit <at> debbugs.gnu.org id=B57598.16625382145465
          (code B ref 57598); Wed, 07 Sep 2022 08:11:01 +0000
Received: (at 57598) by debbugs.gnu.org; 7 Sep 2022 08:10:14 +0000
Received: from localhost ([127.0.0.1]:53313 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oVq8T-0001Q4-48
	for submit <at> debbugs.gnu.org; Wed, 07 Sep 2022 04:10:14 -0400
Received: from mailrelay.tugraz.at ([129.27.2.202]:30599)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <liliana.prikler@HIDDEN>) id 1oVq8N-0001Po-Kw
 for 57598 <at> debbugs.gnu.org; Wed, 07 Sep 2022 04:10:12 -0400
Received: from lprikler-laptop.ist.intra (gw.ist.tugraz.at [129.27.202.101])
 by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4MMw0Q5pwSz3wVf;
 Wed,  7 Sep 2022 10:09:58 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at;
 s=mailrelay; t=1662538198;
 bh=lu8bYcjyUDFPErl1qLcQyrpo/NtDhSTJfp6UDgESjIo=;
 h=Subject:From:To:Date:In-Reply-To:References;
 b=ZtnApfojCspEyGEBp5JYBzpKqvZ7CByrGzCEM9f3/Yg/dRujoaHbhnc/A8jVB6hkF
 rMTJ8axgO2oQpHb1fzCxak8hLYRQ2aJgK70jLvvlSB8LXOY4bwyWT1f6N17NkWgLJE
 E4d2pL1NWgm94n+3pzF0UJHLqpv51S+s0owZgbaY=
Message-ID: <44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN>
From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
Date: Wed, 07 Sep 2022 10:09:58 +0200
In-Reply-To: <d0a48b72-c62b-cc97-e399-22abc0af182d@HIDDEN>
References: <20220905160048.18173-1-maximedevos@HIDDEN>
 <0f78953d57d8f66a934baf518b7c9e3247b580fd.camel@HIDDEN>
 <d0a48b72-c62b-cc97-e399-22abc0af182d@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.1 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-TUG-Backscatter-control: waObeELIUl4ypBWmcn/8wQ
X-Spam-Scanner: SpamAssassin 3.003001 
X-Spam-Score-relay: -0.4
X-Scanned-By: MIMEDefang 2.74 on 129.27.10.116
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Am Dienstag, dem 06.09.2022 um 22:21 +0200 schrieb Maxime Devos:
> 
> > We also avoid spelling out the non-free filename where possible,
> > preferring keep lists over remove lists, which this kind of patches
> > would be.
> Should we? I'm not seeing the point of that. I have not experienced
> any such avoidance myself, see e.g. 'tennix', 'neverball' and
> 'shogun'.  It is, to my knowledge, not forbidden to mention non-free
> software by name in code, as long as its not a recommendation
> (explicit or implied).
Indeed,  there is no hard rule, hence "avoid" rather than "forbid".

> > 
> > > +@subsubsection Fixing technical issues (compilation errors, test
> > > failures, other bugs ...)
> > > [...]
> > I am pretty sure that most of these are *not* done in snippets, but
> > rather phases, if they only affect Guix.  In particular, grep for
> > failing-tests and you will find a few phases disabling them.
> I do not think that ignoring a test counts as a bug fix.  I'll add it
> to this subsubsection, at cost of some additional length.
I do think it counts as "fixing technical issues such as test
failures".

> > In fact, as far as files that will not be installed are concerned,
> > I think phases ought to be preferred, because they're easier to
> > take away if an actual fix is made.
> I do not see a difference in hardness/easyness between removing a
> phase and removing a snippet (both are just a matter of opening
> an editor, pointing it at gnu/packages/... and removing a few lines),
> though I do consider removing a patch to be slightly harder (because
> gnu/local.mk is easy to forget).
There still is the difference that phases are clearly delimited while
snippets are a block of code that shouldn't get too large.

> > For the store path embedding, that's a rather roundabout way of
> > saying that contributers *ought to* embed store paths of certaing
> > things, such as commands invoked via exec et al.
> 
> It's not? It's kind of implied, yes, but the purpose isn't being a
> 'you should embed store paths' (subsub)section, but rather, 'if you
> go embedding store paths (at least for fixing a technical issue), do
> it in a phase'.
> 
> I'm not following what the complaint is, I suppose a section could be
> added somewhere to properly document the 'embedding store file names'
> practice, and insert a cross-reference, but that wasn't the purpose
> of the patch and going by later responses, you seem opposed to making
> things longer.
> 
> The alternative would be to remove this information, but then
> valuable information would be lost (there had been some cases where
> store file names were embedded in origin).
I think my version at least hinted at this practice in a more concise
way, so it's not impossible to mention.  Not embedding store paths *is*
a technical issue, because it'll cause the installed program to fail
and most people new to Guix will then just go "oh, let's propagate gcc-
toolchain".

> > > Otherwise, if the store
> > > +file name were embedded in the source, the result of
> > > @command{guix build
> > > +--source} would be unusable on non-Guix systems and also likely
> > > unusable
> > > +on Guix systems of another architecture.
> > Why are you repeating a guiding principle?
> I'm showing why, in this case, a phase must be used, by noting that
> not doing so would be contrary to one of the principles.
> 
> If not repeating the principle is desired, I could perhaps number
> them, and refer to the principles by number instead of restating
> them? Would reduce the length a little.
I think calling back to a guiding principle in and of itself shows that
the section has grown too long to remember it by the point you come to
this example, and I think that's more problematic than merely the
callback.  If you didn't need to divide this into subsubsections, you
could introduce the guiding principles in a way that feels more
natural.

> > > +@subsubsection Adding new functionality
> > > +To add new functionality, a patch is almost always the most
> > > convenient
> > > +choice of the three -- patches are usually multi-line changes,
> > > which
> > > are
> > > +convenient to do with patches and inconvenient to do with phases
> > > or
> > > +snippets.
> > Uhm, what?  Patches are the preferred form of patches?
> 
> No, I meant that patches are (usually) the preferred method for
> adding new functionality, and that multi-line changes are convenient
> to do with patches.  ‘which’ refers to the ‘multi-line changes’ here,
> not ‘patches’.
I still find this wording very confusing.  Perhaps "To add new
functionality, a patch is almost always the best choice.  For one, it
is likely that the new functionality requires changing multiple lines
of source code, which is more convenient to do with a patch than with a
snippet.  Further, patches can be taken from and submitted to upstreams
more easily.  If your patch has not been submitted to upstream,
consider doing so."

> > 
> > [...]
> > Overall, I'm not convinced that we have enough guiding principles
> > to call them that,
> 
> I don't think there's any lower limit on how many guiding principles
> to have, except for perhaps 2 (because otherwise it should have been
> singular or there aren't any).  At how few guiding principles stop
> the guiding principles from being guiding principles for you, and
> why?
> 
> For example, on <https://www.gnu.org/philosophy/free-sw.html>, four 
> guiding principles are mentioned (which are named 'essential
> freedoms' there), and
> <https://en.wikipedia.org/wiki/Guiding_Principles> has 5 ‘Guiding 
> Principles’.
An enumeration ought to have at least three elements (otherwise it's
just a pair), and I think if we do proper counting and omit no-
brainers, such as the "only free software" part that has already been
mentioned, we come very close to skirting that line.

> > which (along with its sheer length) is my main
> > complaint with the way you've phrased things.
> 
> (I'm assuming "its = the patch as a whole" here)
> 
> I could remove another section of the manual to compensate for the
> additional length, but I doubt that's what you intended.  I do not
> see the problem with the sheer length -- we have a bit of a
> documentation problem in Guix, there is lots of useful information
> that is currently undocumented.
> I do not think there have been any complaints about the manual being
> too long, if anything, it's too short.
I personally tend towards "less verbose", hence my complaint of
describing something with many words that could be described with
fewer.  A section can still be too long while the chapter around it is
too short.

> I've written some documentation, it was originally a bit hard to
> follow so in a next version I've restructured it a bit and explained
> more, this restructuring and explanation entailed some additional
> length.
> 
> There had been some proposals for additional cases to document, so
> they were added, increasing the length.  You have added new
> information is your patch, it was considered useful so I've
> integrated some of it in my patch, increasing the length.  (I didn't
> integrate all of the new parts, if I did, it would increase even
> further.  (If desired, in can integrate the rest, at cost  of some
> time.)).
My patch did not just state some things you missed, it also omitted
things that I think are either not necessary or probably better
documented elsewhere.

> I do not see what the problem is with additional length as long as
> this additional length comes with additional useful information and
> the manual is well-structured (e.g. with (sub)(sub)sections, chapters
> and indices) -- we do not have a page limit.
> 
> At worst, perhaps the same information could perhaps be encoded with
> fewer words? I could compare the two patches to see which one
> formulates certain information in the fewest words, and choose the
> least verbose of the two for each piece of information that is
> present in both?
> 
> Also, comparing the two patches, my patch has 40 more lines, but
> about 25 of them are for noting the guiding principles (which are
> absent in your patch).
> Compensating for that, the patches are about the same length, so I do
> not think that 'sheer length' is accurate here.
25 lines calling back to earlier information are, imho, an indicator
that the section is too long.  Imagine you'd have twenty-five function
calls to guiding_principles(n) in your program – at some point, you'd
try to cache those.

> > Going down to subsubsections just to find out where patches are
> > appropriate, is imho overkill.
> 
> The 'going down to subsubsection' is the case for your patch too,
> though?  In my case, it's a subsubsection, in your case it's a table
> entry inside a subsection, both are the same level of nesting.
These are still two very different kinds of nesting.  A table fits onto
a (virtual) page more easily than several subsections.

> Also, it's a matter of different structure -- in my v2 and v3 patch,
> I have a 'problem -> solution' structure -- the idea is that the
> packages has a problem, they look at the section, they read the
> subsubsection names, select the
> subsubsection that matches their problem and read the solution -- in
> short, the idea is to provide a solution to the problem.
> 
> Your structure is the other way around -- for solutions (patches,
> snippets, phases), it gives the permitted problems to apply it to.
> 
> So yes, your patch is more convenient for finding out where patches
> are appropriate.  I do not see the benefit of that though -- a new
> contributor packaging a thing wouldn't know in advance which
> solutions could be appropriate for them (your 'solution -> problem'
> patch?), rather, they start with a problem and are searching for an
> appropriate solution (my problem->solution patch).
I think this idea can be debunked pretty easily.  If I give you a
hammer and I tell you "this is a hammer, you can use it to put nails
into a wall", and you have a nail and you want to put it into a wall,
you won't go "oh no, however will I put this nail into a wall?" – you
will simply use the hammer to do so.  Of course, for this to work I
also have to tell you *how* to use a hammer to put nails into a wall,
but that's exactly what I did in my patch by inserting the right notes
into the Guix manual.

My solution->problem approach has the benefit, that folks can just go
over all the solutions, check if their problem fits, and apply the one
that says "here, use this".  And if they don't find anything, they see
the handy little line at the bottom saying "use whatever you think is
convenient".  I also expand a little on the benefits and drawbacks of
these approaches as you would when describing design patterns.

Your problem->solution approach instead leaves people wondering when
their particular use case has not been described.  It gives them a
solution rather than the tools to build solutions with.

Cheers

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#57598] [PATCH] doc: Update contribution guidelines on patches, etc.
Resent-From: Maxime Devos <maximedevos@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Thu, 08 Sep 2022 11:13:02 +0000
Resent-Message-ID: <handler.57598.B57598.16626355759018 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 57598
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Liliana Marie Prikler <liliana.prikler@HIDDEN>, 57598 <at> debbugs.gnu.org
Received: via spool by 57598-submit <at> debbugs.gnu.org id=B57598.16626355759018
          (code B ref 57598); Thu, 08 Sep 2022 11:13:02 +0000
Received: (at 57598) by debbugs.gnu.org; 8 Sep 2022 11:12:55 +0000
Received: from localhost ([127.0.0.1]:57364 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oWFSm-0002LM-S8
	for submit <at> debbugs.gnu.org; Thu, 08 Sep 2022 07:12:54 -0400
Received: from laurent.telenet-ops.be ([195.130.137.89]:36376)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <maximedevos@HIDDEN>) id 1oWFSh-0002LA-KM
 for 57598 <at> debbugs.gnu.org; Thu, 08 Sep 2022 07:12:51 -0400
Received: from [IPV6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16]
 ([IPv6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16])
 by laurent.telenet-ops.be with bizsmtp
 id HPCj2800E20ykKC01PCjxg; Thu, 08 Sep 2022 13:12:46 +0200
Message-ID: <b33540cb-0c72-6170-34d0-b8df4ab79b8f@HIDDEN>
Date: Thu, 8 Sep 2022 13:12:43 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.12.0
Content-Language: en-US
References: <20220905160048.18173-1-maximedevos@HIDDEN>
 <0f78953d57d8f66a934baf518b7c9e3247b580fd.camel@HIDDEN>
 <d0a48b72-c62b-cc97-e399-22abc0af182d@HIDDEN>
 <44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN>
From: Maxime Devos <maximedevos@HIDDEN>
In-Reply-To: <44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------bYZznqRF4e00yv03Q3Otn4Cv"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r22;
 t=1662635566; bh=BVj7tKpf7nZIYzt8MDLzRBiS15zOU/pDnYZAaFh4sMU=;
 h=Date:To:References:From:Subject:In-Reply-To;
 b=L9pccPYsqDvdVfGfZo600Nvy5POMADKNHMwjwsR3tsM03UkqiVvW1cS2VIZ6fbu2F
 q1afo3I3P0ab0PmnTKbeYohJ+QgqyVhYEfJD09a6c88psEKDXrdp/hR8oTX7wa09nt
 GlKKHDd8+NqBbowj6Uq5RYtPHH6e9QnU1pXfEbGMM3APzn5s3Lnn6blt/1AqmNnV4q
 y+pOXtLckMpIppflgMLJXbq7Ncv/+HR2bzncx0gkJzpHzCZAEWkTuE05lIEFC3efDI
 81oGJD4W18n3zJpS46Z/l7pSKXJBLHUqg/UefopNbEWNeLIq4xRK7NKqJwxOIWJgH3
 jyLSbWMBrvq8w==
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------bYZznqRF4e00yv03Q3Otn4Cv
Content-Type: multipart/mixed; boundary="------------N4yS7ui6DXqk1oJogkEaW0eQ";
 protected-headers="v1"
From: Maxime Devos <maximedevos@HIDDEN>
To: Liliana Marie Prikler <liliana.prikler@HIDDEN>,
 57598 <at> debbugs.gnu.org
Message-ID: <b33540cb-0c72-6170-34d0-b8df4ab79b8f@HIDDEN>
Subject: Re: [PATCH] doc: Update contribution guidelines on patches, etc.
References: <20220905160048.18173-1-maximedevos@HIDDEN>
 <0f78953d57d8f66a934baf518b7c9e3247b580fd.camel@HIDDEN>
 <d0a48b72-c62b-cc97-e399-22abc0af182d@HIDDEN>
 <44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN>
In-Reply-To: <44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN>

--------------N4yS7ui6DXqk1oJogkEaW0eQ
Content-Type: multipart/mixed; boundary="------------lT8JlkWSD5VQXD90Dz1boRGV"

--------------lT8JlkWSD5VQXD90Dz1boRGV
Content-Type: multipart/alternative;
 boundary="------------fiI7W13Wn7SOCrw0E7hFeOyo"

--------------fiI7W13Wn7SOCrw0E7hFeOyo
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMDctMDktMjAyMiAxMDowOSwgTGlsaWFuYSBNYXJpZSBQcmlrbGVyIHdyb3RlOg0KDQo+
IEFtIERpZW5zdGFnLCBkZW0gMDYuMDkuMjAyMiB1bSAyMjoyMSArMDIwMCBzY2hyaWViIE1h
eGltZSBEZXZvczoNCj4+PiBXZSBhbHNvIGF2b2lkIHNwZWxsaW5nIG91dCB0aGUgbm9uLWZy
ZWUgZmlsZW5hbWUgd2hlcmUgcG9zc2libGUsDQo+Pj4gcHJlZmVycmluZyBrZWVwIGxpc3Rz
IG92ZXIgcmVtb3ZlIGxpc3RzLCB3aGljaCB0aGlzIGtpbmQgb2YgcGF0Y2hlcw0KPj4+IHdv
dWxkIGJlLg0KPj4gU2hvdWxkIHdlPyBJJ20gbm90IHNlZWluZyB0aGUgcG9pbnQgb2YgdGhh
dC4gSSBoYXZlIG5vdCBleHBlcmllbmNlZA0KPj4gYW55IHN1Y2ggYXZvaWRhbmNlIG15c2Vs
Ziwgc2VlIGUuZy4gJ3Rlbm5peCcsICduZXZlcmJhbGwnIGFuZA0KPj4gJ3Nob2d1bicuICBJ
dCBpcywgdG8gbXkga25vd2xlZGdlLCBub3QgZm9yYmlkZGVuIHRvIG1lbnRpb24gbm9uLWZy
ZWUNCj4+IHNvZnR3YXJlIGJ5IG5hbWUgaW4gY29kZSwgYXMgbG9uZyBhcyBpdHMgbm90IGEg
cmVjb21tZW5kYXRpb24NCj4+IChleHBsaWNpdCBvciBpbXBsaWVkKS4NCj4gSW5kZWVkLCAg
dGhlcmUgaXMgbm8gaGFyZCBydWxlLCBoZW5jZSAiYXZvaWQiIHJhdGhlciB0aGFuICJmb3Ji
aWQiLg0KDQpXaGF0IEkgYWxzbyBtZWFudCBpcywgdGhhdCB0byBteSBrbm93bGVkZ2UgdGhl
cmUgaXMgbm8gc29mdCBydWxlIGVpdGhlci4NCg0KQWdhaW4sIHdoeSBzaG91bGQgd2UgYXZv
aWQgdGhpcywgd2hhdCdzIHRoZSBwb2ludCBvZiB0aGF0Pw0KDQo+Pj4+ICtAc3Vic3Vic2Vj
dGlvbiBGaXhpbmcgdGVjaG5pY2FsIGlzc3VlcyAoY29tcGlsYXRpb24gZXJyb3JzLCB0ZXN0
DQo+Pj4+IGZhaWx1cmVzLCBvdGhlciBidWdzIC4uLikNCj4+Pj4gWy4uLl0NCj4+PiBJIGFt
IHByZXR0eSBzdXJlIHRoYXQgbW9zdCBvZiB0aGVzZSBhcmUgKm5vdCogZG9uZSBpbiBzbmlw
cGV0cywgYnV0DQo+Pj4gcmF0aGVyIHBoYXNlcywgaWYgdGhleSBvbmx5IGFmZmVjdCBHdWl4
LsKgIEluIHBhcnRpY3VsYXIsIGdyZXAgZm9yDQo+Pj4gZmFpbGluZy10ZXN0cyBhbmQgeW91
IHdpbGwgZmluZCBhIGZldyBwaGFzZXMgZGlzYWJsaW5nIHRoZW0uDQo+PiBJIGRvIG5vdCB0
aGluayB0aGF0IGlnbm9yaW5nIGEgdGVzdCBjb3VudHMgYXMgYSBidWcgZml4LsKgIEknbGwg
YWRkIGl0DQo+PiB0byB0aGlzIHN1YnN1YnNlY3Rpb24sIGF0IGNvc3Qgb2Ygc29tZSBhZGRp
dGlvbmFsIGxlbmd0aC4NCj4gSSBkbyB0aGluayBpdCBjb3VudHMgYXMgImZpeGluZyB0ZWNo
bmljYWwgaXNzdWVzIHN1Y2ggYXMgdGVzdA0KPiBmYWlsdXJlcyIuDQpIb3cgZG9lcyBpZ25v
cmluZyBhIHRlc3QgZml4IHRoZSB0ZWNobmljYWwgaXNzdWUgaWRlbnRpZmllZCBieSB0aGUg
dGVzdA0KKHNvbWV0aW1lcywgdGhlIHRlY2huaWNhbCBpc3N1ZSBiZWluZyBhIGJ1ZyBpbiB0
aGUgdGVzdCBpdHNlbGYpPw0KPj4+IEluIGZhY3QsIGFzIGZhciBhcyBmaWxlcyB0aGF0IHdp
bGwgbm90IGJlIGluc3RhbGxlZCBhcmUgY29uY2VybmVkLA0KPj4+IEkgdGhpbmsgcGhhc2Vz
IG91Z2h0IHRvIGJlIHByZWZlcnJlZCwgYmVjYXVzZSB0aGV5J3JlIGVhc2llciB0bw0KPj4+
IHRha2UgYXdheSBpZiBhbiBhY3R1YWwgZml4IGlzIG1hZGUuDQo+PiBJIGRvIG5vdCBzZWUg
YSBkaWZmZXJlbmNlIGluIGhhcmRuZXNzL2Vhc3luZXNzIGJldHdlZW4gcmVtb3ZpbmcgYQ0K
Pj4gcGhhc2UgYW5kIHJlbW92aW5nIGEgc25pcHBldCAoYm90aCBhcmUganVzdCBhIG1hdHRl
ciBvZiBvcGVuaW5nDQo+PiBhbiBlZGl0b3IsIHBvaW50aW5nIGl0IGF0IGdudS9wYWNrYWdl
cy8uLi4gYW5kIHJlbW92aW5nIGEgZmV3IGxpbmVzKSwNCj4+IHRob3VnaCBJIGRvIGNvbnNp
ZGVyIHJlbW92aW5nIGEgcGF0Y2ggdG8gYmUgc2xpZ2h0bHkgaGFyZGVyIChiZWNhdXNlDQo+
PiBnbnUvbG9jYWwubWsgaXMgZWFzeSB0byBmb3JnZXQpLg0KPiBUaGVyZSBzdGlsbCBpcyB0
aGUgZGlmZmVyZW5jZSB0aGF0IHBoYXNlcyBhcmUgY2xlYXJseSBkZWxpbWl0ZWQgd2hpbGUN
Cj4gc25pcHBldHMgYXJlIGEgYmxvY2sgb2YgY29kZSB0aGF0IHNob3VsZG4ndCBnZXQgdG9v
IGxhcmdlLg0KDQpTbmlwcGV0cyBhcmUgZGVsaW1pdGVkIGNsZWFybHkgYXMgd2VsbCwgdGhv
dWdoLCB3aXRoIHRoZSAnc25pcHBldCcgZmllbGQ/DQoNCkFuZCB0aGUgbGltaXRhdGlvbnMg
b2Ygc25pcHBldCBsZW5ndGggYW5kIHBoYXNlcyBsZW5ndGggYXJlIHRoZSBzYW1lDQotLSBu
byBsaW1pdHMsIHRob3VnaCBjb25jaXNlbmVzcyBpcyBhcHByZWNpYXRlIGFzIGFsd2F5cy4N
Cg0KPj4+IEZvciB0aGUgc3RvcmUgcGF0aCBlbWJlZGRpbmcsIHRoYXQncyBhIHJhdGhlciBy
b3VuZGFib3V0IHdheSBvZg0KPj4+IHNheWluZyB0aGF0IGNvbnRyaWJ1dGVycyAqb3VnaHQg
dG8qIGVtYmVkIHN0b3JlIHBhdGhzIG9mIGNlcnRhaW5nDQo+Pj4gdGhpbmdzLCBzdWNoIGFz
IGNvbW1hbmRzIGludm9rZWQgdmlhIGV4ZWMgZXQgYWwuDQo+PiBJdCdzIG5vdD8gSXQncyBr
aW5kIG9mIGltcGxpZWQsIHllcywgYnV0IHRoZSBwdXJwb3NlIGlzbid0IGJlaW5nIGENCj4+
ICd5b3Ugc2hvdWxkIGVtYmVkIHN0b3JlIHBhdGhzJyAoc3Vic3ViKXNlY3Rpb24sIGJ1dCBy
YXRoZXIsICdpZiB5b3UNCj4+IGdvIGVtYmVkZGluZyBzdG9yZSBwYXRocyAoYXQgbGVhc3Qg
Zm9yIGZpeGluZyBhIHRlY2huaWNhbCBpc3N1ZSksIGRvDQo+PiBpdCBpbiBhIHBoYXNlJy4N
Cj4+DQo+PiBJJ20gbm90IGZvbGxvd2luZyB3aGF0IHRoZSBjb21wbGFpbnQgaXMsIEkgc3Vw
cG9zZSBhIHNlY3Rpb24gY291bGQgYmUNCj4+IGFkZGVkIHNvbWV3aGVyZSB0byBwcm9wZXJs
eSBkb2N1bWVudCB0aGUgJ2VtYmVkZGluZyBzdG9yZSBmaWxlIG5hbWVzJw0KPj4gcHJhY3Rp
Y2UsIGFuZCBpbnNlcnQgYSBjcm9zcy1yZWZlcmVuY2UsIGJ1dCB0aGF0IHdhc24ndCB0aGUg
cHVycG9zZQ0KPj4gb2YgdGhlIHBhdGNoIGFuZCBnb2luZyBieSBsYXRlciByZXNwb25zZXMs
IHlvdSBzZWVtIG9wcG9zZWQgdG8gbWFraW5nDQo+PiB0aGluZ3MgbG9uZ2VyLg0KPj4NCj4+
IFRoZSBhbHRlcm5hdGl2ZSB3b3VsZCBiZSB0byByZW1vdmUgdGhpcyBpbmZvcm1hdGlvbiwg
YnV0IHRoZW4NCj4+IHZhbHVhYmxlIGluZm9ybWF0aW9uIHdvdWxkIGJlIGxvc3QgKHRoZXJl
IGhhZCBiZWVuIHNvbWUgY2FzZXMgd2hlcmUNCj4+IHN0b3JlIGZpbGUgbmFtZXMgd2VyZSBl
bWJlZGRlZCBpbiBvcmlnaW4pLg0KPiBJIHRoaW5rIG15IHZlcnNpb24gYXQgbGVhc3QgaGlu
dGVkIGF0IHRoaXMgcHJhY3RpY2UgaW4gYSBtb3JlIGNvbmNpc2UNCj4gd2F5LCBzbyBpdCdz
IG5vdCBpbXBvc3NpYmxlIHRvIG1lbnRpb24uIFsuLi5dDQoNCkkgYWdyZWUgaXQncyBwb3Nz
aWJsZSAtLSBhcyBJIHJlcGxpZWQgcHJldmlvdXNseToNCg0KPiBJIHN1cHBvc2UgYSBzZWN0
aW9uIGNvdWxkIGJlIGFkZGVkIHNvbWV3aGVyZSB0byBwcm9wZXJseSBkb2N1bWVudCB0aGUN
Cj4gJ2VtYmVkZGluZyBzdG9yZSBmaWxlIG5hbWVzJyBwcmFjdGljZSwgYW5kIGluc2VydCBh
IGNyb3NzLXJlZmVyZW5jZSwNCkkgZG9uJ3QgdGhpbmsgZG9jdW1lbnRpbmcgdGhlIGhvdyBv
ZiB0aGUgcHJhY3RpY2Ugc2hvdWxkIGJlIGRvbmUNCmluIHRoaXMgc2VjdGlvbiwgcHJvcGVy
bHkgZXhwbGFpbmluZyAnc2VhcmNoLWlucHV0LWZpbGUnIC8gDQonc2VhcmNoLWlucHV0LWRp
cmVjdG9yeScsDQonaW5wdXRzIC8gbmF0aXZlLWlucHV0cycsICdiYXNoJyBiZWluZyBhbiBp
bXBsaWNpdCBpbnB1dCBidXQgeW91IHN0aWxsDQpoYXZlIHRvIGFkZCBpdCB0byAnaW5wdXRz
JyBpbiBzb21lIGNhc2VzIGJlY2F1c2Ugb2YgY3Jvc3MtY29tcGlsYXRpb24sDQp0aGlzLXBh
Y2thZ2UtaW5wdXQgYW5kIHRoaXMtcGFja2FnZS1uYXRpdmUtaW5wdXQgLi4uIHdvdWxkIG1h
a2UgdGhlDQpzdWJzdWJzZWN0aW9uIGEgYml0IHRvbyBsb25nIEkgdGhpbmssIGRpc3RyYWN0
aW5nIGZyb20gb3RoZXIgc2l0dWF0aW9ucywNCmhlbmNlIHRoZSBwcm9wb3NhbCBmb3IgYSBj
cm9zcy1yZWZlcmVuY2UuDQoNCkhvdyBhYm91dCBsZWF2aW5nIHRoZSAnaG93IHRvIGVtYmVk
IHN0b3JlIGZpbGUgbmFtZXMnIGZvciBhIHNlcGFyYXRlDQpkb2N1bWVudGF0aW9uIHBhdGNo
IGFuZCBzZWN0aW9uLCBhZGRpbmcgYSBjcm9zcy1yZWZlcmVuY2UgbGF0ZXI/DQoNCj4+Pj4g
T3RoZXJ3aXNlLCBpZiB0aGUgc3RvcmUNCj4+Pj4gK2ZpbGUgbmFtZSB3ZXJlIGVtYmVkZGVk
IGluIHRoZSBzb3VyY2UsIHRoZSByZXN1bHQgb2YNCj4+Pj4gQGNvbW1hbmR7Z3VpeCBidWls
ZA0KPj4+PiArLS1zb3VyY2V9IHdvdWxkIGJlIHVudXNhYmxlIG9uIG5vbi1HdWl4IHN5c3Rl
bXMgYW5kIGFsc28gbGlrZWx5DQo+Pj4+IHVudXNhYmxlDQo+Pj4+ICtvbiBHdWl4IHN5c3Rl
bXMgb2YgYW5vdGhlciBhcmNoaXRlY3R1cmUuDQo+Pj4gV2h5IGFyZSB5b3UgcmVwZWF0aW5n
IGEgZ3VpZGluZyBwcmluY2lwbGU/DQo+PiBJJ20gc2hvd2luZyB3aHksIGluIHRoaXMgY2Fz
ZSwgYSBwaGFzZSBtdXN0IGJlIHVzZWQsIGJ5IG5vdGluZyB0aGF0DQo+PiBub3QgZG9pbmcg
c28gd291bGQgYmUgY29udHJhcnkgdG8gb25lIG9mIHRoZSBwcmluY2lwbGVzLg0KPj4NCj4+
IElmIG5vdCByZXBlYXRpbmcgdGhlIHByaW5jaXBsZSBpcyBkZXNpcmVkLCBJIGNvdWxkIHBl
cmhhcHMgbnVtYmVyDQo+PiB0aGVtLCBhbmQgcmVmZXIgdG8gdGhlIHByaW5jaXBsZXMgYnkg
bnVtYmVyIGluc3RlYWQgb2YgcmVzdGF0aW5nDQo+PiB0aGVtPyBXb3VsZCByZWR1Y2UgdGhl
IGxlbmd0aCBhIGxpdHRsZS4NCj4gSSB0aGluayBjYWxsaW5nIGJhY2sgdG8gYSBndWlkaW5n
IHByaW5jaXBsZSBpbiBhbmQgb2YgaXRzZWxmIHNob3dzIHRoYXQNCj4gdGhlIHNlY3Rpb24g
aGFzIGdyb3duIHRvbyBsb25nIHRvIHJlbWVtYmVyIGl0IGJ5IHRoZSBwb2ludCB5b3UgY29t
ZSB0bw0KPiB0aGlzIGV4YW1wbGUsDQpUaGlzIGhhcyBub3RoaW5nIHRvIGRvIHdpdGggbGVu
Z3RoIGFuZCByZW1lbWJlcmluZywgYnV0IHJhdGhlciB3aXRoDQpleHBsYWluaW5nIHdoeSBh
IHBoYXNlIG11c3QgYmUgdXNlZCAtLSB0byBleHBsYWluIHRoYXQsIEkgc3RhdGUgd2hpY2gN
CnByaW5jaXBsZSBhcHBsaWVzIChhcyBtZW50aW9uZWQgcHJldmlvdXNseSkuIElmIEkgcmVt
b3ZlZCB0aGUNCmV4cGxhbmF0aW9ucywgSSB3b3VsZCBqdXN0IGJlIHN0YXRpbmcgaG93IHRv
IGRvIHRoaW5ncywgd2l0aG91dCBnaXZpbmcNCmEgbG9naWNhbCByZWFzb25pbmcgb24gdGhl
ICd3aHknLg0KPiBhbmQgSSB0aGluayB0aGF0J3MgbW9yZSBwcm9ibGVtYXRpYyB0aGFuIG1l
cmVseSB0aGUNCj4gY2FsbGJhY2suICBJZiB5b3UgZGlkbid0IG5lZWQgdG8gZGl2aWRlIHRo
aXMgaW50byBzdWJzdWJzZWN0aW9ucywgeW91DQo+IGNvdWxkIGludHJvZHVjZSB0aGUgZ3Vp
ZGluZyBwcmluY2lwbGVzIGluIGEgd2F5IHRoYXQgZmVlbHMgbW9yZQ0KPiBuYXR1cmFsLg0K
SSBjb25zaWRlciBpdCBtb3JlIG5hdHVyYWwgdG8gaGF2ZSB0aGUgJ2d1aWRpbmcgcHJpbmNp
cGxlcycgX2JlZm9yZV8gdGhlDQpjb25jcmV0ZSBjYXNlcywgYXMgdGhleSBhcmUgbWVhbnQg
dG8gYmUgJ2d1aWRpbmcnIGFuZCAncHJpbmNpcGxlcycuIEl0J3MNCmxpa2UgJ3N0YXJ0aW5n
IGZyb20gZmlyc3QgcHJpbmNpcGxlcycsIHRoZXJlIGludHJvZHVjaW5nIHRoZSBmaXJzdCAN
CnByaW5jaXBsZXMNCmFzIHlvdSBnbyBpcyBhZC1ob2MuDQoNClRoZSBndWlkaW5nIHByaW5j
aXBsZXMgYWxzbyBuZWVkIHRvIGJlIG91dHNpZGUgdGhlIGV4YW1wbGVzLCBpbiBjYXNlDQpv
bmUgb2YgdGhlIGV4YW1wbGVzIGRvZXNuJ3QgYXBwbHkgdG8gdGhlIHBhY2thZ2VyJ3MgdXNl
IGNhc2UsIHN1Y2gNCnRoYXQgdGhleSBjYW4gZmFsbC1iYWNrIHRvIHRoZSBndWlkaW5nIHBy
aW5jaXBsZXMuDQoNCkFsc28sIGluIHlvdXIgcGF0Y2ggeW91IGFyZSBkaXZpZGluZyB0aGlu
Z3MgaW4gc3Vic3Vic2VjdGlvbnMgYXMgd2VsbCwNCmp1c3QgdW5kZXIgYSBkaWZmZXJlbnQg
bmFtZSBhbmQgZGlmZmVyZW50IHJlcHJlc2VudGF0aW9uICh0YWJsZSBlbnRyaWVzDQppbiBh
IHN1YnNlY3Rpb24pLCBhcyBtZW50aW9uZWQgcHJldmlvdXNseS4NCg0KPj4+PiArQHN1YnN1
YnNlY3Rpb24gQWRkaW5nIG5ldyBmdW5jdGlvbmFsaXR5DQo+Pj4+ICtUbyBhZGQgbmV3IGZ1
bmN0aW9uYWxpdHksIGEgcGF0Y2ggaXMgYWxtb3N0IGFsd2F5cyB0aGUgbW9zdA0KPj4+PiBj
b252ZW5pZW50DQo+Pj4+ICtjaG9pY2Ugb2YgdGhlIHRocmVlIC0tIHBhdGNoZXMgYXJlIHVz
dWFsbHkgbXVsdGktbGluZSBjaGFuZ2VzLA0KPj4+PiB3aGljaA0KPj4+PiBhcmUNCj4+Pj4g
K2NvbnZlbmllbnQgdG8gZG8gd2l0aCBwYXRjaGVzIGFuZCBpbmNvbnZlbmllbnQgdG8gZG8g
d2l0aCBwaGFzZXMNCj4+Pj4gb3INCj4+Pj4gK3NuaXBwZXRzLg0KPj4+IFVobSwgd2hhdD/C
oCBQYXRjaGVzIGFyZSB0aGUgcHJlZmVycmVkIGZvcm0gb2YgcGF0Y2hlcz8NCj4+IE5vLCBJ
IG1lYW50IHRoYXQgcGF0Y2hlcyBhcmUgKHVzdWFsbHkpIHRoZSBwcmVmZXJyZWQgbWV0aG9k
IGZvcg0KPj4gYWRkaW5nIG5ldyBmdW5jdGlvbmFsaXR5LCBhbmQgdGhhdCBtdWx0aS1saW5l
IGNoYW5nZXMgYXJlIGNvbnZlbmllbnQNCj4+IHRvIGRvIHdpdGggcGF0Y2hlcy7CoCDigJh3
aGljaOKAmSByZWZlcnMgdG8gdGhlIOKAmG11bHRpLWxpbmUgY2hhbmdlc+KAmSBoZXJlLA0K
Pj4gbm90IOKAmHBhdGNoZXPigJkuDQo+IEkgc3RpbGwgZmluZCB0aGlzIHdvcmRpbmcgdmVy
eSBjb25mdXNpbmcuICBQZXJoYXBzICJUbyBhZGQgbmV3DQo+IGZ1bmN0aW9uYWxpdHksIGEg
cGF0Y2ggaXMgYWxtb3N0IGFsd2F5cyB0aGUgYmVzdCBjaG9pY2UuICBGb3Igb25lLCBpdA0K
PiBpcyBsaWtlbHkgdGhhdCB0aGUgbmV3IGZ1bmN0aW9uYWxpdHkgcmVxdWlyZXMgY2hhbmdp
bmcgbXVsdGlwbGUgbGluZXMNCj4gb2Ygc291cmNlIGNvZGUsIHdoaWNoIGlzIG1vcmUgY29u
dmVuaWVudCB0byBkbyB3aXRoIGEgcGF0Y2ggdGhhbiB3aXRoIGENCj4gc25pcHBldC4gIEZ1
cnRoZXIsIHBhdGNoZXMgY2FuIGJlIHRha2VuIGZyb20gYW5kIHN1Ym1pdHRlZCB0byB1cHN0
cmVhbXMNCj4gbW9yZSBlYXNpbHkuICBJZiB5b3VyIHBhdGNoIGhhcyBub3QgYmVlbiBzdWJt
aXR0ZWQgdG8gdXBzdHJlYW0sDQo+IGNvbnNpZGVyIGRvaW5nIHNvLiINCkl0IGxvc2VzIHNv
bWUgaW5mb3JtYXRpb24gKHRoYXQgcGF0Y2hlcyBhcmUgcHJlZmVycmVkKSBhbmQNCihhZnRl
ciByZS1hZGRpbmcgdGhlIGNvbmNsdXNpb24pIGlzIG1vcmUgdmVyYm9zZSwgd2hpY2ggYXBw
ZWFycw0KdG8gYmUgY29uc2lkZXJlZCB2ZXJ5IGltcG9ydGFudC4NCj4+PiBbLi4uXQ0KPj4+
IE92ZXJhbGwsIEknbSBub3QgY29udmluY2VkIHRoYXQgd2UgaGF2ZSBlbm91Z2ggZ3VpZGlu
ZyBwcmluY2lwbGVzDQo+Pj4gdG8gY2FsbCB0aGVtIHRoYXQsDQo+PiBJIGRvbid0IHRoaW5r
IHRoZXJlJ3MgYW55IGxvd2VyIGxpbWl0IG9uIGhvdyBtYW55IGd1aWRpbmcgcHJpbmNpcGxl
cw0KPj4gdG8gaGF2ZSwgZXhjZXB0IGZvciBwZXJoYXBzIDIgKGJlY2F1c2Ugb3RoZXJ3aXNl
IGl0IHNob3VsZCBoYXZlIGJlZW4NCj4+IHNpbmd1bGFyIG9yIHRoZXJlIGFyZW4ndCBhbnkp
LsKgIEF0IGhvdyBmZXcgZ3VpZGluZyBwcmluY2lwbGVzIHN0b3ANCj4+IHRoZSBndWlkaW5n
IHByaW5jaXBsZXMgZnJvbSBiZWluZyBndWlkaW5nIHByaW5jaXBsZXMgZm9yIHlvdSwgYW5k
DQo+PiB3aHk/DQo+Pg0KPj4gRm9yIGV4YW1wbGUsIG9uPGh0dHBzOi8vd3d3LmdudS5vcmcv
cGhpbG9zb3BoeS9mcmVlLXN3Lmh0bWw+LCBmb3VyDQo+PiBndWlkaW5nIHByaW5jaXBsZXMg
YXJlIG1lbnRpb25lZCAod2hpY2ggYXJlIG5hbWVkICdlc3NlbnRpYWwNCj4+IGZyZWVkb21z
JyB0aGVyZSksIGFuZA0KPj4gPGh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0d1aWRp
bmdfUHJpbmNpcGxlcz4gIGhhcyA1IOKAmEd1aWRpbmcNCj4+IFByaW5jaXBsZXPigJkuDQo+
IEFuIGVudW1lcmF0aW9uIG91Z2h0IHRvIGhhdmUgYXQgbGVhc3QgdGhyZWUgZWxlbWVudHMg
KG90aGVyd2lzZSBpdCdzDQo+IGp1c3QgYSBwYWlyKSwgYW5kIEkgdGhpbmsgaWYgd2UgZG8g
cHJvcGVyIGNvdW50aW5nIGFuZCBvbWl0IG5vLQ0KPiBicmFpbmVycywgc3VjaCBhcyB0aGUg
Im9ubHkgZnJlZSBzb2Z0d2FyZSIgcGFydCB0aGF0IGhhcyBhbHJlYWR5IGJlZW4NCj4gbWVu
dGlvbmVkLCB3ZSBjb21lIHZlcnkgY2xvc2UgdG8gc2tpcnRpbmcgdGhhdCBsaW5lLg0KVGhl
ICJvbmx5IGZyZWUgc29mdHdhcmUiIGlzIG1lbnRpb25lZCBlbHNld2hlcmUsIHllcywgYnV0
IGl0IGlzIG9uZQ0Kb2YgdGhlIHByaW5jaXBsZXMgZm9yIGRlY2lkaW5nIGJldHdlZW4gc25p
cHBldHMsIHBoYXNlcyBhbmQgcGF0Y2hlcy4NCldoaWxlIHlvdSBjYWxsIGl0IGEgbm8tYnJh
aW5lciwgaXQgaXMgc29tZXRpbWVzIG5lZ2xlY3RlZCwgc28gaXQgc291bmRzDQppbXBvcnRh
bnQgdG8gbWUgdG8gZXhwbGljaXRseSBsaXN0IGl0Lg0KDQpNZXJnaW5nIHRoZSAzdGggYW5k
IDR0aCBAaXRlbSwgSSBjb3VudCA0IHByaW5jaXBsZXMsIHNvIGl0IGZpdHMgd2l0aA0KYW4g
ZW51bWVyYXRpb24uDQoNCkFsc28sIEknbSBub3QgZm9sbG93aW5nIHlvdXIgcG9pbnQgaGVy
ZSAtLSB5b3VyIGNvbXBsYWludCB3YXMgdGhhdCB0aGV5DQphcmVuJ3QgZ3VpZGluZyBwcmlu
Y2lwbGVzIChiYXNlZCBvbiB0aGUgbnVtYmVyIG9mIHRoZW0pLCBidXQgeW91cg0KcmVzcG9u
c2UgaXMgdGhhdCB0aGV5IG1pZ2h0IG5vdCBmb3JtIGFuIGVudW1lcmF0aW9uP8KgIFRoZXkg
YXJlIG5hbWVkDQp0aGUgZ3VpZGluZyBwcmluY2lwbGVzLCBub3QgdGhlIGd1aWRpbmcgZW51
bWVyYXRpb24uwqAgV2hhdCBoYXZlDQplbnVtZXJhdGlvbnMgdG8gZG8gd2l0aCBhbnl0aGlu
Zz8NCg0KPj4+IHdoaWNoIChhbG9uZyB3aXRoIGl0cyBzaGVlciBsZW5ndGgpIGlzIG15IG1h
aW4NCj4+PiBjb21wbGFpbnQgd2l0aCB0aGUgd2F5IHlvdSd2ZSBwaHJhc2VkIHRoaW5ncy4N
Cj4+IChJJ20gYXNzdW1pbmcgIml0cyA9IHRoZSBwYXRjaCBhcyBhIHdob2xlIiBoZXJlKQ0K
Pj4NCj4+IEkgY291bGQgcmVtb3ZlIGFub3RoZXIgc2VjdGlvbiBvZiB0aGUgbWFudWFsIHRv
IGNvbXBlbnNhdGUgZm9yIHRoZQ0KPj4gYWRkaXRpb25hbCBsZW5ndGgsIGJ1dCBJIGRvdWJ0
IHRoYXQncyB3aGF0IHlvdSBpbnRlbmRlZC7CoCBJIGRvIG5vdA0KPj4gc2VlIHRoZSBwcm9i
bGVtIHdpdGggdGhlIHNoZWVyIGxlbmd0aCAtLSB3ZSBoYXZlIGEgYml0IG9mIGENCj4+IGRv
Y3VtZW50YXRpb24gcHJvYmxlbSBpbiBHdWl4LCB0aGVyZSBpcyBsb3RzIG9mIHVzZWZ1bCBp
bmZvcm1hdGlvbg0KPj4gdGhhdCBpcyBjdXJyZW50bHkgdW5kb2N1bWVudGVkLg0KPj4gSSBk
byBub3QgdGhpbmsgdGhlcmUgaGF2ZSBiZWVuIGFueSBjb21wbGFpbnRzIGFib3V0IHRoZSBt
YW51YWwgYmVpbmcNCj4+IHRvbyBsb25nLCBpZiBhbnl0aGluZywgaXQncyB0b28gc2hvcnQu
DQo+IEkgcGVyc29uYWxseSB0ZW5kIHRvd2FyZHMgImxlc3MgdmVyYm9zZSIsIGhlbmNlIG15
IGNvbXBsYWludCBvZg0KPiBkZXNjcmliaW5nIHNvbWV0aGluZyB3aXRoIG1hbnkgd29yZHMg
dGhhdCBjb3VsZCBiZSBkZXNjcmliZWQgd2l0aA0KPiBmZXdlci4gIEEgc2VjdGlvbiBjYW4g
c3RpbGwgYmUgdG9vIGxvbmcgd2hpbGUgdGhlIGNoYXB0ZXIgYXJvdW5kIGl0IGlzDQo+IHRv
byBzaG9ydC4NCg0KRG8geW91IGhhdmUgYW55dGhpbmcgaW4gcGFydGljdWxhciBpbiBtaW5k
Pw0KDQo+PiBJJ3ZlIHdyaXR0ZW4gc29tZSBkb2N1bWVudGF0aW9uLCBpdCB3YXMgb3JpZ2lu
YWxseSBhIGJpdCBoYXJkIHRvDQo+PiBmb2xsb3cgc28gaW4gYSBuZXh0IHZlcnNpb24gSSd2
ZSByZXN0cnVjdHVyZWQgaXQgYSBiaXQgYW5kIGV4cGxhaW5lZA0KPj4gbW9yZSwgdGhpcyBy
ZXN0cnVjdHVyaW5nIGFuZCBleHBsYW5hdGlvbiBlbnRhaWxlZCBzb21lIGFkZGl0aW9uYWwN
Cj4+IGxlbmd0aC4NCj4+DQo+PiBUaGVyZSBoYWQgYmVlbiBzb21lIHByb3Bvc2FscyBmb3Ig
YWRkaXRpb25hbCBjYXNlcyB0byBkb2N1bWVudCwgc28NCj4+IHRoZXkgd2VyZSBhZGRlZCwg
aW5jcmVhc2luZyB0aGUgbGVuZ3RoLsKgIFlvdSBoYXZlIGFkZGVkIG5ldw0KPj4gaW5mb3Jt
YXRpb24gaXMgeW91ciBwYXRjaCwgaXQgd2FzIGNvbnNpZGVyZWQgdXNlZnVsIHNvIEkndmUN
Cj4+IGludGVncmF0ZWQgc29tZSBvZiBpdCBpbiBteSBwYXRjaCwgaW5jcmVhc2luZyB0aGUg
bGVuZ3RoLsKgIChJIGRpZG4ndA0KPj4gaW50ZWdyYXRlIGFsbCBvZiB0aGUgbmV3IHBhcnRz
LCBpZiBJIGRpZCwgaXQgd291bGQgaW5jcmVhc2UgZXZlbg0KPj4gZnVydGhlci7CoCAoSWYg
ZGVzaXJlZCwgaW4gY2FuIGludGVncmF0ZSB0aGUgcmVzdCwgYXQgY29zdCAgb2Ygc29tZQ0K
Pj4gdGltZS4pKS4NCj4gTXkgcGF0Y2ggZGlkIG5vdCBqdXN0IHN0YXRlIHNvbWUgdGhpbmdz
IHlvdSBtaXNzZWQsIGl0IGFsc28gb21pdHRlZA0KPiB0aGluZ3MgdGhhdCBJIHRoaW5rIGFy
ZSBlaXRoZXIgbm90IG5lY2Vzc2FyeSBvciBwcm9iYWJseSBiZXR0ZXINCj4gZG9jdW1lbnRl
ZCBlbHNld2hlcmUuDQpXaGF0IHBhcnRpY3VsYXIgdGhpbmdzIGRvIHlvdSBoYXZlIGluIG1p
bmQsIGFuZCB3aGVyZSBkbyB5b3UNCnRoaW5rIHRoZXkgc2hvdWxkIGJldHRlciBiZSBkb2N1
bWVudGVkP8KgIEkgY2FuIG1vdmUgdGhpbmdzDQphcm91bmQgYSBiaXQgYW5kIGFkZCBjcm9z
cy1yZWZlcmVuY2VzLg0KPj4gSSBkbyBub3Qgc2VlIHdoYXQgdGhlIHByb2JsZW0gaXMgd2l0
aCBhZGRpdGlvbmFsIGxlbmd0aCBhcyBsb25nIGFzDQo+PiB0aGlzIGFkZGl0aW9uYWwgbGVu
Z3RoIGNvbWVzIHdpdGggYWRkaXRpb25hbCB1c2VmdWwgaW5mb3JtYXRpb24gYW5kDQo+PiB0
aGUgbWFudWFsIGlzIHdlbGwtc3RydWN0dXJlZCAoZS5nLiB3aXRoIChzdWIpKHN1YilzZWN0
aW9ucywgY2hhcHRlcnMNCj4+IGFuZCBpbmRpY2VzKSAtLSB3ZSBkbyBub3QgaGF2ZSBhIHBh
Z2UgbGltaXQuDQo+Pg0KPj4gQXQgd29yc3QsIHBlcmhhcHMgdGhlIHNhbWUgaW5mb3JtYXRp
b24gY291bGQgcGVyaGFwcyBiZSBlbmNvZGVkIHdpdGgNCj4+IGZld2VyIHdvcmRzPyBJIGNv
dWxkIGNvbXBhcmUgdGhlIHR3byBwYXRjaGVzIHRvIHNlZSB3aGljaCBvbmUNCj4+IGZvcm11
bGF0ZXMgY2VydGFpbiBpbmZvcm1hdGlvbiBpbiB0aGUgZmV3ZXN0IHdvcmRzLCBhbmQgY2hv
b3NlIHRoZQ0KPj4gbGVhc3QgdmVyYm9zZSBvZiB0aGUgdHdvIGZvciBlYWNoIHBpZWNlIG9m
IGluZm9ybWF0aW9uIHRoYXQgaXMNCj4+IHByZXNlbnQgaW4gYm90aD8NCj4+DQo+PiBBbHNv
LCBjb21wYXJpbmcgdGhlIHR3byBwYXRjaGVzLCBteSBwYXRjaCBoYXMgNDAgbW9yZSBsaW5l
cywgYnV0DQo+PiBhYm91dCAyNSBvZiB0aGVtIGFyZSBmb3Igbm90aW5nIHRoZSBndWlkaW5n
IHByaW5jaXBsZXMgKHdoaWNoIGFyZQ0KPj4gYWJzZW50IGluIHlvdXIgcGF0Y2gpLg0KPj4g
Q29tcGVuc2F0aW5nIGZvciB0aGF0LCB0aGUgcGF0Y2hlcyBhcmUgYWJvdXQgdGhlIHNhbWUg
bGVuZ3RoLCBzbyBJIGRvDQo+PiBub3QgdGhpbmsgdGhhdCAnc2hlZXIgbGVuZ3RoJyBpcyBh
Y2N1cmF0ZSBoZXJlLg0KPiAyNSBsaW5lcyBjYWxsaW5nIGJhY2sgdG8gZWFybGllciBpbmZv
cm1hdGlvbiBhcmUsIGltaG8sIGFuIGluZGljYXRvcg0KPiB0aGF0IHRoZSBzZWN0aW9uIGlz
IHRvbyBsb25nLiAgSW1hZ2luZSB5b3UnZCBoYXZlIHR3ZW50eS1maXZlIGZ1bmN0aW9uDQo+
IGNhbGxzIHRvIGd1aWRpbmdfcHJpbmNpcGxlcyhuKSBpbiB5b3VyIHByb2dyYW0g4oCTIGF0
IHNvbWUgcG9pbnQsIHlvdSdkDQo+IHRyeSB0byBjYWNoZSB0aG9zZS4NCihkZWZpbmUgY2Fj
aGVkLWd1aWRpbmctcHJpbmNpcGxlcw0KIMKgIChkZWxheSAobGlzdCAoZ3VpZGluZy1wcmlu
Y2lwbGUtMCkNCiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBbLi4u
XQ0KIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIChndWlkaW5nLXBy
aW5jaXBsZS0yNCkpKSkNCg0KQ2FjaGluZyB0aGUgZ3VpZGluZyBwcmluY2lwbGVzIGRvZXMg
bm90IHJlZHVjZSB0aGUgbGVuZ3RoLg0KDQpJIGRvbid0IHNlZSB0aGUgcHJvYmxlbSB3aXRo
IGNhbGxpbmcgYmFjayB0byBlYXJsaWVyIGluZm9ybWF0aW9uLg0KQWxzbywgaXQgaXNuJ3Qg
ZWFybGllciBpbmZvcm1hdGlvbiwgdGhlcmUgaXMgbm8gbmljZSBsaXN0IG9mIGd1aWRpbmcN
CnByaW5jaXBsZXMgYW55d2hlcmUgZWxzZS4NCg0KPj4+IEdvaW5nIGRvd24gdG8gc3Vic3Vi
c2VjdGlvbnMganVzdCB0byBmaW5kIG91dCB3aGVyZSBwYXRjaGVzIGFyZQ0KPj4+IGFwcHJv
cHJpYXRlLCBpcyBpbWhvIG92ZXJraWxsLg0KPj4gVGhlICdnb2luZyBkb3duIHRvIHN1YnN1
YnNlY3Rpb24nIGlzIHRoZSBjYXNlIGZvciB5b3VyIHBhdGNoIHRvbywNCj4+IHRob3VnaD8g
IEluIG15IGNhc2UsIGl0J3MgYSBzdWJzdWJzZWN0aW9uLCBpbiB5b3VyIGNhc2UgaXQncyBh
IHRhYmxlDQo+PiBlbnRyeSBpbnNpZGUgYSBzdWJzZWN0aW9uLCBib3RoIGFyZSB0aGUgc2Ft
ZSBsZXZlbCBvZiBuZXN0aW5nLg0KPiBUaGVzZSBhcmUgc3RpbGwgdHdvIHZlcnkgZGlmZmVy
ZW50IGtpbmRzIG9mIG5lc3RpbmcuICBBIHRhYmxlIGZpdHMgb250bw0KPiBhICh2aXJ0dWFs
KSBwYWdlIG1vcmUgZWFzaWx5IHRoYW4gc2V2ZXJhbCBzdWJzZWN0aW9ucy4NCkkgc3VwcG9z
ZSB0YWJsZSBpdGVtcyBtaWdodCB0YWtlIHR3byBsZXNzIGxpbmUgb3Igc28gbGVzcyB0aGFu
DQpzdWJzdWJzZWN0aW9ucywgYnV0IEkgZG9uJ3QgdGhpbmsgdGhhdCdzIHN1ZmZpY2llbnQg
cmVhc29uIHRvIHN0ZXANCmF3YXkgZnJvbSBhIG5pY2Ugc2VjdGlvbiBzdHJ1Y3R1cmUuDQo+
PiBBbHNvLCBpdCdzIGEgbWF0dGVyIG9mIGRpZmZlcmVudCBzdHJ1Y3R1cmUgLS0gaW4gbXkg
djIgYW5kIHYzIHBhdGNoLA0KPj4gSSBoYXZlIGEgJ3Byb2JsZW0gLT4gc29sdXRpb24nIHN0
cnVjdHVyZSAtLSB0aGUgaWRlYSBpcyB0aGF0IHRoZQ0KPj4gcGFja2FnZXMgaGFzIGEgcHJv
YmxlbSwgdGhleSBsb29rIGF0IHRoZSBzZWN0aW9uLCB0aGV5IHJlYWQgdGhlDQo+PiBzdWJz
dWJzZWN0aW9uIG5hbWVzLCBzZWxlY3QgdGhlDQo+PiBzdWJzdWJzZWN0aW9uIHRoYXQgbWF0
Y2hlcyB0aGVpciBwcm9ibGVtIGFuZCByZWFkIHRoZSBzb2x1dGlvbiAtLSBpbg0KPj4gc2hv
cnQsIHRoZSBpZGVhIGlzIHRvIHByb3ZpZGUgYSBzb2x1dGlvbiB0byB0aGUgcHJvYmxlbS4N
Cj4+DQo+PiBZb3VyIHN0cnVjdHVyZSBpcyB0aGUgb3RoZXIgd2F5IGFyb3VuZCAtLSBmb3Ig
c29sdXRpb25zIChwYXRjaGVzLA0KPj4gc25pcHBldHMsIHBoYXNlcyksIGl0IGdpdmVzIHRo
ZSBwZXJtaXR0ZWQgcHJvYmxlbXMgdG8gYXBwbHkgaXQgdG8uDQo+Pg0KPj4gU28geWVzLCB5
b3VyIHBhdGNoIGlzIG1vcmUgY29udmVuaWVudCBmb3IgZmluZGluZyBvdXQgd2hlcmUgcGF0
Y2hlcw0KPj4gYXJlIGFwcHJvcHJpYXRlLsKgIEkgZG8gbm90IHNlZSB0aGUgYmVuZWZpdCBv
ZiB0aGF0IHRob3VnaCAtLSBhIG5ldw0KPj4gY29udHJpYnV0b3IgcGFja2FnaW5nIGEgdGhp
bmcgd291bGRuJ3Qga25vdyBpbiBhZHZhbmNlIHdoaWNoDQo+PiBzb2x1dGlvbnMgY291bGQg
YmUgYXBwcm9wcmlhdGUgZm9yIHRoZW0gKHlvdXIgJ3NvbHV0aW9uIC0+IHByb2JsZW0nDQo+
PiBwYXRjaD8pLCByYXRoZXIsIHRoZXkgc3RhcnQgd2l0aCBhIHByb2JsZW0gYW5kIGFyZSBz
ZWFyY2hpbmcgZm9yIGFuDQo+PiBhcHByb3ByaWF0ZSBzb2x1dGlvbiAobXkgcHJvYmxlbS0+
c29sdXRpb24gcGF0Y2gpLg0KPiBJIHRoaW5rIHRoaXMgaWRlYSBjYW4gYmUgZGVidW5rZWQg
cHJldHR5IGVhc2lseS4gIElmIEkgZ2l2ZSB5b3UgYQ0KPiBoYW1tZXIgYW5kIEkgdGVsbCB5
b3UgInRoaXMgaXMgYSBoYW1tZXIsIHlvdSBjYW4gdXNlIGl0IHRvIHB1dCBuYWlscw0KPiBp
bnRvIGEgd2FsbCIsIGFuZCB5b3UgaGF2ZSBhIG5haWwgYW5kIHlvdSB3YW50IHRvIHB1dCBp
dCBpbnRvIGEgd2FsbCwNCj4geW91IHdvbid0IGdvICJvaCBubywgaG93ZXZlciB3aWxsIEkg
cHV0IHRoaXMgbmFpbCBpbnRvIGEgd2FsbD8iIOKAkyB5b3UNCj4gd2lsbCBzaW1wbHkgdXNl
IHRoZSBoYW1tZXIgdG8gZG8gc28uDQpUaGUgcGF0Y2ggZG9lcyB0aGlzLCBjdXJyZW50bHku
wqAgSXQgYWxyZWFkeSBwcm9wb3NlcyBhIG51bWJlciBvZiBoYW1tZXJzDQoocGF0Y2hlcywg
c25pcHBldHMgYW5kIHBoYXNlcykgYW5kIHB1cnBvc2VzIChhZGRpbmcgbmV3IGZ1bmN0aW9u
YWxpdHksDQpmaXhpbmcgdGVjaG5pY2FsIGlzc3VlcywgdW5idW5kbGluZywgLi4uKS4NCg0K
QWxzbywgdGhlIHNjZW5hcmlvICJvaCBubywgaG93ZXZlciB3aWxsIEkgcHV0IHRoaXMgbmFp
bCBpbnRvIGEgd2FsbCINCmFjdHVhbGx5IGhhcHBlbmVkIC0tIHNlZSB0aGUgU2hlcGhlcmQg
ZGlzY3Vzc2lvbiwgd2hlcmUgdGhlcmUgd2FzDQphIGxvdCBvZiBkaXNhZ3JlZW1lbnQgb24g
aG93IG5haWxzICg9IHNtYWxsIHdvcmstYXJvdW5kIGluIHRoZSBNYWtlZmlsZSkNCnNob3Vs
ZCBiZSBwdXQgaW4gd2FsbHMgKD0gcGF0Y2hlcywgc25pcHBldCwgcGhhc2U/KS7CoMKgIEl0
IHdhcyB0aGUgd2hvbGUNCnJlYXNvbiB0byBzdGFydCB3cml0aW5nIGEgZG9jdW1lbnRhdGlv
biBwYXRjaC4NCg0KPiBPZiBjb3Vyc2UsIGZvciB0aGlzIHRvIHdvcmsgSQ0KPiBhbHNvIGhh
dmUgdG8gdGVsbCB5b3UgKmhvdyogdG8gdXNlIGEgaGFtbWVyIHRvIHB1dCBuYWlscyBpbnRv
IGEgd2FsbCwNCj4gYnV0IHRoYXQncyBleGFjdGx5IHdoYXQgSSBkaWQgaW4gbXkgcGF0Y2gg
YnkgaW5zZXJ0aW5nIHRoZSByaWdodCBub3Rlcw0KPiBpbnRvIHRoZSBHdWl4IG1hbnVhbC4N
CkFsc28gYWxyZWFkeSB0aGUgY2FzZS4NCj4gTXkgc29sdXRpb24tPnByb2JsZW0gYXBwcm9h
Y2ggaGFzIHRoZSBiZW5lZml0LCB0aGF0IGZvbGtzIGNhbiBqdXN0IGdvDQo+IG92ZXIgYWxs
IHRoZSBzb2x1dGlvbnMsIGNoZWNrIGlmIHRoZWlyIHByb2JsZW0gZml0cywgYW5kIGFwcGx5
IHRoZSBvbmUNCj4gdGhhdCBzYXlzICJoZXJlLCB1c2UgdGhpcyIuDQoNCkEgcHJvYmxlbS0+
c29sdXRpb24gc3RydWN0dXJlIGlzIHVzZWZ1bCBmb3IgdGhhdCB0b28/DQoNCkFuZCBpdCBh
bHJlYWR5IGxpc3RzIGFsbCB0aGUgc29sdXRpb25zIChzbmlwcGV0cywgcGhhc2VzIGFuZCBw
YXRjaGVzKQ0KYW5kIGluZm9ybWF0aW9uIHRvIGRlY2lkZSB3aGV0aGVyIHRoZSBzb2x1dGlv
biBmaXRzIHRoZWlyIHByb2JsZW0NCih0aGUgZ3VpZGluZyBwcmluY2lwbGVzLCBhbmQgdGhl
IHdvcmtlZC1vdXQgY2FzZXMpLg0KDQo+IEFuZCBpZiB0aGV5IGRvbid0IGZpbmQgYW55dGhp
bmcsIHRoZXkgc2VlDQo+IHRoZSBoYW5keSBsaXR0bGUgbGluZSBhdCB0aGUgYm90dG9tIHNh
eWluZyAidXNlIHdoYXRldmVyIHlvdSB0aGluayBpcw0KPiBjb252ZW5pZW50Ii4NCk5vd2hl
cmUgZGlkIHRoZSBwYXRjaCBpbXBseSB0aGF0IHRoZSBsaXN0ZWQgY2FzZXMgd2VyZSBhbGwg
Y2FzZXMuIEluIGZhY3QsDQppbiB0d28gcGxhY2VzIGluIHRoZSBpbnRyb2R1Y3Rpb24gaXQg
aXMgaW1wbGllZCB0aGF0IHRoZSBleGFtcGxlcyBhcmUgbm90DQpleGhhdXN0aXZlLCBhbmQg
dGhhdCB0aGV5IGNhbiBjaG9vc2UgYWNjb3JkaW5nIHRvIGNvbnZlbmllbmNlOg0KDQogICog
4oCYVG8gbWFrZSB0aGluZ3MgbW9yZSBjb25jcmV0ZSBhbmQgdG8gcmVzb2x2ZSBjb25mbGlj
dHMgYmV0d2VlbiB0aGUNCiAgICBwcmluY2lwbGVzLCBhIF9mZXdfIGNhc2VzIGhhdmUgYmVl
biB3b3JrZWQgb3V0OuKAmQ0KDQogICAgKEVtcGhhc2lzIG9uIF9mZXdfIGFkZGVkKQ0KICAq
IOKAmFdoZW4gdGhlcmUgaXMgbW9yZSB0aGFuIG9uZSB3YXkgdG8gZG8gc29tZXRoaW5nLCBj
aG9vc2Ugd2hpY2hldmVyDQogICAgbWV0aG9kDQogICAgaXMgdGhlIHNpbXBsZXN04oCZDQoN
CiAgICAoSXQgc2F5cyDigJhzaW1wbGVzdOKAmSBpbnN0ZWFkIG9mIOKAmG1vc3QgY29udmVu
aWVudOKAmSwgYnV0IHdoYXRldmVyLikNCg0KPiAgICBJIGFsc28gZXhwYW5kIGEgbGl0dGxl
IG9uIHRoZSBiZW5lZml0cyBhbmQgZHJhd2JhY2tzIG9mDQo+IHRoZXNlIGFwcHJvYWNoZXMg
YXMgeW91IHdvdWxkIHdoZW4gZGVzY3JpYmluZyBkZXNpZ24gcGF0dGVybnMuDQoNClRoaXMg
aXMgYWxzbyBkb25lIGluIG15IHBhdGNoLiBFLmcuLA0KDQogICog4oCYVGhlcmUgYXJlIGEg
ZmV3IGJlbmVmaXRzIGZvciBzbmlwcGV0cyBoZXJlOg0KDQogICAgV2hlbiB1c2luZyBzbmlw
cGV0cywgdGhlIGJ1bmRsZWQgbGlicmFyeSBkb2VzIG5vdCBvY2N1ciBpbiB0aGUgc291cmNl
DQoNCiAgICByZXR1cm5lZCBieSBAY29kZXtndWl4IGJ1aWxkIC0tc291cmNlfSwgc28gdXNl
cnMgYW5kIHJldmlld2VycyBkbyBub3QNCg0KICAgIGhhdmUgdG8gd29ycnkgYWJvdXQgd2hl
dGhlciB0aGUgYnVuZGxlZCBsaWJyYXJ5IGNvbnRhaW5zIG1hbHdhcmUsDQoNCiAgICB3aGV0
aGVyIGl0IGlzIG5vbi1mcmVlLCBpZiBpdCBjb250YWlucyBwcmUtY29tcGlsZWQgYmluYXJp
ZXMgLi4uIFRoZXJlDQoNCiAgICBhcmUgYWxzbyBsZXNzIGxpY2Vuc2luZyBjb25jZXJuczog
aWYgdGhlIGJ1bmRsZWQgbGlicmFyaWVzIGFyZSByZW1vdmVkLA0KDQogICAgaXQgYmVjb21l
cyBsZXNzIGxpa2VseSB0aGF0IHRoZSBsaWNlbnNpbmcgY29uZGl0aW9ucyBhcHBseSB0byBw
ZW9wbGUNCg0KICAgIHNoYXJpbmcgdGhlIHNvdXJjZSByZXR1cm5lZCBieSBAY29tbWFuZHtn
dWl4IGJ1aWxkIC0tc291cmNlfSwgZXNwZWNpYWxseSBpZg0KDQogICAgdGhlIGJ1bmRsZWQg
bGlicmFyeSBpcyBub3QgYWN0dWFsbHkgdXNlZCBvbiBHdWl4IHN5c3RlbXMuQGZvb3Rub3Rl
e1RoaXMNCg0KICAgIGlzIEBlbXBoe25vdH0gYSBjbGFpbSB0aGF0IHlvdSBjYW4gc2ltcGx5
IGlnbm9yZSB0aGUgbGljZW5zZXMgb2YNCg0KICAgIGxpYnJhcmllcyB3aGVuIHRoZXkgYXJl
IHVuYnVuZGxlZCBhbmQgcmVwbGFjZWQgYnkgR3VpeCBwYWNrYWdlcyAtLSB0aGVyZQ0KDQog
ICAgYXJlIGxlc3MgY29uY2VybnMsIG5vdCBub25lLn0NCg0KICAgIEFzIHN1Y2gsIHNuaXBw
ZXRzIGFyZSByZWNvbW1lbmRlZCBoZXJlLuKAmQ0KDQogICog4oCYRm9yIHBoYXNlcywgdGhl
IHByb2JsZW0gaXMgdGhhdCBwaGFzZXMgZG8gbm90IGluZmx1ZW5jZSB0aGUgcmVzdWx0IG9m
DQogICAgQGNvbW1hbmR7Z3VpeCBidWlsZCAtLXNvdXJjZX0u4oCZDQoNCj4gWW91ciBwcm9i
bGVtLT5zb2x1dGlvbiBhcHByb2FjaCBpbnN0ZWFkIGxlYXZlcyBwZW9wbGUgd29uZGVyaW5n
IHdoZW4NCj4gdGhlaXIgcGFydGljdWxhciB1c2UgY2FzZSBoYXMgbm90IGJlZW4gZGVzY3Jp
YmVkLg0KU2VlIG15IHJlcGx5IHRvIOKAmEFuZCBpZiB0aGV5IGRvbid0IGZpbmQgYW55dGhp
bmcsIHRoZXkgc2VlIHRoZSBoYW5keSBsaXR0bGUNCmxpbmUgYXQgdGhlIGJvdHRvbSBzYXlp
bmcgInVzZSB3aGF0ZXZlciB5b3UgdGhpbmsgaXMgY29udmVuaWVudOKAmS4NCj4gSXQgZ2l2
ZXMgdGhlbSBhIHNvbHV0aW9uIHJhdGhlciB0aGFuIHRoZSB0b29scyB0byBidWlsZCBzb2x1
dGlvbnMgd2l0aC4NCg0KSXQgZG9lcyBnaXZlIHRoZSB0b29sczogc25pcHBldHMsIHBhdGNo
ZXMgYW5kIHBoYXNlcy7CoCBBbmQgYXMgdG9vbHMNCmZvciBkZWNpZGluZyBiZXR3ZWVuIHRo
ZSB0aHJlZSBmb3Igbm90LXlldC1kb2N1bWVudGVkIGNhc2VzLCB0aGVyZSBhcmUNCnRoZSBn
dWlkaW5nIHByaW5jaXBsZXMuwqAgQXMgYSBkZW1vbnN0cmF0aW9uIG9uIGhvdyB0byB1c2Ug
dGhlc2UgZ3VpZGluZw0KcHJpbmNpcGxlcywgdmFyaW91cyBjYXNlcyBoYXZlIGJlZW4gd29y
a2VkIG91dCBiYXNlZCBvbiB0aGUgZ3VpZGluZw0KcHJpbmNpcGxlcy4NCg0KU3VtbWFyaXNl
ZCwgaXQgZ2l2ZXMgYm90aCB0aGUgdG9vbHMgX2FuZF8gdGhlIHNvbHV0aW9ucy4NCg0KQWxz
bywgImdpdmluZyB0aGUgdG9vbHMgdG8gYnVpbGQgc29sdXRpb25zIHdpdGgiIGRvZXMgbm90
IGhlbHAgd2l0aCB0aGUNCnByb2JsZW0gdGhhdCBJIGFpbWVkIHRvIHNvbHZlIC0tIHRoZXJl
IHdhcyBkaXNhZ3JlZW1lbnQgb24gd2hhdCB0aGUNCmFwcHJvcHJpYXRlIHRvb2xzIGFyZSAo
c2VlOiBTaGVwaGVyZCksIHNvIGl0IG5vdCBqdXN0IG5lZWRzIHRvIGdpdmUgdGhlDQp0b29s
cywgYnV0IGFsc28gdGhlIHNvbHV0aW9ucy4NCg0KR3JlZXRpbmdzLA0KTWF4aW1lDQo=
--------------fiI7W13Wn7SOCrw0E7hFeOyo
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF=
-8">
  </head>
  <body>
    <p>On 07-09-2022 10:09, Liliana Marie Prikler wrote:<br>
    </p>
    <blockquote type=3D"cite"
      cite=3D"mid:44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN=
az.at">
      <pre class=3D"moz-quote-pre" wrap=3D"">Am Dienstag, dem 06.09.2022 =
um 22:21 +0200 schrieb Maxime Devos:
</pre>
      <blockquote type=3D"cite">
        <pre class=3D"moz-quote-pre" wrap=3D"">
</pre>
        <blockquote type=3D"cite">
          <pre class=3D"moz-quote-pre" wrap=3D"">We also avoid spelling o=
ut the non-free filename where possible,
preferring keep lists over remove lists, which this kind of patches
would be.
</pre>
        </blockquote>
        <pre class=3D"moz-quote-pre" wrap=3D"">Should we? I'm not seeing =
the point of that. I have not experienced
any such avoidance myself, see e.g. 'tennix', 'neverball' and
'shogun'.  It is, to my knowledge, not forbidden to mention non-free
software by name in code, as long as its not a recommendation
(explicit or implied).
</pre>
      </blockquote>
      <pre class=3D"moz-quote-pre" wrap=3D"">Indeed,  there is no hard ru=
le, hence "avoid" rather than "forbid".
</pre>
    </blockquote>
    <p>What I also meant is, that to my knowledge there is no soft rule
      either.</p>
    <p>Again, why should we avoid this, what's the point of that?<br>
    </p>
    <blockquote type=3D"cite"
      cite=3D"mid:44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN=
az.at">
      <blockquote type=3D"cite">
        <blockquote type=3D"cite">
          <pre class=3D"moz-quote-pre" wrap=3D"">
</pre>
          <blockquote type=3D"cite">
            <pre class=3D"moz-quote-pre" wrap=3D"">+@subsubsection Fixing=
 technical issues (compilation errors, test
failures, other bugs ...)
[...]
</pre>
          </blockquote>
          <pre class=3D"moz-quote-pre" wrap=3D"">I am pretty sure that mo=
st of these are *not* done in snippets, but
rather phases, if they only affect Guix.=C2=A0 In particular, grep for
failing-tests and you will find a few phases disabling them.
</pre>
        </blockquote>
        <pre class=3D"moz-quote-pre" wrap=3D"">I do not think that ignori=
ng a test counts as a bug fix.=C2=A0 I'll add it
to this subsubsection, at cost of some additional length.
</pre>
      </blockquote>
      <pre class=3D"moz-quote-pre" wrap=3D"">I do think it counts as "fix=
ing technical issues such as test
failures".
</pre>
    </blockquote>
    How does ignoring a test fix the technical issue identified by the
    test<br>
    (sometimes, the technical issue being a bug in the test itself)?<br>
    <blockquote type=3D"cite"
      cite=3D"mid:44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN=
az.at">
      <blockquote type=3D"cite">
        <blockquote type=3D"cite">
          <pre class=3D"moz-quote-pre" wrap=3D"">In fact, as far as files=
 that will not be installed are concerned,
I think phases ought to be preferred, because they're easier to
take away if an actual fix is made.
</pre>
        </blockquote>
        <pre class=3D"moz-quote-pre" wrap=3D"">I do not see a difference =
in hardness/easyness between removing a
phase and removing a snippet (both are just a matter of opening
an editor, pointing it at gnu/packages/... and removing a few lines),
though I do consider removing a patch to be slightly harder (because
gnu/local.mk is easy to forget).
</pre>
      </blockquote>
      <pre class=3D"moz-quote-pre" wrap=3D"">There still is the differenc=
e that phases are clearly delimited while
snippets are a block of code that shouldn't get too large.
</pre>
    </blockquote>
    <p>Snippets are delimited clearly as well, though, with the
      'snippet' field?</p>
    <p>And the limitations of snippet length and phases length are the
      same<br>
      -- no limits, though conciseness is appreciate as always.
    </p>
    <blockquote type=3D"cite"
      cite=3D"mid:44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN=
az.at">
      <blockquote type=3D"cite">
        <blockquote type=3D"cite">
          <pre class=3D"moz-quote-pre" wrap=3D"">For the store path embed=
ding, that's a rather roundabout way of
saying that contributers *ought to* embed store paths of certaing
things, such as commands invoked via exec et al.
</pre>
        </blockquote>
        <pre class=3D"moz-quote-pre" wrap=3D"">
It's not? It's kind of implied, yes, but the purpose isn't being a
'you should embed store paths' (subsub)section, but rather, 'if you
go embedding store paths (at least for fixing a technical issue), do
it in a phase'.

I'm not following what the complaint is, I suppose a section could be
added somewhere to properly document the 'embedding store file names'
practice, and insert a cross-reference, but that wasn't the purpose
of the patch and going by later responses, you seem opposed to making
things longer.

The alternative would be to remove this information, but then
valuable information would be lost (there had been some cases where
store file names were embedded in origin).
</pre>
      </blockquote>
      <pre class=3D"moz-quote-pre" wrap=3D"">I think my version at least =
hinted at this practice in a more concise
way, so it's not impossible to mention. [...]</pre>
    </blockquote>
    <p>I agree it's possible -- as I replied previously:</p>
    <p>
      <blockquote type=3D"cite">
        <pre class=3D"moz-quote-pre" wrap=3D"">I suppose a section could =
be added somewhere to properly document the
'embedding store file names' practice, and insert a cross-reference,</pre=
>
      </blockquote>
      I don't think documenting the how of the practice should be done<br=
>
      in this section, properly explaining 'search-input-file' /
      'search-input-directory',<br>
      'inputs / native-inputs', 'bash' being an implicit input but you
      still<br>
      have to add it to 'inputs' in some cases because of
      cross-compilation,<br>
      this-package-input and this-package-native-input ... would make
      the<br>
      subsubsection a bit too long I think, distracting from other
      situations,<br>
      hence the proposal for a cross-reference.</p>
    <p>How about leaving the 'how to embed store file names' for a
      separate<br>
      documentation patch and section, adding a cross-reference later?<br=
>
    </p>
    <blockquote type=3D"cite"
      cite=3D"mid:44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN=
az.at">
      <blockquote type=3D"cite">
        <blockquote type=3D"cite">
          <blockquote type=3D"cite">
            <pre class=3D"moz-quote-pre" wrap=3D"">Otherwise, if the stor=
e
+file name were embedded in the source, the result of
@command{guix build
+--source} would be unusable on non-Guix systems and also likely
unusable
+on Guix systems of another architecture.
</pre>
          </blockquote>
          <pre class=3D"moz-quote-pre" wrap=3D"">Why are you repeating a =
guiding principle?
</pre>
        </blockquote>
        <pre class=3D"moz-quote-pre" wrap=3D"">I'm showing why, in this c=
ase, a phase must be used, by noting that
not doing so would be contrary to one of the principles.

If not repeating the principle is desired, I could perhaps number
them, and refer to the principles by number instead of restating
them? Would reduce the length a little.
</pre>
      </blockquote>
      <pre class=3D"moz-quote-pre" wrap=3D"">I think calling back to a gu=
iding principle in and of itself shows that
the section has grown too long to remember it by the point you come to
this example,</pre>
    </blockquote>
    This has nothing to do with length and remembering, but rather with<b=
r>
    explaining why a phase must be used -- to explain that, I state
    which<br>
    principle applies (as mentioned previously). If I removed the<br>
    explanations, I would just be stating how to do things, without
    giving<br>
    a logical reasoning on the 'why'.<br>
    <blockquote type=3D"cite"
      cite=3D"mid:44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN=
az.at">
      <pre class=3D"moz-quote-pre" wrap=3D"">and I think that's more prob=
lematic than merely the
callback.  If you didn't need to divide this into subsubsections, you
could introduce the guiding principles in a way that feels more
natural.
</pre>
    </blockquote>
    I consider it more natural to have the 'guiding principles' _before_
    the<br>
    concrete cases, as they are meant to be 'guiding' and 'principles'.=C2=
=A0
    It's<br>
    like 'starting from first principles', there introducing the first
    principles<br>
    as you go is ad-hoc.<br>
    <p>The guiding principles also need to be outside the examples, in
      case<br>
      one of the examples doesn't apply to the packager's use case, such<=
br>
      that they can fall-back to the guiding principles.<br>
    </p>
    <p>Also, in your patch you are dividing things in subsubsections as
      well,<br>
      just under a different name and different representation (table
      entries<br>
      in a subsection), as mentioned previously.<br>
    </p>
    <blockquote type=3D"cite"
      cite=3D"mid:44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN=
az.at">
      <blockquote type=3D"cite">
        <blockquote type=3D"cite">
          <blockquote type=3D"cite">
            <pre class=3D"moz-quote-pre" wrap=3D"">+@subsubsection Adding=
 new functionality
+To add new functionality, a patch is almost always the most
convenient
+choice of the three -- patches are usually multi-line changes,
which
are
+convenient to do with patches and inconvenient to do with phases
or
+snippets.
</pre>
          </blockquote>
          <pre class=3D"moz-quote-pre" wrap=3D"">Uhm, what?=C2=A0 Patches=
 are the preferred form of patches?
</pre>
        </blockquote>
        <pre class=3D"moz-quote-pre" wrap=3D"">
No, I meant that patches are (usually) the preferred method for
adding new functionality, and that multi-line changes are convenient
to do with patches.=C2=A0 =E2=80=98which=E2=80=99 refers to the =E2=80=98=
multi-line changes=E2=80=99 here,
not =E2=80=98patches=E2=80=99.
</pre>
      </blockquote>
      <pre class=3D"moz-quote-pre" wrap=3D"">I still find this wording ve=
ry confusing.  Perhaps "To add new
functionality, a patch is almost always the best choice.  For one, it
is likely that the new functionality requires changing multiple lines
of source code, which is more convenient to do with a patch than with a
snippet.  Further, patches can be taken from and submitted to upstreams
more easily.  If your patch has not been submitted to upstream,
consider doing so."
</pre>
    </blockquote>
    It loses some information (that patches are preferred) and<br>
    (after re-adding the conclusion) is more verbose, which appears<br>
    to be considered very important.<br>
    <blockquote type=3D"cite"
      cite=3D"mid:44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN=
az.at">
      <blockquote type=3D"cite">
        <blockquote type=3D"cite">
          <pre class=3D"moz-quote-pre" wrap=3D"">[...]
Overall, I'm not convinced that we have enough guiding principles
to call them that,
</pre>
        </blockquote>
        <pre class=3D"moz-quote-pre" wrap=3D"">
I don't think there's any lower limit on how many guiding principles
to have, except for perhaps 2 (because otherwise it should have been
singular or there aren't any).=C2=A0 At how few guiding principles stop
the guiding principles from being guiding principles for you, and
why?

For example, on <a class=3D"moz-txt-link-rfc2396E" href=3D"https://www.gn=
u.org/philosophy/free-sw.html">&lt;https://www.gnu.org/philosophy/free-sw=
=2Ehtml&gt;</a>, four=20
guiding principles are mentioned (which are named 'essential
freedoms' there), and
<a class=3D"moz-txt-link-rfc2396E" href=3D"https://en.wikipedia.org/wiki/=
Guiding_Principles">&lt;https://en.wikipedia.org/wiki/Guiding_Principles&=
gt;</a> has 5 =E2=80=98Guiding=20
Principles=E2=80=99.
</pre>
      </blockquote>
      <pre class=3D"moz-quote-pre" wrap=3D"">An enumeration ought to have=
 at least three elements (otherwise it's
just a pair), and I think if we do proper counting and omit no-
brainers, such as the "only free software" part that has already been
mentioned, we come very close to skirting that line.
</pre>
    </blockquote>
    The "only free software" is mentioned elsewhere, yes, but it is one<b=
r>
    of the principles for deciding between snippets, phases and patches.<=
br>
    While you call it a no-brainer, it is sometimes neglected, so it
    sounds<br>
    important to me to explicitly list it.
    <p>Merging the 3th and 4th @item, I count 4 principles, so it fits
      with<br>
      an enumeration.</p>
    <p>Also, I'm not following your point here -- your complaint was
      that they<br>
      aren't guiding principles (based on the number of them), but your<b=
r>
      response is that they might not form an enumeration?=C2=A0 They are=

      named<br>
      the guiding principles, not the guiding enumeration.=C2=A0 What hav=
e<br>
      enumerations to do with anything?<br>
    </p>
    <blockquote type=3D"cite"
      cite=3D"mid:44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN=
az.at">
      <blockquote type=3D"cite">
        <blockquote type=3D"cite">
          <pre class=3D"moz-quote-pre" wrap=3D"">which (along with its sh=
eer length) is my main
complaint with the way you've phrased things.
</pre>
        </blockquote>
        <pre class=3D"moz-quote-pre" wrap=3D"">
(I'm assuming "its =3D the patch as a whole" here)

I could remove another section of the manual to compensate for the
additional length, but I doubt that's what you intended.=C2=A0 I do not
see the problem with the sheer length -- we have a bit of a
documentation problem in Guix, there is lots of useful information
that is currently undocumented.
I do not think there have been any complaints about the manual being
too long, if anything, it's too short.
</pre>
      </blockquote>
      <pre class=3D"moz-quote-pre" wrap=3D"">I personally tend towards "l=
ess verbose", hence my complaint of
describing something with many words that could be described with
fewer.  A section can still be too long while the chapter around it is
too short.</pre>
    </blockquote>
    <p>Do you have anything in particular in mind?<br>
    </p>
    <blockquote type=3D"cite"
      cite=3D"mid:44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN=
az.at">
      <blockquote type=3D"cite">
        <pre class=3D"moz-quote-pre" wrap=3D"">I've written some document=
ation, it was originally a bit hard to
follow so in a next version I've restructured it a bit and explained
more, this restructuring and explanation entailed some additional
length.

There had been some proposals for additional cases to document, so
they were added, increasing the length.=C2=A0 You have added new
information is your patch, it was considered useful so I've
integrated some of it in my patch, increasing the length.=C2=A0 (I didn't=

integrate all of the new parts, if I did, it would increase even
further.=C2=A0 (If desired, in can integrate the rest, at cost  of some
time.)).
</pre>
      </blockquote>
      <pre class=3D"moz-quote-pre" wrap=3D"">My patch did not just state =
some things you missed, it also omitted
things that I think are either not necessary or probably better
documented elsewhere.
</pre>
    </blockquote>
    What particular things do you have in mind, and where do you<br>
    think they should better be documented?=C2=A0 I can move things<br>
    around a bit and add cross-references.
    <blockquote type=3D"cite"
      cite=3D"mid:44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN=
az.at">
      <blockquote type=3D"cite">
        <pre class=3D"moz-quote-pre" wrap=3D"">I do not see what the prob=
lem is with additional length as long as
this additional length comes with additional useful information and
the manual is well-structured (e.g. with (sub)(sub)sections, chapters
and indices) -- we do not have a page limit.

At worst, perhaps the same information could perhaps be encoded with
fewer words? I could compare the two patches to see which one
formulates certain information in the fewest words, and choose the
least verbose of the two for each piece of information that is
present in both?

Also, comparing the two patches, my patch has 40 more lines, but
about 25 of them are for noting the guiding principles (which are
absent in your patch).
Compensating for that, the patches are about the same length, so I do
not think that 'sheer length' is accurate here.
</pre>
      </blockquote>
      <pre class=3D"moz-quote-pre" wrap=3D"">25 lines calling back to ear=
lier information are, imho, an indicator
that the section is too long.  Imagine you'd have twenty-five function
calls to guiding_principles(n) in your program =E2=80=93 at some point, y=
ou'd
try to cache those.
</pre>
    </blockquote>
    (define cached-guiding-principles<br>
    =C2=A0 (delay (list (guiding-principle-0)<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [...]<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (guiding-principle-24))))
    <p>Caching the guiding principles does not reduce the length.</p>
    <p>I don't see the problem with calling back to earlier information.<=
br>
      Also, it isn't earlier information, there is no nice list of
      guiding<br>
      principles anywhere else.<br>
    </p>
    <blockquote type=3D"cite"
      cite=3D"mid:44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN=
az.at">
      <blockquote type=3D"cite">
        <blockquote type=3D"cite">
          <pre class=3D"moz-quote-pre" wrap=3D"">Going down to subsubsect=
ions just to find out where patches are
appropriate, is imho overkill.
</pre>
        </blockquote>
        <pre class=3D"moz-quote-pre" wrap=3D"">
The 'going down to subsubsection' is the case for your patch too,
though?  In my case, it's a subsubsection, in your case it's a table
entry inside a subsection, both are the same level of nesting.
</pre>
      </blockquote>
      <pre class=3D"moz-quote-pre" wrap=3D"">These are still two very dif=
ferent kinds of nesting.  A table fits onto
a (virtual) page more easily than several subsections.
</pre>
    </blockquote>
    I suppose table items might take two less line or so less than<br>
    subsubsections, but I don't think that's sufficient reason to step<br=
>
    away from a nice section structure.<br>
    <blockquote type=3D"cite"
      cite=3D"mid:44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN=
az.at">
      <blockquote type=3D"cite">
        <pre class=3D"moz-quote-pre" wrap=3D"">Also, it's a matter of dif=
ferent structure -- in my v2 and v3 patch,
I have a 'problem -&gt; solution' structure -- the idea is that the
packages has a problem, they look at the section, they read the
subsubsection names, select the
subsubsection that matches their problem and read the solution -- in
short, the idea is to provide a solution to the problem.

Your structure is the other way around -- for solutions (patches,
snippets, phases), it gives the permitted problems to apply it to.

So yes, your patch is more convenient for finding out where patches
are appropriate.=C2=A0 I do not see the benefit of that though -- a new
contributor packaging a thing wouldn't know in advance which
solutions could be appropriate for them (your 'solution -&gt; problem'
patch?), rather, they start with a problem and are searching for an
appropriate solution (my problem-&gt;solution patch).
</pre>
      </blockquote>
      <pre class=3D"moz-quote-pre" wrap=3D"">I think this idea can be deb=
unked pretty easily.  If I give you a
hammer and I tell you "this is a hammer, you can use it to put nails
into a wall", and you have a nail and you want to put it into a wall,
you won't go "oh no, however will I put this nail into a wall?" =E2=80=93=
 you
will simply use the hammer to do so.</pre>
    </blockquote>
    The patch does this, currently.=C2=A0 It already proposes a number of=

    hammers<br>
    (patches, snippets and phases) and purposes (adding new
    functionality,<br>
    fixing technical issues, unbundling, ...).
    <p>Also, the scenario "oh no, however will I put this nail into a
      wall"<br>
      actually happened -- see the Shepherd discussion, where there was<b=
r>
      a lot of disagreement on how nails (=3D small work-around in the
      Makefile)<br>
      should be put in walls (=3D patches, snippet, phase?).=C2=A0=C2=A0 =
It was the
      whole<br>
      reason to start writing a documentation patch.<br>
    </p>
    <blockquote type=3D"cite"
      cite=3D"mid:44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN=
az.at">
      <pre class=3D"moz-quote-pre" wrap=3D"">Of course, for this to work =
I
also have to tell you *how* to use a hammer to put nails into a wall,
but that's exactly what I did in my patch by inserting the right notes
into the Guix manual.
</pre>
    </blockquote>
    Also already the case.
    <blockquote type=3D"cite"
      cite=3D"mid:44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN=
az.at">
      <pre class=3D"moz-quote-pre" wrap=3D"">My solution-&gt;problem appr=
oach has the benefit, that folks can just go
over all the solutions, check if their problem fits, and apply the one
that says "here, use this".</pre>
    </blockquote>
    <p>A problem-&gt;solution structure is useful for that too?</p>
    <p>And it already lists all the solutions (snippets, phases and
      patches)<br>
      and information to decide whether the solution fits their problem<b=
r>
      (the guiding principles, and the worked-out cases).<br>
    </p>
    <blockquote type=3D"cite"
      cite=3D"mid:44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN=
az.at">
      <pre class=3D"moz-quote-pre" wrap=3D"">And if they don't find anyth=
ing, they see
the handy little line at the bottom saying "use whatever you think is
convenient".</pre>
    </blockquote>
    Nowhere did the patch imply that the listed cases were all cases. In
    fact,<br>
    in two places in the introduction it is implied that the examples
    are not<br>
    exhaustive, and that they can choose according to convenience:<br>
    <ul>
      <li>=E2=80=98To make things more concrete and to resolve conflicts =
between
        the<br>
        principles, a _few_ cases have been worked out:=E2=80=99<br>
        <br>
        (Emphasis on _few_ added)</li>
      <li>=E2=80=98When there is more than one way to do something, choos=
e
        whichever method<br>
        is the simplest=E2=80=99<br>
        <br>
        (It says =E2=80=98simplest=E2=80=99 instead of =E2=80=98most conv=
enient=E2=80=99, but whatever.)<br>
      </li>
    </ul>
    <blockquote type=3D"cite"
      cite=3D"mid:44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN=
az.at">
      <pre class=3D"moz-quote-pre" wrap=3D"">  I also expand a little on =
the benefits and drawbacks of
these approaches as you would when describing design patterns.</pre>
    </blockquote>
    <p>This is also done in my patch. E.g.,</p>
    <ul>
      <li>=E2=80=98There are a few benefits for snippets here:<br>
        <br>
        <div class=3D"line diff addition">
          <pre>When using snippets, the bundled library does not occur in=
 the source</pre>
        </div>
        <div class=3D"line diff addition">
          <pre>returned by @code{guix build --source}, so users and revie=
wers do not</pre>
        </div>
        <div class=3D"line diff addition">
          <pre>have to worry about whether the bundled library contains m=
alware,</pre>
        </div>
        <div class=3D"line diff addition">
          <pre>whether it is non-free, if it contains pre-compiled binari=
es ... There</pre>
        </div>
        <div class=3D"line diff addition">
          <pre>are also less licensing concerns: if the bundled libraries=
 are removed,</pre>
        </div>
        <div class=3D"line diff addition">
          <pre>it becomes less likely that the licensing conditions apply=
 to people</pre>
        </div>
        <div class=3D"line diff addition">
          <pre>sharing the source returned by @command{guix build --sourc=
e}, especially if</pre>
        </div>
        <div class=3D"line diff addition">
          <pre>the bundled library is not actually used on Guix systems.@=
footnote{This</pre>
        </div>
        <div class=3D"line diff addition">
          <pre>is @emph{not} a claim that you can simply ignore the licen=
ses of</pre>
        </div>
        <div class=3D"line diff addition">
          <pre>libraries when they are unbundled and replaced by Guix pac=
kages -- there</pre>
        </div>
        <div class=3D"line diff addition">
          <pre>are less concerns, not none.}</pre>
        </div>
        <div class=3D"line diff addition">
          <pre>
</pre>
        </div>
        <div class=3D"line diff addition">
          <pre>As such, snippets are recommended here.=E2=80=99</pre>
        </div>
      </li>
      <li>=E2=80=98For phases, the problem is that phases do not influenc=
e the
        result of<br>
        @command{guix build --source}.=E2=80=99
      </li>
    </ul>
    <blockquote type=3D"cite"
      cite=3D"mid:44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN=
az.at">
      <pre class=3D"moz-quote-pre" wrap=3D"">Your problem-&gt;solution ap=
proach instead leaves people wondering when
their particular use case has not been described.</pre>
    </blockquote>
    See my reply to =E2=80=98And if they don't find anything, they see th=
e handy
    little<br>
    line at the bottom saying "use whatever you think is convenient=E2=80=
=99.
    <blockquote type=3D"cite"
      cite=3D"mid:44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN=
az.at">
      <pre class=3D"moz-quote-pre" wrap=3D"">It gives them a solution rat=
her than the tools to build solutions with.</pre>
    </blockquote>
    <p>It does give the tools: snippets, patches and phases.=C2=A0 And as=

      tools<br>
      for deciding between the three for not-yet-documented cases, there
      are<br>
      the guiding principles.=C2=A0 As a demonstration on how to use thes=
e
      guiding<br>
      principles, various cases have been worked out based on the
      guiding<br>
      principles.</p>
    <p>Summarised, it gives both the tools _and_ the solutions.<br>
    </p>
    <p>Also, "giving the tools to build solutions with" does not help
      with the<br>
      problem that I aimed to solve -- there was disagreement on what
      the<br>
      appropriate tools are (see: Shepherd), so it not just needs to
      give the<br>
      tools, but also the solutions.<br>
    </p>
    Greetings,<br>
    Maxime<br>
  </body>
</html>

--------------fiI7W13Wn7SOCrw0E7hFeOyo--

--------------lT8JlkWSD5VQXD90Dz1boRGV
Content-Type: application/pgp-keys; name="OpenPGP_0x49E3EE22191725EE.asc"
Content-Disposition: attachment; filename="OpenPGP_0x49E3EE22191725EE.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xjMEX4ch6BYJKwYBBAHaRw8BAQdANPb/d6MrGnGi5HyvODCkBUJPRjiFQcRU5V+m
xvMaAa/NL01heGltZSBEZXZvcyA8bWF4aW1lLmRldm9zQHN0dWRlbnQua3VsZXV2
ZW4uYmU+wpAEExYIADgWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCX4ch6AIbAwUL
CQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRBJ4+4iGRcl7japAQC3opZ2KGWzWmRc
/gIWSu0AAcfMwyinFEEPa/QhUt2CogD/e2RdF4CYAgaRHJJmZ9WU7piKbLZ7llB4
LzgezVDHggzNJU1heGltZSBEZXZvcyA8bWF4aW1lZGV2b3NAdGVsZW5ldC5iZT7C
kAQTFggAOBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJf56ycAhsDBQsJCAcDBRUK
CQgLBRYCAwEAAh4BAheAAAoJEEnj7iIZFyXujpQBAKV1SwDDl4f24rXciDlB9L8W
ycZt30CgbewMSRQk4mvbAP9dFMbVVixYBd6C8cfhR+NsOBGiOJnQABlUmgNuqGFJ
Dc44BF+HIegSCisGAQQBl1UBBQEBB0BOlzIWiJzgobMF6/cqwLaLk7jIcFSZ++c0
k9cCNT6YXwMBCAfCeAQYFggAIBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJfhyHo
AhsMAAoJEEnj7iIZFyXuMr0BAJc8cl5PGvVmVuSQVKjleNl4DK1/XAaPAYPe34AE
fZJPAP9IqLCQhH/FeJanHqBP8gNdGNI2qn8RnnLVfRJgUjZ1BA=3D=3D
=3DOVqp
-----END PGP PUBLIC KEY BLOCK-----

--------------lT8JlkWSD5VQXD90Dz1boRGV--

--------------N4yS7ui6DXqk1oJogkEaW0eQ--

--------------bYZznqRF4e00yv03Q3Otn4Cv
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wnsEABYIACMWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYxnOKwUDAAAAAAAKCRBJ4+4iGRcl7oE4
AQDtdxmMVTnJacU9WxjP4u0o+5DrGsvJxnT41XavjvSmfgD/UucFg4ulPdrlNij3rvlwEFU2y+1/
/n00uv4kVb+vswI=
=7etQ
-----END PGP SIGNATURE-----

--------------bYZznqRF4e00yv03Q3Otn4Cv--

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#57598] [PATCH] doc: Update contribution guidelines on patches, etc.
Resent-From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Fri, 09 Sep 2022 08:05:01 +0000
Resent-Message-ID: <handler.57598.B57598.166271068424599 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 57598
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Maxime Devos <maximedevos@HIDDEN>, 57598 <at> debbugs.gnu.org
Received: via spool by 57598-submit <at> debbugs.gnu.org id=B57598.166271068424599
          (code B ref 57598); Fri, 09 Sep 2022 08:05:01 +0000
Received: (at 57598) by debbugs.gnu.org; 9 Sep 2022 08:04:44 +0000
Received: from localhost ([127.0.0.1]:60854 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oWZ0F-0006Og-Dx
	for submit <at> debbugs.gnu.org; Fri, 09 Sep 2022 04:04:44 -0400
Received: from mailrelay.tugraz.at ([129.27.2.202]:4606)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <liliana.prikler@HIDDEN>) id 1oWZ0A-0006OR-WF
 for 57598 <at> debbugs.gnu.org; Fri, 09 Sep 2022 04:04:42 -0400
Received: from kagayaki.fritz.box (85-127-52-93.dsl.dynamic.surfer.at
 [85.127.52.93])
 by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4MP7nF6sNXz3wkj;
 Fri,  9 Sep 2022 10:04:33 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at;
 s=mailrelay; t=1662710674;
 bh=wt03wgni0fyW7+DkIj8549+pqugm7pa/dcKT+FftKvs=;
 h=Subject:From:To:Date:In-Reply-To:References;
 b=ojTfoV6Q4mRmaAN1svBf5VRWzsRW57q8CpVPwXqFg8J4NBWvtHYYKkGKVs0eHi85J
 cjAQWkUtOn5OppSaarjNlqZJleK8MLKiypb/UMeNiKeFR3xJD/woBN8Z9w+5vZ7uR1
 jZbB6eeq63h328fPbam6jBRZCghC1PTP5za0bhbk=
Message-ID: <1e707c8e345af7b2fb0353c5f1c0e37d716e3308.camel@HIDDEN>
From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
Date: Fri, 09 Sep 2022 10:04:32 +0200
In-Reply-To: <b33540cb-0c72-6170-34d0-b8df4ab79b8f@HIDDEN>
References: <20220905160048.18173-1-maximedevos@HIDDEN>
 <0f78953d57d8f66a934baf518b7c9e3247b580fd.camel@HIDDEN>
 <d0a48b72-c62b-cc97-e399-22abc0af182d@HIDDEN>
 <44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN>
 <b33540cb-0c72-6170-34d0-b8df4ab79b8f@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.1 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-TUG-Backscatter-control: waObeELIUl4ypBWmcn/8wQ
X-Spam-Scanner: SpamAssassin 3.003001 
X-Spam-Score-relay: -1.9
X-Scanned-By: MIMEDefang 2.74 on 129.27.10.116
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Am Donnerstag, dem 08.09.2022 um 13:12 +0200 schrieb Maxime Devos:
> On 07-09-2022 10:09, Liliana Marie Prikler wrote:
> > Am Dienstag, dem 06.09.2022 um 22:21 +0200 schrieb Maxime Devos:
> > > It is, to my knowledge, not forbidden to mention non-free
> > > software by name in code, as long as its not a recommendation
> > > (explicit or implied).
> > Indeed, there is no hard rule, hence "avoid" rather than "forbid".
> What I also meant is, that to my knowledge there is no soft rule
> either.  Again, why should we avoid this, what's the point of that?
In descriptions, it is wise to do so because it helps software stand on
its own merits rather than just "being a clone of this thing you aren't
allowed to have" (this is real criticism pointed at us from the
proprietary software embracers).  See for instance minetest, whichisy

> How does ignoring a test fix the technical issue identified by the
> test (sometimes, the technical issue being a bug in the test itself)?
It fixes the technical issue that an otherwise functional package
(w.r.t. the N tests that don't fail) builds.  This is a particularly
useful distinction with tests that require a network connection and
thus have to fail in a build container, or are known flaky upstream and
thus cause reproducibility issues.

> > There still is the difference that phases are clearly delimited
> > while snippets are a block of code that shouldn't get too large.
> Snippets are delimited clearly as well, though, with the 'snippet'
> field?
> And the limitations of snippet length and phases length are the same
>  -- no limits, though conciseness is appreciate as always. 
True, but phases can be made to do just one thing, whereas snippets
have to fix everything that's wrong in more or less one (begin ...). 
This is a noticable distinction.

> 
> > I think my version at least hinted at this practice in a more
> > concise way, so it's not impossible to mention. [...]
> I agree it's possible -- as I replied previously:
> > I suppose a section could be added somewhere to properly document
> > the 'embedding store file names' practice, and insert a
> > cross-reference,
> I don't think documenting the how of the practice should be done
> in this section, properly explaining 'search-input-file' / 'search-
> input-directory', 'inputs / native-inputs', 'bash' being an implicit
> input but you still have to add it to 'inputs' in some cases because
> of cross-compilation, this-package-input and this-package-native-
> input ... would make the
> subsubsection a bit too long I think, distracting from other
> situations, hence the proposal for a cross-reference.
> How about leaving the 'how to embed store file names' for a separate
>  documentation patch and section, adding a cross-reference later?
See above, "I suppose a section could be added..." means I'm somewhat
indifferent to whether it's done now or later; I would however very
much prefer a wording that points people toward this practice existing,
even if they have to go look in the code for examples.  Alternatively,
a footnote for the most common case (search-input-file inputs
"bin/command") ought to suffice for the time being.

> 
> 
> > I think calling back to a guiding principle in and of itself shows
> > that the section has grown too long to remember it by the point you
> > come to this example,
> This has nothing to do with length and remembering, but rather with
> explaining why a phase must be used -- to explain that, I state which
> principle applies (as mentioned previously). If I removed the
> explanations, I would just be stating how to do things, without
> giving a logical reasoning on the 'why'.
IMHO, I think a reader who remembers the guiding principles should see
that it applies.

> > and I think that's more problematic than merely the
> > callback. If you didn't need to divide this into subsubsections,
> > you could introduce the guiding principles in a way that feels more
> > natural.
> I consider it more natural to have the 'guiding principles' _before_
> the concrete cases, as they are meant to be 'guiding' and
> 'principles'. 
> It's like 'starting from first principles', there introducing the
> first principles as you go is ad-hoc.
> The guiding principles also need to be outside the examples, in case
>  one of the examples doesn't apply to the packager's use case, such
>  that they can fall-back to the guiding principles.
> Also, in your patch you are dividing things in subsubsections as
> well, just under a different name and different representation (table
> entries in a subsection), as mentioned previously.
A table entry is not a subsection, as much as you want it to be that.

Also, your guiding principles are (with one exception) really just
invariants that ought to hold for the source field of a package.  
As such, I think it would be easier to state "A package's source should
be the smallest corresponding source in terms of uncompressed file
size.  This corresponding source must consist only of free software
(note Free Software) and should build on all platforms supported by
upstream."  Note how smallest naturally implies unbundling bundled
sources.

> > I still find this wording very confusing. Perhaps "To add new
> > functionality, a patch is almost always the best choice. For one,
> > it is likely that the new functionality requires changing multiple
> > lines of source code, which is more convenient to do with a patch
> > than with a snippet. Further, patches can be taken from and
> > submitted to upstreams more easily. If your patch has not been
> > submitted to upstream, consider doing so."
> It loses some information (that patches are preferred) and
> (after re-adding the conclusion) is more verbose, which appears
> to be considered very important.
Which conclusion is there to re-add?  The conclusion is already stated
in the beginning: patches are almost always the best choice.  Then two
reasons as for why.  The part w.r.t. upstreaming changes has also been
addressed.

> > An enumeration ought to have at least three elements (otherwise
> > it's just a pair), and I think if we do proper counting and omit
> > no-brainers, such as the "only free software" part that has already
> > been mentioned, we come very close to skirting that line.
> The "only free software" is mentioned elsewhere, yes, but it is one
> of the principles for deciding between snippets, phases and patches.
> While you call it a no-brainer, it is sometimes neglected, so it
> sounds important to me to explicitly list it. 
> Merging the 3th and 4th @item, I count 4 principles, so it fits with
> an enumeration.
> Also, I'm not following your point here -- your complaint was that
> they aren't guiding principles (based on the number of them), but
> your response is that they might not form an enumeration?  They are
> named the guiding principles, not the guiding enumeration.  What have
> enumerations to do with anything?
I'm using enumeration as a super term here, which can be
((sub)sub)sections, chapters, list elements, whatever, and my claim is
that we barely have enough principles to allow the use of a plural. 
Adding to that, now that I think of it, I also doubt their usefulness
in guiding.  "Use whatever feels convenient, but note that that might
be subjective" is more useful at the end of the section when a user
didn't find what they were looking for than at the start.

> > > > which (along with its sheer length) is my main
> > > > complaint with the way you've phrased things.
> > > (I'm assuming "its = the patch as a whole" here)
> > > 
> > > I could remove another section of the manual to compensate for
> > > the additional length, but I doubt that's what you intended.  I
> > > do not see the problem with the sheer length -- we have a bit of
> > > a documentation problem in Guix, there is lots of useful
> > > information that is currently undocumented.
> > > I do not think there have been any complaints about the manual
> > > being too long, if anything, it's too short.
> > I personally tend towards "less verbose", hence my complaint of
> > describing something with many words that could be described with
> > fewer. A section can still be too long while the chapter around it
> > is too short.
> Do you have anything in particular in mind?
This is more of a broad statement that applies to the patch as a whole
than to any of its constituent parts in particular.  However, in some
cases where I think it's particularly noticable, I'll try to point out
shorter formulations.

> > > I've written some documentation, it was originally a bit hard to
> > > follow so in a next version I've restructured it a bit and
> > > explained more, this restructuring and explanation entailed some
> > > additional length.
> > > 
> > > There had been some proposals for additional cases to document,
> > > so they were added, increasing the length.  You have added new
> > > information is your patch, it was considered useful so I've
> > > integrated some of it in my patch, increasing the length.  (I
> > > didn't integrate all of the new parts, if I did, it would
> > > increase even further.  (If desired, in can integrate the rest,
> > > at cost of some time.)).
> > My patch did not just state some things you missed, it also omitted
> > things that I think are either not necessary or probably better
> > documented elsewhere.
> What particular things do you have in mind, and where do you
> think they should better be documented?  I can move things
> around a bit and add cross-references. 
> > 
> > > I do not see what the problem is with additional length as long
> > > as this additional length comes with additional useful
> > > information and the manual is well-structured (e.g. with
> > > (sub)(sub)sections, chapters and indices) -- we do not have a
> > > page limit.
> > > 
> > > At worst, perhaps the same information could perhaps be encoded
> > > with fewer words? I could compare the two patches to see which
> > > one formulates certain information in the fewest words, and
> > > choose the least verbose of the two for each piece of information
> > > that is present in both?
> > > 
> > > Also, comparing the two patches, my patch has 40 more lines, but
> > > about 25 of them are for noting the guiding principles (which are
> > > absent in your patch).
> > > Compensating for that, the patches are about the same length, so
> > > I do not think that 'sheer length' is accurate here.
> > 25 lines calling back to earlier information are, imho, an
> > indicator that the section is too long. Imagine you'd have twenty-
> > five function calls to guiding_principles(n) in your program – at
> > some point, you'd try to cache those.
> (define cached-guiding-principles
>   (delay (list (guiding-principle-0)
>                     [...]
>                     (guiding-principle-24)))) 
> Caching the guiding principles does not reduce the length.
> I don't see the problem with calling back to earlier information.
> Also, it isn't earlier information, there is no nice list of guiding
> principles anywhere else.
At the risk of responding jokingly to what was meant serious: I didn't
know we suddenly gained 20 guiding principles.

> 
> > > > Going down to subsubsections just to find out where patches are
> > > > appropriate, is imho overkill.
> > > The 'going down to subsubsection' is the case for your patch too,
> > > though? In my case, it's a subsubsection, in your case it's a
> > > table
> > > entry inside a subsection, both are the same level of nesting.
> > These are still two very different kinds of nesting. A table fits
> > onto a (virtual) page more easily than several subsections.
> I suppose table items might take two less line or so less than
> subsubsections, but I don't think that's sufficient reason to step
> away from a nice section structure.
Another reason is that you can end a table in the middle of a section,
which you can't do with subsections.  Hence why I'm able to put a
remark at the bottom, which you have to clumsily fit into the top.

> > > Also, it's a matter of different structure -- in my v2 and v3
> > > patch, I have a 'problem -> solution' structure -- the idea is
> > > that the packages has a problem, they look at the section, they
> > > read the subsubsection names, select the
> > > subsubsection that matches their problem and read the solution --
> > > in short, the idea is to provide a solution to the problem.
> > > 
> > > Your structure is the other way around -- for solutions (patches,
> > > snippets, phases), it gives the permitted problems to apply it
> > > to.
> > > 
> > > So yes, your patch is more convenient for finding out where
> > > patches are appropriate.  I do not see the benefit of that though
> > > -- a new contributor packaging a thing wouldn't know in advance
> > > which solutions could be appropriate for them (your 'solution ->
> > > problem' patch?), rather, they start with a problem and are
> > > searching for an appropriate solution (my problem->solution
> > > patch).
> > I think this idea can be debunked pretty easily. If I give you a
> > hammer and I tell you "this is a hammer, you can use it to put
> > nails into a wall", and you have a nail and you want to put it into
> > a wall, you won't go "oh no, however will I put this nail into a
> > wall?" – you will simply use the hammer to do so.
> The patch does this, currently.  It already proposes a number of
> hammers (patches, snippets and phases) and purposes (adding new
> functionality, fixing technical issues, unbundling, ...). 
> Also, the scenario "oh no, however will I put this nail into a wall"
> actually happened -- see the Shepherd discussion, where there was
> a lot of disagreement on how nails (= small work-around in the
> Makefile) should be put in walls (= patches, snippet, phase?).   It
> was the whole reason to start writing a documentation patch.
You might want to add a link here if it supports your argument, but
without looking at the discussion this rather sounds like "oh no, I
have three hammers, which one do I pick?" – which, fair enough, is
still a problem, but one that neither of our patches would cause imho.

> > Of course, for this to work I also have to tell you *how* to use a
> > hammer to put nails into a wall, but that's exactly what I did in
> > my patch by inserting the right notes into the Guix manual.
> Also already the case. 
> > My solution->problem approach has the benefit, that folks can just
> > go over all the solutions, check if their problem fits, and apply
> > the one that says "here, use this".
> A problem->solution structure is useful for that too?
> And it already lists all the solutions (snippets, phases and patches)
> and information to decide whether the solution fits their problem
> (the guiding principles, and the worked-out cases).
Again, I believe you're overselling the guiding principles.

> > And if they don't find anything, they see the handy little line at
> > the bottom saying "use whatever you think is convenient".
> Nowhere did the patch imply that the listed cases were all cases. In
> fact, in two places in the introduction it is implied that the
> examples are not exhaustive, and that they can choose according to
> convenience  [...]
Emphasis on handy little line rather than needing to be told twice
(particularly if people have no idea what to expect due to not having
looked at the worked-out cases yet).

> >  I also expand a little on the benefits and drawbacks of
> > these approaches as you would when describing design patterns.
> This is also done in my patch. [...]
This is not about the contained information, but the structure of the
contained information.

My solution->problem style follows roughly this style:
1. solution
2. problems it is known to solve
3. how to use
4. properties, caveats, etc.

Your problem->solution style roughly has the following:
1. problem
2. (set of) solution(s)
3. if more than one solution, maybe a help to select

This makes it so that people might have to go to a different subsection
than the one they read for their solution to find out about potential
caveats, e.g. not embedding store paths in a snippet.

> > Your problem->solution approach instead leaves people wondering
> > when their particular use case has not been described.
> See my reply to ‘And if they don't find anything, they see the handy
> little line at the bottom saying "use whatever you think is
> convenient’. 
> > It gives them a solution rather than the tools to build solutions
> > with.
> It does give the tools: snippets, patches and phases.
As far as I read, it describes none of those.  It puts out guiding
principles and some already worked-out cases.

> Also, "giving the tools to build solutions with" does not help with
> the problem that I aimed to solve -- there was disagreement on what
> the appropriate tools are (see: Shepherd), so it not just needs to
> give the tools, but also the solutions.
I don't see how my patch lacks this information however.  In
particular, for review purposes, mine should be easier to work with. 
For instance, the reviewer sees a hash embedded in a snippet, sees in
the snippet entry that you shouldn't do that, and can thus say "nope,
don't do a snippet here".

Regardless of which patch we pick, it should not mandate a particular
solution in potentially contentious cases, and also point towards the
right solution.  See our discussions on the individual solutions on
points in which I believe you've errored.

Cheers

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#57598] [PATCH] doc: Update contribution guidelines on patches, etc.
Resent-From: Maxime Devos <maximedevos@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Fri, 09 Sep 2022 11:15:02 +0000
Resent-Message-ID: <handler.57598.B57598.166272207911105 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 57598
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Liliana Marie Prikler <liliana.prikler@HIDDEN>, 57598 <at> debbugs.gnu.org
Received: via spool by 57598-submit <at> debbugs.gnu.org id=B57598.166272207911105
          (code B ref 57598); Fri, 09 Sep 2022 11:15:02 +0000
Received: (at 57598) by debbugs.gnu.org; 9 Sep 2022 11:14:39 +0000
Received: from localhost ([127.0.0.1]:60941 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oWbxz-0002sz-Ce
	for submit <at> debbugs.gnu.org; Fri, 09 Sep 2022 07:14:38 -0400
Received: from baptiste.telenet-ops.be ([195.130.132.51]:56248)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <maximedevos@HIDDEN>) id 1oWbxt-0002si-H0
 for 57598 <at> debbugs.gnu.org; Fri, 09 Sep 2022 07:14:34 -0400
Received: from [IPV6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16]
 ([IPv6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16])
 by baptiste.telenet-ops.be with bizsmtp
 id HnER2800P20ykKC01nERlQ; Fri, 09 Sep 2022 13:14:27 +0200
Message-ID: <a24e8c5c-a986-3f6f-15a4-03caeb801e6d@HIDDEN>
Date: Fri, 9 Sep 2022 13:14:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.12.0
Content-Language: en-US
References: <20220905160048.18173-1-maximedevos@HIDDEN>
 <0f78953d57d8f66a934baf518b7c9e3247b580fd.camel@HIDDEN>
 <d0a48b72-c62b-cc97-e399-22abc0af182d@HIDDEN>
 <44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN>
 <b33540cb-0c72-6170-34d0-b8df4ab79b8f@HIDDEN>
 <1e707c8e345af7b2fb0353c5f1c0e37d716e3308.camel@HIDDEN>
From: Maxime Devos <maximedevos@HIDDEN>
In-Reply-To: <1e707c8e345af7b2fb0353c5f1c0e37d716e3308.camel@HIDDEN>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------ztoDhl3zz8S7BeO6MhLpiOLo"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r22;
 t=1662722067; bh=1Y1FS593G81grZ4wkUEizHFCc0seFdnJfROIZljCB3A=;
 h=Date:To:References:From:Subject:In-Reply-To;
 b=dI9rZonTyHxJI5VccKRyRLeOgT2KAA5j9ep4DsaH4ZC4AXqeojOqv/ptfDLNd5zHt
 Bd3T079JVIA4YxFrXbJpS+qFgvWOiJ3tVOQNO/qF9mmYAZerkeiJyFjwD/1VRTlMi1
 zE/jyIon2Qufagw/Rl8HXmtw1yEE0SsRx8Wpz4selzayeYdsgqDbjlT++CbJ82LTdQ
 7Jg7SOPwCmRnWoRoopbPr5tF/qGxaNftiMTDED5zNIPpoN8MKsd00kIjj0YpyWi7EP
 9aJtD/UXt3pDOOaUy4iqfU0TJIqQQF4JEJrSFw0vpYrgmOFx3C3OVVeFxrNHhrjL5x
 ZlpH30Grn5INA==
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------ztoDhl3zz8S7BeO6MhLpiOLo
Content-Type: multipart/mixed; boundary="------------LEdw0eVxVIORtTBS4903Yefe";
 protected-headers="v1"
From: Maxime Devos <maximedevos@HIDDEN>
To: Liliana Marie Prikler <liliana.prikler@HIDDEN>,
 57598 <at> debbugs.gnu.org
Message-ID: <a24e8c5c-a986-3f6f-15a4-03caeb801e6d@HIDDEN>
Subject: Re: [PATCH] doc: Update contribution guidelines on patches, etc.
References: <20220905160048.18173-1-maximedevos@HIDDEN>
 <0f78953d57d8f66a934baf518b7c9e3247b580fd.camel@HIDDEN>
 <d0a48b72-c62b-cc97-e399-22abc0af182d@HIDDEN>
 <44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN>
 <b33540cb-0c72-6170-34d0-b8df4ab79b8f@HIDDEN>
 <1e707c8e345af7b2fb0353c5f1c0e37d716e3308.camel@HIDDEN>
In-Reply-To: <1e707c8e345af7b2fb0353c5f1c0e37d716e3308.camel@HIDDEN>

--------------LEdw0eVxVIORtTBS4903Yefe
Content-Type: multipart/mixed; boundary="------------tRDWi1bv5GRDIutW2FCxCszJ"

--------------tRDWi1bv5GRDIutW2FCxCszJ
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

DQoNCk9uIDA5LTA5LTIwMjIgMTA6MDQsIExpbGlhbmEgTWFyaWUgUHJpa2xlciB3cm90ZToN
Cj4gQW0gRG9ubmVyc3RhZywgZGVtIDA4LjA5LjIwMjIgdW0gMTM6MTIgKzAyMDAgc2Nocmll
YiBNYXhpbWUgRGV2b3M6DQo+PiBPbiAwNy0wOS0yMDIyIDEwOjA5LCBMaWxpYW5hIE1hcmll
IFByaWtsZXIgd3JvdGU6DQo+Pj4gQW0gRGllbnN0YWcsIGRlbSAwNi4wOS4yMDIyIHVtIDIy
OjIxICswMjAwIHNjaHJpZWIgTWF4aW1lIERldm9zOg0KPj4+PiBJdCBpcywgdG8gbXkga25v
d2xlZGdlLCBub3QgZm9yYmlkZGVuIHRvIG1lbnRpb24gbm9uLWZyZWUNCj4+Pj4gc29mdHdh
cmUgYnkgbmFtZSBpbiBjb2RlLCBhcyBsb25nIGFzIGl0cyBub3QgYSByZWNvbW1lbmRhdGlv
bg0KPj4+PiAoZXhwbGljaXQgb3IgaW1wbGllZCkuDQo+Pj4gSW5kZWVkLCB0aGVyZSBpcyBu
byBoYXJkIHJ1bGUsIGhlbmNlICJhdm9pZCIgcmF0aGVyIHRoYW4gImZvcmJpZCIuDQo+PiBX
aGF0IEkgYWxzbyBtZWFudCBpcywgdGhhdCB0byBteSBrbm93bGVkZ2UgdGhlcmUgaXMgbm8g
c29mdCBydWxlDQo+PiBlaXRoZXIuICBBZ2Fpbiwgd2h5IHNob3VsZCB3ZSBhdm9pZCB0aGlz
LCB3aGF0J3MgdGhlIHBvaW50IG9mIHRoYXQ/DQo+IEluIGRlc2NyaXB0aW9ucywgaXQgaXMg
d2lzZSB0byBkbyBzbyBiZWNhdXNlIGl0IGhlbHBzIHNvZnR3YXJlIHN0YW5kIG9uDQo+IGl0
cyBvd24gbWVyaXRzIHJhdGhlciB0aGFuIGp1c3QgImJlaW5nIGEgY2xvbmUgb2YgdGhpcyB0
aGluZyB5b3UgYXJlbid0DQo+IGFsbG93ZWQgdG8gaGF2ZSIgKHRoaXMgaXMgcmVhbCBjcml0
aWNpc20gcG9pbnRlZCBhdCB1cyBmcm9tIHRoZQ0KPiBwcm9wcmlldGFyeSBzb2Z0d2FyZSBl
bWJyYWNlcnMpLiAgU2VlIGZvciBpbnN0YW5jZSBtaW5ldGVzdCwgd2hpY2hpc3kNCg0KU2Vu
dGVuY2UgbWlnaHQgaGF2ZSBiZWVuIHRydW5jYXRlZD8gQWxzbywgdGhpcyBpcyB0aGUgcGFj
a2FnZSBzb3VyY2UgDQpmaWVsZCwgbm90IHRoZSBkZXNjcmlwdGlvbiwgSSBkb24ndCBzZWUg
aG93IHRoZSAiaGVscHMgc29mdHdhcmUgc3RhbmQgb24gDQppdHMgb3duIG1lcml0cyIgYXBw
bGllcyB0byBzbmlwcGV0cyBvZiB0aGUgcGFja2FnZSBzb3VyY2UuDQoNCj4gDQo+PiBIb3cg
ZG9lcyBpZ25vcmluZyBhIHRlc3QgZml4IHRoZSB0ZWNobmljYWwgaXNzdWUgaWRlbnRpZmll
ZCBieSB0aGUNCj4+IHRlc3QgKHNvbWV0aW1lcywgdGhlIHRlY2huaWNhbCBpc3N1ZSBiZWlu
ZyBhIGJ1ZyBpbiB0aGUgdGVzdCBpdHNlbGYpPw0KPiBJdCBmaXhlcyB0aGUgdGVjaG5pY2Fs
IGlzc3VlIHRoYXQgYW4gb3RoZXJ3aXNlIGZ1bmN0aW9uYWwgcGFja2FnZQ0KPiAody5yLnQu
IHRoZSBOIHRlc3RzIHRoYXQgZG9uJ3QgZmFpbCkgYnVpbGRzLiAgVGhpcyBpcyBhIHBhcnRp
Y3VsYXJseQ0KPiB1c2VmdWwgZGlzdGluY3Rpb24gd2l0aCB0ZXN0cyB0aGF0IHJlcXVpcmUg
YSBuZXR3b3JrIGNvbm5lY3Rpb24gYW5kDQo+IHRodXMgaGF2ZSB0byBmYWlsIGluIGEgYnVp
bGQgY29udGFpbmVyLCBvciBhcmUga25vd24gZmxha3kgdXBzdHJlYW0gYW5kDQo+IHRodXMg
Y2F1c2UgcmVwcm9kdWNpYmlsaXR5IGlzc3Vlcy4NCg0KTmV0d29yayB0ZXN0OiByaWdodCAo
dGhvdWdoIHByZWZlcmFibHkgdGhvc2Ugd291bGQgc3VwcG9ydCBhIA0KLS1uby1uZXR3b3Jr
LXRlc3RzIHRlc3Qgb3B0aW9uIG9yIHN1Y2gpLg0KDQpGb3IgZmxha3kgdGVzdHM6IHRob3Nl
IHNvdW5kIGxpa2UgYnVncyB0byBtZSwgaWdub3JpbmcgdGhlbSBkb2Vzbid0IA0KcmVtb3Zl
IHRoZSBmbGFreW5lc3MuDQoNCj4+PiBUaGVyZSBzdGlsbCBpcyB0aGUgZGlmZmVyZW5jZSB0
aGF0IHBoYXNlcyBhcmUgY2xlYXJseSBkZWxpbWl0ZWQNCj4+PiB3aGlsZSBzbmlwcGV0cyBh
cmUgYSBibG9jayBvZiBjb2RlIHRoYXQgc2hvdWxkbid0IGdldCB0b28gbGFyZ2UuDQo+PiBT
bmlwcGV0cyBhcmUgZGVsaW1pdGVkIGNsZWFybHkgYXMgd2VsbCwgdGhvdWdoLCB3aXRoIHRo
ZSAnc25pcHBldCcNCj4+IGZpZWxkPw0KPj4gQW5kIHRoZSBsaW1pdGF0aW9ucyBvZiBzbmlw
cGV0IGxlbmd0aCBhbmQgcGhhc2VzIGxlbmd0aCBhcmUgdGhlIHNhbWUNCj4+ICDCoC0tIG5v
IGxpbWl0cywgdGhvdWdoIGNvbmNpc2VuZXNzIGlzIGFwcHJlY2lhdGUgYXMgYWx3YXlzLg0K
PiBUcnVlLCBidXQgcGhhc2VzIGNhbiBiZSBtYWRlIHRvIGRvIGp1c3Qgb25lIHRoaW5nLCB3
aGVyZWFzIHNuaXBwZXRzDQo+IGhhdmUgdG8gZml4IGV2ZXJ5dGhpbmcgdGhhdCdzIHdyb25n
IGluIG1vcmUgb3IgbGVzcyBvbmUgKGJlZ2luIC4uLikuDQo+IFRoaXMgaXMgYSBub3RpY2Fi
bGUgZGlzdGluY3Rpb24uPiANCg0KWW91IGNhbiBkbyB0aGF0IGluIHNuaXBwZXRzIHRvbywg
d2l0aCBjb21tZW50czoNCg0KKHNuaXBwZXQNCiAgICN+KGJlZ2luDQogICAgICAgOzsgRG8g
dGhlIGZvbyB0aGluZw0KICAgICAgIChmb28pDQogICAgICAgKGZvby0yIFsuLi5dKQ0KICAg
ICAgIFsuLi5dDQogICAgICAgOzsgRG8gdGhlIGJhciB0aGluZw0KICAgICAgIChiYXIpDQog
ICAgICAgKGJhci0yIFsuLi5dKQ0KICAgICAgIFsuLi5dKSkNCg0KDQo+Pg0KPj4+IEkgdGhp
bmsgbXkgdmVyc2lvbiBhdCBsZWFzdCBoaW50ZWQgYXQgdGhpcyBwcmFjdGljZSBpbiBhIG1v
cmUNCj4+PiBjb25jaXNlIHdheSwgc28gaXQncyBub3QgaW1wb3NzaWJsZSB0byBtZW50aW9u
LiBbLi4uXQ0KPj4gSSBhZ3JlZSBpdCdzIHBvc3NpYmxlIC0tIGFzIEkgcmVwbGllZCBwcmV2
aW91c2x5Og0KPj4+IEkgc3VwcG9zZSBhIHNlY3Rpb24gY291bGQgYmUgYWRkZWQgc29tZXdo
ZXJlIHRvIHByb3Blcmx5IGRvY3VtZW50DQo+Pj4gdGhlICdlbWJlZGRpbmcgc3RvcmUgZmls
ZSBuYW1lcycgcHJhY3RpY2UsIGFuZCBpbnNlcnQgYQ0KPj4+IGNyb3NzLXJlZmVyZW5jZSwN
Cj4+IEkgZG9uJ3QgdGhpbmsgZG9jdW1lbnRpbmcgdGhlIGhvdyBvZiB0aGUgcHJhY3RpY2Ug
c2hvdWxkIGJlIGRvbmUNCj4+IGluIHRoaXMgc2VjdGlvbiwgcHJvcGVybHkgZXhwbGFpbmlu
ZyAnc2VhcmNoLWlucHV0LWZpbGUnIC8gJ3NlYXJjaC0NCj4+IGlucHV0LWRpcmVjdG9yeScs
ICdpbnB1dHMgLyBuYXRpdmUtaW5wdXRzJywgJ2Jhc2gnIGJlaW5nIGFuIGltcGxpY2l0DQo+
PiBpbnB1dCBidXQgeW91IHN0aWxsIGhhdmUgdG8gYWRkIGl0IHRvICdpbnB1dHMnIGluIHNv
bWUgY2FzZXMgYmVjYXVzZQ0KPj4gb2YgY3Jvc3MtY29tcGlsYXRpb24sIHRoaXMtcGFja2Fn
ZS1pbnB1dCBhbmQgdGhpcy1wYWNrYWdlLW5hdGl2ZS0NCj4+IGlucHV0IC4uLiB3b3VsZCBt
YWtlIHRoZQ0KPj4gc3Vic3Vic2VjdGlvbiBhIGJpdCB0b28gbG9uZyBJIHRoaW5rLCBkaXN0
cmFjdGluZyBmcm9tIG90aGVyDQo+PiBzaXR1YXRpb25zLCBoZW5jZSB0aGUgcHJvcG9zYWwg
Zm9yIGEgY3Jvc3MtcmVmZXJlbmNlLg0KPj4gSG93IGFib3V0IGxlYXZpbmcgdGhlICdob3cg
dG8gZW1iZWQgc3RvcmUgZmlsZSBuYW1lcycgZm9yIGEgc2VwYXJhdGUNCj4+ICDCoGRvY3Vt
ZW50YXRpb24gcGF0Y2ggYW5kIHNlY3Rpb24sIGFkZGluZyBhIGNyb3NzLXJlZmVyZW5jZSBs
YXRlcj8NCj4gU2VlIGFib3ZlLCAiSSBzdXBwb3NlIGEgc2VjdGlvbiBjb3VsZCBiZSBhZGRl
ZC4uLiIgbWVhbnMgSSdtIHNvbWV3aGF0DQo+IGluZGlmZmVyZW50IHRvIHdoZXRoZXIgaXQn
cyBkb25lIG5vdyBvciBsYXRlcjsNCg0KTml0cGljazogeW91IGFyZSBxdW90aW5nIHNvbWUg
dGV4dCBJIHdyb3RlLCBzbyAnSScgcmVmZXJzIHRvIG1lIGhlcmUsIA0Kbm90IHlvdS4NCg0K
ICBJIHdvdWxkIGhvd2V2ZXIgdmVyeQ0KPiBtdWNoIHByZWZlciBhIHdvcmRpbmcgdGhhdCBw
b2ludHMgcGVvcGxlIHRvd2FyZCB0aGlzIHByYWN0aWNlIGV4aXN0aW5nLA0KPiBldmVuIGlm
IHRoZXkgaGF2ZSB0byBnbyBsb29rIGluIHRoZSBjb2RlIGZvciBleGFtcGxlcy4gIEFsdGVy
bmF0aXZlbHksDQo+IGEgZm9vdG5vdGUgZm9yIHRoZSBtb3N0IGNvbW1vbiBjYXNlIChzZWFy
Y2gtaW5wdXQtZmlsZSBpbnB1dHMNCj4gImJpbi9jb21tYW5kIikgb3VnaHQgdG8gc3VmZmlj
ZSBmb3IgdGhlIHRpbWUgYmVpbmcuDQoNCkFzaWRlIGZyb20gdGhlIHR5cG8ncyBhbmQgYSBm
ZXcgcmVwaHJhc2luZ3MsIEknbSBkb25lIHdpdGggdGhlIA0KZG9jdW1lbnRhdGlvbi4gIElm
IHNvbWVvbmUgd2FudHMgdG8gZXh0ZW5kIHRoZSBzZWN0aW9uIHdpdGggc3VjaCANCmluZm9y
bWF0aW9uLCB0aGV5IGNhbiBhbHdheXMgZG8gc28gbGF0ZXIuDQoNCj4+DQo+Pj4gSSB0aGlu
ayBjYWxsaW5nIGJhY2sgdG8gYSBndWlkaW5nIHByaW5jaXBsZSBpbiBhbmQgb2YgaXRzZWxm
IHNob3dzDQo+Pj4gdGhhdCB0aGUgc2VjdGlvbiBoYXMgZ3Jvd24gdG9vIGxvbmcgdG8gcmVt
ZW1iZXIgaXQgYnkgdGhlIHBvaW50IHlvdQ0KPj4+IGNvbWUgdG8gdGhpcyBleGFtcGxlLA0K
Pj4gVGhpcyBoYXMgbm90aGluZyB0byBkbyB3aXRoIGxlbmd0aCBhbmQgcmVtZW1iZXJpbmcs
IGJ1dCByYXRoZXIgd2l0aA0KPj4gZXhwbGFpbmluZyB3aHkgYSBwaGFzZSBtdXN0IGJlIHVz
ZWQgLS0gdG8gZXhwbGFpbiB0aGF0LCBJIHN0YXRlIHdoaWNoDQo+PiBwcmluY2lwbGUgYXBw
bGllcyAoYXMgbWVudGlvbmVkIHByZXZpb3VzbHkpLiBJZiBJIHJlbW92ZWQgdGhlDQo+PiBl
eHBsYW5hdGlvbnMsIEkgd291bGQganVzdCBiZSBzdGF0aW5nIGhvdyB0byBkbyB0aGluZ3Ms
IHdpdGhvdXQNCj4+IGdpdmluZyBhIGxvZ2ljYWwgcmVhc29uaW5nIG9uIHRoZSAnd2h5Jy4N
Cj4gSU1ITywgSSB0aGluayBhIHJlYWRlciB3aG8gcmVtZW1iZXJzIHRoZSBndWlkaW5nIHBy
aW5jaXBsZXMgc2hvdWxkIHNlZQ0KPiB0aGF0IGl0IGFwcGxpZXMuDQoNCkxpa2VseS4gQnV0
IHJlbW92aW5nIHRoZSBleHBsaWNpdCBtZW50aW9uIG9mIHRoZSBndWlkaW5nIHByaW5jaXBs
ZSBzdGlsbCANCm1ha2VzIHRoZSBsb2dpY2FsIHJlYXNvbmluZyBpbmNvbXBsZXRlLCByZW1l
bWJlcmluZyBoYXMgbm90aGluZyB0byBkbyANCndpdGggaXQuICBBcyBJJ3ZlIHdyaXR0ZW4g
cHJldmlvdXNseTog4oCYVGhpcyBoYXMgbm90aGluZyBkbyBkbyB3aXRoIFsuLi5dIA0KYW5k
IHJlbWVtYmVyaW5nLCBidXQgcmF0aGVyIHdpdGggWy4uLl3igJkuDQoNCj4+PiBhbmQgSSB0
aGluayB0aGF0J3MgbW9yZSBwcm9ibGVtYXRpYyB0aGFuIG1lcmVseSB0aGUNCj4+PiBjYWxs
YmFjay4gSWYgeW91IGRpZG4ndCBuZWVkIHRvIGRpdmlkZSB0aGlzIGludG8gc3Vic3Vic2Vj
dGlvbnMsDQo+Pj4geW91IGNvdWxkIGludHJvZHVjZSB0aGUgZ3VpZGluZyBwcmluY2lwbGVz
IGluIGEgd2F5IHRoYXQgZmVlbHMgbW9yZQ0KPj4+IG5hdHVyYWwuDQo+PiBJIGNvbnNpZGVy
IGl0IG1vcmUgbmF0dXJhbCB0byBoYXZlIHRoZSAnZ3VpZGluZyBwcmluY2lwbGVzJyBfYmVm
b3JlXw0KPj4gdGhlIGNvbmNyZXRlIGNhc2VzLCBhcyB0aGV5IGFyZSBtZWFudCB0byBiZSAn
Z3VpZGluZycgYW5kDQo+PiAncHJpbmNpcGxlcycuDQo+PiBJdCdzIGxpa2UgJ3N0YXJ0aW5n
IGZyb20gZmlyc3QgcHJpbmNpcGxlcycsIHRoZXJlIGludHJvZHVjaW5nIHRoZQ0KPj4gZmly
c3QgcHJpbmNpcGxlcyBhcyB5b3UgZ28gaXMgYWQtaG9jLg0KPj4gVGhlIGd1aWRpbmcgcHJp
bmNpcGxlcyBhbHNvIG5lZWQgdG8gYmUgb3V0c2lkZSB0aGUgZXhhbXBsZXMsIGluIGNhc2UN
Cj4+ICDCoG9uZSBvZiB0aGUgZXhhbXBsZXMgZG9lc24ndCBhcHBseSB0byB0aGUgcGFja2Fn
ZXIncyB1c2UgY2FzZSwgc3VjaA0KPj4gIMKgdGhhdCB0aGV5IGNhbiBmYWxsLWJhY2sgdG8g
dGhlIGd1aWRpbmcgcHJpbmNpcGxlcy4NCj4+IEFsc28sIGluIHlvdXIgcGF0Y2ggeW91IGFy
ZSBkaXZpZGluZyB0aGluZ3MgaW4gc3Vic3Vic2VjdGlvbnMgYXMNCj4+IHdlbGwswqBqdXN0
IHVuZGVyIGEgZGlmZmVyZW50IG5hbWUgYW5kIGRpZmZlcmVudCByZXByZXNlbnRhdGlvbiAo
dGFibGUNCj4+IGVudHJpZXPCoGluIGEgc3Vic2VjdGlvbiksIGFzIG1lbnRpb25lZCBwcmV2
aW91c2x5Lg0KPiBBIHRhYmxlIGVudHJ5IGlzIG5vdCBhIHN1YnNlY3Rpb24sIGFzIG11Y2gg
YXMgeW91IHdhbnQgaXQgdG8gYmUgdGhhdC4NCg0KSXQgaW5kZWVkIGlzIG5vdCwgcmF0aGVy
IHRoZXkgYXJlIGVxdWl2YWxlbnQgaGVyZSBpbiB0ZXJtcyBvZiBzdHJ1Y3R1cmUsIA0KbmVz
dGluZyBhbmQgcHJvYmxlbWF0aWNuZXNzLg0KDQo+IA0KPiBBbHNvLCB5b3VyIGd1aWRpbmcg
cHJpbmNpcGxlcyBhcmUgKHdpdGggb25lIGV4Y2VwdGlvbikgcmVhbGx5IGp1c3QNCj4gaW52
YXJpYW50cyB0aGF0IG91Z2h0IHRvIGhvbGQgZm9yIHRoZSBzb3VyY2UgZmllbGQgb2YgYSBw
YWNrYWdlLg0KDQpJIGRvbid0IGtub3cgYWJvdXQgdGhlIGV4Y2VwdGlvbnMgKEkgaGF2ZW4n
dCBjb3VudGVkIHRoZW0pLCBidXQgeWVzLCANCmluZGVlZC4gIEkgZG8gbm90IHNlZSB0aGUg
cHJvYmxlbSBvZiB0aGlzLg0KDQo+IEFzIHN1Y2gsIEkgdGhpbmsgaXQgd291bGQgYmUgZWFz
aWVyIHRvIHN0YXRlICJBIHBhY2thZ2UncyBzb3VyY2Ugc2hvdWxkDQo+IGJlIHRoZSBzbWFs
bGVzdCBjb3JyZXNwb25kaW5nIHNvdXJjZSBpbiB0ZXJtcyBvZiB1bmNvbXByZXNzZWQgZmls
ZQ0KPiBzaXplLiAgVGhpcyBjb3JyZXNwb25kaW5nIHNvdXJjZSBtdXN0IGNvbnNpc3Qgb25s
eSBvZiBmcmVlIHNvZnR3YXJlDQo+IChub3RlIEZyZWUgU29mdHdhcmUpIGFuZCBzaG91bGQg
YnVpbGQgb24gYWxsIHBsYXRmb3JtcyBzdXBwb3J0ZWQgYnkNCj4gdXBzdHJlYW0uIiAgTm90
ZSBob3cgc21hbGxlc3QgbmF0dXJhbGx5IGltcGxpZXMgdW5idW5kbGluZyBidW5kbGVkDQo+
IHNvdXJjZXMuDQoNClRoaXMgY3JpdGVyaXVtIG9uIG92ZXJseSBzbWFsbCBzb3VyY2VzLiAg
T2Z0ZW4sIGEgcGFja2FnZSdzIHNvdXJjZSANCmNvbnRhaW5zIHRoaW5ncyB0aGF0IGlzIG5v
dCB1c2VkIGZvciB0aGUgYnVpbGQgb3Igb3V0cHV0cyBhbmQgaGVuY2UNCmlzIG5vdCBwYXJ0
IG9mIHRoZSBjb3JyZXNwb25kaW5nIHNvdXJjZS4gIEV4YW1wbGVzOg0KDQoqIHRoZSBzb3Vy
Y2UgY29udGFpbnMgZG9jdW1lbnRhdGlvbiB0aGF0IGNvdWxkIGJlIGJ1aWx0IGFuZCBpbnN0
YWxsZWQsDQogICBidXQgR3VpeCBkb2Vzbid0IGRvIHNvIHlldC4gIC0tPiBzaG91bGQgYmUg
a2VwdCAodW5sZXNzIG5vbi1mcmVlKQ0KKiBkb2N1bWVudGF0aW9uIHRoYXQgaXNuJ3QgbWVh
bnQgdG8gYmUgYnVpbHQgb3IgaW5zdGFsbGVkDQogICAoZS5nLiBIQUNLSU5HLCBQQUNLQUdF
UlMsIC4uLikgLS0+IHVzZWZ1bCwgc2hvdWxkbid0IGJlIHJlbW92ZWQuDQoqIC5naXRpZ25v
cmUsIC5naXRodWIsIC4uLiAtLT4gbm90aGluZyB3cm9uZyB3aXRoIHJlbW92aW5nIHRob3Nl
LA0KICAgYnV0IHBvaW50bGVzcywgbGV0J3Mgbm90IHdhc3RlIG91ciB0aW1lIHdpdGggbG9v
a2luZyBmb3IgdGhvc2UNCiAgIGFuZCByZW1vdmluZyB0aGVtLCBldmVuIHRob3VnaCBkb2lu
ZyBzbyB3b3VsZCBtYWtlIGl0IHNtYWxsZXIuDQoqIHNvdXJjZSBmaWxlcyBmb3IgcGxhdGZv
cm1zIHRoZSB1cHN0cmVhbSBkb2VzIG5vdCBzdXBwb3J0IHlldC9hbnltb3JlDQogICAoYnV0
IHdpdGggc29tZSB2b2x1bnRlZXIgZWZmb3J0IChlLmcuIGJ1Z2ZpeGVzKSwgaXQgbWlnaHQg
YmVjb21lDQogICBhIHN1cHBvcnRlZCBzeXN0ZW0gYWdhaW4pDQogICAtLT4gcmVtb3Zpbmcg
dGhlbSAoZS5nLiBhcyBwYXJ0IG9mIGFuIG92ZXJseS1icm9hZCANCihkZWxldGUtZmlsZS1y
ZWN1cnNpdmVseSANCiJ0aGlzLWRpci1oYXMtYnVuZGxpbmctYWxiZWl0LW5vdC1hbGwtb2Yt
aXQtaXMtYnVuZGxpbmciKSkNCiAgICAgICBjYW4gYmUgT0staXNoLCBidXQgcmVtb3Zpbmcg
dGhlbSBmb3IgJ21pbmltYWxpdHknIGlzIHBvaW50bGVzcy4NCg0KDQo+Pj4gSSBzdGlsbCBm
aW5kIHRoaXMgd29yZGluZyB2ZXJ5IGNvbmZ1c2luZy4gUGVyaGFwcyAiVG8gYWRkIG5ldw0K
Pj4+IGZ1bmN0aW9uYWxpdHksIGEgcGF0Y2ggaXMgYWxtb3N0IGFsd2F5cyB0aGUgYmVzdCBj
aG9pY2UuIEZvciBvbmUsDQo+Pj4gaXQgaXMgbGlrZWx5IHRoYXQgdGhlIG5ldyBmdW5jdGlv
bmFsaXR5IHJlcXVpcmVzIGNoYW5naW5nIG11bHRpcGxlDQo+Pj4gbGluZXMgb2Ygc291cmNl
IGNvZGUsIHdoaWNoIGlzIG1vcmUgY29udmVuaWVudCB0byBkbyB3aXRoIGEgcGF0Y2gNCj4+
PiB0aGFuIHdpdGggYSBzbmlwcGV0LiBGdXJ0aGVyLCBwYXRjaGVzIGNhbiBiZSB0YWtlbiBm
cm9tIGFuZA0KPj4+IHN1Ym1pdHRlZCB0byB1cHN0cmVhbXMgbW9yZSBlYXNpbHkuIElmIHlv
dXIgcGF0Y2ggaGFzIG5vdCBiZWVuDQo+Pj4gc3VibWl0dGVkIHRvIHVwc3RyZWFtLCBjb25z
aWRlciBkb2luZyBzby4iDQo+PiBJdCBsb3NlcyBzb21lIGluZm9ybWF0aW9uICh0aGF0IHBh
dGNoZXMgYXJlIHByZWZlcnJlZCkgYW5kDQo+PiAoYWZ0ZXIgcmUtYWRkaW5nIHRoZSBjb25j
bHVzaW9uKSBpcyBtb3JlIHZlcmJvc2UsIHdoaWNoIGFwcGVhcnMNCj4+IHRvIGJlIGNvbnNp
ZGVyZWQgdmVyeSBpbXBvcnRhbnQuDQo+IFdoaWNoIGNvbmNsdXNpb24gaXMgdGhlcmUgdG8g
cmUtYWRkPw0KDQoicGF0Y2hlcyBhcmUgcHJlZmVycmVkIg0KDQogICBUaGUgY29uY2x1c2lv
biBpcyBhbHJlYWR5IHN0YXRlZA0KPiBpbiB0aGUgYmVnaW5uaW5nOiBwYXRjaGVzIGFyZSBh
bG1vc3QgYWx3YXlzIHRoZSBiZXN0IGNob2ljZS4gIFRoZW4gdHdvDQo+IHJlYXNvbnMgYXMg
Zm9yIHdoeS4gIFRoZSBwYXJ0IHcuci50LiB1cHN0cmVhbWluZyBjaGFuZ2VzIGhhcyBhbHNv
IGJlZW4NCj4gYWRkcmVzc2VkLg0KDQpXaGlsZSBJIGNvbnNpZGVyIHRoYXQgcG9saWNpZXMg
c2hvdWxkIGhhdmUgImJlc3QgY2hvaWNlcyIgY29pbmNpZGluZyANCndpdGggInByZWZlcnJl
ZCIgYW5kIHRoYXQgbm90IGRvaW5nIHNvIHdvdWxkIGJlIGlsbG9naWNhbCwgcGVvcGxlLCAN
CnByb2plY3RzLCBkZWNpc2lvbnMgLi4uIGFyZSBmYXIgZnJvbSBhbHdheXMgbG9naWNhbC4N
Cg0KQmVjYXVzZSBvZiB0aGlzLCBwZW9wbGUgY2Fubm90IGFzc3VtZSB0aGF0IHRoZSAnYmVz
dCBjaG9pY2VzJyBhcmUgDQoncHJlZmVycmVkJywgc28gaXQgbmVlZHMgdG8gYmUgbWVudGlv
bmVkIGV4cGxpY2l0bHkgdGhhdCB0aGVzZSAnYmVzdCANCmNob2ljZXMnIGFyZSBhY3R1YWxs
eSAncHJlZmVycmVkJy4NCg0KPj4+IEFuIGVudW1lcmF0aW9uIG91Z2h0IHRvIGhhdmUgYXQg
bGVhc3QgdGhyZWUgZWxlbWVudHMgKG90aGVyd2lzZQ0KPj4+IGl0J3MganVzdCBhIHBhaXIp
LCBhbmQgSSB0aGluayBpZiB3ZSBkbyBwcm9wZXIgY291bnRpbmcgYW5kIG9taXQNCj4+PiBu
by1icmFpbmVycywgc3VjaCBhcyB0aGUgIm9ubHkgZnJlZSBzb2Z0d2FyZSIgcGFydCB0aGF0
IGhhcyBhbHJlYWR5DQo+Pj4gYmVlbiBtZW50aW9uZWQsIHdlIGNvbWUgdmVyeSBjbG9zZSB0
byBza2lydGluZyB0aGF0IGxpbmUuDQo+PiBUaGUgIm9ubHkgZnJlZSBzb2Z0d2FyZSIgaXMg
bWVudGlvbmVkIGVsc2V3aGVyZSwgeWVzLCBidXQgaXQgaXMgb25lDQo+PiBvZiB0aGUgcHJp
bmNpcGxlcyBmb3IgZGVjaWRpbmcgYmV0d2VlbiBzbmlwcGV0cywgcGhhc2VzIGFuZCBwYXRj
aGVzLg0KPj4gV2hpbGUgeW91IGNhbGwgaXQgYSBuby1icmFpbmVyLCBpdCBpcyBzb21ldGlt
ZXMgbmVnbGVjdGVkLCBzbyBpdA0KPj4gc291bmRzIGltcG9ydGFudCB0byBtZSB0byBleHBs
aWNpdGx5IGxpc3QgaXQuDQo+PiBNZXJnaW5nIHRoZSAzdGggYW5kIDR0aCBAaXRlbSwgSSBj
b3VudCA0IHByaW5jaXBsZXMsIHNvIGl0IGZpdHMgd2l0aA0KPj4gYW4gZW51bWVyYXRpb24u
DQo+PiBBbHNvLCBJJ20gbm90IGZvbGxvd2luZyB5b3VyIHBvaW50IGhlcmUgLS0geW91ciBj
b21wbGFpbnQgd2FzIHRoYXQNCj4+IHRoZXnCoGFyZW4ndCBndWlkaW5nIHByaW5jaXBsZXMg
KGJhc2VkIG9uIHRoZSBudW1iZXIgb2YgdGhlbSksIGJ1dA0KPj4geW91csKgcmVzcG9uc2Ug
aXMgdGhhdCB0aGV5IG1pZ2h0IG5vdCBmb3JtIGFuIGVudW1lcmF0aW9uP8KgIFRoZXkgYXJl
DQo+PiBuYW1lZMKgdGhlIGd1aWRpbmcgcHJpbmNpcGxlcywgbm90IHRoZSBndWlkaW5nIGVu
dW1lcmF0aW9uLsKgIFdoYXQgaGF2ZQ0KPj4gZW51bWVyYXRpb25zIHRvIGRvIHdpdGggYW55
dGhpbmc/DQo+IEknbSB1c2luZyBlbnVtZXJhdGlvbiBhcyBhIHN1cGVyIHRlcm0gaGVyZSwg
d2hpY2ggY2FuIGJlDQo+ICgoc3ViKXN1YilzZWN0aW9ucywgY2hhcHRlcnMsIGxpc3QgZWxl
bWVudHMsIHdoYXRldmVyLCBhbmQgbXkgY2xhaW0gaXMNCj4gdGhhdCB3ZSBiYXJlbHkgaGF2
ZSBlbm91Z2ggcHJpbmNpcGxlcyB0byBhbGxvdyB0aGUgdXNlIG9mIGEgcGx1cmFsLg0KDQpJ
biBFbmdsaXNoLCB0aGluZ3MgYXJlIGVpdGhlciBwbHVyYWwgb3Igc2luZ3VsYXIuICBFdmVy
eXRoaW5nID49IDIgaXMgDQpwbHVyYWwuICBUaGVyZSBudW1iZXIgb2YgcHJpbmNpcGxlcywg
aG93ZXZlciB3ZSBjb3VudCB0aGVtLCBpcywgYXQgDQpsZWFzdCwgMi4gIENvbnNlcXVlbnRs
eSwgdGhlIHByaW5jaXBsZXMgYXJlIHBsdXJhbCwgbm90IHNpbmd1bGFyLiANClRyZWF0aW5n
IHRoZSBwcmluY2lwbGVzIGFzIHNpbmd1bGFyIGlzIHNpbXBseSBncmFtbWF0aWNhbGx5IGlu
Y29ycmVjdC4NCg0KTWF5YmUgaXQgaXMgYmFyZWx5IGFsbG93ZWQgdG8gYmUgcGx1cmFsLCBi
dXQgRW5nbGlzaCBncmFtbWFyIGRvZXNuJ3QgDQpjYXJlIGFib3V0IHRoYXQgLS0gaXQgaXMg
ZGVmaW5pdGl2ZWx5IGRpc2FsbG93ZWQgdG8gYmUgc2luZ3VsYXIsIG9ubHkgDQpwbHVyYWwg
cmVtYWlucy4NCg0KPiBBZGRpbmcgdG8gdGhhdCwgbm93IHRoYXQgSSB0aGluayBvZiBpdCwg
SSBhbHNvIGRvdWJ0IHRoZWlyIHVzZWZ1bG5lc3MNCj4gaW4gZ3VpZGluZy4gICJVc2Ugd2hh
dGV2ZXIgZmVlbHMgY29udmVuaWVudCwgYnV0IG5vdGUgdGhhdCB0aGF0IG1pZ2h0DQo+IGJl
IHN1YmplY3RpdmUiIGlzIG1vcmUgdXNlZnVsIGF0IHRoZSBlbmQgb2YgdGhlIHNlY3Rpb24g
d2hlbiBhIHVzZXINCj4gZGlkbid0IGZpbmQgd2hhdCB0aGV5IHdlcmUgbG9va2luZyBmb3Ig
dGhhbiBhdCB0aGUgc3RhcnQuDQoNClRoZSBpbnRyb2R1Y3Rpb24gaGFzIGEgc2V0IG9mIGd1
aWRpbmcgcHJpbmNpcGxlcywgZnJvbSB3aXRoIGNvbmNyZXRlIA0KY2FzZXMgYXJlIGJ1aWx0
LiAgQnkgYWRkaW5nIGFub3RoZXIgcHJpbmNpcGxlIGF0IHRoZSBlbmQsIHRoZSBjYXNlcw0K
Y2Fubm90IG1ha2UgdXNlIG9mIHRoZSAidXNlIFsuLi5dIGNvbnZlbmllbnQiIHByaW5jaXBs
ZS4NCg0KQWRkaXRpb25hbGx5LCBub3cgdGhlIHVzZXIgaGFzIHRvIGxvb2sgYXQgX3R3b18g
cGxhY2VzIHRvIGZpbmQgdGhlIA0KZ3VpZGluZyBwcmluY2lwbGVzIC0tIGF0IHRoZSBiZWdp
bm5pbmcsIGFuZCBhdCB0aGUgZW5kLiAgV29yc2UsDQp0aGUgYmVnaW5uaW5nIGRvZXMgbm90
IGhhdmUgYSBjcm9zcy1yZWZlcmVuY2UgdG8gdGhlIGVuZCwgc28gc2luY2UNCnRoZSBzZXQg
YXQgdGhlIGJlZ2lubmluZyBpcyBwcmVzZW50ZWQgYXMgZXhoYXVzdGl2ZSwgdGhlIHVzZXIg
bWlnaHQNCm5vdCBrbm93IHRoZXJlIGlzIGFub3RoZXIgZ3VpZGluZyBwcmluY2lwbGUuDQoN
CkFuZCBldmVuIGlmIHRoZXkgZGlkIHJlYWQgdGhyb3VnaCB0aGUgd2hvbGUgc2VjdGlvbiAo
ZXZlbiB0aG91Z2ggdGhleSANCnNob3VsZCBvbmx5IGhhdmUgdG8gcmVhZCB0aGUgaW50cm9k
dWN0aW9uIGFuZCB0aGUgcmVsZXZhbnQgd29ya2VkLW91dCANCmNhc2UpLCBhc3N1bWluZyB0
aGV5IHJlYWQgdGhyb3VnaCBpdCBpbiBhIGxpbmVhciBmYXNoaW9uLCBkdWUgdG8gdGhlIG5l
dyANCmd1aWRpbmcgcHJpbmNpcGxlIHRoYXQgd2Fzbid0IGFsbHVkZWQgdG8gYXQgdGhlIGJl
Z2lubmluZywgdGhleSBoYXZlDQp0byByZWRvIHRoZWlyIG1lbnRhbCBtb2RlbCBvZiAiTW9k
aWZ5aW5nIFNvdXJjZXMiIGFzIHRoaXMgcHJpbmNpcGxlDQpjb3VsZCBpbnZhbGlkYXRlIHRo
aW5ncy4NCg0KPj4+PiBJIGRvIG5vdCBzZWUgd2hhdCB0aGUgcHJvYmxlbSBpcyB3aXRoIGFk
ZGl0aW9uYWwgbGVuZ3RoIGFzIGxvbmcNCj4+Pj4gYXMgdGhpcyBhZGRpdGlvbmFsIGxlbmd0
aCBjb21lcyB3aXRoIGFkZGl0aW9uYWwgdXNlZnVsDQo+Pj4+IGluZm9ybWF0aW9uIGFuZCB0
aGUgbWFudWFsIGlzIHdlbGwtc3RydWN0dXJlZCAoZS5nLiB3aXRoDQo+Pj4+IChzdWIpKHN1
YilzZWN0aW9ucywgY2hhcHRlcnMgYW5kIGluZGljZXMpIC0tIHdlIGRvIG5vdCBoYXZlIGEN
Cj4+Pj4gcGFnZSBsaW1pdC4NCj4+Pj4NCj4+Pj4gQXQgd29yc3QsIHBlcmhhcHMgdGhlIHNh
bWUgaW5mb3JtYXRpb24gY291bGQgcGVyaGFwcyBiZSBlbmNvZGVkDQo+Pj4+IHdpdGggZmV3
ZXIgd29yZHM/IEkgY291bGQgY29tcGFyZSB0aGUgdHdvIHBhdGNoZXMgdG8gc2VlIHdoaWNo
DQo+Pj4+IG9uZSBmb3JtdWxhdGVzIGNlcnRhaW4gaW5mb3JtYXRpb24gaW4gdGhlIGZld2Vz
dCB3b3JkcywgYW5kDQo+Pj4+IGNob29zZSB0aGUgbGVhc3QgdmVyYm9zZSBvZiB0aGUgdHdv
IGZvciBlYWNoIHBpZWNlIG9mIGluZm9ybWF0aW9uDQo+Pj4+IHRoYXQgaXMgcHJlc2VudCBp
biBib3RoPw0KPj4+Pg0KPj4+PiBBbHNvLCBjb21wYXJpbmcgdGhlIHR3byBwYXRjaGVzLCBt
eSBwYXRjaCBoYXMgNDAgbW9yZSBsaW5lcywgYnV0DQo+Pj4+IGFib3V0IDI1IG9mIHRoZW0g
YXJlIGZvciBub3RpbmcgdGhlIGd1aWRpbmcgcHJpbmNpcGxlcyAod2hpY2ggYXJlDQo+Pj4+
IGFic2VudCBpbiB5b3VyIHBhdGNoKS4NCj4+Pj4gQ29tcGVuc2F0aW5nIGZvciB0aGF0LCB0
aGUgcGF0Y2hlcyBhcmUgYWJvdXQgdGhlIHNhbWUgbGVuZ3RoLCBzbw0KPj4+PiBJIGRvIG5v
dCB0aGluayB0aGF0ICdzaGVlciBsZW5ndGgnIGlzIGFjY3VyYXRlIGhlcmUuDQo+Pj4gMjUg
bGluZXMgY2FsbGluZyBiYWNrIHRvIGVhcmxpZXIgaW5mb3JtYXRpb24gYXJlLCBpbWhvLCBh
bg0KPj4+IGluZGljYXRvciB0aGF0IHRoZSBzZWN0aW9uIGlzIHRvbyBsb25nLiBJbWFnaW5l
IHlvdSdkIGhhdmUgdHdlbnR5LQ0KPj4+IGZpdmUgZnVuY3Rpb24gY2FsbHMgdG8gZ3VpZGlu
Z19wcmluY2lwbGVzKG4pIGluIHlvdXIgcHJvZ3JhbSDigJMgYXQNCj4+PiBzb21lIHBvaW50
LCB5b3UnZCB0cnkgdG8gY2FjaGUgdGhvc2UuDQo+PiAoZGVmaW5lIGNhY2hlZC1ndWlkaW5n
LXByaW5jaXBsZXMNCj4+ICDCoCAoZGVsYXkgKGxpc3QgKGd1aWRpbmctcHJpbmNpcGxlLTAp
DQo+PiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgWy4uLl0NCj4+
ICDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAoZ3VpZGluZy1wcmlu
Y2lwbGUtMjQpKSkpDQo+PiBDYWNoaW5nIHRoZSBndWlkaW5nIHByaW5jaXBsZXMgZG9lcyBu
b3QgcmVkdWNlIHRoZSBsZW5ndGguDQo+PiBJIGRvbid0IHNlZSB0aGUgcHJvYmxlbSB3aXRo
IGNhbGxpbmcgYmFjayB0byBlYXJsaWVyIGluZm9ybWF0aW9uLg0KPj4gQWxzbywgaXQgaXNu
J3QgZWFybGllciBpbmZvcm1hdGlvbiwgdGhlcmUgaXMgbm8gbmljZSBsaXN0IG9mIGd1aWRp
bmcNCj4+IHByaW5jaXBsZXMgYW55d2hlcmUgZWxzZS4NCj4gQXQgdGhlIHJpc2sgb2YgcmVz
cG9uZGluZyBqb2tpbmdseSB0byB3aGF0IHdhcyBtZWFudCBzZXJpb3VzOiBJIGRpZG4ndA0K
PiBrbm93IHdlIHN1ZGRlbmx5IGdhaW5lZCAyMCBndWlkaW5nIHByaW5jaXBsZXMuDQoNCjI1
IGxpbmVzIGFyZSBmb3IgdGhlIGd1aWRpbmcgcHJpbmNpcGxlcyAoc29tZXRpbWVzIHJlZmVy
cmluZyB0byBhIA0KcHJpbmNpcGxlIG9mIGVsc2V3aGVyZSBpbiBHdWl4LCBzb21ldGltZXMg
YSBuZXcgcHJpbmNpcGxlIGZvciAiTW9kaWZ5aW5nIA0KU291cmNlcyIpLiAgWW91IHByb3Bv
c2VkIHRvICdjYWNoZScgdGhlbSBzb21laG93LiAgSW4gR3VpbGUsIHRvIGNhY2hlIA0Kc29t
ZXRoaW5nLCB5b3UgY2FuIHVzZSAnZGVsYXkvZm9yY2UnLiAgQnV0IHRoaXMgaW5jcmVhc2Vz
IHRoZSBhbW91bnQgb2YgDQpjb2RlIChkdWUgdG8gdGhlIGFkZGl0aW9uYWwgdXNlIG9mICdk
ZWxheScpLCBpbnN0ZWFkIG9mIGRlY3JlYXNpbmcuDQoNClRoZSBkb2N1bWVudGF0aW9uIGVx
dWl2YWxlbnQgKHdoYXRldmVyIHRoYXQgbWlnaHQgYmUsIEkgYW0gbm90IHNlZWluZyANCm9u
ZSBteXNlbGYpIHdvdWxkIHRoZW4gYWxzbyBiZSBhdCBsZWFzdCBhcyBsb25nLCBtYXliZSBl
dmVuIGEgbGl0dGxlIA0KbG9uZ2VyIGR1ZSB0byB0aGUgdXNlIG9mICdkZWxheScuDQoNCj4+
Pj4+IEdvaW5nIGRvd24gdG8gc3Vic3Vic2VjdGlvbnMganVzdCB0byBmaW5kIG91dCB3aGVy
ZSBwYXRjaGVzIGFyZQ0KPj4+Pj4gYXBwcm9wcmlhdGUsIGlzIGltaG8gb3ZlcmtpbGwuDQo+
Pj4+IFRoZSAnZ29pbmcgZG93biB0byBzdWJzdWJzZWN0aW9uJyBpcyB0aGUgY2FzZSBmb3Ig
eW91ciBwYXRjaCB0b28sDQo+Pj4+IHRob3VnaD8gSW4gbXkgY2FzZSwgaXQncyBhIHN1YnN1
YnNlY3Rpb24sIGluIHlvdXIgY2FzZSBpdCdzIGENCj4+Pj4gdGFibGUNCj4+Pj4gZW50cnkg
aW5zaWRlIGEgc3Vic2VjdGlvbiwgYm90aCBhcmUgdGhlIHNhbWUgbGV2ZWwgb2YgbmVzdGlu
Zy4NCj4+PiBUaGVzZSBhcmUgc3RpbGwgdHdvIHZlcnkgZGlmZmVyZW50IGtpbmRzIG9mIG5l
c3RpbmcuIEEgdGFibGUgZml0cw0KPj4+IG9udG8gYSAodmlydHVhbCkgcGFnZSBtb3JlIGVh
c2lseSB0aGFuIHNldmVyYWwgc3Vic2VjdGlvbnMuDQo+PiBJIHN1cHBvc2UgdGFibGUgaXRl
bXMgbWlnaHQgdGFrZSB0d28gbGVzcyBsaW5lIG9yIHNvIGxlc3MgdGhhbg0KPj4gc3Vic3Vi
c2VjdGlvbnMsIGJ1dCBJIGRvbid0IHRoaW5rIHRoYXQncyBzdWZmaWNpZW50IHJlYXNvbiB0
byBzdGVwDQo+PiBhd2F5IGZyb20gYSBuaWNlIHNlY3Rpb24gc3RydWN0dXJlLg0KPiBBbm90
aGVyIHJlYXNvbiBpcyB0aGF0IHlvdSBjYW4gZW5kIGEgdGFibGUgaW4gdGhlIG1pZGRsZSBv
ZiBhIHNlY3Rpb24sDQo+IHdoaWNoIHlvdSBjYW4ndCBkbyB3aXRoIHN1YnNlY3Rpb25zLiAg
SGVuY2Ugd2h5IEknbSBhYmxlIHRvIHB1dCBhDQo+IHJlbWFyayBhdCB0aGUgYm90dG9tLCB3
aGljaCB5b3UgaGF2ZSB0byBjbHVtc2lseSBmaXQgaW50byB0aGUgdG9wLg0KDQpJIGNhbiwg
aW5kZWVkLCBub3QgcHV0IHRoZSAnY29udmVuaWVuY2UgcHJpbmNpcGxlJyBhdCB0aGUgYm90
dG9tLCBleGNlcHQgDQpwZXJoYXBzIGJ5IGFkZGluZyBhIG5ldyBzdWJzdWJzZWN0aW9uLCBh
bmQgZm9yIHRhYmxlcyBhZGRpbmcgc3VjaCBhIA0KcmVtYXJrIGF0IHRoZSBib3R0b20gaXMg
aW5kZWVkIG1vcmUgY29udmVuaWVudC4NCg0KSG93ZXZlciwgSSBkb24ndCBzZWUgdGhlICdo
YXZlIHRvIGNsdW1zaWx5JyBoZXJlIC0tIGFzIGV4cGxhaW5lZCANCmVsc2V3aGVyZSwgSSBi
ZWxpZXZlIHRoYXQgdGhlICdjb252ZW5pZW5jZSBwcmluY2lwbGUnIHNob3VsZG4ndCBiZSAN
CnNlcGFyYXRlZCBmcm9tIHRoZSBvdGhlciBwcmluY2lwbGVzIGFuZCB0aGF0IGl0IGZpdHMg
bmljZWx5IG5leHQgdG8gdGhlIA0KdGhlIHByaW5jaXBsZXMgLS0tIHRoZXJlIGlzIG5vICdo
YXZlIHRvJywgYmVjYXVzZSBJIGNob29zZSBmb3IgdGhpcywgYW5kIA0KSSBhbSBub3Qgc2Vl
aW5nIGFueSAnY2x1bXNpbmVzcycgaGVyZS4NCg0KPj4+PiBBbHNvLCBpdCdzIGEgbWF0dGVy
IG9mIGRpZmZlcmVudCBzdHJ1Y3R1cmUgLS0gaW4gbXkgdjIgYW5kIHYzDQo+Pj4+IHBhdGNo
LCBJIGhhdmUgYSAncHJvYmxlbSAtPiBzb2x1dGlvbicgc3RydWN0dXJlIC0tIHRoZSBpZGVh
IGlzDQo+Pj4+IHRoYXQgdGhlIHBhY2thZ2VzIGhhcyBhIHByb2JsZW0sIHRoZXkgbG9vayBh
dCB0aGUgc2VjdGlvbiwgdGhleQ0KPj4+PiByZWFkIHRoZSBzdWJzdWJzZWN0aW9uIG5hbWVz
LCBzZWxlY3QgdGhlDQo+Pj4+IHN1YnN1YnNlY3Rpb24gdGhhdCBtYXRjaGVzIHRoZWlyIHBy
b2JsZW0gYW5kIHJlYWQgdGhlIHNvbHV0aW9uIC0tDQo+Pj4+IGluIHNob3J0LCB0aGUgaWRl
YSBpcyB0byBwcm92aWRlIGEgc29sdXRpb24gdG8gdGhlIHByb2JsZW0uDQo+Pj4+DQo+Pj4+
IFlvdXIgc3RydWN0dXJlIGlzIHRoZSBvdGhlciB3YXkgYXJvdW5kIC0tIGZvciBzb2x1dGlv
bnMgKHBhdGNoZXMsDQo+Pj4+IHNuaXBwZXRzLCBwaGFzZXMpLCBpdCBnaXZlcyB0aGUgcGVy
bWl0dGVkIHByb2JsZW1zIHRvIGFwcGx5IGl0DQo+Pj4+IHRvLg0KPj4+Pg0KPj4+PiBTbyB5
ZXMsIHlvdXIgcGF0Y2ggaXMgbW9yZSBjb252ZW5pZW50IGZvciBmaW5kaW5nIG91dCB3aGVy
ZQ0KPj4+PiBwYXRjaGVzIGFyZSBhcHByb3ByaWF0ZS7CoCBJIGRvIG5vdCBzZWUgdGhlIGJl
bmVmaXQgb2YgdGhhdCB0aG91Z2gNCj4+Pj4gLS0gYSBuZXcgY29udHJpYnV0b3IgcGFja2Fn
aW5nIGEgdGhpbmcgd291bGRuJ3Qga25vdyBpbiBhZHZhbmNlDQo+Pj4+IHdoaWNoIHNvbHV0
aW9ucyBjb3VsZCBiZSBhcHByb3ByaWF0ZSBmb3IgdGhlbSAoeW91ciAnc29sdXRpb24gLT4N
Cj4+Pj4gcHJvYmxlbScgcGF0Y2g/KSwgcmF0aGVyLCB0aGV5IHN0YXJ0IHdpdGggYSBwcm9i
bGVtIGFuZCBhcmUNCj4+Pj4gc2VhcmNoaW5nIGZvciBhbiBhcHByb3ByaWF0ZSBzb2x1dGlv
biAobXkgcHJvYmxlbS0+c29sdXRpb24NCj4+Pj4gcGF0Y2gpLg0KPj4+IEkgdGhpbmsgdGhp
cyBpZGVhIGNhbiBiZSBkZWJ1bmtlZCBwcmV0dHkgZWFzaWx5LiBJZiBJIGdpdmUgeW91IGEN
Cj4+PiBoYW1tZXIgYW5kIEkgdGVsbCB5b3UgInRoaXMgaXMgYSBoYW1tZXIsIHlvdSBjYW4g
dXNlIGl0IHRvIHB1dA0KPj4+IG5haWxzIGludG8gYSB3YWxsIiwgYW5kIHlvdSBoYXZlIGEg
bmFpbCBhbmQgeW91IHdhbnQgdG8gcHV0IGl0IGludG8NCj4+PiBhIHdhbGwsIHlvdSB3b24n
dCBnbyAib2ggbm8sIGhvd2V2ZXIgd2lsbCBJIHB1dCB0aGlzIG5haWwgaW50byBhDQo+Pj4g
d2FsbD8iIOKAkyB5b3Ugd2lsbCBzaW1wbHkgdXNlIHRoZSBoYW1tZXIgdG8gZG8gc28uDQo+
PiBUaGUgcGF0Y2ggZG9lcyB0aGlzLCBjdXJyZW50bHkuwqAgSXQgYWxyZWFkeSBwcm9wb3Nl
cyBhIG51bWJlciBvZg0KPj4gaGFtbWVycyAocGF0Y2hlcywgc25pcHBldHMgYW5kIHBoYXNl
cykgYW5kIHB1cnBvc2VzIChhZGRpbmcgbmV3DQo+PiBmdW5jdGlvbmFsaXR5LCBmaXhpbmcg
dGVjaG5pY2FsIGlzc3VlcywgdW5idW5kbGluZywgLi4uKS4NCj4+IEFsc28sIHRoZSBzY2Vu
YXJpbyAib2ggbm8sIGhvd2V2ZXIgd2lsbCBJIHB1dCB0aGlzIG5haWwgaW50byBhIHdhbGwi
DQo+PiBhY3R1YWxseSBoYXBwZW5lZCAtLSBzZWUgdGhlIFNoZXBoZXJkIGRpc2N1c3Npb24s
IHdoZXJlIHRoZXJlIHdhcw0KPj4gYSBsb3Qgb2YgZGlzYWdyZWVtZW50IG9uIGhvdyBuYWls
cyAoPSBzbWFsbCB3b3JrLWFyb3VuZCBpbiB0aGUNCj4+IE1ha2VmaWxlKSBzaG91bGQgYmUg
cHV0IGluIHdhbGxzICg9IHBhdGNoZXMsIHNuaXBwZXQsIHBoYXNlPykuwqDCoCBJdA0KPj4g
d2FzIHRoZSB3aG9sZcKgcmVhc29uIHRvIHN0YXJ0IHdyaXRpbmcgYSBkb2N1bWVudGF0aW9u
IHBhdGNoLg0KPiBZb3UgbWlnaHQgd2FudCB0byBhZGQgYSBsaW5rIGhlcmUgaWYgaXQgc3Vw
cG9ydHMgeW91ciBhcmd1bWVudCwgYnV0DQo+IHdpdGhvdXQgbG9va2luZyBhdCB0aGUgZGlz
Y3Vzc2lvbiB0aGlzIHJhdGhlciBzb3VuZHMgbGlrZSAib2ggbm8sIEkNCj4gaGF2ZSB0aHJl
ZSBoYW1tZXJzLCB3aGljaCBvbmUgZG8gSSBwaWNrPyIg4oCTIHdoaWNoLCBmYWlyIGVub3Vn
aCwgaXMNCj4gc3RpbGwgYSBwcm9ibGVtLCBidXQgb25lIHRoYXQgbmVpdGhlciBvZiBvdXIg
cGF0Y2hlcyB3b3VsZCBjYXVzZSBpbWhvLg0KDQpBcyBJIHRoaW5rIEkndmUgd3JpdHRlbiBw
cmV2aW91c2x5LCB0aGUgd2hvbGUgcG9pbnQgd2FzIHRvIHNvbHZlIHRoYXQgDQpwcm9ibGVt
LiBGb3IgdGhlIGRpc2N1c3Npb24sIHNlZToNCg0KKiBodHRwczovL2lzc3Vlcy5ndWl4Lmdu
dS5vcmcvNTQyMTYNCiogaHR0cHM6Ly95aGV0aWwub3JnL2d1aXgvYzRjMGEwNzEtMmUwMy1k
NGQ2LTY3MTgtMDU0MjRkMjFkMTQ2QHRlbGVuZXQuYmUvDQoqIA0KaHR0cHM6Ly95aGV0aWwu
b3JnL2d1aXgtZGV2ZWwvODRlMTNlZjdkNDM3MDYyZGY1Y2NhNTFhMTJlNmRhNTQ5MjllMDE3
Ni5jYW1lbEB0ZWxlbmV0LmJlLw0KDQpOb3Qgc29sdmluZyB0aGUgcHJvYmxlbSBkZWZlYXRz
IHRoZSB3aG9sZSBwb2ludCwgYXMgdGhlIHB1cnBvc2UgaXMgdG8gDQpzb2x2ZSB0aGF0IHBy
b2JsZW0uDQoNCj4+PiBPZiBjb3Vyc2UsIGZvciB0aGlzIHRvIHdvcmsgSSBhbHNvIGhhdmUg
dG8gdGVsbCB5b3UgKmhvdyogdG8gdXNlIGENCj4+PiBoYW1tZXIgdG8gcHV0IG5haWxzIGlu
dG8gYSB3YWxsLCBidXQgdGhhdCdzIGV4YWN0bHkgd2hhdCBJIGRpZCBpbg0KPj4+IG15IHBh
dGNoIGJ5IGluc2VydGluZyB0aGUgcmlnaHQgbm90ZXMgaW50byB0aGUgR3VpeCBtYW51YWwu
DQo+PiBBbHNvIGFscmVhZHkgdGhlIGNhc2UuDQo+Pj4gTXkgc29sdXRpb24tPnByb2JsZW0g
YXBwcm9hY2ggaGFzIHRoZSBiZW5lZml0LCB0aGF0IGZvbGtzIGNhbiBqdXN0DQo+Pj4gZ28g
b3ZlciBhbGwgdGhlIHNvbHV0aW9ucywgY2hlY2sgaWYgdGhlaXIgcHJvYmxlbSBmaXRzLCBh
bmQgYXBwbHkNCj4+PiB0aGUgb25lIHRoYXQgc2F5cyAiaGVyZSwgdXNlIHRoaXMiLg0KPj4g
QSBwcm9ibGVtLT5zb2x1dGlvbiBzdHJ1Y3R1cmUgaXMgdXNlZnVsIGZvciB0aGF0IHRvbz8N
Cj4+IEFuZCBpdCBhbHJlYWR5IGxpc3RzIGFsbCB0aGUgc29sdXRpb25zIChzbmlwcGV0cywg
cGhhc2VzIGFuZCBwYXRjaGVzKQ0KPj4gYW5kIGluZm9ybWF0aW9uIHRvIGRlY2lkZSB3aGV0
aGVyIHRoZSBzb2x1dGlvbiBmaXRzIHRoZWlyIHByb2JsZW0NCj4+ICh0aGUgZ3VpZGluZyBw
cmluY2lwbGVzLCBhbmQgdGhlIHdvcmtlZC1vdXQgY2FzZXMpLg0KPiBBZ2FpbiwgSSBiZWxp
ZXZlIHlvdSdyZSBvdmVyc2VsbGluZyB0aGUgZ3VpZGluZyBwcmluY2lwbGVzLg0KDQpJIG5l
dmVyIGNsYWltZWQgdGhleSB3ZXJlIHN1cGVyIGdyZWF0LCBqdXN0IHRoYXQgdGhleSBhcmUg
Y29udmVuaWVudCBhbmQgDQpzb2x2ZWQgYSBudW1iZXIgb2YgcHJvYmxlbXMuICBJJ20gbm90
IHNlZWluZyBhbnkgb3ZlcnNlbGxpbmcgaGVyZS4NCg0KPj4+IEFuZCBpZiB0aGV5IGRvbid0
IGZpbmQgYW55dGhpbmcsIHRoZXkgc2VlIHRoZSBoYW5keSBsaXR0bGUgbGluZSBhdA0KPj4+
IHRoZSBib3R0b20gc2F5aW5nICJ1c2Ugd2hhdGV2ZXIgeW91IHRoaW5rIGlzIGNvbnZlbmll
bnQiLg0KPj4gTm93aGVyZSBkaWQgdGhlIHBhdGNoIGltcGx5IHRoYXQgdGhlIGxpc3RlZCBj
YXNlcyB3ZXJlIGFsbCBjYXNlcy4gSW4NCj4+IGZhY3QsIGluIHR3byBwbGFjZXMgaW4gdGhl
IGludHJvZHVjdGlvbiBpdCBpcyBpbXBsaWVkIHRoYXQgdGhlDQo+PiBleGFtcGxlcyBhcmUg
bm90IGV4aGF1c3RpdmUsIGFuZCB0aGF0IHRoZXkgY2FuIGNob29zZSBhY2NvcmRpbmcgdG8N
Cj4+IGNvbnZlbmllbmNlICBbLi4uXQ0KPiBFbXBoYXNpcyBvbiBoYW5keSBsaXR0bGUgbGlu
ZSByYXRoZXIgdGhhbiBuZWVkaW5nIHRvIGJlIHRvbGQgdHdpY2UNCj4gKHBhcnRpY3VsYXJs
eSBpZiBwZW9wbGUgaGF2ZSBubyBpZGVhIHdoYXQgdG8gZXhwZWN0IGR1ZSB0byBub3QgaGF2
aW5nDQo+IGxvb2tlZCBhdCB0aGUgd29ya2VkLW91dCBjYXNlcyB5ZXQpLg0KDQpUaGV5IGRv
bid0IG5lZWQgdG8gYmUgdG9sZCB0d2ljZS4gIEFsc28sIG15IHBhdGNoIGFsc28gaGFzIHRo
YXQgaGFuZHkgDQpsaXR0bGUgbGluZSAoYWxiZWl0IGRpZmZlcmVudGx5IHdvcmRlZCksIHNl
ZSB0aGUgJ2d1aWRpbmcgcHJpbmNpcGxlcycuDQoNCkFsc28sIG9uIHRoZSAnbm8gaWRlYSB3
aGF0IHRvIGV4cGVjdCcgLS0gdGhpcyBpcyBleGFjdGx5IHRoZSBzYW1lIGZvciANCnlvdXIg
cGF0Y2ggdG9vPyAgSW4gYm90aCBwYXRjaGVzLCBpZiB0aGUgdXNlciBvbmx5IHJlYWRzIHRo
ZSANCmludHJvZHVjdGlvbiBhbmQgY29uY2x1c2lvbiAoaWYgYW55KSBhbmQgZG9lc24ndCBy
ZWFkIHRoZSBhY3R1YWwgDQoocmVsZXZhbnQgZXhhbXBsZXMpLyhleHBsYW5hdGlvbiBvZiBw
YXRjaGVzLCBzbmlwcGV0cywgcGhhc2VzKSwgdGhlbiANCnRoYXQncyB0aGVpciBwcm9ibGVt
Lg0KDQo+Pj4gIMKgSSBhbHNvIGV4cGFuZCBhIGxpdHRsZSBvbiB0aGUgYmVuZWZpdHMgYW5k
IGRyYXdiYWNrcyBvZg0KPj4+IHRoZXNlIGFwcHJvYWNoZXMgYXMgeW91IHdvdWxkIHdoZW4g
ZGVzY3JpYmluZyBkZXNpZ24gcGF0dGVybnMuDQo+PiBUaGlzIGlzIGFsc28gZG9uZSBpbiBt
eSBwYXRjaC4gWy4uLl0NCj4gVGhpcyBpcyBub3QgYWJvdXQgdGhlIGNvbnRhaW5lZCBpbmZv
cm1hdGlvbiwgYnV0IHRoZSBzdHJ1Y3R1cmUgb2YgdGhlDQo+IGNvbnRhaW5lZCBpbmZvcm1h
dGlvbi4NCj4gDQo+IE15IHNvbHV0aW9uLT5wcm9ibGVtIHN0eWxlIGZvbGxvd3Mgcm91Z2hs
eSB0aGlzIHN0eWxlOg0KPiAxLiBzb2x1dGlvbg0KPiAyLiBwcm9ibGVtcyBpdCBpcyBrbm93
biB0byBzb2x2ZQ0KPiAzLiBob3cgdG8gdXNlDQo+IDQuIHByb3BlcnRpZXMsIGNhdmVhdHMs
IGV0Yy4NCj4gDQo+IFlvdXIgcHJvYmxlbS0+c29sdXRpb24gc3R5bGUgcm91Z2hseSBoYXMg
dGhlIGZvbGxvd2luZzoNCj4gMS4gcHJvYmxlbQ0KPiAyLiAoc2V0IG9mKSBzb2x1dGlvbihz
KQ0KPiAzLiBpZiBtb3JlIHRoYW4gb25lIHNvbHV0aW9uLCBtYXliZSBhIGhlbHAgdG8gc2Vs
ZWN0DQoNCkFsc28sIGluIG5vIHBhcnRpY3VsYXIgb3JkZXINCg0KICAgNC46IGhvdyB0byB1
c2UNCiAgIDUuOiBleHBsYW5hdGlvbiB3aHkgaXQgaXMgcHJlZmVycmVkIChwcm9wZXJ0aWVz
LCBjYXZlYXRzPykNCg0KPiANCj4gVGhpcyBtYWtlcyBpdCBzbyB0aGF0IHBlb3BsZSBtaWdo
dCBoYXZlIHRvIGdvIHRvIGEgZGlmZmVyZW50IHN1YnNlY3Rpb24NCj4gdGhhbiB0aGUgb25l
IHRoZXkgcmVhZCBmb3IgdGhlaXIgc29sdXRpb24gdG8gZmluZCBvdXQgYWJvdXQgcG90ZW50
aWFsDQo+IGNhdmVhdHMsIGUuZy4gbm90IGVtYmVkZGluZyBzdG9yZSBwYXRocyBpbiBhIHNu
aXBwZXQuDQoNCkkgYXNzdW1lIHRoZWlyIHByb2JsZW0gd2FzICJYIGRvZXNuJ3QgZmluZCBZ
Ii4gIFRoaXMgYmVpbmcgYSB0ZWNobmljYWwgDQppc3N1ZSwgdGhleSBnbyB0byAiRml4aW5n
IHRlY2huaWNhbCBpc3N1ZXMiLiAgSW4gdGhhdCBzdWJzdWJzZWN0aW9uLCANCnRoZXJlIGFy
ZSB0aGUgd29yZHM6DQoNCj4gU2Vjb25kbHksIGlmIHRoZSBmaXggb2YgYSB0ZWNobmljYWwg
aXNzdWUgZW1iZWRzIGEgc3RvcmUgZmlsZSBuYW1lLCB0aGVuDQo+IGl0IGhhcyB0byBiZSBh
IHBoYXNlLiAgT3RoZXJ3aXNlLCBpZiB0aGUgc3RvcmUgZmlsZSBuYW1lIHdlcmUgZW1iZWRk
ZWQgaW4NCj4gdGhlIHNvdXJjZSwgdGhlIHJlc3VsdCBvZiBAY29tbWFuZHtndWl4IGJ1aWxk
IC0tc291cmNlfSB3b3VsZCBiZSB1bnVzYWJsZQ0KPiBvbiBub24tR3VpeCBzeXN0ZW1zIGFu
ZCBhbHNvIGxpa2VseSB1bnVzYWJsZSBvbiBHdWl4IHN5c3RlbXMgb2YgYW5vdGhlcg0KPiBh
cmNoaXRlY3R1cmUuDQoNCnNvIHRoZXkgYWN0dWFsbHkgZG8ga25vdyBvZiB0aGUgY2F2ZWF0
ICdkb24ndCBlbWJlZCBzdG9yZSBwYXRocyBpbiBhIA0Kc25pcHBldCwgZG8gaXQgaW4gYSBw
aGFzZSBpbnN0ZWFkJywgYW5kIHRoZXkgZGlkIG5vdCBuZWVkIHRvIGdvIHRvIGEgDQpkaWZm
ZXJlbnQgc3Vic3Vic2VjdGlvbi4NCg0KPj4+IFlvdXIgcHJvYmxlbS0+c29sdXRpb24gYXBw
cm9hY2ggaW5zdGVhZCBsZWF2ZXMgcGVvcGxlIHdvbmRlcmluZw0KPj4+IHdoZW4gdGhlaXIg
cGFydGljdWxhciB1c2UgY2FzZSBoYXMgbm90IGJlZW4gZGVzY3JpYmVkLg0KPj4gU2VlIG15
IHJlcGx5IHRvIOKAmEFuZCBpZiB0aGV5IGRvbid0IGZpbmQgYW55dGhpbmcsIHRoZXkgc2Vl
IHRoZSBoYW5keQ0KPj4gbGl0dGxlIGxpbmUgYXQgdGhlIGJvdHRvbSBzYXlpbmcgInVzZSB3
aGF0ZXZlciB5b3UgdGhpbmsgaXMNCj4+IGNvbnZlbmllbnTigJkuDQo+Pj4gSXQgZ2l2ZXMg
dGhlbSBhIHNvbHV0aW9uIHJhdGhlciB0aGFuIHRoZSB0b29scyB0byBidWlsZCBzb2x1dGlv
bnMNCj4+PiB3aXRoLg0KPj4gSXQgZG9lcyBnaXZlIHRoZSB0b29sczogc25pcHBldHMsIHBh
dGNoZXMgYW5kIHBoYXNlcy4NCj4gQXMgZmFyIGFzIEkgcmVhZCwgaXQgZGVzY3JpYmVzIG5v
bmUgb2YgdGhvc2UuICBJdCBwdXRzIG91dCBndWlkaW5nDQo+IHByaW5jaXBsZXMgYW5kIHNv
bWUgYWxyZWFkeSB3b3JrZWQtb3V0IGNhc2VzLg0KSGVyZSBhcmUgdGhlIGRlc2NyaXB0aW9u
czoNCg0KPiBHdWl4IGhhcyB0cmVlIG1haW4gd2F5cyBvZiBtb2RpZnlpbmcgdGhlIHNvdXJj
ZSBjb2RlIG9mIGEgcGFja2FnZSwgdGhhdA0KPiB5b3UgYXMgYSBwYWNrYWdlciBtYXkgdXNl
LiAgVGhlc2UgYXJlIHBhdGNoZXMsIHNuaXBwZXRzIGFuZCBwaGFzZXMNCg0KT25jZSB0aGUg
dXNlciBrbm93cyBfd2hpY2hfIG9mIHRoZSB0aHJlZSB0aGV5IHNob3VsZCB1c2UgKGJ5IGNv
bnN1bHRpbmcNCnRoZSBmb2xsb3dpbmcgc3Vic3Vic2VjdGlvbnMpLCB0aGV5IGNhbiB0aGVu
IHNlYXJjaCBmb3IgJ3BhdGNoJywgDQonc25pcHBldCcgYW5kICdwaGFzZXMnIGluIHRoZSBt
YW51YWwgZm9yIG1vcmUgaW5mb3JtYXRpb24sIG5vIG5lZWQgdG8gDQpkdXBsaWNhdGUgdGhh
dCBpbmZvcm1hdGlvbi4NCg0KPj4gQWxzbywgImdpdmluZyB0aGUgdG9vbHMgdG8gYnVpbGQg
c29sdXRpb25zIHdpdGgiIGRvZXMgbm90IGhlbHAgd2l0aA0KPj4gdGhlwqBwcm9ibGVtIHRo
YXQgSSBhaW1lZCB0byBzb2x2ZSAtLSB0aGVyZSB3YXMgZGlzYWdyZWVtZW50IG9uIHdoYXQN
Cj4+IHRoZcKgYXBwcm9wcmlhdGUgdG9vbHMgYXJlIChzZWU6IFNoZXBoZXJkKSwgc28gaXQg
bm90IGp1c3QgbmVlZHMgdG8NCj4+IGdpdmUgdGhlwqB0b29scywgYnV0IGFsc28gdGhlIHNv
bHV0aW9ucy4NCj4gSSBkb24ndCBzZWUgaG93IG15IHBhdGNoIGxhY2tzIHRoaXMgaW5mb3Jt
YXRpb24gaG93ZXZlci4NCg0KSUlVQywgdGhlIHJhdyBpbmZvcm1hdGlvbiBzaG91bGQgdXN1
YWxseSBiZSBpbmRlZWQgYWxsIHRoZXJlLCBidXQgdGhlIA0KdXNlciBoYXMgdG8gY29uc3Vs
dCBfYWxsXyBvZiB0aGUgc2VjdGlvbnMgdG8gZGV0ZXJtaW5lIHdoaWNoIG9wdGlvbiANCihw
YXRjaCwgc25pcHBldCwgcGhhc2UpIGlzIGFwcHJvcHJpYXRlLCBoYXZpbmcgdG8gYXNzZW1i
bGUgYWxsIHRoZSANCmluZm9ybWF0aW9uIGlzIChhKSBhIHdhc3RlIG9mIHRpbWUgYW5kIChi
KSBjYW4gbGVhZCB0byBkaWZmZXJlbnQgDQppbnRlcnByZXRhdGlvbnMgYW5kIGNvbmNsdXNp
b25zIChzZWU6IFNoZXBoZXJkKS4NCg0KTW9yZSBjb25jcmV0ZWx5LCBJIGNhbm5vdCB1c2Ug
eW91ciBwYXRjaCB0byBkZWNpZGUgYmV0d2VlbiBwaGFzZXMsIA0Kc25pcHBldHMgYW5kIHBh
dGNoZXMgZm9yIHRoZSBTaGVwaGVyZCBpc3N1ZToNCg0KKiBub25lIG9mIHRocmVlIGFwcGVh
ciB0byBiZSBmb3JiaWRkZW4gYnkgeW91ciBkb2N1bWVudGF0aW9uDQoqIHRoZXJlIGlzIG5v
IHJlY29tbWVuZGF0aW9uIGZvciAncGF0Y2hlcycgKElJUkMgaXQgd2Fzbid0IGFjY2VwdGVk
IA0KdXBzdHJlYW0gYW5kIHRoZXJlIHdhcyBubyBpbnRlbnQgdG8gc3VibWl0IGl0IHVwc3Ry
ZWFtLCBpdCBiZWluZyByZWFsbHkgDQphIEd1aWxlIGJ1Zywgbm90IGEgU2hlcGhlcmQgYnVn
KQ0KKiB0aGVyZSBpcyBubyByZWNvbW1lbmRhdGlvbiBmb3Igc25pcHBldHMgKGl0J3MgYWxs
IGZyZWUsIG5vIGJ1bmRsaW5nKQ0KKiBidWlsZCBwaGFzZXMgYXJlICd0byBiZSBhdm9pZGVk
JyAoYnV0IG5vdCBmb3JiaWRkZW4pLCBhcyBpdCByZXN1bHRlZA0KICAgaW4gb2JzZXJ2YWJs
eSBkaWZmZXJlbnQgcnVudGltZSBiZWhhdmlvdXIgKGJlaW5nIGEgYnVnIGZpeCkNCg0KLS0g
dGhyZWUgKG9yIGF0IGJlc3QsIHR3bywgaWYgYnVpbGQgcGhhc2VzIGFyZSBkaXNjb3VudGVk
KSBvcHRpb25zIA0KcmVtYWluLiAgTXlzZWxmLCBJIHdvdWxkIHRoZW4gY29uc2lkZXIgJ3Nu
aXBwZXRzJyB0byBiZSB0aGUgbW9zdCANCmNvbnZlbmllbnQsIGJ1dCBzb21lIG90aGVycyAo
c2VlOiBTaGVwaGVyZCwgSUlSQykgd291bGQgcmVhbGx5IHdhbnQgYSANCnBhdGNoIGluc3Rl
YWQsIGJlY2F1c2UgJ3BhdGNoZXMgY2FuIGJlIHJldmVydGVkJyBvciBzb21ldGhpbmcgbGlr
ZSB0aGF0Lg0KDQpBcyBzdWNoLCB5b3UgYXJlIGdpdmluZyB0aGUgdG9vbHMgKHNuaXBwZXRz
IC8gcGF0Y2hlcyAvIHBoYXNlcywgc29tZSANCmRvd25zaWRlcyBhbmQgdXBzaWRlcyksIGJ1
dCBkaWZmZXJlbnQgcGVvcGxlIGNhbiBjb25zdHJ1Y3QgZGlmZmVyZW50IA0Kc29sdXRpb25z
IGZyb20gdGhvc2UgdG9vbHMgZXZlbiBpbiB0aGUgc2FtZSBzaXR1YXRpb24sIGxlYWRpbmcg
dG8gY29uZmxpY3RzLg0KDQpJZiBJIHVzZSBteSBwYXRjaCBpbnN0ZWFkLCBJIGdvIHRvICJm
aXhpbmcgdGVjaG5pY2FsIGlzc3VlcyIuIFRoaXMgDQpzZWN0aW9uIHRlbGxzIG1lIHRvIHVz
ZSBhIHBhdGNoIG9yIGEgc25pcHBldC4gIEFzIHRoZSBmaXggaXMgbm90IA0KR3VpeC1zcGVj
aWZpYywgaXQgcmVjb21tZW5kcyBhIHBhdGNoIHRvIHNhdmUgdGltZSB3aGVuIHVwc3RyZWFt
aW5nLiANCkNvbmNsdXNpb246IHdyaXRlIGEgcGF0Y2guICBJdCB3YXMgYSBHdWlsZSBidWcs
IHNvIHRoZSBmaXggd2FzIGEgcGF0Y2ggDQp0byBHdWlsZS4gIEJ1dCB0aGF0IHdvdWxkIHRh
a2UgdGltZSBhbmQgdXBzdHJlYW0gdG9vayB0aGUgcmVzcG9uc2liaWxpdHkgDQpmb3IgYSBm
aXgsIHNvIHRoZSAnZWZmaWNpZW50IHRpbWUgdGhpbmcnIGRvZXNuJ3QgcmVhbGx5IGFwcGx5
IGFuZCBhIA0Kc21hbGwgd29yay1hcm91bmQgKHNldHRpbmcgb3B0aW1pc2F0aW9uIGZsYWdz
KSBzdWZmaWNlcy4NCg0KSW4gdGhpcyBzaXR1YXRpb24sIHRoZSBzdWJzdWJzZWN0aW9uIGRv
ZXNuJ3QgY2FyZSBhdCBhbGwgaWYgeW91IGdvIGZvciBhIA0Kc25pcHBldCwgc28gYXBwbHkg
dGhlIGxhc3QgZ3VpZGluZyBwcmluY2lwbGU6IGdvIGZvciB0aGUgc2ltcGxlc3QgdGhpbmc6
DQphIHNuaXBwZXQuIChVbmxlc3MgeW91IGFscmVhZHkgaGF2ZSBhIHBhdGNoLCB0aGVuIGEg
cGF0Y2ggaXMgc2ltcGxlc3QuKQ0KRG9lcyBzb21lb25lIGVsc2UgaGF2ZSBhIGRpZmZlcmVu
dCBpZGVhIG9uIHdoYXQncyBzaW1wbGVzdD8gIERvZXNuJ3QNCnJlYWxseSBtYXR0ZXIsIOKA
mFNvbWV0aW1lcyB0aGlzIGlzIHN1YmplY3RpdmUsIHdoaWNoIGlzIGFsc28gZmluZeKAmS4N
Cg0KPiBJbg0KPiBwYXJ0aWN1bGFyLCBmb3IgcmV2aWV3IHB1cnBvc2VzLCBtaW5lIHNob3Vs
ZCBiZSBlYXNpZXIgdG8gd29yayB3aXRoLg0KPiBGb3IgaW5zdGFuY2UsIHRoZSByZXZpZXdl
ciBzZWVzIGEgaGFzaCBlbWJlZGRlZCBpbiBhIHNuaXBwZXQsIHNlZXMgaW4NCj4gdGhlIHNu
aXBwZXQgZW50cnkgdGhhdCB5b3Ugc2hvdWxkbid0IGRvIHRoYXQsIGFuZCBjYW4gdGh1cyBz
YXkgIm5vcGUsDQo+IGRvbid0IGRvIGEgc25pcHBldCBoZXJlIi4NCg0KSSB0aGluayB3ZSBz
aG91bGQgb3B0aW1pc2UgZm9yIHBhY2thZ2VycyBiZWZvcmUgcmV2aWV3ZXJzDQo+IA0KPiBS
ZWdhcmRsZXNzIG9mIHdoaWNoIHBhdGNoIHdlIHBpY2ssIGl0IHNob3VsZCBub3QgbWFuZGF0
ZSBhIHBhcnRpY3VsYXINCj4gc29sdXRpb24gaW4gcG90ZW50aWFsbHkgY29udGVudGlvdXMg
Y2FzZXMsDQoNCkFjdHVhbGx5IHRoZSB3aG9sZSBwb2ludCB3YXMgdG8gbWFuZGF0ZSBhIHBh
cnRpY3VsYXIgc29sdXRpb24gZm9yIHRoZSANCmNvbnRlbnRpb3VzIGNhc2VzLCBzZWUgU2hl
cGhlcmQuDQoNCj4gYW5kIGFsc28gcG9pbnQgdG93YXJkcyB0aGUNCj4gcmlnaHQgc29sdXRp
b24uICBTZWUgb3VyIGRpc2N1c3Npb25zIG9uIHRoZSBpbmRpdmlkdWFsIHNvbHV0aW9ucyBv
bg0KPiBwb2ludHMgaW4gd2hpY2ggSSBiZWxpZXZlIHlvdSd2ZSBlcnJvcmVkLg0KDQpUaGVz
ZSBhcmU6DQoNCiogdGhlIHR5cG8ncw0KKiBpbmNsdWRpbmcgInNraXBwaW5nIHRlc3RzIGlu
ZGljYXRpbmcgZmFpbHVyZSB1bmRlciDigJhGaXhpbmcgdGVjaG5pY2FsIA0KaXNzdWVz4oCZ
Ig0KKiAiZG9uJ3QgbWVudGlvbiBmaWxlIG5hbWVzIG9mIG5vbi1mcmVlIHRoaW5ncyBpbiBw
YXRjaGVzIg0KDQpEaWQgSSBtaXNzIGFueT8NCg0KR3JlZXRpbmdzLA0KTWF4aW1lDQo=
--------------tRDWi1bv5GRDIutW2FCxCszJ
Content-Type: application/pgp-keys; name="OpenPGP_0x49E3EE22191725EE.asc"
Content-Disposition: attachment; filename="OpenPGP_0x49E3EE22191725EE.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xjMEX4ch6BYJKwYBBAHaRw8BAQdANPb/d6MrGnGi5HyvODCkBUJPRjiFQcRU5V+m
xvMaAa/NL01heGltZSBEZXZvcyA8bWF4aW1lLmRldm9zQHN0dWRlbnQua3VsZXV2
ZW4uYmU+wpAEExYIADgWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCX4ch6AIbAwUL
CQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRBJ4+4iGRcl7japAQC3opZ2KGWzWmRc
/gIWSu0AAcfMwyinFEEPa/QhUt2CogD/e2RdF4CYAgaRHJJmZ9WU7piKbLZ7llB4
LzgezVDHggzNJU1heGltZSBEZXZvcyA8bWF4aW1lZGV2b3NAdGVsZW5ldC5iZT7C
kAQTFggAOBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJf56ycAhsDBQsJCAcDBRUK
CQgLBRYCAwEAAh4BAheAAAoJEEnj7iIZFyXujpQBAKV1SwDDl4f24rXciDlB9L8W
ycZt30CgbewMSRQk4mvbAP9dFMbVVixYBd6C8cfhR+NsOBGiOJnQABlUmgNuqGFJ
Dc44BF+HIegSCisGAQQBl1UBBQEBB0BOlzIWiJzgobMF6/cqwLaLk7jIcFSZ++c0
k9cCNT6YXwMBCAfCeAQYFggAIBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJfhyHo
AhsMAAoJEEnj7iIZFyXuMr0BAJc8cl5PGvVmVuSQVKjleNl4DK1/XAaPAYPe34AE
fZJPAP9IqLCQhH/FeJanHqBP8gNdGNI2qn8RnnLVfRJgUjZ1BA=3D=3D
=3DOVqp
-----END PGP PUBLIC KEY BLOCK-----

--------------tRDWi1bv5GRDIutW2FCxCszJ--

--------------LEdw0eVxVIORtTBS4903Yefe--

--------------ztoDhl3zz8S7BeO6MhLpiOLo
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wnsEABYIACMWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYxsgEQUDAAAAAAAKCRBJ4+4iGRcl7lVn
AP0c+nSCLm1gIRDKhyzhSqGikSO1/NELtlT7yKCO7xDq4gD/bWt8MRqdlRdLGYTDFgFSL4Nhnao0
EVHaLzEKmrPgbAk=
=ftmT
-----END PGP SIGNATURE-----

--------------ztoDhl3zz8S7BeO6MhLpiOLo--

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#57598] [PATCH v2] doc: Update contribution guidelines on patches, etc.
References: <20220905160048.18173-1-maximedevos@HIDDEN>
In-Reply-To: <20220905160048.18173-1-maximedevos@HIDDEN>
Resent-From: Maxime Devos <maximedevos@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Fri, 09 Sep 2022 12:32:01 +0000
Resent-Message-ID: <handler.57598.B57598.166272666526772 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 57598
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: 57598 <at> debbugs.gnu.org
Cc: Maxime Devos <maximedevos@HIDDEN>
Received: via spool by 57598-submit <at> debbugs.gnu.org id=B57598.166272666526772
          (code B ref 57598); Fri, 09 Sep 2022 12:32:01 +0000
Received: (at 57598) by debbugs.gnu.org; 9 Sep 2022 12:31:05 +0000
Received: from localhost ([127.0.0.1]:60998 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oWdA0-0006xj-7B
	for submit <at> debbugs.gnu.org; Fri, 09 Sep 2022 08:31:05 -0400
Received: from albert.telenet-ops.be ([195.130.137.90]:52404)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <maximedevos@HIDDEN>) id 1oWd9w-0006xI-KE
 for 57598 <at> debbugs.gnu.org; Fri, 09 Sep 2022 08:31:03 -0400
Received: from localhost.localdomain
 ([IPv6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16])
 by albert.telenet-ops.be with bizsmtp
 id HoWy2800N20ykKC06oWyqS; Fri, 09 Sep 2022 14:30:58 +0200
From: Maxime Devos <maximedevos@HIDDEN>
Date: Fri,  9 Sep 2022 14:30:51 +0200
Message-Id: <20220909123051.15747-1-maximedevos@HIDDEN>
X-Mailer: git-send-email 2.37.2
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r22;
 t=1662726659; bh=ShuyIi5oL2KLu5raMueIVayMxJvraM6D4TAkISgfEBU=;
 h=From:To:Cc:Subject:Date;
 b=WhNwaFDfVGb1lt3/LKr8fbyZWF1n1GX/h40LURo36dX5Gf81MjofENZePz+wp6/0j
 4ovILLK/DSRrY0ab0eftwP1dwT7rNgIeYbfp11QQoY915TgzvH/uUhr0bkdO4iK2MQ
 x4/7qK8iA8sHzcVcO84nh5y1g5/B7EJiob4L9A8AeGm0kcu0NFf+CcE+HnOYVd7H2k
 /tzJ0Y2K+ZDIc2WOA6DbP2z3seyXX2N8CtBn0maIvZWUaq5OFvBBZBanLrkHmbk5Re
 +EeAbRdGW/RhksxuddT2rYzUpVMB/8wpsOdNi+OPuIHeQjzsw6yWGgi92WwAsSFBI2
 hs+j5qc+tf9dQ==
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

* doc/contributing.texi (Modifying Sources): Replaced with ...
("Modifying Sources"): ... this.  List more use cases and some principles.

This patch incorporates some text written by Liliana Marie Prikler.  The
structure is based on a proposal by Julien Lepiller.  The text has been
revised based on reviews by David Larsson and blake.

(! remove following text before committing !)

Unless someone finds some more typo's or such, this is the final version for
me, as it has become a time sink with diminishing returns.

Changes since previous version:

- typofix: tree -> three
- third and fourth principle are merged
- corrected @subsection -> @subsubsection

Not changed:
- no additional information on bugfixes even though initially proposed, I'm
  done with the patch, if you'd like such information please write a follow-up
  patch.
- I didn't add 'no naming the file names of non-free things in the snippets’,
  as I don't think this is currently policy and it seems rather inconvenient
  to work with (e.g.: then we wouldn't be able to keep records of what parts
  still need to be replaced with something free in the comments)
- going from ‘problem -> solution’ to ‘solution -> problem’ -- would partially
  defeats the point of the patch.
- going through the two different patches and take the most concise phrasing
  (other people in 57598 <at> debbugs.gnu.org didn't agree to my proposal, also,
  I'm about done with the patch
- ‘subsubsections -> item / table’: I haven't read a convincing explanation
  on why item / table is better here.
---
 doc/contributing.texi | 140 +++++++++++++++++++++++++++++++++++++-----
 doc/guix.texi         |   2 +-
 2 files changed, 126 insertions(+), 16 deletions(-)

diff --git a/doc/contributing.texi b/doc/contributing.texi
index 02c7c5ae59..bd2ae8d9b6 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -441,7 +441,7 @@ needed is to review and apply the patch.
 * Package Naming::              What's in a name?
 * Version Numbers::             When the name is not enough.
 * Synopses and Descriptions::   Helping users find the right package.
-* Snippets versus Phases::      Whether to use a snippet, or a build phase.
+* Modifying Sources::           Whether to use a snippet, or a build phase.
 * Emacs Packages::              Your Elisp fix.
 * Python Modules::              A touch of British comedy.
 * Perl Modules::                Little pearls.
@@ -698,20 +698,130 @@ Gettext}):
 for the X11 resize-and-rotate (RandR) extension. @dots{}")
 @end lisp
 
-@node Snippets versus Phases
-@subsection Snippets versus Phases
-
-@cindex snippets, when to use
-The boundary between using an origin snippet versus a build phase to
-modify the sources of a package can be elusive.  Origin snippets are
-typically used to remove unwanted files such as bundled libraries,
-nonfree sources, or to apply simple substitutions.  The source derived
-from an origin should produce a source that can be used to build the
-package on any system that the upstream package supports (i.e., act as
-the corresponding source).  In particular, origin snippets must not
-embed store items in the sources; such patching should rather be done
-using build phases.  Refer to the @code{origin} record documentation for
-more information (@pxref{origin Reference}).
+@node Modifying Sources
+@subsection Modifying Sources
+
+Guix has tree main ways of modifying the source code of a package, that
+you as a packager may use.  These are patches, snippets and phases.
+Each one has its strengths and drawbacks.  To decide between the three,
+there are a few guiding principles to satisfy simultanuously where
+possible:
+
+@itemize
+@item
+In principle, Guix only has free software; when the upstream source
+contains some non-free software, it has to be removed such that
+@command{guix build --source} returns the ‘freed’ source code rather than
+the unmodified upstream source (@pxref{Software Freedom}).
+@item
+The source of the package needs to correspond to what is actually built
+(i.e., act as the corresponding source), to fulfill our ethical and
+legal obligations.
+@item
+The source needs to actually work, not only on your Guix system but also
+on other Guix systems.  It preferably should also work on non-Guix
+systems if supported by upstream.  This requires some care for
+substitutions involving store items and other architecture-specific
+changes.
+@item
+When there is more than one way to do something, choose whichever method
+is the simplest.  Sometimes this is subjective, which is also fine.
+What matters is that you use techniques that are common within the
+community (i.e., patterns that appear throughout @code{gnu/packages/...})
+and are thus clearly legible for reviewers.
+@end itemize
+
+To make things more concrete and to resolve conflicts between the
+principles, a few cases have been worked out:
+
+@subsubsection Removing non-free software
+Non-free software has to be removed in snippets; the reason is that
+patches or phases will not work.
+
+For patches, the problem is that a patch removing a non-free file
+automatically contains the non-free file@footnote{It has been noted that
+git patches support removing files without including the file in the
+patch in
+@url{https://yhetil.org/guix/8b13e899-eb60-490b-a268-639249698c81@@www.fastmail.com/}. If
+it is verified that the @command{patch} utility supports such patches,
+this method can be used and this policy adjusted appropriately.}, and we
+do not want anything non-free in Guix even if only in its patches.
+
+For phases, the problem is that phases do not influence the result of
+@command{guix build --source}.
+
+@subsubsection Removing bundled libraries
+Bundled libraries should not be removed with patches, because then the
+patch would contain the full bundled library, which can be large. They
+can be removed either in snippets or phases, often using the procedure
+@code{delete-file-recursively}. There are a few benefits for snippets here:
+
+When using snippets, the bundled library does not occur in the source
+returned by @code{guix build --source}, so users and reviewers do not
+have to worry about whether the bundled library contains malware,
+whether it is non-free, if it contains pre-compiled binaries ... There
+are also less licensing concerns: if the bundled libraries are removed,
+it becomes less likely that the licensing conditions apply to people
+sharing the source returned by @command{guix build --source}, especially if
+the bundled library is not actually used on Guix systems.@footnote{This
+is @emph{not} a claim that you can simply ignore the licenses of
+libraries when they are unbundled and replaced by Guix packages -- there
+are less concerns, not none.}
+
+As such, snippets are recommended here.
+
+@subsubsection Fixing technical issues (compilation errors, test failures, other bugs ...)
+Usually, a bug fix comes in the form of a patch copied from upstream or
+another distribution.  In that case, simply adding the patch to the
+@code{patches} field is the most convenient and usually does not cause
+any problems; there is no need to rewrite it as a snippet or a phase.
+
+If no ready-made patch already exists, then choosing between a patch or
+a snippet is a matter of convenience. However, there are two things to
+keep in mind:
+
+First, when the fix is not Guix-specific, upstreaming the fix is
+strongly desired to avoid the additional maintenance cost to Guix.  As
+upstreams cannot accept snippets, writing a patch can be a more
+efficient use of time.  Secondly, if the fix of a technical issue embeds
+a store file name, then it has to be a phase.  Otherwise, if the store
+file name were embedded in the source, the result of @command{guix build
+--source} would be unusable on non-Guix systems and also likely unusable
+on Guix systems of another architecture.
+
+@subsubsection Adding new functionality
+To add new functionality, a patch is almost always the most convenient
+choice of the three -- patches are usually multi-line changes, which are
+convenient to do with patches and inconvenient to do with phases or
+snippets.  This choice is usually also compatible with all the guiding
+principles.  As such, patches are preferred.  However, as with bug
+fixes, upstreaming the new functionality is desired.
+
+@subsubsection How to add patches
+Refer to the @code{origin} record documentation (particularly the fields
+@code{patches}, @code{patch-inputs}, and @code{patch-flags}) for
+information on how to use patches (@pxref{origin Reference}).  When
+adding a patch, do not forget to also list it in @code{dist_patch_DATA}
+of @file{gnu/local.mk}.
+
+@subsubsection How to add files
+New source files can be added in phases or snippets, by using
+@b{auxiliarry files}.  Auxiliary files are stored in the
+@file{gnu/packages/aux-files} directory and can be retrieved (in a
+snippet or a phase) with @code{search-auxiliary-file}.  When adding an
+auxiliary file, do not forget to also list it in @code{AUX_FILES} of
+@file{Makefile.am}.
+
+Another option for adding new files, is to use procedures such as
+@code{display}, @code{format} and @code{call-with-output-file}.  As a
+matter of principle, auxiliary files ought to be preferred over an
+equivalent @code{call-with-output-file} when creating non-trivil files,
+as that makes them easier to edit.  The exact threshold for a
+non-trivial file might be subjective, though it should lie somewhere
+between 10--20 lines.
+
+Currently, there is no policy on deciding between phase and snippets for
+adding new files, except for the guiding principles.
 
 @node Emacs Packages
 @subsection Emacs Packages
diff --git a/doc/guix.texi b/doc/guix.texi
index 7bce8a567c..042ab3bd8a 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -70,7 +70,7 @@ Copyright @copyright{} 2019 Jakob L. Kreuze@*
 Copyright @copyright{} 2019 Kyle Andrews@*
 Copyright @copyright{} 2019 Alex Griffin@*
 Copyright @copyright{} 2019, 2020, 2021, 2022 Guillaume Le Vaillant@*
-Copyright @copyright{} 2020 Liliana Marie Prikler@*
+Copyright @copyright{} 2020, 2022 Liliana Marie Prikler@*
 Copyright @copyright{} 2019, 2020, 2021, 2022 Simon Tournier@*
 Copyright @copyright{} 2020 Wiktor Żelazny@*
 Copyright @copyright{} 2020 Damien Cassou@*

base-commit: a44e08337d15b3f254a35d0311663c2bbd501852
prerequisite-patch-id: 0caac311875ee39cb48573657ebb960e90da6dfb
prerequisite-patch-id: 418285493d89ebf102175902d9b09a0174e88190
prerequisite-patch-id: 3c39eb839d9d3ff3fca6cd98621a5d5c411b7af4
prerequisite-patch-id: 8d5662e874c469f5ee496ef5181cf2d0a30ad1d8
prerequisite-patch-id: 26513c3b3b86963df718ee41d14a25d1cc6a8f3f
prerequisite-patch-id: 2b2497e2edec0afc48ebadd6f09f0c661c466127
prerequisite-patch-id: 2712efb97bf33985fd0658e4dd8e936dc08be5fe
prerequisite-patch-id: 9d2409b480a8bff0fef029b4b095922d4957e06f
-- 
2.37.2

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#57598] [PATCH] doc: Update contribution guidelines on patches, etc.
Resent-From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Fri, 09 Sep 2022 13:33:01 +0000
Resent-Message-ID: <handler.57598.B57598.166273036232696 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 57598
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Maxime Devos <maximedevos@HIDDEN>, 57598 <at> debbugs.gnu.org
Received: via spool by 57598-submit <at> debbugs.gnu.org id=B57598.166273036232696
          (code B ref 57598); Fri, 09 Sep 2022 13:33:01 +0000
Received: (at 57598) by debbugs.gnu.org; 9 Sep 2022 13:32:42 +0000
Received: from localhost ([127.0.0.1]:32876 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oWe7c-0008VG-TC
	for submit <at> debbugs.gnu.org; Fri, 09 Sep 2022 09:32:42 -0400
Received: from mailrelay.tugraz.at ([129.27.2.202]:7899)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <liliana.prikler@HIDDEN>) id 1oWe7Z-0008V6-NR
 for 57598 <at> debbugs.gnu.org; Fri, 09 Sep 2022 09:32:39 -0400
Received: from kagayaki.fritz.box (85-127-52-93.dsl.dynamic.surfer.at
 [85.127.52.93])
 by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4MPH3h4PwXz1LXsR;
 Fri,  9 Sep 2022 15:32:32 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4MPH3h4PwXz1LXsR
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at;
 s=mailrelay; t=1662730353;
 bh=JlOFPewa0DKs44hThj4/dpGiOvpO1u72noMUmD4yX54=;
 h=Subject:From:To:Date:In-Reply-To:References:From;
 b=FYFFf9RocV5xJx5Qc6OkXbDDU6gGyi98JRPLI8Cyo33IEm3S6ORg2SoKRtlPaT4WV
 h1k+zjm2GIpf2DpHi43LW8GmJOMbi1cqgOGJyqfk2huIDhWlHcMvhuCBzh3zn4gjf1
 DT8iW/EH073UICz/E4sLzqigVnbynUARSXIHSCAM=
Message-ID: <b74c40c57dff2a0ac6eee2a7a2124d8ab2d6314e.camel@HIDDEN>
From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
Date: Fri, 09 Sep 2022 15:32:31 +0200
In-Reply-To: <a24e8c5c-a986-3f6f-15a4-03caeb801e6d@HIDDEN>
References: <20220905160048.18173-1-maximedevos@HIDDEN>
 <0f78953d57d8f66a934baf518b7c9e3247b580fd.camel@HIDDEN>
 <d0a48b72-c62b-cc97-e399-22abc0af182d@HIDDEN>
 <44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN>
 <b33540cb-0c72-6170-34d0-b8df4ab79b8f@HIDDEN>
 <1e707c8e345af7b2fb0353c5f1c0e37d716e3308.camel@HIDDEN>
 <a24e8c5c-a986-3f6f-15a4-03caeb801e6d@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.1 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-TUG-Backscatter-control: waObeELIUl4ypBWmcn/8wQ
X-Spam-Scanner: SpamAssassin 3.003001 
X-Spam-Score-relay: -0.4
X-Scanned-By: MIMEDefang 2.74 on 129.27.10.116
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Am Freitag, dem 09.09.2022 um 13:14 +0200 schrieb Maxime Devos:
> 
> > In descriptions, it is wise to do so because it helps software
> > stand on its own merits rather than just "being a clone of this
> > thing you aren't allowed to have" (this is real criticism pointed
> > at us from the proprietary software embracers).  See for instance
> > minetest, which is described in terms of its features rather than
> > "being a Minecraft clone".
> 
> Sentence might have been truncated? 
Corrected above.

> Also, this is the package source field, not the description, I don't
> see how the "helps software stand on its own merits" applies to
> snippets of the package source.
Point taken, but imho it still makes sense to prefer keep lists over
remove lists.  The GNU project encourages people to read the sources
after all.


> > > How does ignoring a test fix the technical issue identified by
> > > the test (sometimes, the technical issue being a bug in the test
> > > itself)?
> > It fixes the technical issue that an otherwise functional package
> > (w.r.t. the N tests that don't fail) builds.  This is a
> > particularly
> > useful distinction with tests that require a network connection and
> > thus have to fail in a build container, or are known flaky upstream
> > and thus cause reproducibility issues.
> 
> Network test: right (though preferably those would support a 
> --no-network-tests test option or such).
> 
> For flaky tests: those sound like bugs to me, ignoring them doesn't 
> remove the flakyness.
Call it a bug or whatever, it is a technical issue that we deal with at
build time and not in the origin.

> > > 
> > > > There still is the difference that phases are clearly delimited
> > > > while snippets are a block of code that shouldn't get too
> > > > large.
> > > Snippets are delimited clearly as well, though, with the
> > > 'snippet' field?
> > > And the limitations of snippet length and phases length are the
> > > same -- no limits, though conciseness is appreciate as always.
> > True, but phases can be made to do just one thing, whereas snippets
> > have to fix everything that's wrong in more or less one (begin
> > ...).
> > This is a noticable distinction.> 
> 
> You can do that in snippets too, with comments:
> 
> (snippet
>    #~(begin
>        ;; Do the foo thing
>        (foo)
>        (foo-2 [...])
>        [...]
>        ;; Do the bar thing
>        (bar)
>        (bar-2 [...])
>        [...]))
You can, but it's still wiser to just keep the snippet short enough so
you don't have to.

> > 
> > > > I think my version at least hinted at this practice in a more
> > > > concise way, so it's not impossible to mention. [...]
> > > I agree it's possible -- as I replied previously:
> > > > I suppose a section could be added somewhere to properly
> > > > document
> > > > the 'embedding store file names' practice, and insert a
> > > > cross-reference,
> > > I don't think documenting the how of the practice should be done
> > > in this section, properly explaining 'search-input-file' /
> > > 'search-
> > > input-directory', 'inputs / native-inputs', 'bash' being an
> > > implicit
> > > input but you still have to add it to 'inputs' in some cases
> > > because
> > > of cross-compilation, this-package-input and this-package-native-
> > > input ... would make the
> > > subsubsection a bit too long I think, distracting from other
> > > situations, hence the proposal for a cross-reference.
> > > How about leaving the 'how to embed store file names' for a
> > > separate
> > >   documentation patch and section, adding a cross-reference
> > > later?
> > See above, "I suppose a section could be added..." means I'm
> > somewhat indifferent to whether it's done now or later;
> 
> Nitpick: you are quoting some text I wrote, so 'I' refers to me here,
> not you.
Ahh, my bad, the nesting level confused me.

>   I would however very
> > much prefer a wording that points people toward this practice
> > existing,
> > even if they have to go look in the code for examples. 
> > Alternatively,
> > a footnote for the most common case (search-input-file inputs
> > "bin/command") ought to suffice for the time being.
> 
> Aside from the typo's and a few rephrasings, I'm done with the 
> documentation.  If someone wants to extend the section with such 
> information, they can always do so later.
I haven't seen a v2 though.  Am I correct in assuming that none of the
points we discussed in the last few mails are going to be addressed?

> > 
> > IMHO, I think a reader who remembers the guiding principles should
> > see that it applies.
> 
> Likely. But removing the explicit mention of the guiding principle
> still makes the logical reasoning incomplete, remembering has nothing
> to do with it.  As I've written previously: ‘This has nothing do do
> with [...] and remembering, but rather with [...]’.
In that case, let me rephrase my criticism: "It passes the guidelines"
should not be part of the logical reasoning here.  Otherwise, why not
have a guideline checklist at the end of each subsection (which would
be silly, obviously, but that's the point).

> > > 
> > Also, your guiding principles are (with one exception) really just
> > invariants that ought to hold for the source field of a package.
> 
> I don't know about the exceptions (I haven't counted them), but yes, 
> indeed.  I do not see the problem of this.
For the record, the exception is the "most convenient" bit you've
copied from my patch :)

> > As such, I think it would be easier to state "A package's source
> > should
> > be the smallest corresponding source in terms of uncompressed file
> > size.  This corresponding source must consist only of free software
> > (note Free Software) and should build on all platforms supported by
> > upstream."  Note how smallest naturally implies unbundling bundled
> > sources.
> 
> This criterium on overly small sources.  Often, a package's source 
> contains things that is not used for the build or outputs and hence
> is not part of the corresponding source.  Examples:
Note "should" rather than "shall" or "must", meaning that slightly
larger tarballs are still acceptable.

> * the source contains documentation that could be built and
> installed,
>    but Guix doesn't do so yet.  --> should be kept (unless non-free)
> * documentation that isn't meant to be built or installed
>    (e.g. HACKING, PACKAGERS, ...) --> useful, shouldn't be removed.
> * .gitignore, .github, ... --> nothing wrong with removing those,
>    but pointless, let's not waste our time with looking for those
>    and removing them, even though doing so would make it smaller.
> * source files for platforms the upstream does not support
> yet/anymore
>    (but with some volunteer effort (e.g. bugfixes), it might become
>    a supported system again)
>    --> removing them (e.g. as part of an overly-broad 
> (delete-file-recursively 
> "this-dir-has-bundling-albeit-not-all-of-it-is-bundling"))
>        can be OK-ish, but removing them for 'minimality' is
> pointless.
I see you're nitpicking for the sake of the argument, but none of the
examples you provide (safe for the bundling one) add much cost to
either packing or unpacking.  Thus, I'm pretty sure we can ignore them
for practical purposes.  That being said, if you have a better
formulation, please do tell.

> 
> > > > I still find this wording very confusing. Perhaps "To add new
> > > > functionality, a patch is almost always the best choice. For
> > > > one,
> > > > it is likely that the new functionality requires changing
> > > > multiple
> > > > lines of source code, which is more convenient to do with a
> > > > patch
> > > > than with a snippet. Further, patches can be taken from and
> > > > submitted to upstreams more easily. If your patch has not been
> > > > submitted to upstream, consider doing so."
> > > It loses some information (that patches are preferred) and
> > > (after re-adding the conclusion) is more verbose, which appears
> > > to be considered very important.
> > Which conclusion is there to re-add?
> 
> "patches are preferred"
> 
>    The conclusion is already stated
> > in the beginning: patches are almost always the best choice.  Then
> > two
> > reasons as for why.  The part w.r.t. upstreaming changes has also
> > been
> > addressed.
> 
> While I consider that policies should have "best choices" coinciding 
> with "preferred" and that not doing so would be illogical, people, 
> projects, decisions ... are far from always logical.
> 
> Because of this, people cannot assume that the 'best choices' are 
> 'preferred', so it needs to be mentioned explicitly that these 'best 
> choices' are actually 'preferred'.
In that case, simply write preferred choice?

> > I'm using enumeration as a super term here, which can be
> > ((sub)sub)sections, chapters, list elements, whatever, and my claim
> > is that we barely have enough principles to allow the use of a
> > plural.
> 
> In English, things are either plural or singular.  Everything >= 2 is
> plural.  There number of principles, however we count them, is, at 
> least, 2.  Consequently, the principles are plural, not singular. 
> Treating the principles as singular is simply grammatically
> incorrect.
Correction: Everything that isn't exactly 1 is plural in English,
including 0, with perhaps the exception of -1 also using singular.

> Maybe it is barely allowed to be plural, but English grammar doesn't 
> care about that -- it is definitively disallowed to be singular, only
> plural remains.
Note that my argument isn't about English grammar, it uses English
grammar.

> > Adding to that, now that I think of it, I also doubt their
> > usefulness in guiding.  "Use whatever feels convenient, but note
> > that that might be subjective" is more useful at the end of the
> > section when a user didn't find what they were looking for than at
> > the start.
> 
> The introduction has a set of guiding principles, from with concrete 
> cases are built.  By adding another principle at the end, the cases
> cannot make use of the "use [...] convenient" principle.
> 
> Additionally, now the user has to look at _two_ places to find the 
> guiding principles -- at the beginning, and at the end.  Worse,
> the beginning does not have a cross-reference to the end, so since
> the set at the beginning is presented as exhaustive, the user might
> not know there is another guiding principle.
> 
> And even if they did read through the whole section (even though they
> should only have to read the introduction and the relevant worked-out
> case), assuming they read through it in a linear fashion, due to the
> new guiding principle that wasn't alluded to at the beginning, they
> have to redo their mental model of "Modifying Sources" as this
> principle could invalidate things.
This shows both a problem with your structure, but more importantly, a
failure to understand what I meant when I wrote "use whatever is
convenient" in my own patch.  This principle *can* only work for cases
in which there is *no clearly established practice*, thus putting it at
the end *after having enumerated all practices* is the logical choice.
With your structure, you have to bend it sideways to shoehorn it in
with the other principles.

> > At the risk of responding jokingly to what was meant serious: I
> > didn't know we suddenly gained 20 guiding principles.
> 
> 25 lines are for the guiding principles (sometimes referring to a 
> principle of elsewhere in Guix, sometimes a new principle for
> "Modifying Sources").  You proposed to 'cache' them somehow.  In
> Guile, to cache something, you can use 'delay/force'.  But this
> increases the amount of code (due to the additional use of 'delay'),
> instead of decreasing.
> 
> The documentation equivalent (whatever that might be, I am not seeing
> one myself) would then also be at least as long, maybe even a little 
> longer due to the use of 'delay'.
Okay, so I did misunderstand those 25 lines as 25 lines within the text
calling back to those guiding principles rather than 25 lines for the
guiding principles themselves.  Still, 25 lines are a little much,
especially given that the bulk of it explains the semantics of the
packages' source field.
> > 

> > > I suppose table items might take two less line or so less than
> > > subsubsections, but I don't think that's sufficient reason to
> > > step away from a nice section structure.
> > Another reason is that you can end a table in the middle of a
> > section, which you can't do with subsections.  Hence why I'm able
> > to put a remark at the bottom, which you have to clumsily fit into
> > the top.
> 
> I can, indeed, not put the 'convenience principle' at the bottom,
> except perhaps by adding a new subsubsection, and for tables adding
> such a remark at the bottom is indeed more convenient.
> 
> However, I don't see the 'have to clumsily' here -- as explained 
> elsewhere, I believe that the 'convenience principle' shouldn't be 
> separated from the other principles and that it fits nicely next to
> the the principles --- there is no 'have to', because I choose for
> this, and I am not seeing any 'clumsiness' here.
I think we'd have to debate choice vs. force here which would be a
rather long aside, but to make my argument short, your choice of how to
structure this section (table vs subsections) directly influences your
"choice" where to place particular information in a way that might 
inhibit natural information flow.
> > 
> > 
> > 

> > > The patch does this, currently.  It already proposes a number of
> > > hammers (patches, snippets and phases) and purposes (adding new
> > > functionality, fixing technical issues, unbundling, ...).
> > > Also, the scenario "oh no, however will I put this nail into a
> > > wall"
> > > actually happened -- see the Shepherd discussion, where there was
> > > a lot of disagreement on how nails (= small work-around in the
> > > Makefile) should be put in walls (= patches, snippet, phase?).  
> > > It
> > > was the whole reason to start writing a documentation patch.
> > You might want to add a link here if it supports your argument, but
> > without looking at the discussion this rather sounds like "oh no, I
> > have three hammers, which one do I pick?" – which, fair enough, is
> > still a problem, but one that neither of our patches would cause
> > imho.
> 
> As I think I've written previously, the whole point was to solve that
> problem. For the discussion, see:
> 
> * https://issues.guix.gnu.org/54216
> *
> https://yhetil.org/guix/c4c0a071-2e03-d4d6-6718-05424d21d146@HIDDEN/
> * 
> https://yhetil.org/guix-devel/84e13ef7d437062df5cca51a12e6da54929e0176.camel@HIDDEN/
> 
> Not solving the problem defeats the whole point, as the purpose is to
> solve that problem.
I think we might be disagreeing about what constitutes "solving the
problem" here.  Correct me if I'm wrong, but to me it seems any
scenario that is not covered by whatever patch is applied counts as
"not having solved the problem".  I personally find this line of
reasoning questionable, as there are perfectly valid reasons why
multiple tools could apply.

Take the problem of embedding a store path.  You could for instance
replace all occurences of "sh" with /gnu/store/.../bin/sh, or you could
first replace them in a patch with "@sh@" and then replace that with
/gnu/store/.../bin/sh.  Of course, you rarely have to do the latter and
the former is simpler, hence why you will often see the former, but
that doesn't mean the latter is invalid.
> 

> 
> > > 
> > > > And if they don't find anything, they see the handy little line
> > > > at the bottom saying "use whatever you think is convenient".
> > > Nowhere did the patch imply that the listed cases were all cases.
> > > In fact, in two places in the introduction it is implied that the
> > > examples are not exhaustive, and that they can choose according
> > > to convenience  [...]
> > Emphasis on handy little line rather than needing to be told twice
> > (particularly if people have no idea what to expect due to not
> > having looked at the worked-out cases yet).
> 
> They don't need to be told twice.  Also, my patch also has that handy
> little line (albeit differently worded), see the 'guiding
> principles'.
> 
> Also, on the 'no idea what to expect' -- this is exactly the same for
> your patch too?  In both patches, if the user only reads the 
> introduction and conclusion (if any) and doesn't read the actual 
> (relevant examples)/(explanation of patches, snippets, phases), then 
> that's their problem.
I do think a table in the middle of the section is hard to ignore, but
suppose for the sake of argument that they do, then in my case they
will have learned exactly nothing.  In your case, they will know the
"guiding principles" and then interpret them to mean whatever they
think it means.  I'm not convinced mine is worse here.

> > > 
> > > > I also expand a little on the benefits and drawbacks of
> > > > these approaches as you would when describing design patterns.
> > > This is also done in my patch. [...]
> > This is not about the contained information, but the structure of
> > the contained information.
> > 
> > My solution->problem style follows roughly this style:
> > 1. solution
> > 2. problems it is known to solve
> > 3. how to use
> > 4. properties, caveats, etc.
> > 
> > Your problem->solution style roughly has the following:
> > 1. problem
> > 2. (set of) solution(s)
> > 3. if more than one solution, maybe a help to select
> 
> Also, in no particular order
> 
>    4.: how to use
>    5.: explanation why it is preferred (properties, caveats?)
No particular order is problematic, but more importantly if a
technology appears more than once (guaranteed by the pigeonhole
principle), then either its properties get repeated (not good for
length) or scattered (not good for the flow you want).  Again, a
structural problem.

> > This makes it so that people might have to go to a different
> > subsection than the one they read for their solution to find out
> > about potential caveats, e.g. not embedding store paths in a
> > snippet.
> 
> I assume their problem was "X doesn't find Y".  This being a
> technical issue, they go to "Fixing technical issues".  In that
> subsubsection,  there are the words:
> 
> > Secondly, if the fix of a technical issue embeds a store file name,
> > then it has to be a phase.  Otherwise, if the store file name were
> > embedded in the source, the result of @command{guix build --source}
> > would be unusable on non-Guix systems and also likely unusable on
> > Guix systems of another architecture.
> 
> so they actually do know of the caveat 'don't embed store paths in a 
> snippet, do it in a phase instead', and they did not need to go to a 
> different subsubsection.
Typical happy path.

> > > 
> > > > Your problem->solution approach instead leaves people wondering
> > > > when their particular use case has not been described.
> > > See my reply to ‘And if they don't find anything, they see the
> > > handy little line at the bottom saying "use whatever you think is
> > > convenient’.
> > > > It gives them a solution rather than the tools to build
> > > > solutions with.
> > > It does give the tools: snippets, patches and phases.
> > As far as I read, it describes none of those.  It puts out guiding
> > principles and some already worked-out cases.
> Here are the descriptions:
> 
> > Guix has tree main ways of modifying the source code of a package,
> > that you as a packager may use.  These are patches, snippets and
> > phases
> 
> Once the user knows _which_ of the three they should use (by
> consulting the following subsubsections), they can then search for
> 'patch', 'snippet' and 'phases' in the manual for more information,
> no need to duplicate that information.
Point taken, but imho cross-references are nice for those who just
learned "okay, I now know I need to solve my technical problem with a
phase, how do I do that?"  
> 
> > > Also, "giving the tools to build solutions with" does not help
> > > with the problem that I aimed to solve -- there was disagreement
> > > on what the appropriate tools are (see: Shepherd), so it not just
> > > needs to give the tools, but also the solutions.
> > I don't see how my patch lacks this information however.
> 
> IIUC, the raw information should usually be indeed all there, but the
> user has to consult _all_ of the sections to determine which option 
> (patch, snippet, phase) is appropriate, having to assemble all the 
> information is (a) a waste of time and (b) can lead to different 
> interpretations and conclusions (see: Shepherd).
> 
> More concretely, I cannot use your patch to decide between phases, 
> snippets and patches for the Shepherd issue:
> 
> * none of three appear to be forbidden by your documentation
> * there is no recommendation for 'patches' (IIRC it wasn't accepted 
> upstream and there was no intent to submit it upstream, it being
> really a Guile bug, not a Shepherd bug)
> * there is no recommendation for snippets (it's all free, no
> bundling)
> * build phases are 'to be avoided' (but not forbidden), as it
> resulted
>    in observably different runtime behaviour (being a bug fix)
> 
> -- three (or at best, two, if build phases are discounted) options 
> remain.  Myself, I would then consider 'snippets' to be the most 
> convenient, but some others (see: Shepherd, IIRC) would really want a
> patch instead, because 'patches can be reverted' or something like
> that.
> 
> As such, you are giving the tools (snippets / patches / phases, some 
> downsides and upsides), but different people can construct different 
> solutions from those tools even in the same situation, leading to
> conflicts.
> 
> If I use my patch instead, I go to "fixing technical issues". This 
> section tells me to use a patch or a snippet.  As the fix is not 
> Guix-specific, it recommends a patch to save time when upstreaming. 
> Conclusion: write a patch.  It was a Guile bug, so the fix was a
> patch to Guile.  But that would take time and upstream took the
> responsibility for a fix, so the 'efficient time thing' doesn't
> really apply and a small work-around (setting optimisation flags)
> suffices.
> 
> In this situation, the subsubsection doesn't care at all if you go
> for a snippet, so apply the last guiding principle: go for the
> simplest thing: a snippet. (Unless you already have a patch, then a
> patch is simplest.)
> Does someone else have a different idea on what's simplest?  Doesn't
> really matter, ‘Sometimes this is subjective, which is also fine’.
I do get the impression that this patch simply codifies what you feel
is right based on the shepherd situation rather than thinking about the
general case, which is why my patch makes weaker statements here.  If
this issue could have been avoided with a #:make-flag, we would have
used that.

More importantly, I fail to see the superiority of your patch here. 
IIUC neither patch offers a unique solution to the shepherd thing, so
the room for debate remains.  You could claim that my patch offers more
room, which fair enough, it does, but on the same token it allows
people to see that the guidelines have been followed and the patch can
be applied.

> > In particular, for review purposes, mine should be easier to work
> > with.  For instance, the reviewer sees a hash embedded in a
> > snippet, sees in the snippet entry that you shouldn't do that, and
> > can thus say "nope, don't do a snippet here".
> 
> I think we should optimise for packagers before reviewers
Code is more often read than written, so optimising for the reader is
optimizing for the packager as well.

> > Regardless of which patch we pick, it should not mandate a
> > particular solution in potentially contentious cases,
> 
> Actually the whole point was to mandate a particular solution for the
> contentious cases, see Shepherd.
But I disagree.

Memes aside, please refrain from the "I'm right, do this" style (which
is another problem with the "problem-centric" approach), but rather
focus on writing a patch that makes reviewers not discard a patch due
to formalities.  If the shepherd thing had needed an upstream patch,
even with a snippet that patch could have easily been created by
converting that snippet to a sed, so more time was wasted debating than
overworking.

> > and also point towards the right solution.  See our discussions on
> > the individual solutions on points in which I believe you've
> > errored.
> 
> These are:
> 
> * the typo's
> * including "skipping tests indicating failure under ‘Fixing
> technical issues’"
> * "don't mention file names of non-free things in patches"
> 
> Did I miss any?
I'm pretty sure there's also a discussion on store path embeddings at
the very least.  Forgive me if I too missed something.

Cheers

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#57598] [alternative PATCH] doc: Update contribution guidelines on patches, etc.
References: <20220905160048.18173-1-maximedevos@HIDDEN>
In-Reply-To: <20220905160048.18173-1-maximedevos@HIDDEN>
Resent-From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Fri, 09 Sep 2022 15:10:02 +0000
Resent-Message-ID: <handler.57598.B57598.166273619212231 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 57598
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: 57598 <at> debbugs.gnu.org
Cc: Maxime Devos <maximedevos@HIDDEN>
Received: via spool by 57598-submit <at> debbugs.gnu.org id=B57598.166273619212231
          (code B ref 57598); Fri, 09 Sep 2022 15:10:02 +0000
Received: (at 57598) by debbugs.gnu.org; 9 Sep 2022 15:09:52 +0000
Received: from localhost ([127.0.0.1]:35009 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oWfdf-0003BB-Im
	for submit <at> debbugs.gnu.org; Fri, 09 Sep 2022 11:09:52 -0400
Received: from mail-ej1-f65.google.com ([209.85.218.65]:33655)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <liliana.prikler@HIDDEN>) id 1oWfdd-0003Ay-DI
 for 57598 <at> debbugs.gnu.org; Fri, 09 Sep 2022 11:09:50 -0400
Received: by mail-ej1-f65.google.com with SMTP id lc7so4789376ejb.0
 for <57598 <at> debbugs.gnu.org>; Fri, 09 Sep 2022 08:09:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:message-id:content-transfer-encoding:cc:to:subject
 :date:from:from:to:cc:subject:date;
 bh=DSH2NtZY3PQTC9fFJQkWMf/DkB/1uEtpmw/Cv0n+AMo=;
 b=RB27Z8fDTtIJ2XFhBirBQANWfULF0jfkBugGZd4Rw0w6xoRT4pHsnPzA/oUwy+QU4c
 2kl9ebzqGuLU31Dxvb3pYQyJilPkTfwNIlxb8T5Ae0DDDFUJ/3OFjLg1ORSnlBsNFYeh
 ab1QRNL7dsEruUKgQElSScUflGRqFadVfFUXY/zNOEAwE6PuP2P8QRYrPsKlUAaJuGzI
 DpqRrZ7H7yJUp2vkY4iuUiqW6gVEXnSyOtwbkJCIKDRmB7Xa7QsTalWn/pqmoTBGfJUF
 tZ6/bPbrlTbMScxnr7FUdnP4Dz7kx5uRZSr9l/QWm7pIuwnwESrv50ygtNQgYNG0dfm1
 pILQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=mime-version:message-id:content-transfer-encoding:cc:to:subject
 :date:from:x-gm-message-state:from:to:cc:subject:date;
 bh=DSH2NtZY3PQTC9fFJQkWMf/DkB/1uEtpmw/Cv0n+AMo=;
 b=GjYi+GizlJchSsS5oFpLLPwS97G55b+1jnU1J3wI1q8liMrm1xfylMx0zEThGzQ0au
 hsBjyJAgm5IBVlbfZXd+F5N7n2DSdNbv9OTUlG6CPEYEKtxk9wrxoQ91RNa2xEK0a9ZP
 yxYv1sgGFt7ibI/jYgYo+e475hOVile106DKh/qZxy6M9mDIo4NuiSxgGPy+KE1AkeuX
 OofFU2WSyfjTkn9qggVWn5BvcUt6xTpg6RQQE3xmfkhth6ONndQWbIZcgEOAb1Z35Fik
 icuAn0tZBEvCNsOBLGlZnNDDfN8rRSZAS8NxZxyRul6Pa1v1b4vDnVCEZCROe4SAMQTK
 93iw==
X-Gm-Message-State: ACgBeo1H2SPRi20lgo7GbcB57M8vAcIwahZa3dizEXvYeX2b8+f7xiGV
 HGhz7nPsg2FKQQyrqk9WIS7hKCrqt+A=
X-Google-Smtp-Source: AA6agR5rA2mTbgIBetX28G58h2IWMDUL2Bom3iKU1G5I9NNBL3Cc5B7j6p74jt+jiXD6+YpXV6jpqA==
X-Received: by 2002:a17:907:2c75:b0:741:5871:4318 with SMTP id
 ib21-20020a1709072c7500b0074158714318mr9954710ejc.532.1662736183642; 
 Fri, 09 Sep 2022 08:09:43 -0700 (PDT)
Received: from nijino.fritz.box (85-127-52-93.dsl.dynamic.surfer.at.
 [85.127.52.93]) by smtp.gmail.com with ESMTPSA id
 kz5-20020a17090777c500b007708851c6f0sm389200ejc.146.2022.09.09.08.09.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 09 Sep 2022 08:09:43 -0700 (PDT)
From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
Date: Sat, 6 Aug 2022 08:55:03 +0200
Content-Transfer-Encoding: 8bit
Message-ID: <246b28ff9c402cfce8c2ef799d7d73b1dbb2cca9.camel@HIDDEN>
MIME-Version: 1.0
X-Spam-Score: 2.1 (++)
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:  * doc/contributing.texi ("Snippets versus Phases"): Replaced
    with... ("Modifying Sources"): ... this. List more use cases and some principles.
    --- Hi Maxime, here is an update of my guidelines patch, incorporating the
    changes =?UTF-8?Q?Ludo=E2=80=99?= requested and some of your bits, as well as fixing some omissions.
    
 
 Content analysis details:   (2.1 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
                             provider (liliana.prikler[at]gmail.com)
  2.1 DATE_IN_PAST_96_XX     Date: is 96 hours or more before Received:
                             date
  0.0 RCVD_IN_MSPIKE_H3      RBL: Good reputation (+3)
                             [209.85.218.65 listed in wl.mailspike.net]
  0.1 PP_MIME_FAKE_ASCII_TEXT BODY: MIME text/plain claims to be ASCII
                              but isn't
  0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
 -0.0 T_SCC_BODY_TEXT_LINE   No description available.
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.1 (+)
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:  * doc/contributing.texi ("Snippets versus Phases"): Replaced
    with... ("Modifying Sources"): ... this. List more use cases and some principles.
    --- Hi Maxime, here is an update of my guidelines patch, incorporating the
    changes =?UTF-8?Q?Ludo=E2=80=99?= requested and some of your bits, as well as fixing some omissions.
    
 
 Content analysis details:   (1.1 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  0.0 RCVD_IN_MSPIKE_H3      RBL: Good reputation (+3)
                             [209.85.218.65 listed in wl.mailspike.net]
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
                             provider (liliana.prikler[at]gmail.com)
  2.1 DATE_IN_PAST_96_XX     Date: is 96 hours or more before Received:
                             date
  0.1 PP_MIME_FAKE_ASCII_TEXT BODY: MIME text/plain claims to be ASCII
                              but isn't
  0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
 -0.0 T_SCC_BODY_TEXT_LINE   No description available.
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

* doc/contributing.texi ("Snippets versus Phases"): Replaced with...
("Modifying Sources"): ... this.  List more use cases and some principles.
---
Hi Maxime,

here is an update of my guidelines patch, incorporating the changes Ludo’
requested and some of your bits, as well as fixing some omissions.

Cheers

 doc/contributing.texi | 115 +++++++++++++++++++++++++++++++++++++-----
 1 file changed, 102 insertions(+), 13 deletions(-)

diff --git a/doc/contributing.texi b/doc/contributing.texi
index 17a54f94cc..4894982259 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -451,7 +451,7 @@ needed is to review and apply the patch.
 * Package Naming::              What's in a name?
 * Version Numbers::             When the name is not enough.
 * Synopses and Descriptions::   Helping users find the right package.
-* Snippets versus Phases::      Whether to use a snippet, or a build phase.
+* Modifying Sources::           When to use patches, snippets, or build phases.
 * Emacs Packages::              Your Elisp fix.
 * Python Modules::              A touch of British comedy.
 * Perl Modules::                Little pearls.
@@ -708,20 +708,109 @@ Gettext}):
 for the X11 resize-and-rotate (RandR) extension. @dots{}")
 @end lisp
 
-@node Snippets versus Phases
-@subsection Snippets versus Phases
+@node Modifying Sources
+@subsection Modifying Sources
 
+@cindex patches, when to use
 @cindex snippets, when to use
-The boundary between using an origin snippet versus a build phase to
-modify the sources of a package can be elusive.  Origin snippets are
-typically used to remove unwanted files such as bundled libraries,
-nonfree sources, or to apply simple substitutions.  The source derived
-from an origin should produce a source that can be used to build the
-package on any system that the upstream package supports (i.e., act as
-the corresponding source).  In particular, origin snippets must not
-embed store items in the sources; such patching should rather be done
-using build phases.  Refer to the @code{origin} record documentation for
-more information (@pxref{origin Reference}).
+
+Guix has three main ways of modifying the source code of a package,
+that you as a packager may use.  Each one has its strengths and
+drawbacks, along with intended and historically derived use cases.
+These are
+
+@table @b
+
+@item patches
+If your package has a bug that takes multiple lines to fix, or a fix
+has already been accepted upstream, patches are the preferred way of
+eliminating said bug.@footnote{If you patch a bug that has hitherto
+not been reported or fixed upstream, consider also contacting upstream
+unless the bug and its fix are specific to Guix.}
+Refer to the @code{origin} record documentation
+(particularly the fields @code{patches}, @code{patch-inputs}, and
+@code{patch-flags}) for more information on how to use patches
+(@pxref{origin Reference}).
+When adding a patch, do not forget to also list it in
+@code{dist_patch_DATA} of @file{gnu/local.mk}
+
+As patches are applied to the origin of a package, they become part
+of the corresponding source.  You can retrieve this source by
+invoking @code{guix build -S YOUR_PACKAGE}.  This also means that
+modifying the patch causes two rebuilds: one for the source and one
+for the package built from it.
+
+Patches are limited in that they lack the expressiveness of Guile.
+If all changes are constrained to single lines, a patch might be much
+larger than the equivalent @code{substitute*}.  It is further bad form
+to use a single patch to address multiple unrelated issues, whereas
+snippets can take ``multiple jobs''.
+
+@item snippets
+If your package contains non-free sources, these need to be removed
+through a snippet.  This snippet should not only remove the sources in
+question, but also references to the removed sources in build scripts,
+documentation, and so on. @ref{Software Freedom}
+
+If your package bundles external libraries, snippets are the preferred
+way of removing said them.  Unlike with non-free sources, it is not a
+requirement to remove @emph{all} bundled libraries, although doing so
+is very much preferred.  Bundled libraries that are kept should be
+clearly indicated, preferrably with a reason as to why the bundled copy
+remains.  As with non-free sources, references to the removed libraries
+should also be updated in the snippet.
+
+Refer to the @code{origin} record documentation
+(particularly the fields @code{snippet} and @code{modules}), for more
+information on how to use snippets (@pxref{origin Reference}).
+
+While snippets have all of Guile's core as well as extra @code{modules}
+available, their most useful procedure for @emph{editing} sources
+(rather than removing them), is @code{substitute*}, which can not deal
+with multi-line changes that well.  Like patches, snippets become part
+of the corresponding source.
+
+@item build phases
+For modifications that retain the intended functionality of the
+package, build phases (usually between @code{unpack} and
+@code{configure}, sometimes between @code{configure} and @code{build})
+can be used.  @ref{Build Phases}.
+Such changes include, but are not limited to, fixes of the
+build script(s) or embeddings of store paths (e.g. replacement of
+@file{/bin/sh} with @code{(search-input-file inputs "bin/sh")}).
+
+If you need to embed a store path, do so only inside a build phase.
+A workaround for patches that span multiple lines, is to use a variable
+such as @code{@@store_path@@} inside the patch and substitute the actual
+store path at build time via @code{substitute*}.
+
+Unlike patches and snippets, build phases do @b{not} become part of
+the corresponding source of a package, and should thus be avoided for
+changes that result in observably different runtime behaviour.
+On the other hand, the reduced overhead of unpacking, repacking and
+unpacking again might make for a slightly more pleasant debugging
+experience.
+
+@end table
+
+If your change does not neatly fit in any of the categories above, it
+is usually a matter of preference or convenience.
+
+@cindex auxiliary files
+
+Sometimes, you may need to add a new file, e.g. a source file or
+configuration file, to your package.  As a matter of principle
+@b{auxiliary files} should be preferred over an equivalent
+@code{display} or @code{format} when creating non-trivial files, as that
+makes them easier to edit.  The exact threshold for a non-trivial file
+might be subjective, though it should lie somewhere between
+10--20 lines.
+
+Auxiliary files are stored in the @file{gnu/packages/aux-files}
+directory and can be retrieved in a snippet or build phase via
+@code{search-auxiliary-file}.
+When adding an auxiliary file, do not forget to also list it in
+@code{AUX_FILES} of @file{Makefile.am}.
 
 @node Emacs Packages
 @subsection Emacs Packages
-- 
2.37.2

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#57598] [PATCH] doc: Update contribution guidelines on patches, etc.
Resent-From: Maxime Devos <maximedevos@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Fri, 09 Sep 2022 18:45:01 +0000
Resent-Message-ID: <handler.57598.B57598.166274906828412 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 57598
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Liliana Marie Prikler <liliana.prikler@HIDDEN>, 57598 <at> debbugs.gnu.org
Received: via spool by 57598-submit <at> debbugs.gnu.org id=B57598.166274906828412
          (code B ref 57598); Fri, 09 Sep 2022 18:45:01 +0000
Received: (at 57598) by debbugs.gnu.org; 9 Sep 2022 18:44:28 +0000
Received: from localhost ([127.0.0.1]:35456 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oWizJ-0007O1-GS
	for submit <at> debbugs.gnu.org; Fri, 09 Sep 2022 14:44:27 -0400
Received: from andre.telenet-ops.be ([195.130.132.53]:58758)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <maximedevos@HIDDEN>) id 1oWizF-0007Nr-EG
 for 57598 <at> debbugs.gnu.org; Fri, 09 Sep 2022 14:44:24 -0400
Received: from [IPV6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16]
 ([IPv6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16])
 by andre.telenet-ops.be with bizsmtp
 id HukH2800D20ykKC01ukHhx; Fri, 09 Sep 2022 20:44:18 +0200
Message-ID: <e9162363-e67b-956e-6346-6a1a6e529abf@HIDDEN>
Date: Fri, 9 Sep 2022 20:44:16 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.12.0
Content-Language: en-US
References: <20220905160048.18173-1-maximedevos@HIDDEN>
 <0f78953d57d8f66a934baf518b7c9e3247b580fd.camel@HIDDEN>
 <d0a48b72-c62b-cc97-e399-22abc0af182d@HIDDEN>
 <44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN>
 <b33540cb-0c72-6170-34d0-b8df4ab79b8f@HIDDEN>
 <1e707c8e345af7b2fb0353c5f1c0e37d716e3308.camel@HIDDEN>
 <a24e8c5c-a986-3f6f-15a4-03caeb801e6d@HIDDEN>
 <b74c40c57dff2a0ac6eee2a7a2124d8ab2d6314e.camel@HIDDEN>
From: Maxime Devos <maximedevos@HIDDEN>
In-Reply-To: <b74c40c57dff2a0ac6eee2a7a2124d8ab2d6314e.camel@HIDDEN>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------b304Y9bejnymBhUvwnTF0ap0"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r22;
 t=1662749058; bh=0aADSMKUBU0fzd5tekJnVsAmdaUV9xOfGxfaDG9HTMk=;
 h=Date:To:References:From:Subject:In-Reply-To;
 b=TvH5hWTI4Y0BceTANeve4Q2BypLqxRgPXGP4T/ITvlQPJPDslCbl6lw2P8VwYGAgp
 ogX5MGtvVBwARKhVnWxJ1tsjy04teNje65/oVRJ609OW2XY8eXjj8OlKSeSMvUPqk9
 VMKsXnwtKYhSe6dmgiuh2bXzGpJYVheq+G6VQU5E5WIM9YVr38tZHxQvSNAnLRpkOj
 waJZNWIe8/9f3TjHiZzNEbIYB518W9mSpQ2uYPwyJPblG8aXFuZfo9NlMzH5NMBzlg
 FL4T9r0BjczBp3B54/TrZ3eFHBkDN1rOU1blOEocoihnbb5Uh/1m/Jn1sZcAkaRGWj
 iJXuzsuWpLOyg==
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------b304Y9bejnymBhUvwnTF0ap0
Content-Type: multipart/mixed; boundary="------------A60oN2LySqwFEM12Dd7BpjjC";
 protected-headers="v1"
From: Maxime Devos <maximedevos@HIDDEN>
To: Liliana Marie Prikler <liliana.prikler@HIDDEN>,
 57598 <at> debbugs.gnu.org
Message-ID: <e9162363-e67b-956e-6346-6a1a6e529abf@HIDDEN>
Subject: Re: [PATCH] doc: Update contribution guidelines on patches, etc.
References: <20220905160048.18173-1-maximedevos@HIDDEN>
 <0f78953d57d8f66a934baf518b7c9e3247b580fd.camel@HIDDEN>
 <d0a48b72-c62b-cc97-e399-22abc0af182d@HIDDEN>
 <44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN>
 <b33540cb-0c72-6170-34d0-b8df4ab79b8f@HIDDEN>
 <1e707c8e345af7b2fb0353c5f1c0e37d716e3308.camel@HIDDEN>
 <a24e8c5c-a986-3f6f-15a4-03caeb801e6d@HIDDEN>
 <b74c40c57dff2a0ac6eee2a7a2124d8ab2d6314e.camel@HIDDEN>
In-Reply-To: <b74c40c57dff2a0ac6eee2a7a2124d8ab2d6314e.camel@HIDDEN>

--------------A60oN2LySqwFEM12Dd7BpjjC
Content-Type: multipart/mixed; boundary="------------RneJSr4rW60YFuWvSkivYcO6"

--------------RneJSr4rW60YFuWvSkivYcO6
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

DQoNCk9uIDA5LTA5LTIwMjIgMTU6MzIsIExpbGlhbmEgTWFyaWUgUHJpa2xlciB3cm90ZToN
Cj4+IEFsc28sIHRoaXMgaXMgdGhlIHBhY2thZ2Ugc291cmNlIGZpZWxkLCBub3QgdGhlIGRl
c2NyaXB0aW9uLCBJIGRvbid0DQo+PiBzZWUgaG93IHRoZSAiaGVscHMgc29mdHdhcmUgc3Rh
bmQgb24gaXRzIG93biBtZXJpdHMiIGFwcGxpZXMgdG8NCj4+IHNuaXBwZXRzIG9mIHRoZSBw
YWNrYWdlIHNvdXJjZS4NCj4gUG9pbnQgdGFrZW4sIGJ1dCBpbWhvIGl0IHN0aWxsIG1ha2Vz
IHNlbnNlIHRvIHByZWZlciBrZWVwIGxpc3RzIG92ZXINCj4gcmVtb3ZlIGxpc3RzLiAgVGhl
IEdOVSBwcm9qZWN0IGVuY291cmFnZXMgcGVvcGxlIHRvIHJlYWQgdGhlIHNvdXJjZXMNCj4g
YWZ0ZXIgYWxsLg0KDQpJIGRvIG5vdCBzZWUgaG93IHRoZSBmb3JtZXIgZm9sbG93cyBmcm9t
IHRoZSBsYXR0ZXIsIEkgd291bGQgZXhwZWN0IHRoZSANCm9wcG9zaXRlLiAgR05VIHByb2pl
Y3QgZW5jb3VyYWdlcyByZWFkaW5nIHNvdXJjZSBjb2RlLCB3ZSBwdXQgdXNlZnVsIA0KaW5m
b3JtYXRpb24gaW4gdGhlIHNvdXJjZSBjb2RlIChlLmcuIHJlY29yZHMgb24gd2hhdCBub24t
ZnJlZSBwYXJ0cw0KaGF2ZW4ndCBiZWVuIHJlcGxhY2VkIHlldCkuDQoNCj4+Pj4NCj4+Pj4+
IFRoZXJlIHN0aWxsIGlzIHRoZSBkaWZmZXJlbmNlIHRoYXQgcGhhc2VzIGFyZSBjbGVhcmx5
IGRlbGltaXRlZA0KPj4+Pj4gd2hpbGUgc25pcHBldHMgYXJlIGEgYmxvY2sgb2YgY29kZSB0
aGF0IHNob3VsZG4ndCBnZXQgdG9vDQo+Pj4+PiBsYXJnZS4NCj4+Pj4gU25pcHBldHMgYXJl
IGRlbGltaXRlZCBjbGVhcmx5IGFzIHdlbGwsIHRob3VnaCwgd2l0aCB0aGUNCj4+Pj4gJ3Nu
aXBwZXQnIGZpZWxkPw0KPj4+PiBBbmQgdGhlIGxpbWl0YXRpb25zIG9mIHNuaXBwZXQgbGVu
Z3RoIGFuZCBwaGFzZXMgbGVuZ3RoIGFyZSB0aGUNCj4+Pj4gc2FtZcKgLS0gbm8gbGltaXRz
LCB0aG91Z2ggY29uY2lzZW5lc3MgaXMgYXBwcmVjaWF0ZSBhcyBhbHdheXMuDQo+Pj4gVHJ1
ZSwgYnV0IHBoYXNlcyBjYW4gYmUgbWFkZSB0byBkbyBqdXN0IG9uZSB0aGluZywgd2hlcmVh
cyBzbmlwcGV0cw0KPj4+IGhhdmUgdG8gZml4IGV2ZXJ5dGhpbmcgdGhhdCdzIHdyb25nIGlu
IG1vcmUgb3IgbGVzcyBvbmUgKGJlZ2luDQo+Pj4gLi4uKS4NCj4+PiBUaGlzIGlzIGEgbm90
aWNhYmxlIGRpc3RpbmN0aW9uLj4NCj4+DQo+PiBZb3UgY2FuIGRvIHRoYXQgaW4gc25pcHBl
dHMgdG9vLCB3aXRoIGNvbW1lbnRzOg0KPj4NCj4+IChzbmlwcGV0DQo+PiAgwqDCoCAjfihi
ZWdpbg0KPj4gIMKgwqDCoMKgwqDCoCA7OyBEbyB0aGUgZm9vIHRoaW5nDQo+PiAgwqDCoMKg
wqDCoMKgIChmb28pDQo+PiAgwqDCoMKgwqDCoMKgIChmb28tMiBbLi4uXSkNCj4+ICDCoMKg
wqDCoMKgwqAgWy4uLl0NCj4+ICDCoMKgwqDCoMKgwqAgOzsgRG8gdGhlIGJhciB0aGluZw0K
Pj4gIMKgwqDCoMKgwqDCoCAoYmFyKQ0KPj4gIMKgwqDCoMKgwqDCoCAoYmFyLTIgWy4uLl0p
DQo+PiAgwqDCoMKgwqDCoMKgIFsuLi5dKSkNCj4gWW91IGNhbiwgYnV0IGl0J3Mgc3RpbGwg
d2lzZXIgdG8ganVzdCBrZWVwIHRoZSBzbmlwcGV0IHNob3J0IGVub3VnaCBzbw0KPiB5b3Ug
ZG9uJ3QgaGF2ZSB0by4NCg0KVGhhdCdzIGFsc28gdGhlIGNhc2UgZm9yIHBoYXNlcywgdGhv
dWdoPyAgQ29uY2lzZW5lc3MgaXMgYm90aCBnb29kIGZvciANCnBoYXNlcyBhbmQgc25pcHBl
dHMuDQo+PiAgwqAgSSB3b3VsZCBob3dldmVyIHZlcnkNCj4+PiBtdWNoIHByZWZlciBhIHdv
cmRpbmcgdGhhdCBwb2ludHMgcGVvcGxlIHRvd2FyZCB0aGlzIHByYWN0aWNlDQo+Pj4gZXhp
c3RpbmcsDQo+Pj4gZXZlbiBpZiB0aGV5IGhhdmUgdG8gZ28gbG9vayBpbiB0aGUgY29kZSBm
b3IgZXhhbXBsZXMuDQo+Pj4gQWx0ZXJuYXRpdmVseSwNCj4+PiBhIGZvb3Rub3RlIGZvciB0
aGUgbW9zdCBjb21tb24gY2FzZSAoc2VhcmNoLWlucHV0LWZpbGUgaW5wdXRzDQo+Pj4gImJp
bi9jb21tYW5kIikgb3VnaHQgdG8gc3VmZmljZSBmb3IgdGhlIHRpbWUgYmVpbmcuDQo+Pg0K
Pj4gQXNpZGUgZnJvbSB0aGUgdHlwbydzIGFuZCBhIGZldyByZXBocmFzaW5ncywgSSdtIGRv
bmUgd2l0aCB0aGUNCj4+IGRvY3VtZW50YXRpb24uwqAgSWYgc29tZW9uZSB3YW50cyB0byBl
eHRlbmQgdGhlIHNlY3Rpb24gd2l0aCBzdWNoDQo+PiBpbmZvcm1hdGlvbiwgdGhleSBjYW4g
YWx3YXlzIGRvIHNvIGxhdGVyLg0KPiBJIGhhdmVuJ3Qgc2VlbiBhIHYyIHRob3VnaC4gIEFt
IEkgY29ycmVjdCBpbiBhc3N1bWluZyB0aGF0IG5vbmUgb2YgdGhlDQo+IHBvaW50cyB3ZSBk
aXNjdXNzZWQgaW4gdGhlIGxhc3QgZmV3IG1haWxzIGFyZSBnb2luZyB0byBiZSBhZGRyZXNz
ZWQ/DQoNCkkgZGlkIHNlbnQgYSB2MjogPGh0dHBzOi8vaXNzdWVzLmd1aXguZ251Lm9yZy81
NzU5OCM4Pi4NCkFuZCBtb3N0IHdlcmUgYWRkcmVzc2VkLCBldmVuIGlmIG9ubHkgYXMgbWUg
bm90IGNvbnNpZGVyaW5nIGl0IGFuIGlzc3VlLg0KDQo+Pj4NCj4+PiBJTUhPLCBJIHRoaW5r
IGEgcmVhZGVyIHdobyByZW1lbWJlcnMgdGhlIGd1aWRpbmcgcHJpbmNpcGxlcyBzaG91bGQN
Cj4+PiBzZWUgdGhhdCBpdCBhcHBsaWVzLg0KPj4NCj4+IExpa2VseS4gQnV0IHJlbW92aW5n
IHRoZSBleHBsaWNpdCBtZW50aW9uIG9mIHRoZSBndWlkaW5nIHByaW5jaXBsZQ0KPj4gc3Rp
bGwgbWFrZXMgdGhlIGxvZ2ljYWwgcmVhc29uaW5nIGluY29tcGxldGUsIHJlbWVtYmVyaW5n
IGhhcyBub3RoaW5nDQo+PiB0byBkbyB3aXRoIGl0LsKgIEFzIEkndmUgd3JpdHRlbiBwcmV2
aW91c2x5OiDigJhUaGlzIGhhcyBub3RoaW5nIGRvIGRvDQo+PiB3aXRoIFsuLi5dIGFuZCBy
ZW1lbWJlcmluZywgYnV0IHJhdGhlciB3aXRoIFsuLi5d4oCZLg0KPiBJbiB0aGF0IGNhc2Us
IGxldCBtZSByZXBocmFzZSBteSBjcml0aWNpc206ICJJdCBwYXNzZXMgdGhlIGd1aWRlbGlu
ZXMiDQo+IHNob3VsZCBub3QgYmUgcGFydCBvZiB0aGUgbG9naWNhbCByZWFzb25pbmcgaGVy
ZS4gIE90aGVyd2lzZSwgd2h5IG5vdA0KPiBoYXZlIGEgZ3VpZGVsaW5lIGNoZWNrbGlzdCBh
dCB0aGUgZW5kIG9mIGVhY2ggc3Vic2VjdGlvbiAod2hpY2ggd291bGQNCj4gYmUgc2lsbHks
IG9idmlvdXNseSwgYnV0IHRoYXQncyB0aGUgcG9pbnQpLg0KDQpCZWNhdXNlLCBhcyB5b3Ug
bm90ZSwgdGhhdCdzIGEgc2lsbHkgc3RydWN0dXJlLCBwdXR0aW5nIHRoZSBwcmVtaXNlcyAo
PSANCmd1aWRpbmcgcHJpbmNpcGxlcykgYWZ0ZXIgdGhlIGNvbmNsdXNpb25zICg9IHdvcmtl
ZC1vdXQgY2FzZXMpIGlzIGFuIA0KaWxsb2dpY2FsIHN0cnVjdHVyZSwgd2hlcmVhcyBwdXR0
aW5nIHRoZSBwcmVtaXNlcyBfYmVmb3JlXyB0aGUgDQpjb25jbHVzaW9ucyBpcyBsb2dpY2Fs
DQoNCj4+Pj4NCj4+PiBBbHNvLCB5b3VyIGd1aWRpbmcgcHJpbmNpcGxlcyBhcmUgKHdpdGgg
b25lIGV4Y2VwdGlvbikgcmVhbGx5IGp1c3QNCj4+PiBpbnZhcmlhbnRzIHRoYXQgb3VnaHQg
dG8gaG9sZCBmb3IgdGhlIHNvdXJjZSBmaWVsZCBvZiBhIHBhY2thZ2UuDQo+Pg0KPj4gSSBk
b24ndCBrbm93IGFib3V0IHRoZSBleGNlcHRpb25zIChJIGhhdmVuJ3QgY291bnRlZCB0aGVt
KSwgYnV0IHllcywNCj4+IGluZGVlZC7CoCBJIGRvIG5vdCBzZWUgdGhlIHByb2JsZW0gb2Yg
dGhpcy4NCj4gRm9yIHRoZSByZWNvcmQsIHRoZSBleGNlcHRpb24gaXMgdGhlICJtb3N0IGNv
bnZlbmllbnQiIGJpdCB5b3UndmUNCj4gY29waWVkIGZyb20gbXkgcGF0Y2ggOikNCg0KVGhh
dCBndWlkZWxpbmUgYWN0dWFsbHkgcHJlZGF0ZXMgeW91ciBwYXRjaCwgaXQncyBwYXJ0IG9m
IHRoZSBvcmlnaW5hbCANCnByb3Bvc2FsIChvZiB3aGljaCB0aGUgd29yZGluZyBjaGFuZ2Vk
IGxhdGVyKToNCg0KID4gaHR0cHM6Ly95aGV0aWwub3JnL2d1aXgvYzRjMGEwNzEtMmUwMy1k
NGQ2LTY3MTgtMDU0MjRkMjFkMTQ2QHRlbGVuZXQuYmUvDQo+IFNvbWV0aW1lcywgdGhlcmUg
cmVtYWlucyBtb3JlIHRoYW4gb25lIGFjY2VwdGFibGUgd2F5IHRvIGFjY29tcGxpc2ggdGhl
IA0KPiBnb2FsLiBJbiB0aGF0IGNhc2UsIGNob29zZSB3aGF0ZXZlciBhcHBlYXJzIHRvIGJl
IG1vc3QgY29udmVuaWVudC4NCg0KDQoNCg0KPj4+IEFzIHN1Y2gsIEkgdGhpbmsgaXQgd291
bGQgYmUgZWFzaWVyIHRvIHN0YXRlICJBIHBhY2thZ2UncyBzb3VyY2UNCj4+PiBzaG91bGQN
Cj4+PiBiZSB0aGUgc21hbGxlc3QgY29ycmVzcG9uZGluZyBzb3VyY2UgaW4gdGVybXMgb2Yg
dW5jb21wcmVzc2VkIGZpbGUNCj4+PiBzaXplLsKgIFRoaXMgY29ycmVzcG9uZGluZyBzb3Vy
Y2UgbXVzdCBjb25zaXN0IG9ubHkgb2YgZnJlZSBzb2Z0d2FyZQ0KPj4+IChub3RlIEZyZWUg
U29mdHdhcmUpIGFuZCBzaG91bGQgYnVpbGQgb24gYWxsIHBsYXRmb3JtcyBzdXBwb3J0ZWQg
YnkNCj4+PiB1cHN0cmVhbS4iwqAgTm90ZSBob3cgc21hbGxlc3QgbmF0dXJhbGx5IGltcGxp
ZXMgdW5idW5kbGluZyBidW5kbGVkDQo+Pj4gc291cmNlcy4NCj4+DQo+PiBUaGlzIGNyaXRl
cml1bSBvbiBvdmVybHkgc21hbGwgc291cmNlcy7CoCBPZnRlbiwgYSBwYWNrYWdlJ3Mgc291
cmNlDQo+PiBjb250YWlucyB0aGluZ3MgdGhhdCBpcyBub3QgdXNlZCBmb3IgdGhlIGJ1aWxk
IG9yIG91dHB1dHMgYW5kIGhlbmNlDQo+PiBpcyBub3QgcGFydCBvZiB0aGUgY29ycmVzcG9u
ZGluZyBzb3VyY2UuwqAgRXhhbXBsZXM6DQo+IE5vdGUgInNob3VsZCIgcmF0aGVyIHRoYW4g
InNoYWxsIiBvciAibXVzdCIsIG1lYW5pbmcgdGhhdCBzbGlnaHRseQ0KPiBsYXJnZXIgdGFy
YmFsbHMgYXJlIHN0aWxsIGFjY2VwdGFibGUuDQpPSy4gIFRoZSBjcml0ZXJpdW0gcmVtYWlu
cyBvdmVybHkgdGlnaHQgdGhvdWdoIC0tIGJ5IHRoYXQgY3JpdGVyaXVtLCANCnNsaWdodGx5
IGxhcmdlciB0YXJiYWxscyBhcmUgY29uc2lkZXJlZCB1bmRlc2lyYWJsZSwgZXZlbiB3aGVu
IHRoZXkgaGF2ZSANCnVzZWZ1bCAoYW5kIGhlbmNlLCBkZXNpcmVkKSB0aGluZ3M6DQoNCj4g
DQo+PiAqIHRoZSBzb3VyY2UgY29udGFpbnMgZG9jdW1lbnRhdGlvbiB0aGF0IGNvdWxkIGJl
IGJ1aWx0IGFuZA0KPj4gaW5zdGFsbGVkLA0KPj4gIMKgwqAgYnV0IEd1aXggZG9lc24ndCBk
byBzbyB5ZXQuwqAgLS0+IHNob3VsZCBiZSBrZXB0ICh1bmxlc3Mgbm9uLWZyZWUpDQo+PiAq
IGRvY3VtZW50YXRpb24gdGhhdCBpc24ndCBtZWFudCB0byBiZSBidWlsdCBvciBpbnN0YWxs
ZWQNCj4+ICDCoMKgIChlLmcuIEhBQ0tJTkcsIFBBQ0tBR0VSUywgLi4uKSAtLT4gdXNlZnVs
LCBzaG91bGRuJ3QgYmUgcmVtb3ZlZC4NCj4+ICogLmdpdGlnbm9yZSwgLmdpdGh1YiwgLi4u
IC0tPiBub3RoaW5nIHdyb25nIHdpdGggcmVtb3ZpbmcgdGhvc2UsDQo+PiAgwqDCoCBidXQg
cG9pbnRsZXNzLCBsZXQncyBub3Qgd2FzdGUgb3VyIHRpbWUgd2l0aCBsb29raW5nIGZvciB0
aG9zZQ0KPj4gIMKgwqAgYW5kIHJlbW92aW5nIHRoZW0sIGV2ZW4gdGhvdWdoIGRvaW5nIHNv
IHdvdWxkIG1ha2UgaXQgc21hbGxlci4NCj4+ICogc291cmNlIGZpbGVzIGZvciBwbGF0Zm9y
bXMgdGhlIHVwc3RyZWFtIGRvZXMgbm90IHN1cHBvcnQNCj4+IHlldC9hbnltb3JlDQo+PiAg
wqDCoCAoYnV0IHdpdGggc29tZSB2b2x1bnRlZXIgZWZmb3J0IChlLmcuIGJ1Z2ZpeGVzKSwg
aXQgbWlnaHQgYmVjb21lDQo+PiAgwqDCoCBhIHN1cHBvcnRlZCBzeXN0ZW0gYWdhaW4pDQo+
PiAgwqDCoCAtLT4gcmVtb3ZpbmcgdGhlbSAoZS5nLiBhcyBwYXJ0IG9mIGFuIG92ZXJseS1i
cm9hZA0KPj4gKGRlbGV0ZS1maWxlLXJlY3Vyc2l2ZWx5DQo+PiAidGhpcy1kaXItaGFzLWJ1
bmRsaW5nLWFsYmVpdC1ub3QtYWxsLW9mLWl0LWlzLWJ1bmRsaW5nIikpDQo+PiAgwqDCoMKg
wqDCoMKgIGNhbiBiZSBPSy1pc2gsIGJ1dCByZW1vdmluZyB0aGVtIGZvciAnbWluaW1hbGl0
eScgaXMNCj4+IHBvaW50bGVzcy4NCg0KPiBJIHNlZSB5b3UncmUgbml0cGlja2luZyBmb3Ig
dGhlIHNha2Ugb2YgdGhlIGFyZ3VtZW50LA0KDQpJJ20gbm90LiAgSXQncyBuaXRwaWNraW5n
IGZvciB0aGUgc2FrZSBvZiB0aGUgZm91ciAqIGV4YW1wbGVzIGFib3ZlLg0KDQo+IGJ1dCBu
b25lIG9mIHRoZQ0KPiBleGFtcGxlcyB5b3UgcHJvdmlkZSAoc2FmZSBmb3IgdGhlIGJ1bmRs
aW5nIG9uZSkgYWRkIG11Y2ggY29zdCB0bw0KPiBlaXRoZXIgcGFja2luZyBvciB1bnBhY2tp
bmcuDQoNCk5vdCB0aGUgcG9pbnQsIHRoZSBwb2ludCBpcyB0aGF0IGhhdmluZyB0byB0cmVh
dCB0aG9zZSBleGFtcGxlcyANCnNlcmlvdXNseSAgaXMgYSB3YXN0ZSBvZiB0aW1lIGFuZCBl
dmVuIHNvbWV3aGF0IGhhcm1mdWwgKHJlbW92aW5nIHVzZWZ1bCANCnN0dWZmKS4NCg0KPiBU
aHVzLCBJJ20gcHJldHR5IHN1cmUgd2UgY2FuIGlnbm9yZSB0aGVtDQo+IGZvciBwcmFjdGlj
YWwgcHVycG9zZXMuDQoNCkFzIEkndmUgZXhwbGFpbmVkLCB0aGlzIGd1aWRlbGluZSBpcyBp
bmNvbnNpc3RlbnQgd2l0aCB3aGF0IGlzIGFjdHVhbGx5IA0KcmVjb21tZW5kZWQuICBIZXJl
IGFyZSBzb21lIHByYWN0aWNhbCBwdXJwb3NlczoNCg0KKiBtaW5pbWFsIGRpc3NvbmFuY2Ug
YmV0d2VlbiAnYXBwcmVjaWF0ZWQgYnkgcG9saWN5JyBhbmQgJ2FwcHJlY2lhdGVkIGJ5DQog
ICByZXZpZXdlcnMsIHBhY2thZ2VycywgdXNlcnMnLg0KKiBub3QgaGF2aW5nIHRvIHJldmll
dyBhbmQgYWNjZXB0IHBvaW50bGVzcyBwYXRjaGVzIHRvIEd1aXggZm9yIGRlbGV0aW5nDQog
ICAuZ2l0aHViLCAuZ2l0aWdub3JlLCB1bmluc3RhbGxlZCBkb2N1bWVudGF0aW9uIHRoYXQg
d2VyZSB3cml0dGVuDQogICBmb3IgdGhlIHNha2Ugb2YgbWluaW1hbGl0eQ0KKiBub3QgaGF2
aW5nIHRvIChpbiB0aGUgc2Vuc2Ugb2Y6IGl0IHdvdWxkIGJlIGFwcHJlY2lhdGVkIGlmIHlv
dSdkIGRvDQogICB0aGF0KSB3cml0ZSBzdWNoIHBhdGNoZXMNCg0KICAgVGhhdCBiZWluZyBz
YWlkLCBpZiB5b3UgaGF2ZSBhIGJldHRlcg0KPiBmb3JtdWxhdGlvbiwgcGxlYXNlIGRvIHRl
bGwuDQoNClRoZSBmb3VyIGd1aWRpbmcgcHJpbmNpcGxlcy4NCg0KPiANCj4+DQo+Pj4+PiBJ
IHN0aWxsIGZpbmQgdGhpcyB3b3JkaW5nIHZlcnkgY29uZnVzaW5nLiBQZXJoYXBzICJUbyBh
ZGQgbmV3DQo+Pj4+PiBmdW5jdGlvbmFsaXR5LCBhIHBhdGNoIGlzIGFsbW9zdCBhbHdheXMg
dGhlIGJlc3QgY2hvaWNlLiBGb3INCj4+Pj4+IG9uZSwNCj4+Pj4+IGl0IGlzIGxpa2VseSB0
aGF0IHRoZSBuZXcgZnVuY3Rpb25hbGl0eSByZXF1aXJlcyBjaGFuZ2luZw0KPj4+Pj4gbXVs
dGlwbGUNCj4+Pj4+IGxpbmVzIG9mIHNvdXJjZSBjb2RlLCB3aGljaCBpcyBtb3JlIGNvbnZl
bmllbnQgdG8gZG8gd2l0aCBhDQo+Pj4+PiBwYXRjaA0KPj4+Pj4gdGhhbiB3aXRoIGEgc25p
cHBldC4gRnVydGhlciwgcGF0Y2hlcyBjYW4gYmUgdGFrZW4gZnJvbSBhbmQNCj4+Pj4+IHN1
Ym1pdHRlZCB0byB1cHN0cmVhbXMgbW9yZSBlYXNpbHkuIElmIHlvdXIgcGF0Y2ggaGFzIG5v
dCBiZWVuDQo+Pj4+PiBzdWJtaXR0ZWQgdG8gdXBzdHJlYW0sIGNvbnNpZGVyIGRvaW5nIHNv
LiINCj4+Pj4gSXQgbG9zZXMgc29tZSBpbmZvcm1hdGlvbiAodGhhdCBwYXRjaGVzIGFyZSBw
cmVmZXJyZWQpIGFuZA0KPj4+PiAoYWZ0ZXIgcmUtYWRkaW5nIHRoZSBjb25jbHVzaW9uKSBp
cyBtb3JlIHZlcmJvc2UsIHdoaWNoIGFwcGVhcnMNCj4+Pj4gdG8gYmUgY29uc2lkZXJlZCB2
ZXJ5IGltcG9ydGFudC4NCj4+PiBXaGljaCBjb25jbHVzaW9uIGlzIHRoZXJlIHRvIHJlLWFk
ZD8NCj4+DQo+PiAicGF0Y2hlcyBhcmUgcHJlZmVycmVkIg0KPj4NCj4+ICDCoMKgIFRoZSBj
b25jbHVzaW9uIGlzIGFscmVhZHkgc3RhdGVkDQo+Pj4gaW4gdGhlIGJlZ2lubmluZzogcGF0
Y2hlcyBhcmUgYWxtb3N0IGFsd2F5cyB0aGUgYmVzdCBjaG9pY2UuwqAgVGhlbg0KPj4+IHR3
bw0KPj4+IHJlYXNvbnMgYXMgZm9yIHdoeS7CoCBUaGUgcGFydCB3LnIudC4gdXBzdHJlYW1p
bmcgY2hhbmdlcyBoYXMgYWxzbw0KPj4+IGJlZW4NCj4+PiBhZGRyZXNzZWQuDQo+Pg0KPj4g
V2hpbGUgSSBjb25zaWRlciB0aGF0IHBvbGljaWVzIHNob3VsZCBoYXZlICJiZXN0IGNob2lj
ZXMiIGNvaW5jaWRpbmcNCj4+IHdpdGggInByZWZlcnJlZCIgYW5kIHRoYXQgbm90IGRvaW5n
IHNvIHdvdWxkIGJlIGlsbG9naWNhbCwgcGVvcGxlLA0KPj4gcHJvamVjdHMsIGRlY2lzaW9u
cyAuLi4gYXJlIGZhciBmcm9tIGFsd2F5cyBsb2dpY2FsLg0KPj4NCj4+IEJlY2F1c2Ugb2Yg
dGhpcywgcGVvcGxlIGNhbm5vdCBhc3N1bWUgdGhhdCB0aGUgJ2Jlc3QgY2hvaWNlcycgYXJl
DQo+PiAncHJlZmVycmVkJywgc28gaXQgbmVlZHMgdG8gYmUgbWVudGlvbmVkIGV4cGxpY2l0
bHkgdGhhdCB0aGVzZSAnYmVzdA0KPj4gY2hvaWNlcycgYXJlIGFjdHVhbGx5ICdwcmVmZXJy
ZWQnLg0KPiBJbiB0aGF0IGNhc2UsIHNpbXBseSB3cml0ZSBwcmVmZXJyZWQgY2hvaWNlPw0K
DQpJdCBpcyBhbHJlYWR5IG1lbnRpb25lZCB0aGF0IHRoZXkgYXJlIHByZWZlcnJlZDoNCg0K
PiDigJhBcyBzdWNoLCBwYXRjaGVzIGFyZSBwcmVmZXJyZWTigJkNCg0KQnkgcmVtb3Zpbmcg
dGhlIGluZm9ybWF0aW9uIHRoYXQgJ3BhdGNoZXMgYXJlIHRoZSBtb3N0IGNvbnZlbmllbnQg
DQpjaG9pY2UnIChieSByZXBsYWNpbmcgaXQgd2l0aCDigJhwYXRjaGVzIGFyZSB0aGUgcHJl
ZmVycmVkIGNob2ljZeKAmSksIHRoZSANCmxvZ2ljYWwgc3RydWN0dXJlIGJlY29tZXMgd2Vh
a2VyOyBhIHBhcnQgb2YgdGhlIGV4cGxhbmF0aW9uIG9uIHRoZSDigJh3aHnigJkgDQpiZWNv
bWVzIG1pc3NpbmcuDQoNCj4gDQo+Pj4gSSdtIHVzaW5nIGVudW1lcmF0aW9uIGFzIGEgc3Vw
ZXIgdGVybSBoZXJlLCB3aGljaCBjYW4gYmUNCj4+PiAoKHN1YilzdWIpc2VjdGlvbnMsIGNo
YXB0ZXJzLCBsaXN0IGVsZW1lbnRzLCB3aGF0ZXZlciwgYW5kIG15IGNsYWltDQo+Pj4gaXMg
dGhhdCB3ZSBiYXJlbHkgaGF2ZSBlbm91Z2ggcHJpbmNpcGxlcyB0byBhbGxvdyB0aGUgdXNl
IG9mIGENCj4+PiBwbHVyYWwuDQo+Pg0KPj4gSW4gRW5nbGlzaCwgdGhpbmdzIGFyZSBlaXRo
ZXIgcGx1cmFsIG9yIHNpbmd1bGFyLsKgIEV2ZXJ5dGhpbmcgPj0gMiBpcw0KPj4gcGx1cmFs
LsKgIFRoZXJlIG51bWJlciBvZiBwcmluY2lwbGVzLCBob3dldmVyIHdlIGNvdW50IHRoZW0s
IGlzLCBhdA0KPj4gbGVhc3QsIDIuwqAgQ29uc2VxdWVudGx5LCB0aGUgcHJpbmNpcGxlcyBh
cmUgcGx1cmFsLCBub3Qgc2luZ3VsYXIuDQo+PiBUcmVhdGluZyB0aGUgcHJpbmNpcGxlcyBh
cyBzaW5ndWxhciBpcyBzaW1wbHkgZ3JhbW1hdGljYWxseQ0KPj4gaW5jb3JyZWN0Lg0KPiBD
b3JyZWN0aW9uOiBFdmVyeXRoaW5nIHRoYXQgaXNuJ3QgZXhhY3RseSAxIGlzIHBsdXJhbCBp
biBFbmdsaXNoLA0KPiBpbmNsdWRpbmcgMCwgd2l0aCBwZXJoYXBzIHRoZSBleGNlcHRpb24g
b2YgLTEgYWxzbyB1c2luZyBzaW5ndWxhci4NCj4gDQo+PiBNYXliZSBpdCBpcyBiYXJlbHkg
YWxsb3dlZCB0byBiZSBwbHVyYWwsIGJ1dCBFbmdsaXNoIGdyYW1tYXIgZG9lc24ndA0KPj4g
Y2FyZSBhYm91dCB0aGF0IC0tIGl0IGlzIGRlZmluaXRpdmVseSBkaXNhbGxvd2VkIHRvIGJl
IHNpbmd1bGFyLCBvbmx5DQo+PiBwbHVyYWwgcmVtYWlucy4NCj4gTm90ZSB0aGF0IG15IGFy
Z3VtZW50IGlzbid0IGFib3V0IEVuZ2xpc2ggZ3JhbW1hciwgaXQgdXNlcyBFbmdsaXNoDQo+
IGdyYW1tYXIuDQoNCllvdXIgYXJndW1lbnQgaXMgdGhhdCDigJh0aGVyZSBhcmVuJ3QgYSBz
dWZmaWNpZW50IGFtb3VudCBvZiBwcmluY2lwbGVzIHRvIA0KYWxsb3cgdGhlIHVzZSBvZiBh
IHBsdXJhbOKAmS4gICdQbHVyYWwnIGlzIGEgY29uY2VwdCBvZiBFbmdsaXNoIGdyYW1tYXIu
DQpBcyBzdWNoLCB5b3UgaGF2ZSB3cml0dGVuIGFuIGFyZ3VtZW50IGFib3V0IEVuZ2xpc2gg
Z3JhbW1hci4NCg0KWW91IGFwcGVhciB0byBoYXZlIG1lYW50IHNvbWUgZGlmZmVyZW50IGFy
Z3VtZW50LCBidXQgYWxsIHRoZSBhcmd1bWVudHMgDQpvbiDigJhhcmUgdGhleSBndWlkaW5n
IHByaW5jaXBsZXMgb3Igbm904oCZIEkndmUgcmVhZCBhcmUgYmFzZWQgb24gdGhlIA0KbnVt
YmVyIG9mIHByaW5jaXBsZXMgb3Igb24gd2hhdCAnZ3VpZGluZyBwcmluY2lwbGUnIG1lYW5z
LCB3aGljaCBhcmUgDQppc3N1ZXMgb2YgZ3JhbW1hciBhbmQgdm9jYWJ1bGFyeSByZXNwZWN0
aXZlbHkuDQoNCkknbSBzdGlsbCBub3Qgc2VlaW5nIGhvdyB0aGV5IGFyZW4ndCBndWlkaW5n
IHByaW5jaXBsZXMuICBNYXliZSB5b3UgaGF2ZSANCmEgZGlmZmVyZW50IG1lYW5pbmcgb2Yg
4oCYZ3VpZGluZyBwcmluY2lwbGVz4oCZIGluIG1pbmQ/ICBPciBtYXliZSB5b3Ugd291bGQN
Cmxpa2UgdG8gbmFtZSB0aGVtICdndWlkZWxpbmVzJyBvciAnZ2VuZXJhbCByZWNvbW1lbmRh
dGlvbnMnIGluc3RlYWQuDQoNCj4+PiBBZGRpbmcgdG8gdGhhdCwgbm93IHRoYXQgSSB0aGlu
ayBvZiBpdCwgSSBhbHNvIGRvdWJ0IHRoZWlyDQo+Pj4gdXNlZnVsbmVzcyBpbiBndWlkaW5n
LsKgICJVc2Ugd2hhdGV2ZXIgZmVlbHMgY29udmVuaWVudCwgYnV0IG5vdGUNCj4+PiB0aGF0
IHRoYXQgbWlnaHQgYmUgc3ViamVjdGl2ZSIgaXMgbW9yZSB1c2VmdWwgYXQgdGhlIGVuZCBv
ZiB0aGUNCj4+PiBzZWN0aW9uIHdoZW4gYSB1c2VyIGRpZG4ndCBmaW5kIHdoYXQgdGhleSB3
ZXJlIGxvb2tpbmcgZm9yIHRoYW4gYXQNCj4+PiB0aGUgc3RhcnQuDQo+Pg0KPj4gVGhlIGlu
dHJvZHVjdGlvbiBoYXMgYSBzZXQgb2YgZ3VpZGluZyBwcmluY2lwbGVzLCBmcm9tIHdpdGgg
Y29uY3JldGUNCj4+IGNhc2VzIGFyZSBidWlsdC7CoCBCeSBhZGRpbmcgYW5vdGhlciBwcmlu
Y2lwbGUgYXQgdGhlIGVuZCwgdGhlIGNhc2VzDQo+PiBjYW5ub3QgbWFrZSB1c2Ugb2YgdGhl
ICJ1c2UgWy4uLl0gY29udmVuaWVudCIgcHJpbmNpcGxlLg0KPj4NCj4+IEFkZGl0aW9uYWxs
eSwgbm93IHRoZSB1c2VyIGhhcyB0byBsb29rIGF0IF90d29fIHBsYWNlcyB0byBmaW5kIHRo
ZQ0KPj4gZ3VpZGluZyBwcmluY2lwbGVzIC0tIGF0IHRoZSBiZWdpbm5pbmcsIGFuZCBhdCB0
aGUgZW5kLsKgIFdvcnNlLA0KPj4gdGhlIGJlZ2lubmluZyBkb2VzIG5vdCBoYXZlIGEgY3Jv
c3MtcmVmZXJlbmNlIHRvIHRoZSBlbmQsIHNvIHNpbmNlDQo+PiB0aGUgc2V0IGF0IHRoZSBi
ZWdpbm5pbmcgaXMgcHJlc2VudGVkIGFzIGV4aGF1c3RpdmUsIHRoZSB1c2VyIG1pZ2h0DQo+
PiBub3Qga25vdyB0aGVyZSBpcyBhbm90aGVyIGd1aWRpbmcgcHJpbmNpcGxlLg0KPj4NCj4+
IEFuZCBldmVuIGlmIHRoZXkgZGlkIHJlYWQgdGhyb3VnaCB0aGUgd2hvbGUgc2VjdGlvbiAo
ZXZlbiB0aG91Z2ggdGhleQ0KPj4gc2hvdWxkIG9ubHkgaGF2ZSB0byByZWFkIHRoZSBpbnRy
b2R1Y3Rpb24gYW5kIHRoZSByZWxldmFudCB3b3JrZWQtb3V0DQo+PiBjYXNlKSwgYXNzdW1p
bmcgdGhleSByZWFkIHRocm91Z2ggaXQgaW4gYSBsaW5lYXIgZmFzaGlvbiwgZHVlIHRvIHRo
ZQ0KPj4gbmV3IGd1aWRpbmcgcHJpbmNpcGxlIHRoYXQgd2Fzbid0IGFsbHVkZWQgdG8gYXQg
dGhlIGJlZ2lubmluZywgdGhleQ0KPj4gaGF2ZSB0byByZWRvIHRoZWlyIG1lbnRhbCBtb2Rl
bCBvZiAiTW9kaWZ5aW5nIFNvdXJjZXMiIGFzIHRoaXMNCj4+IHByaW5jaXBsZSBjb3VsZCBp
bnZhbGlkYXRlIHRoaW5ncy4NCj4gVGhpcyBzaG93cyBib3RoIGEgcHJvYmxlbSB3aXRoIHlv
dXIgc3RydWN0dXJlLA0KDQpJJ20gbm90IHNlZWluZyB0aGUgcHJvYmxlbS4gIEhvdyBkb2Vz
IHRoaXMgc2hvdyBhIHByb2JsZW0/DQoNCj4gYnV0IG1vcmUgaW1wb3J0YW50bHksIGENCj4g
ZmFpbHVyZSB0byB1bmRlcnN0YW5kIHdoYXQgSSBtZWFudCB3aGVuIEkgd3JvdGUgInVzZSB3
aGF0ZXZlciBpcw0KPiBjb252ZW5pZW50IiBpbiBteSBvd24gcGF0Y2guICBUaGlzIHByaW5j
aXBsZSAqY2FuKiBvbmx5IHdvcmsgZm9yIGNhc2VzDQo+IGluIHdoaWNoIHRoZXJlIGlzICpu
byBjbGVhcmx5IGVzdGFibGlzaGVkIHByYWN0aWNlKiwgdGh1cyBwdXR0aW5nIGl0IGF0DQo+
IHRoZSBlbmQgKmFmdGVyIGhhdmluZyBlbnVtZXJhdGVkIGFsbCBwcmFjdGljZXMqIGlzIHRo
ZSBsb2dpY2FsIGNob2ljZS4NCj4gV2l0aCB5b3VyIHN0cnVjdHVyZSwgeW91IGhhdmUgdG8g
YmVuZCBpdCBzaWRld2F5cyB0byBzaG9laG9ybiBpdCBpbg0KPiB3aXRoIHRoZSBvdGhlciBw
cmluY2lwbGVzLg0KDQpZb3UgYXBwZWFyIHRvIGhhdmUgbWVhbnQgaXQgYXMgYSBraW5kIG9m
IOKAmGZhbGxiYWNrIHByaW5jaXBsZeKAmSwgaW4gd2hpY2ggDQpjYXNlIHB1dHRpbmcgaXQg
YXQgdGhlIGVuZCBkb2VzIGluZGVlZCBtYWtlIHNlbnNlLg0KDQpJbiBteSBwYXRjaCwgdGhl
IHByaW5jaXBsZSB3b3JrcyBkaWZmZXJlbnRseSwgaXQgaXMgYWxzbyB1c2VkIGZvciANCmV4
cGxhaW5pbmcgYWxyZWFkeSBlc3RhYmxpc2hlZCBwcmFjdGljZXMsIGZvciB0aGUgY2FzZXMg
d2hlcmUgdGhlcmUgYXJlIA0KbXVsdGlwbGUgdGVjaG5pY2FsbHkgYWxsb3dlZCBwcmluY2lw
bGVzIGJ1dCBzdGlsbCBvZnRlbiBhIHNpbmdsZSANCl9yZWNvbW1lbmRlZF8gcHJpbmNpcGxl
LiAgRS5nLjoNCg0KPiBVc3VhbGx5LCBhIGJ1ZyBmaXggY29tZXMgaW4gdGhlIGZvcm0gb2Yg
YSBwYXRjaCBjb3BpZWQgZnJvbSB1cHN0cmVhbSBvcg0KPiBhbm90aGVyIGRpc3RyaWJ1dGlv
bi4gIEluIHRoYXQgY2FzZSwgc2ltcGx5IGFkZGluZyB0aGUgcGF0Y2ggdG8gdGhlDQo+IEBj
b2Rle3BhdGNoZXN9IGZpZWxkIGlzIHRoZSBtb3N0IGNvbnZlbmllbnQgYW5kIHVzdWFsbHkg
ZG9lcyBub3QgY2F1c2UNCj4gYW55IHByb2JsZW1zOyB0aGVyZSBpcyBubyBuZWVkIHRvIHJl
d3JpdGUgaXQgYXMgYSBzbmlwcGV0IG9yIGEgcGhhc2UuDQo+IA0KPiBJZiBubyByZWFkeS1t
YWRlIHBhdGNoIGFscmVhZHkgZXhpc3RzLCB0aGVuIC4uLl0NCg0KYW5kDQoNCj4gVG8gYWRk
IG5ldyBmdW5jdGlvbmFsaXR5LCBhIHBhdGNoIGlzIGFsbW9zdCBhbHdheXMgdGhlIG1vc3Qg
Y29udmVuaWVudA0KPiBjaG9pY2Ugb2YgdGhlIHRocmVlIA0KDQouDQoNClRvIGdvIGZyb20g
dGhlIHByaW5jaXBsZSBhcyB1c2VkIGluIHlvdXIgcGF0Y2ggdG8gdGhlIHByaW5jaXBsZSBh
cyB1c2VkIA0KaW4gbXkgcGF0Y2gsIHBlcmhhcHMgaW4gdGhlIHByb2Nlc3MgaXQgaXMgYmVu
dCBzaWRld2F5cyBhbmQgc2hvZWhvcm5lZC4NCkJ1dCBhZnRlciBhbGwgdGhlIGJlbmRpbmcg
YW5kIHNob2Vob3JuaW5nLCBpdCBzZWVtcyB0byBmaXQgd2VsbCBub3cgaW4gDQp0aGUgYmVn
aW5uaW5nIChhbmQgbm90IHdlbGwgYXQgYWxsIHRoZSBlbmQpLCBzbyBJJ20gbm90IHNlZWlu
ZyBhbnkgDQpwcm9ibGVtcyBoZXJlLg0KDQo+IA0KPj4+IEF0IHRoZSByaXNrIG9mIHJlc3Bv
bmRpbmcgam9raW5nbHkgdG8gd2hhdCB3YXMgbWVhbnQgc2VyaW91czogSQ0KPj4+IGRpZG4n
dCBrbm93IHdlIHN1ZGRlbmx5IGdhaW5lZCAyMCBndWlkaW5nIHByaW5jaXBsZXMuDQo+Pg0K
Pj4gMjUgbGluZXMgYXJlIGZvciB0aGUgZ3VpZGluZyBwcmluY2lwbGVzIChzb21ldGltZXMg
cmVmZXJyaW5nIHRvIGENCj4+IHByaW5jaXBsZSBvZiBlbHNld2hlcmUgaW4gR3VpeCwgc29t
ZXRpbWVzIGEgbmV3IHByaW5jaXBsZSBmb3INCj4+ICJNb2RpZnlpbmcgU291cmNlcyIpLsKg
IFlvdSBwcm9wb3NlZCB0byAnY2FjaGUnIHRoZW0gc29tZWhvdy7CoCBJbg0KPj4gR3VpbGUs
IHRvIGNhY2hlIHNvbWV0aGluZywgeW91IGNhbiB1c2UgJ2RlbGF5L2ZvcmNlJy7CoCBCdXQg
dGhpcw0KPj4gaW5jcmVhc2VzIHRoZSBhbW91bnQgb2YgY29kZSAoZHVlIHRvIHRoZSBhZGRp
dGlvbmFsIHVzZSBvZiAnZGVsYXknKSwNCj4+IGluc3RlYWQgb2YgZGVjcmVhc2luZy4NCj4+
DQo+PiBUaGUgZG9jdW1lbnRhdGlvbiBlcXVpdmFsZW50ICh3aGF0ZXZlciB0aGF0IG1pZ2h0
IGJlLCBJIGFtIG5vdCBzZWVpbmcNCj4+IG9uZSBteXNlbGYpIHdvdWxkIHRoZW4gYWxzbyBi
ZSBhdCBsZWFzdCBhcyBsb25nLCBtYXliZSBldmVuIGEgbGl0dGxlDQo+PiBsb25nZXIgZHVl
IHRvIHRoZSB1c2Ugb2YgJ2RlbGF5Jy4NCj4gT2theSwgc28gSSBkaWQgbWlzdW5kZXJzdGFu
ZCB0aG9zZSAyNSBsaW5lcyBhcyAyNSBsaW5lcyB3aXRoaW4gdGhlIHRleHQNCj4gY2FsbGlu
ZyBiYWNrIHRvIHRob3NlIGd1aWRpbmcgcHJpbmNpcGxlcyByYXRoZXIgdGhhbiAyNSBsaW5l
cyBmb3IgdGhlDQo+IGd1aWRpbmcgcHJpbmNpcGxlcyB0aGVtc2VsdmVzLiAgU3RpbGwsIDI1
IGxpbmVzIGFyZSBhIGxpdHRsZSBtdWNoLA0KPiBlc3BlY2lhbGx5IGdpdmVuIHRoYXQgdGhl
IGJ1bGsgb2YgaXQgZXhwbGFpbnMgdGhlIHNlbWFudGljcyBvZiB0aGUNCj4gcGFja2FnZXMn
IHNvdXJjZSBmaWVsZC4NCg0KSSB0aGluayB3ZSdsbCBoYXZlIHRvIGFncmVlIHRvIGRpc2Fn
cmVlIG9uIHRoYXQuDQoNCj4gDQo+Pj4+IEkgc3VwcG9zZSB0YWJsZSBpdGVtcyBtaWdodCB0
YWtlIHR3byBsZXNzIGxpbmUgb3Igc28gbGVzcyB0aGFuDQo+Pj4+IHN1YnN1YnNlY3Rpb25z
LCBidXQgSSBkb24ndCB0aGluayB0aGF0J3Mgc3VmZmljaWVudCByZWFzb24gdG8NCj4+Pj4g
c3RlcCBhd2F5IGZyb20gYSBuaWNlIHNlY3Rpb24gc3RydWN0dXJlLg0KPj4+IEFub3RoZXIg
cmVhc29uIGlzIHRoYXQgeW91IGNhbiBlbmQgYSB0YWJsZSBpbiB0aGUgbWlkZGxlIG9mIGEN
Cj4+PiBzZWN0aW9uLCB3aGljaCB5b3UgY2FuJ3QgZG8gd2l0aCBzdWJzZWN0aW9ucy7CoCBI
ZW5jZSB3aHkgSSdtIGFibGUNCj4+PiB0byBwdXQgYSByZW1hcmsgYXQgdGhlIGJvdHRvbSwg
d2hpY2ggeW91IGhhdmUgdG8gY2x1bXNpbHkgZml0IGludG8NCj4+PiB0aGUgdG9wLg0KPj4N
Cj4+IEkgY2FuLCBpbmRlZWQsIG5vdCBwdXQgdGhlICdjb252ZW5pZW5jZSBwcmluY2lwbGUn
IGF0IHRoZSBib3R0b20sDQo+PiBleGNlcHQgcGVyaGFwcyBieSBhZGRpbmcgYSBuZXcgc3Vi
c3Vic2VjdGlvbiwgYW5kIGZvciB0YWJsZXMgYWRkaW5nDQo+PiBzdWNoIGEgcmVtYXJrIGF0
IHRoZSBib3R0b20gaXMgaW5kZWVkIG1vcmUgY29udmVuaWVudC4NCj4+DQo+PiBIb3dldmVy
LCBJIGRvbid0IHNlZSB0aGUgJ2hhdmUgdG8gY2x1bXNpbHknIGhlcmUgLS0gYXMgZXhwbGFp
bmVkDQo+PiBlbHNld2hlcmUsIEkgYmVsaWV2ZSB0aGF0IHRoZSAnY29udmVuaWVuY2UgcHJp
bmNpcGxlJyBzaG91bGRuJ3QgYmUNCj4+IHNlcGFyYXRlZCBmcm9tIHRoZSBvdGhlciBwcmlu
Y2lwbGVzIGFuZCB0aGF0IGl0IGZpdHMgbmljZWx5IG5leHQgdG8NCj4+IHRoZSB0aGUgcHJp
bmNpcGxlcyAtLS0gdGhlcmUgaXMgbm8gJ2hhdmUgdG8nLCBiZWNhdXNlIEkgY2hvb3NlIGZv
cg0KPj4gdGhpcywgYW5kIEkgYW0gbm90IHNlZWluZyBhbnkgJ2NsdW1zaW5lc3MnIGhlcmUu
DQo+IEkgdGhpbmsgd2UnZCBoYXZlIHRvIGRlYmF0ZSBjaG9pY2UgdnMuIGZvcmNlIGhlcmUg
d2hpY2ggd291bGQgYmUgYQ0KPiByYXRoZXIgbG9uZyBhc2lkZSwgYnV0IHRvIG1ha2UgbXkg
YXJndW1lbnQgc2hvcnQsIHlvdXIgY2hvaWNlIG9mIGhvdyB0bw0KPiBzdHJ1Y3R1cmUgdGhp
cyBzZWN0aW9uICh0YWJsZSB2cyBzdWJzZWN0aW9ucykgZGlyZWN0bHkgaW5mbHVlbmNlcyB5
b3VyDQo+ICJjaG9pY2UiIHdoZXJlIHRvIHBsYWNlIHBhcnRpY3VsYXIgaW5mb3JtYXRpb24N
Cg0KU3VyZS4NCg0KPiBpbiBhIHdheSB0aGF0IG1pZ2h0DQo+IGluaGliaXQgbmF0dXJhbCBp
bmZvcm1hdGlvbiBmbG93Lg0KDQpJJ20gbm90IHNlZWluZyBpdC4gIEFzIEkndmUgZXhwbGFp
bmVkIHByZXZpb3VzbHksIHB1dHRpbmcgdGhlIHByZW1pc2VzIA0KKD0gZ3VpZGluZyBwcmlu
Y2lwbGVzKSBiZWZvcmUgdGhlIGNvbmNsdXNpb25zICg9IHdvcmtlZCBvdXQgY2FzZXMgLyAN
CnNvbHV0aW9ucykgaXMgYSBsb2dpY2FsIChoZW5jZSwgbmF0dXJhbCkgaW5mb3JtYXRpb24g
ZmxvdywgYW5kIA0KaW50cm9kdWNpbmcgdGhlbSBvbi10aGUtd2F5IG9yIGltcGxpY2l0bHkg
aXMgYWQtaG9jICh1bm5hdHVyYWwpLg0KPj4+PiBUaGUgcGF0Y2ggZG9lcyB0aGlzLCBjdXJy
ZW50bHkuwqAgSXQgYWxyZWFkeSBwcm9wb3NlcyBhIG51bWJlciBvZg0KPj4+PiBoYW1tZXJz
IChwYXRjaGVzLCBzbmlwcGV0cyBhbmQgcGhhc2VzKSBhbmQgcHVycG9zZXMgKGFkZGluZyBu
ZXcNCj4+Pj4gZnVuY3Rpb25hbGl0eSwgZml4aW5nIHRlY2huaWNhbCBpc3N1ZXMsIHVuYnVu
ZGxpbmcsIC4uLikuDQo+Pj4+IEFsc28sIHRoZSBzY2VuYXJpbyAib2ggbm8sIGhvd2V2ZXIg
d2lsbCBJIHB1dCB0aGlzIG5haWwgaW50byBhDQo+Pj4+IHdhbGwiDQo+Pj4+IGFjdHVhbGx5
IGhhcHBlbmVkIC0tIHNlZSB0aGUgU2hlcGhlcmQgZGlzY3Vzc2lvbiwgd2hlcmUgdGhlcmUg
d2FzDQo+Pj4+IGEgbG90IG9mIGRpc2FncmVlbWVudCBvbiBob3cgbmFpbHMgKD0gc21hbGwg
d29yay1hcm91bmQgaW4gdGhlDQo+Pj4+IE1ha2VmaWxlKSBzaG91bGQgYmUgcHV0IGluIHdh
bGxzICg9IHBhdGNoZXMsIHNuaXBwZXQsIHBoYXNlPykuDQo+Pj4+IEl0DQo+Pj4+IHdhcyB0
aGUgd2hvbGXCoHJlYXNvbiB0byBzdGFydCB3cml0aW5nIGEgZG9jdW1lbnRhdGlvbiBwYXRj
aC4NCj4+PiBZb3UgbWlnaHQgd2FudCB0byBhZGQgYSBsaW5rIGhlcmUgaWYgaXQgc3VwcG9y
dHMgeW91ciBhcmd1bWVudCwgYnV0DQo+Pj4gd2l0aG91dCBsb29raW5nIGF0IHRoZSBkaXNj
dXNzaW9uIHRoaXMgcmF0aGVyIHNvdW5kcyBsaWtlICJvaCBubywgSQ0KPj4+IGhhdmUgdGhy
ZWUgaGFtbWVycywgd2hpY2ggb25lIGRvIEkgcGljaz8iIOKAkyB3aGljaCwgZmFpciBlbm91
Z2gsIGlzDQo+Pj4gc3RpbGwgYSBwcm9ibGVtLCBidXQgb25lIHRoYXQgbmVpdGhlciBvZiBv
dXIgcGF0Y2hlcyB3b3VsZCBjYXVzZQ0KPj4+IGltaG8uDQo+Pg0KPj4gQXMgSSB0aGluayBJ
J3ZlIHdyaXR0ZW4gcHJldmlvdXNseSwgdGhlIHdob2xlIHBvaW50IHdhcyB0byBzb2x2ZSB0
aGF0DQo+PiBwcm9ibGVtLiBGb3IgdGhlIGRpc2N1c3Npb24sIHNlZToNCj4+DQo+PiAqIGh0
dHBzOi8vaXNzdWVzLmd1aXguZ251Lm9yZy81NDIxNg0KPj4gKg0KPj4gaHR0cHM6Ly95aGV0
aWwub3JnL2d1aXgvYzRjMGEwNzEtMmUwMy1kNGQ2LTY3MTgtMDU0MjRkMjFkMTQ2QHRlbGVu
ZXQuYmUvDQo+PiAqDQo+PiBodHRwczovL3loZXRpbC5vcmcvZ3VpeC1kZXZlbC84NGUxM2Vm
N2Q0MzcwNjJkZjVjY2E1MWExMmU2ZGE1NDkyOWUwMTc2LmNhbWVsQHRlbGVuZXQuYmUvDQo+
Pg0KPj4gTm90IHNvbHZpbmcgdGhlIHByb2JsZW0gZGVmZWF0cyB0aGUgd2hvbGUgcG9pbnQs
IGFzIHRoZSBwdXJwb3NlIGlzIHRvDQo+PiBzb2x2ZSB0aGF0IHByb2JsZW0uDQo+IEkgdGhp
bmsgd2UgbWlnaHQgYmUgZGlzYWdyZWVpbmcgYWJvdXQgd2hhdCBjb25zdGl0dXRlcyAic29s
dmluZyB0aGUNCj4gcHJvYmxlbSIgaGVyZS4gIENvcnJlY3QgbWUgaWYgSSdtIHdyb25nLCBi
dXQgdG8gbWUgaXQgc2VlbXMgYW55DQo+IHNjZW5hcmlvIHRoYXQgaXMgbm90IGNvdmVyZWQg
Ynkgd2hhdGV2ZXIgcGF0Y2ggaXMgYXBwbGllZCBjb3VudHMgYXMNCj4gIm5vdCBoYXZpbmcg
c29sdmVkIHRoZSBwcm9ibGVtIi4NCg0KSXQgZG9lc24ndCAtLSBJIGNvbnNpZGVyIHRoZSBT
aGVwaGVyZCBwcm9ibGVtIHRvIGJlIHNvbHZlZCBieSBteSBwYXRjaCANCihhbGJlaXQgcmF0
aGVyIHdlYWtseSwgc2VlIGxhdGVyKSwgYW5kIHRoZSB3aWRlciBwcm9ibGVtIG9mIHVuY2xl
YXIgDQpndWlkZWxpbmVzIGFuZCBwb2xpY3kgb24gc25pcHBldC9waGFzZS9wYXRjaCB0byBi
ZSwgcGVyaGFwcyBub3QgcmVhbGx5IA0Kc29sdmVkLCBidXQgc3RpbGwgbXVjaCBpbXByb3Zl
ZCAodGhpcyB0aW1lIG5vdCB3ZWFrbHkpLg0KDQo+IEkgcGVyc29uYWxseSBmaW5kIHRoaXMg
bGluZSBvZg0KPiByZWFzb25pbmcgcXVlc3Rpb25hYmxlLCBhcyB0aGVyZSBhcmUgcGVyZmVj
dGx5IHZhbGlkIHJlYXNvbnMgd2h5DQo+IG11bHRpcGxlIHRvb2xzIGNvdWxkIGFwcGx5Lg0K
DQpTZWUgcHJldmlvdXMgcGFyYWdyYXBoLg0KDQo+IFRha2UgdGhlIHByb2JsZW0gb2YgZW1i
ZWRkaW5nIGEgc3RvcmUgcGF0aC4gIFlvdSBjb3VsZCBmb3IgaW5zdGFuY2UNCj4gcmVwbGFj
ZSBhbGwgb2NjdXJlbmNlcyBvZiAic2giIHdpdGggL2dudS9zdG9yZS8uLi4vYmluL3NoLCBv
ciB5b3UgY291bGQNCj4gZmlyc3QgcmVwbGFjZSB0aGVtIGluIGEgcGF0Y2ggd2l0aCAiQHNo
QCIgYW5kIHRoZW4gcmVwbGFjZSB0aGF0IHdpdGgNCj4gL2dudS9zdG9yZS8uLi4vYmluL3No
LiAgT2YgY291cnNlLCB5b3UgcmFyZWx5IGhhdmUgdG8gZG8gdGhlIGxhdHRlciBhbmQNCj4g
dGhlIGZvcm1lciBpcyBzaW1wbGVyLCBoZW5jZSB3aHkgeW91IHdpbGwgb2Z0ZW4gc2VlIHRo
ZSBmb3JtZXIsIGJ1dA0KPiB0aGF0IGRvZXNuJ3QgbWVhbiB0aGUgbGF0dGVyIGlzIGludmFs
aWQuDQoNCkl0J3MgY29udHJhcnkgdG8gJ0l0IHByZWZlcmFibHkgc2hvdWxkIGFsc28gd29y
ayBvbiBub24tR3VpeCBzeXN0ZW1z4oCZIC0tIA0Kbm90IGludmFsaWQsIGJ1dCBzdGlsbCB1
c3VhbGx5ICgqKSBhZ2FpbnN0IChwcm9wb3NlZCkgcG9saWN5IGJlY2F1c2UgYSANCmRpcmVj
dCBzdWJzdGl0dXRlKiBpcyBhdCB0aGUgc2FtZSB0aW1lIG1vcmUgY29udmVuaWVudCBhbmQg
Zm9sbG93cyBhbGwgDQp0aGUgdGhlIHByaW5jaXBsZXMuDQoNCigqKSBzb21ldGltZXMsIGlu
IGNhc2Ugb2Ygc2hlbGwgc2NyaXB0cywgYSBzdWJzdGl0dXRlKiBpcyBmcmFnaWxlIA0KKHN1
YnN0aXR1dGluZyB0b28gbXVjaCksIGluIHdoaWNoIGNhc2UgYSAic2giIC0+ICJAc2hAIiBi
ZWNvbWVzIG1vcmUgDQpjb252ZW5pZW50IGFuZCBoZW5jZSB0aGUgdmlvbGF0aW9uIG9mIHRo
ZSAnbm9uLUd1aXggc3lzdGVtJyBydWxlcyANCmJlY29tZXMgYWNjZXB0YWJsZS4NCg0KPj4+
Pj4gQW5kIGlmIHRoZXkgZG9uJ3QgZmluZCBhbnl0aGluZywgdGhleSBzZWUgdGhlIGhhbmR5
IGxpdHRsZSBsaW5lDQo+Pj4+PiBhdCB0aGUgYm90dG9tIHNheWluZyAidXNlIHdoYXRldmVy
IHlvdSB0aGluayBpcyBjb252ZW5pZW50Ii4NCj4+Pj4gTm93aGVyZSBkaWQgdGhlIHBhdGNo
IGltcGx5IHRoYXQgdGhlIGxpc3RlZCBjYXNlcyB3ZXJlIGFsbCBjYXNlcy4NCj4+Pj4gSW4g
ZmFjdCwgaW4gdHdvIHBsYWNlcyBpbiB0aGUgaW50cm9kdWN0aW9uIGl0IGlzIGltcGxpZWQg
dGhhdCB0aGUNCj4+Pj4gZXhhbXBsZXMgYXJlIG5vdCBleGhhdXN0aXZlLCBhbmQgdGhhdCB0
aGV5IGNhbiBjaG9vc2UgYWNjb3JkaW5nDQo+Pj4+IHRvIGNvbnZlbmllbmNlwqAgWy4uLl0N
Cj4+PiBFbXBoYXNpcyBvbiBoYW5keSBsaXR0bGUgbGluZSByYXRoZXIgdGhhbiBuZWVkaW5n
IHRvIGJlIHRvbGQgdHdpY2UNCj4+PiAocGFydGljdWxhcmx5IGlmIHBlb3BsZSBoYXZlIG5v
IGlkZWEgd2hhdCB0byBleHBlY3QgZHVlIHRvIG5vdA0KPj4+IGhhdmluZyBsb29rZWQgYXQg
dGhlIHdvcmtlZC1vdXQgY2FzZXMgeWV0KS4NCj4+DQo+PiBUaGV5IGRvbid0IG5lZWQgdG8g
YmUgdG9sZCB0d2ljZS7CoCBBbHNvLCBteSBwYXRjaCBhbHNvIGhhcyB0aGF0IGhhbmR5DQo+
PiBsaXR0bGUgbGluZSAoYWxiZWl0IGRpZmZlcmVudGx5IHdvcmRlZCksIHNlZSB0aGUgJ2d1
aWRpbmcNCj4+IHByaW5jaXBsZXMnLg0KPj4NCj4+IEFsc28sIG9uIHRoZSAnbm8gaWRlYSB3
aGF0IHRvIGV4cGVjdCcgLS0gdGhpcyBpcyBleGFjdGx5IHRoZSBzYW1lIGZvcg0KPj4geW91
ciBwYXRjaCB0b28/wqAgSW4gYm90aCBwYXRjaGVzLCBpZiB0aGUgdXNlciBvbmx5IHJlYWRz
IHRoZQ0KPj4gaW50cm9kdWN0aW9uIGFuZCBjb25jbHVzaW9uIChpZiBhbnkpIGFuZCBkb2Vz
bid0IHJlYWQgdGhlIGFjdHVhbA0KPj4gKHJlbGV2YW50IGV4YW1wbGVzKS8oZXhwbGFuYXRp
b24gb2YgcGF0Y2hlcywgc25pcHBldHMsIHBoYXNlcyksIHRoZW4NCj4+IHRoYXQncyB0aGVp
ciBwcm9ibGVtLg0KPiBJIGRvIHRoaW5rIGEgdGFibGUgaW4gdGhlIG1pZGRsZSBvZiB0aGUg
c2VjdGlvbiBpcyBoYXJkIHRvIGlnbm9yZSwNCg0KSSB0aGluayBzbyB0b28sIGhlbmNlIG15
IHByZXZpb3VzIHJlc3BvbnNlLg0KDQo+IGJ1dCBzdXBwb3NlIGZvciB0aGUgc2FrZSBvZiBh
cmd1bWVudCB0aGF0IHRoZXkgZG8sIFsuLi5dDQoNCkdpdmVuIHRoaXMgcmVzcG9uc2UsIEkg
YXNzdW1lIEkndmUgbWlzaW50ZXJwcmV0ZWQgd2hhdCB5b3UgbWVhbnQgd2l0aCANCuKAmG5v
dCBoYXZpbmcgbG9va2VkIGF0IHRoZSB3b3JrZWQtb3V0IGNhc2VzIHlldOKAmS4NCg0KPj4+
Pg0KPj4+Pj4gSSBhbHNvIGV4cGFuZCBhIGxpdHRsZSBvbiB0aGUgYmVuZWZpdHMgYW5kIGRy
YXdiYWNrcyBvZg0KPj4+Pj4gdGhlc2UgYXBwcm9hY2hlcyBhcyB5b3Ugd291bGQgd2hlbiBk
ZXNjcmliaW5nIGRlc2lnbiBwYXR0ZXJucy4NCj4+Pj4gVGhpcyBpcyBhbHNvIGRvbmUgaW4g
bXkgcGF0Y2guIFsuLi5dDQo+Pj4gVGhpcyBpcyBub3QgYWJvdXQgdGhlIGNvbnRhaW5lZCBp
bmZvcm1hdGlvbiwgYnV0IHRoZSBzdHJ1Y3R1cmUgb2YNCj4+PiB0aGUgY29udGFpbmVkIGlu
Zm9ybWF0aW9uLg0KPj4+DQo+Pj4gTXkgc29sdXRpb24tPnByb2JsZW0gc3R5bGUgZm9sbG93
cyByb3VnaGx5IHRoaXMgc3R5bGU6DQo+Pj4gMS4gc29sdXRpb24NCj4+PiAyLiBwcm9ibGVt
cyBpdCBpcyBrbm93biB0byBzb2x2ZQ0KPj4+IDMuIGhvdyB0byB1c2UNCj4+PiA0LiBwcm9w
ZXJ0aWVzLCBjYXZlYXRzLCBldGMuDQo+Pj4NCj4+PiBZb3VyIHByb2JsZW0tPnNvbHV0aW9u
IHN0eWxlIHJvdWdobHkgaGFzIHRoZSBmb2xsb3dpbmc6DQo+Pj4gMS4gcHJvYmxlbQ0KPj4+
IDIuIChzZXQgb2YpIHNvbHV0aW9uKHMpDQo+Pj4gMy4gaWYgbW9yZSB0aGFuIG9uZSBzb2x1
dGlvbiwgbWF5YmUgYSBoZWxwIHRvIHNlbGVjdA0KPj4NCj4+IEFsc28sIGluIG5vIHBhcnRp
Y3VsYXIgb3JkZXINCj4+DQo+PiAgwqDCoCA0LjogaG93IHRvIHVzZQ0KPj4gIMKgwqAgNS46
IGV4cGxhbmF0aW9uIHdoeSBpdCBpcyBwcmVmZXJyZWQgKHByb3BlcnRpZXMsIGNhdmVhdHM/
KQ0KPiBObyBwYXJ0aWN1bGFyIG9yZGVyIGlzIHByb2JsZW1hdGljLA0KDQpJJ20gbm90IHNl
ZWluZyB3aHkuDQoNCiAgYnV0IG1vcmUgaW1wb3J0YW50bHkgaWYgYQ0KPiB0ZWNobm9sb2d5
IGFwcGVhcnMgbW9yZSB0aGFuIG9uY2UgKGd1YXJhbnRlZWQgYnkgdGhlIHBpZ2VvbmhvbGUN
Cj4gcHJpbmNpcGxlKSwgdGhlbiBlaXRoZXIgaXRzIHByb3BlcnRpZXMgZ2V0IHJlcGVhdGVk
IChub3QgZ29vZCBmb3INCj4gbGVuZ3RoKSBvciBzY2F0dGVyZWQgKG5vdCBnb29kIGZvciB0
aGUgZmxvdyB5b3Ugd2FudCkuICBBZ2FpbiwgYQ0KPiBzdHJ1Y3R1cmFsIHByb2JsZW0uDQoN
ClRoYXQncyBlcXVhbGx5IGFwcGxpZXMgdG8geW91ciBwYXRjaCB0b28sIHRob3VnaD8gIChT
d2l0Y2hpbmcgDQoidGVjaG5vbG9neSIgd2l0aCAicHJvYmxlbSIuKQ0KDQpBbHNvLCBJJ3Zl
IHJlLXJlYWQgbXkgcGF0Y2gsIGFuZCBJIGRpZG4ndCBmaW5kIGFueSByZXBlYXRlZCBwcm9w
ZXJ0aWVzIA0Kb3Igc2NhdHRlcmluZywgZXhjZXB0IGZvciBhIHNpbmdsZSBwcm9wZXJ0eSAo
cGF0Y2hlcyBhcmUgdXBzdHJlYW1hYmxlKToNCg0KID4gRmlyc3QsIHdoZW4gdGhlIGZpeCBp
cyBub3QgR3VpeC1zcGVjaWZpYywgdXBzdHJlYW1pbmcgdGhlIGZpeCBpcw0KID4gc3Ryb25n
bHkgZGVzaXJlZCB0byBhdm9pZCB0aGUgYWRkaXRpb25hbCBtYWludGVuYW5jZSBjb3N0IHRv
IEd1aXguDQogPiBbLi4uXQ0KPiBBcyBzdWNoLCBwYXRjaGVzIGFyZSBwcmVmZXJyZWQuICBI
b3dldmVyLCBhcyB3aXRoIGJ1Zw0KPiBmaXhlcywgdXBzdHJlYW1pbmcgdGhlIG5ldyBmdW5j
dGlvbmFsaXR5IGlzIGRlc2lyZWQuDQoNCkFzIHN1Y2gsIEknbSBub3QgZm9sbG93aW5nIHlv
dXIgcG9pbnQgaGVyZS4NCg0KPj4+IFRoaXMgbWFrZXMgaXQgc28gdGhhdCBwZW9wbGUgbWln
aHQgaGF2ZSB0byBnbyB0byBhIGRpZmZlcmVudA0KPj4+IHN1YnNlY3Rpb24gdGhhbiB0aGUg
b25lIHRoZXkgcmVhZCBmb3IgdGhlaXIgc29sdXRpb24gdG8gZmluZCBvdXQNCj4+PiBhYm91
dCBwb3RlbnRpYWwgY2F2ZWF0cywgZS5nLiBub3QgZW1iZWRkaW5nIHN0b3JlIHBhdGhzIGlu
IGENCj4+PiBzbmlwcGV0Lg0KPj4NCj4+IEkgYXNzdW1lIHRoZWlyIHByb2JsZW0gd2FzICJY
IGRvZXNuJ3QgZmluZCBZIi7CoCBUaGlzIGJlaW5nIGENCj4+IHRlY2huaWNhbCBpc3N1ZSwg
dGhleSBnbyB0byAiRml4aW5nIHRlY2huaWNhbCBpc3N1ZXMiLsKgIEluIHRoYXQNCj4+IHN1
YnN1YnNlY3Rpb24sICB0aGVyZSBhcmUgdGhlIHdvcmRzOg0KPj4NCj4+PiBTZWNvbmRseSwg
aWYgdGhlIGZpeCBvZiBhIHRlY2huaWNhbCBpc3N1ZSBlbWJlZHMgYSBzdG9yZSBmaWxlIG5h
bWUsDQo+Pj4gdGhlbiBpdCBoYXMgdG8gYmUgYSBwaGFzZS7CoCBPdGhlcndpc2UsIGlmIHRo
ZSBzdG9yZSBmaWxlIG5hbWUgd2VyZQ0KPj4+IGVtYmVkZGVkIGluIHRoZSBzb3VyY2UsIHRo
ZSByZXN1bHQgb2YgQGNvbW1hbmR7Z3VpeCBidWlsZCAtLXNvdXJjZX0NCj4+PiB3b3VsZCBi
ZSB1bnVzYWJsZSBvbiBub24tR3VpeCBzeXN0ZW1zIGFuZCBhbHNvIGxpa2VseSB1bnVzYWJs
ZSBvbg0KPj4+IEd1aXggc3lzdGVtcyBvZiBhbm90aGVyIGFyY2hpdGVjdHVyZS4NCj4+DQo+
PiBzbyB0aGV5IGFjdHVhbGx5IGRvIGtub3cgb2YgdGhlIGNhdmVhdCAnZG9uJ3QgZW1iZWQg
c3RvcmUgcGF0aHMgaW4gYQ0KPj4gc25pcHBldCwgZG8gaXQgaW4gYSBwaGFzZSBpbnN0ZWFk
JywgYW5kIHRoZXkgZGlkIG5vdCBuZWVkIHRvIGdvIHRvIGENCj4+IGRpZmZlcmVudCBzdWJz
dWJzZWN0aW9uLg0KPiBUeXBpY2FsIGhhcHB5IHBhdGguDQoNCkluZGVlZCwgaXQncyBhIGhh
cHB5IHBhdGghDQoNCj4+Pj4NCj4+Pj4+IFlvdXIgcHJvYmxlbS0+c29sdXRpb24gYXBwcm9h
Y2ggaW5zdGVhZCBsZWF2ZXMgcGVvcGxlIHdvbmRlcmluZw0KPj4+Pj4gd2hlbiB0aGVpciBw
YXJ0aWN1bGFyIHVzZSBjYXNlIGhhcyBub3QgYmVlbiBkZXNjcmliZWQuDQo+Pj4+IFNlZSBt
eSByZXBseSB0byDigJhBbmQgaWYgdGhleSBkb24ndCBmaW5kIGFueXRoaW5nLCB0aGV5IHNl
ZSB0aGUNCj4+Pj4gaGFuZHkgbGl0dGxlIGxpbmUgYXQgdGhlIGJvdHRvbSBzYXlpbmcgInVz
ZSB3aGF0ZXZlciB5b3UgdGhpbmsgaXMNCj4+Pj4gY29udmVuaWVudOKAmS4NCj4+Pj4+IEl0
IGdpdmVzIHRoZW0gYSBzb2x1dGlvbiByYXRoZXIgdGhhbiB0aGUgdG9vbHMgdG8gYnVpbGQN
Cj4+Pj4+IHNvbHV0aW9ucyB3aXRoLg0KPj4+PiBJdCBkb2VzIGdpdmUgdGhlIHRvb2xzOiBz
bmlwcGV0cywgcGF0Y2hlcyBhbmQgcGhhc2VzLg0KPj4+IEFzIGZhciBhcyBJIHJlYWQsIGl0
IGRlc2NyaWJlcyBub25lIG9mIHRob3NlLsKgIEl0IHB1dHMgb3V0IGd1aWRpbmcNCj4+PiBw
cmluY2lwbGVzIGFuZCBzb21lIGFscmVhZHkgd29ya2VkLW91dCBjYXNlcy4NCj4+IEhlcmUg
YXJlIHRoZSBkZXNjcmlwdGlvbnM6DQo+Pg0KPj4+IEd1aXggaGFzIHRyZWUgbWFpbiB3YXlz
IG9mIG1vZGlmeWluZyB0aGUgc291cmNlIGNvZGUgb2YgYSBwYWNrYWdlLA0KPj4+IHRoYXQg
eW91IGFzIGEgcGFja2FnZXIgbWF5IHVzZS7CoCBUaGVzZSBhcmUgcGF0Y2hlcywgc25pcHBl
dHMgYW5kDQo+Pj4gcGhhc2VzDQo+Pg0KPj4gT25jZSB0aGUgdXNlciBrbm93cyBfd2hpY2hf
IG9mIHRoZSB0aHJlZSB0aGV5IHNob3VsZCB1c2UgKGJ5DQo+PiBjb25zdWx0aW5nIHRoZSBm
b2xsb3dpbmcgc3Vic3Vic2VjdGlvbnMpLCB0aGV5IGNhbiB0aGVuIHNlYXJjaCBmb3INCj4+
ICdwYXRjaCcsICdzbmlwcGV0JyBhbmQgJ3BoYXNlcycgaW4gdGhlIG1hbnVhbCBmb3IgbW9y
ZSBpbmZvcm1hdGlvbiwNCj4+IG5vIG5lZWQgdG8gZHVwbGljYXRlIHRoYXQgaW5mb3JtYXRp
b24uDQo+IFBvaW50IHRha2VuLCBidXQgaW1obyBjcm9zcy1yZWZlcmVuY2VzIGFyZSBuaWNl
IGZvciB0aG9zZSB3aG8ganVzdA0KPiBsZWFybmVkICJva2F5LCBJIG5vdyBrbm93IEkgbmVl
ZCB0byBzb2x2ZSBteSB0ZWNobmljYWwgcHJvYmxlbSB3aXRoIGENCj4gcGhhc2UsIGhvdyBk
byBJIGRvIHRoYXQ/Ig0KDQpUaGV5IGFyZSBpbmRlZWQuICBCdXQgSSdtIG5vdCBmb2xsb3dp
bmcgd2hhdCB5b3UgbWVhbiB3aXRoICJCdXQiIGhlcmUuDQpJIGRpZG4ndCBjbGFpbSBhbnl0
aGluZyBhYm91dCBjcm9zcy1yZWZlcmVuY2VzIHRoZXJlPw0KDQpEbyB5b3Ugd2FudCBtZSB0
byBhZGQgYSBmZXcgY3Jvc3MtcmVmZXJlbmNlcyAoZm9yICdwYXRjaCcsICdzbmlwcGV0JyBh
bmQgDQoncGhhc2VzJyk/DQoNCj4+Pj4gQWxzbywgImdpdmluZyB0aGUgdG9vbHMgdG8gYnVp
bGQgc29sdXRpb25zIHdpdGgiIGRvZXMgbm90IGhlbHANCj4+Pj4gd2l0aCB0aGXCoHByb2Js
ZW0gdGhhdCBJIGFpbWVkIHRvIHNvbHZlIC0tIHRoZXJlIHdhcyBkaXNhZ3JlZW1lbnQNCj4+
Pj4gb24gd2hhdCB0aGXCoGFwcHJvcHJpYXRlIHRvb2xzIGFyZSAoc2VlOiBTaGVwaGVyZCks
IHNvIGl0IG5vdCBqdXN0DQo+Pj4+IG5lZWRzIHRvIGdpdmUgdGhlwqB0b29scywgYnV0IGFs
c28gdGhlIHNvbHV0aW9ucy4NCj4+PiBJIGRvbid0IHNlZSBob3cgbXkgcGF0Y2ggbGFja3Mg
dGhpcyBpbmZvcm1hdGlvbiBob3dldmVyLg0KPj4NCj4+IElJVUMsIHRoZSByYXcgaW5mb3Jt
YXRpb24gc2hvdWxkIHVzdWFsbHkgYmUgaW5kZWVkIGFsbCB0aGVyZSwgYnV0IHRoZQ0KPj4g
dXNlciBoYXMgdG8gY29uc3VsdCBfYWxsXyBvZiB0aGUgc2VjdGlvbnMgdG8gZGV0ZXJtaW5l
IHdoaWNoIG9wdGlvbg0KPj4gKHBhdGNoLCBzbmlwcGV0LCBwaGFzZSkgaXMgYXBwcm9wcmlh
dGUsIGhhdmluZyB0byBhc3NlbWJsZSBhbGwgdGhlDQo+PiBpbmZvcm1hdGlvbiBpcyAoYSkg
YSB3YXN0ZSBvZiB0aW1lIGFuZCAoYikgY2FuIGxlYWQgdG8gZGlmZmVyZW50DQo+PiBpbnRl
cnByZXRhdGlvbnMgYW5kIGNvbmNsdXNpb25zIChzZWU6IFNoZXBoZXJkKS4NCj4+DQo+PiBN
b3JlIGNvbmNyZXRlbHksIEkgY2Fubm90IHVzZSB5b3VyIHBhdGNoIHRvIGRlY2lkZSBiZXR3
ZWVuIHBoYXNlcywNCj4+IHNuaXBwZXRzIGFuZCBwYXRjaGVzIGZvciB0aGUgU2hlcGhlcmQg
aXNzdWU6DQo+Pg0KPj4gKiBub25lIG9mIHRocmVlIGFwcGVhciB0byBiZSBmb3JiaWRkZW4g
YnkgeW91ciBkb2N1bWVudGF0aW9uDQo+PiAqIHRoZXJlIGlzIG5vIHJlY29tbWVuZGF0aW9u
IGZvciAncGF0Y2hlcycgKElJUkMgaXQgd2Fzbid0IGFjY2VwdGVkDQo+PiB1cHN0cmVhbSBh
bmQgdGhlcmUgd2FzIG5vIGludGVudCB0byBzdWJtaXQgaXQgdXBzdHJlYW0sIGl0IGJlaW5n
DQo+PiByZWFsbHkgYSBHdWlsZSBidWcsIG5vdCBhIFNoZXBoZXJkIGJ1ZykNCj4+ICogdGhl
cmUgaXMgbm8gcmVjb21tZW5kYXRpb24gZm9yIHNuaXBwZXRzIChpdCdzIGFsbCBmcmVlLCBu
bw0KPj4gYnVuZGxpbmcpDQo+PiAqIGJ1aWxkIHBoYXNlcyBhcmUgJ3RvIGJlIGF2b2lkZWQn
IChidXQgbm90IGZvcmJpZGRlbiksIGFzIGl0DQo+PiByZXN1bHRlZA0KPj4gIMKgwqAgaW4g
b2JzZXJ2YWJseSBkaWZmZXJlbnQgcnVudGltZSBiZWhhdmlvdXIgKGJlaW5nIGEgYnVnIGZp
eCkNCj4+DQo+PiAtLSB0aHJlZSAob3IgYXQgYmVzdCwgdHdvLCBpZiBidWlsZCBwaGFzZXMg
YXJlIGRpc2NvdW50ZWQpIG9wdGlvbnMNCj4+IHJlbWFpbi7CoCBNeXNlbGYsIEkgd291bGQg
dGhlbiBjb25zaWRlciAnc25pcHBldHMnIHRvIGJlIHRoZSBtb3N0DQo+PiBjb252ZW5pZW50
LCBidXQgc29tZSBvdGhlcnMgKHNlZTogU2hlcGhlcmQsIElJUkMpIHdvdWxkIHJlYWxseSB3
YW50IGENCj4+IHBhdGNoIGluc3RlYWQsIGJlY2F1c2UgJ3BhdGNoZXMgY2FuIGJlIHJldmVy
dGVkJyBvciBzb21ldGhpbmcgbGlrZQ0KPj4gdGhhdC4NCj4+DQo+PiBBcyBzdWNoLCB5b3Ug
YXJlIGdpdmluZyB0aGUgdG9vbHMgKHNuaXBwZXRzIC8gcGF0Y2hlcyAvIHBoYXNlcywgc29t
ZQ0KPj4gZG93bnNpZGVzIGFuZCB1cHNpZGVzKSwgYnV0IGRpZmZlcmVudCBwZW9wbGUgY2Fu
IGNvbnN0cnVjdCBkaWZmZXJlbnQNCj4+IHNvbHV0aW9ucyBmcm9tIHRob3NlIHRvb2xzIGV2
ZW4gaW4gdGhlIHNhbWUgc2l0dWF0aW9uLCBsZWFkaW5nIHRvDQo+PiBjb25mbGljdHMuDQo+
Pg0KPj4gSWYgSSB1c2UgbXkgcGF0Y2ggaW5zdGVhZCwgSSBnbyB0byAiZml4aW5nIHRlY2hu
aWNhbCBpc3N1ZXMiLiBUaGlzDQo+PiBzZWN0aW9uIHRlbGxzIG1lIHRvIHVzZSBhIHBhdGNo
IG9yIGEgc25pcHBldC7CoCBBcyB0aGUgZml4IGlzIG5vdA0KPj4gR3VpeC1zcGVjaWZpYywg
aXQgcmVjb21tZW5kcyBhIHBhdGNoIHRvIHNhdmUgdGltZSB3aGVuIHVwc3RyZWFtaW5nLg0K
Pj4gQ29uY2x1c2lvbjogd3JpdGUgYSBwYXRjaC7CoCBJdCB3YXMgYSBHdWlsZSBidWcsIHNv
IHRoZSBmaXggd2FzIGENCj4+IHBhdGNoIHRvIEd1aWxlLsKgIEJ1dCB0aGF0IHdvdWxkIHRh
a2UgdGltZSBhbmQgdXBzdHJlYW0gdG9vayB0aGUNCj4+IHJlc3BvbnNpYmlsaXR5IGZvciBh
IGZpeCwgc28gdGhlICdlZmZpY2llbnQgdGltZSB0aGluZycgZG9lc24ndA0KPj4gcmVhbGx5
IGFwcGx5IGFuZCBhIHNtYWxsIHdvcmstYXJvdW5kIChzZXR0aW5nIG9wdGltaXNhdGlvbiBm
bGFncykNCj4+IHN1ZmZpY2VzLg0KPj4NCj4+IEluIHRoaXMgc2l0dWF0aW9uLCB0aGUgc3Vi
c3Vic2VjdGlvbiBkb2Vzbid0IGNhcmUgYXQgYWxsIGlmIHlvdSBnbw0KPj4gZm9yIGEgc25p
cHBldCwgc28gYXBwbHkgdGhlIGxhc3QgZ3VpZGluZyBwcmluY2lwbGU6IGdvIGZvciB0aGUN
Cj4+IHNpbXBsZXN0IHRoaW5nOiBhIHNuaXBwZXQuIChVbmxlc3MgeW91IGFscmVhZHkgaGF2
ZSBhIHBhdGNoLCB0aGVuIGENCj4+IHBhdGNoIGlzIHNpbXBsZXN0LikNCj4+IERvZXMgc29t
ZW9uZSBlbHNlIGhhdmUgYSBkaWZmZXJlbnQgaWRlYSBvbiB3aGF0J3Mgc2ltcGxlc3Q/wqAg
RG9lc24ndA0KPj4gcmVhbGx5IG1hdHRlciwg4oCYU29tZXRpbWVzIHRoaXMgaXMgc3ViamVj
dGl2ZSwgd2hpY2ggaXMgYWxzbyBmaW5l4oCZLg0KPiBJIGRvIGdldCB0aGUgaW1wcmVzc2lv
biB0aGF0IHRoaXMgcGF0Y2ggc2ltcGx5IGNvZGlmaWVzIHdoYXQgeW91IGZlZWwNCj4gaXMg
cmlnaHQgYmFzZWQgb24gdGhlIHNoZXBoZXJkIHNpdHVhdGlvbg0KDQpUcnVlLCBleGNlcHQg
Zm9yIHRoZSAnc2ltcGx5JywgYXMgSSBhbHNvIGNvbnNpZGVyZWQgc2V2ZXJhbCBvdGhlciAN
CnNpdHVhdGlvbnMgKFJlbW92aW5nIGJ1bmRsZWQgbGlicmFyaWVzLCBSZW1vdmluZyBub24t
ZnJlZSBzb2Z0d2FyZSwgDQpBZGRpbmcgbmV3IGZ1bmN0aW9uYWxpdHkpLiAgSSBkbyBub3Qg
c2VlIHRoZSBwcm9ibGVtIHdpdGggdGhpcyAtLSB0aGUgDQpwcm9wb3NlZCBwb2xpY3kgd2Fz
IGNvbnNpZGVyZWQgd29ya2FibGUgZXZlbiBpZiBzb21lIHdvdWxkIGxpa2UgaXQgdG8gYmUg
DQphIGxpdHRsZSBiaXQgZGlmZmVyZW50LCBhbmQgaWYgb3RoZXJzIGZlZWwgc3Ryb25nbHkg
YWJvdXQgdGhleSBjb3VsZCwgSSANCmRvbid0LCBtYXliZSBzZXQgdXAgYSB2b3RlIHN5c3Rl
bSBvciBzdWNoLg0KDQo+IHJhdGhlciB0aGFuIHRoaW5raW5nIGFib3V0IHRoZSBnZW5lcmFs
IGNhc2UsDQoNClNlZTogc2V2ZXJhbCBvdGhlciBjYXNlcyB0aGF0IHNob3VsZCBjb3ZlciBt
b3N0IHNpdHVhdGlvbnMgZW5jb3VudGVyZWQgDQppbiBwcmFjdGljZSwgYW5kIGZvciB0aGUg
cGFydHMgb2YgdGhlIGdlbmVyYWwgY2FzZSB0aGF0IGFyZW4ndCANCndvcmtlZC1vdXQgeWV0
LCB0aGVyZSBhcmUgdGhlIGd1aWRpbmcgcHJpbmNpcGxlcy4NCg0KPiB3aGljaCBpcyB3aHkg
bXkgcGF0Y2ggbWFrZXMgd2Vha2VyIHN0YXRlbWVudHMgaGVyZS4gIElmDQo+IHRoaXMgaXNz
dWUgY291bGQgaGF2ZSBiZWVuIGF2b2lkZWQgd2l0aCBhICM6bWFrZS1mbGFnLCB3ZSB3b3Vs
ZCBoYXZlDQo+IHVzZWQgdGhhdC4NCj4gDQo+IE1vcmUgaW1wb3J0YW50bHksIEkgZmFpbCB0
byBzZWUgdGhlIHN1cGVyaW9yaXR5IG9mIHlvdXIgcGF0Y2ggaGVyZSA+IElJVUMgbmVpdGhl
ciBwYXRjaCBvZmZlcnMgYSB1bmlxdWUgc29sdXRpb24gdG8gdGhlIHNoZXBoZXJkIHRoaW5n
LCBzbw0KPiB0aGUgcm9vbSBmb3IgZGViYXRlIHJlbWFpbnMNCg0KSW4gbXkgcGF0Y2gsIG11
bHRpcGxlIG9wdGlvbnMgcmVtYWluLCBidXQgdGhlcmUgaXMgbm8gcmVhbCByb29tIGZvciAN
CmRlYmF0ZS4gIE1vcmUgY29uY3JldGVseToNCg0KPiBXaGVuIHRoZXJlIGlzIG1vcmUgdGhh
biBvbmUgd2F5IHRvIGRvIHNvbWV0aGluZywgY2hvb3NlIHdoaWNoZXZlciBtZXRob2QNCj4g
aXMgdGhlIHNpbXBsZXN0LiAgU29tZXRpbWVzIHRoaXMgaXMgc3ViamVjdGl2ZSwgd2hpY2gg
aXMgYWxzbyBmaW5lLg0KPiBXaGF0IG1hdHRlcnMgaXMgdGhhdCB5b3UgdXNlIHRlY2huaXF1
ZXMgdGhhdCBhcmUgY29tbW9uIHdpdGhpbiB0aGUNCj4gY29tbXVuaXR5IChpLmUuLCBwYXR0
ZXJucyB0aGF0IGFwcGVhciB0aHJvdWdob3V0IEBjb2Rle2dudS9wYWNrYWdlcy8uLi59KQ0K
PiBhbmQgYXJlIHRodXMgY2xlYXJseSBsZWdpYmxlIGZvciByZXZpZXdlcnMuDQoNCml0IGlz
IGNvbnNpZGVyZWQgc3ViamVjdGl2ZSwgaGF2aW5nIG11bHRpcGxlIG9wdGlvbnMgaWYgZmlu
ZSEgIFRvIA0KY29ycmVjdCBhIHBhY2thZ2luZyBmb2xsb3dpbmcgdGhlIG90aGVyIG9wdGlv
biAodG8gaGVscCB3aXRoIGZvbGxvd2luZyANCnRoZSBwb2xpY2llcyksIHlvdSBkb24ndCBo
YXZlIHRvIGRlYmF0ZSBvbiB3aGF0J3MgdGhlIHByb3BlciBvcHRpb24gdG8gDQpnZXQgYSBm
aXggaW4sIGFzIGJvdGggYXJlIGNvbnNpZGVyZWQgYWNjZXB0YWJsZS4gIEluIG1hbnkgY2Fz
ZXMsIG5vIG5lZWQgDQpmb3IgZGViYXRlLCBqdXN0IHBpY2sgb25lIGFuZCBtb3ZlIG9uLiAg
KEFsc28gdGhlIGNhc2UgZm9yIHlvdXIgcGF0Y2ggSUlVQy4pDQoNClRoaW5ncyBhcmUgYWxz
byBwaHJhc2VkIHJlY29uY2lsaWF0b3J5LCBlO2cuOg0KDQo+IFRvIG1ha2UgdGhpbmdzIG1v
cmUgY29uY3JldGUgYW5kIHRvIHJlc29sdmUgY29uZmxpY3RzIGJldHdlZW4gdGhlDQo+IHBy
aW5jaXBsZXMsIGEgZmV3IGNhc2VzIGhhdmUgYmVlbiB3b3JrZWQgb3V0Og0KDQpIb3dldmVy
LCBpbiB5b3VyIHBhdGNoLCB0aGVyZSBpcyBtb3JlIG9wcG9ydHVuaXR5IGZvciBjb25mbGlj
dHMuIEUuZy46DQoNCj4gRWFjaCBvbmUgaGFzIGl0cyBzdHJlbmd0aHMgYW5kIGRyYXdiYWNr
cywgYWxvbmcgd2l0aCBpbnRlbmRlZCBhbmRoaXN0b3JpY2FsbHkgZGVyaXZlZCB1c2UgY2Fz
ZXMuDQoNCkJ5IHRoaXMgbGluZSwgYXJndW1lbnRzIGxpa2UgJ1ggd2FzIGhpc3RvcmljYWxs
eSB0aGUgaW50ZW5kZWQgcHVycG9zZSBvZiANClksIHVzaW5nIFkgZm9yIFogaXMgaW5jb3Jy
ZWN0JyBiZWNvbWUgcmVhc29uYWJsZSwgd2hpY2ggbWFrZXMgDQpkaXNhZ3JlZW1lbnRzIG1v
cmUgZGlmZmljdWx0IHRvIHJlc29sdmUgKGFzIHlvdSBrbm93IG5lZWQgdG8gY29uc3VsdCAN
Cmhpc3RvcnkgYW5kIGJlY2F1c2UgaGlzdG9yeSBpcyBmaXhlZCwgc28gbm8gaW1wcm92ZW1l
bnRzIHdvdWxkIGJlIA0KcG9zc2libGUgYW55bW9yZSBpbiBhcmVhcyB3aGVyZSB0aGVyZSBp
cyBhIGhpc3RvcmljYWxseSBpbnRlbmRlZCB1c2UgY2FzZSkuDQoNCj4gWW91IGNvdWxkIGNs
YWltIHRoYXQgbXkgcGF0Y2ggb2ZmZXJzIG1vcmUNCj4gcm9vbSwgd2hpY2ggZmFpciBlbm91
Z2gsIGl0IGRvZXMsIGJ1dCBvbiB0aGUgc2FtZSB0b2tlbiBpdCBhbGxvd3MNCj4gcGVvcGxl
IHRvIHNlZSB0aGF0IHRoZSBndWlkZWxpbmVzIGhhdmUgYmVlbiBmb2xsb3dlZCBhbmQgdGhl
IHBhdGNoIGNhbg0KPiBiZSBhcHBsaWVkLg0KPiANCj4+PiBJbiBwYXJ0aWN1bGFyLCBmb3Ig
cmV2aWV3IHB1cnBvc2VzLCBtaW5lIHNob3VsZCBiZSBlYXNpZXIgdG8gd29yaw0KPj4+IHdp
dGguICBGb3IgaW5zdGFuY2UsIHRoZSByZXZpZXdlciBzZWVzIGEgaGFzaCBlbWJlZGRlZCBp
biBhDQo+Pj4gc25pcHBldCwgc2VlcyBpbiB0aGUgc25pcHBldCBlbnRyeSB0aGF0IHlvdSBz
aG91bGRuJ3QgZG8gdGhhdCwgYW5kDQo+Pj4gY2FuIHRodXMgc2F5ICJub3BlLCBkb24ndCBk
byBhIHNuaXBwZXQgaGVyZSIuDQoNClRoYXQgaXMgYWxzbyB0aGUgY2FzZSBmb3IgcHJvYmxl
bS0+c29sdXRpb24/ICBBICJzaCIgLT4gIyQoZmlsZS1hcHBlbmQgDQpiYXNoLW1pbmltYWwg
Ii9iaW4vc2giKSBzdWJzdGl0dXRpb24gY2FuIGJlIHJlY29nbmlzZWQgb24gc2lnaHQgYXMg
bm90IA0KcG9zc2libHkgYmVpbmcgYW55dGhpbmcgZWxzZSB0aGFuIGEgdGVjaG5pY2FsIGZp
eCwgYW5kIHRoZW4gdGhlIA0Kc3Vic3Vic2VjdGlvbiBvbiB0ZWNobmljYWwgZml4ZXMgbWVu
dGlvbnMgdGhhdCB0aG9zZSBtdXN0IGJlIGRvbmUgaW4gcGhhc2VzLg0KDQpPciwgYW5vdGhl
ciBleHBsYW5hdGlvbjogcmV2aWV3ZXJzIHVzdWFsbHkgaGF2ZSBzZWVuIGEgbG90IG9mIG1v
cmUgDQpwYWNrYWdlcyB0aGFuIGEgbmV3IHBhY2thZ2VyLiAgQmVjYXVzZSBvZiB0aGF0LCBh
bmQgYmVjYXVzZSB0aGV5IGhhdmUgDQpmYW1pbGlhcmlzZWQgdGhlaXJzZWx2ZXMgd2l0aCBw
b2xpY3ksIHRoZXkgaGF2ZSBvdmVyIHRpbWUgYXV0b21hdGljYWxseSANCmJ1aWx0IGEgbWVu
dGFsICdyZXZlcnNlIGluZGV4JyBvZiBzb2x1dGlvbnMtPnByb2JsZW1zLg0KPj4gSSB0aGlu
ayB3ZSBzaG91bGQgb3B0aW1pc2UgZm9yIHBhY2thZ2VycyBiZWZvcmUgcmV2aWV3ZXJzDQo+
IENvZGUgaXMgbW9yZSBvZnRlbiByZWFkIHRoYW4gd3JpdHRlbiwgc28gb3B0aW1pc2luZyBm
b3IgdGhlIHJlYWRlciBpcw0KPiBvcHRpbWl6aW5nIGZvciB0aGUgcGFja2FnZXIgYXMgd2Vs
bC4NCg0KV2hpbGUgYWxsIHJldmlld2VycyBhcmUgcmVhZGVycywgbm90IGFsbCByZWFkZXJz
IGFyZSByZXZpZXdlcnMsIGFuZCANCnJldmlld2luZyB1c3VhbGx5IGhhcHBlbnMgb25seSBv
bmNlLCBtYXliZSB0d2ljZSBwZXIgcGF0Y2guDQoNCj4+PiBSZWdhcmRsZXNzIG9mIHdoaWNo
IHBhdGNoIHdlIHBpY2ssIGl0IHNob3VsZCBub3QgbWFuZGF0ZSBhDQo+Pj4gcGFydGljdWxh
ciBzb2x1dGlvbiBpbiBwb3RlbnRpYWxseSBjb250ZW50aW91cyBjYXNlcywNCj4+DQo+PiBB
Y3R1YWxseSB0aGUgd2hvbGUgcG9pbnQgd2FzIHRvIG1hbmRhdGUgYSBwYXJ0aWN1bGFyIHNv
bHV0aW9uIGZvciB0aGUNCj4+IGNvbnRlbnRpb3VzIGNhc2VzLCBzZWUgU2hlcGhlcmQuDQo+
IEJ1dCBJIGRpc2FncmVlLg0KPiANCj4gTWVtZXMgYXNpZGUsIHBsZWFzZSByZWZyYWluIGZy
b20gdGhlICJJJ20gcmlnaHQsIGRvIHRoaXMiIHN0eWxlICh3aGljaA0KPiBpcyBhbm90aGVy
IHByb2JsZW0gd2l0aCB0aGUgInByb2JsZW0tY2VudHJpYyIgYXBwcm9hY2gpLA0KDQpJcyB0
aGlzIHJlZmVycmluZyB0byB0aGUgc3R5bGUgb2YgdGhlIGRvY3VtZW50YXRpb24gcGF0Y2g/
ICBJZiBzbzogaXQgDQpkb2VzIGV4cGxhaW4gd2h5IHRoZSAiZG8gdGhpcyIgaXMgcmlnaHQs
IHNvIEkgZG9uJ3Qgc2VlIHRoZSBwcm9ibGVtLiAgRG8gDQp5b3UgaGF2ZSBhIHBhcnRpY3Vs
YXIgcG9pbnQgb2YgdGhlIGRvY3VtZW50YXRpb24gaW4gbWluZCB5b3UgY29uc2lkZXIgDQp3
cm9uZyAoKik/DQoNCigqKSBwb2ludHMgSSBrbm93IG9mOg0KKiBrZWVwIGxpc3RzIC8gcmVt
b3ZlIGxpc3RzIChmb3IgdGhlIGZvb3Rub3RlIGFib3V0IG5vdC15ZXQtcG9saWN5IG9uIA0K
cmVtb3ZpbmcgdGhpbmdzIGluIHBhdGNoZXMpDQoqIHRoZSBndWlkaW5nIHByaW5jaXBsZXMg
YXJlbid0IGd1aWRpbmcgcHJpbmNpcGxlcw0KDQo+IGJ1dCByYXRoZXINCj4gZm9jdXMgb24g
d3JpdGluZyBhIHBhdGNoIHRoYXQgbWFrZXMgcmV2aWV3ZXJzIG5vdCBkaXNjYXJkIGEgcGF0
Y2ggZHVlDQo+IHRvIGZvcm1hbGl0aWVzLg0KDQpJIHRoaW5rIHRoZSBwYXRjaCAodjEgYW5k
IHYyKSBzYXRpc2ZpZXMgdGhhdC4NCg0KPiBJZiB0aGUgc2hlcGhlcmQgdGhpbmcgaGFkIG5l
ZWRlZCBhbiB1cHN0cmVhbSBwYXRjaCwNCj4gZXZlbiB3aXRoIGEgc25pcHBldCB0aGF0IHBh
dGNoIGNvdWxkIGhhdmUgZWFzaWx5IGJlZW4gY3JlYXRlZCBieQ0KPiBjb252ZXJ0aW5nIHRo
YXQgc25pcHBldCB0byBhIHNlZCwgc28gbW9yZSB0aW1lIHdhcyB3YXN0ZWQgZGViYXRpbmcg
dGhhbg0KPiBvdmVyd29ya2luZy4NCg0KSSBkbyBub3Qgc2VlIHlvdXIgcG9pbnQgaGVyZSAt
LSAjNTc1OTggaXMgYWJvdXQgZG9jdW1lbnRhdGluZy9tYWtpbmcgDQpwb2xpY3ksIG5vdCAn
c2hvdWxkIHdlIHNwZW50IHRpbWUgb24gY29ycmVjdGluZyB0aGUgc2hlcGhlcmQgcGFja2Fn
ZSB0byANCm1hdGNoIHBvbGljeSAvIGNvbnZpbmNpbmcgdGhlIG90aGVyIHBhcnR5IHRoYXQg
dGhlIHN0YXR1cyBxdW8gbWF0Y2hlcyANCnBvbGljeScuDQoNCj4+PiBhbmQgYWxzbyBwb2lu
dCB0b3dhcmRzIHRoZSByaWdodCBzb2x1dGlvbi7CoCBTZWUgb3VyIGRpc2N1c3Npb25zIG9u
DQo+Pj4gdGhlIGluZGl2aWR1YWwgc29sdXRpb25zIG9uIHBvaW50cyBpbiB3aGljaCBJIGJl
bGlldmUgeW91J3ZlDQo+Pj4gZXJyb3JlZC4NCj4+DQo+PiBUaGVzZSBhcmU6DQo+Pg0KPj4g
KiB0aGUgdHlwbydzDQo+PiAqIGluY2x1ZGluZyAic2tpcHBpbmcgdGVzdHMgaW5kaWNhdGlu
ZyBmYWlsdXJlIHVuZGVyIOKAmEZpeGluZw0KPj4gdGVjaG5pY2FsIGlzc3Vlc+KAmSINCj4+
ICogImRvbid0IG1lbnRpb24gZmlsZSBuYW1lcyBvZiBub24tZnJlZSB0aGluZ3MgaW4gcGF0
Y2hlcyINCj4+DQo+PiBEaWQgSSBtaXNzIGFueT8NCj4gSSdtIHByZXR0eSBzdXJlIHRoZXJl
J3MgYWxzbyBhIGRpc2N1c3Npb24gb24gc3RvcmUgcGF0aCBlbWJlZGRpbmdzIGF0DQo+IHRo
ZSB2ZXJ5IGxlYXN0LiAgRm9yZ2l2ZSBtZSBpZiBJIHRvbyBtaXNzZWQgc29tZXRoaW5nLg0K
VGhlcmUgd2FzIGEgZGlzY3Vzc2lvbiBvbiBzdG9yZSBmaWxlIG5hbWUgZW1iZWRkaW5ncy4g
IFRoZXJlIHdhcyBubyANCm1lbnRpb24gb2YgYW55IGVycm9ycyBpbiB0aGUgZG9jdW1lbnRh
dGlvbiBvZiBzdG9yZSBmaWxlIG5hbWVzLiAgSUlSQywgDQp3ZSBhZ3JlZSBvbiBob3cgc3Rv
cmUgZmlsZSBuYW1lIGVtYmVkZGluZ3MgbXVzdCBiZSBkb25lLiAgVGhlcmUgd2VyZSwgDQpo
b3dldmVyLCBwcm9wb3NhbHMgdG8gZXh0ZW5kIHRoZSBkb2N1bWVudGF0aW9uIHRvIGNvdmVy
IOKAmGhvdyB0byBlbWJlZOKAmSANCmluIG1vcmUgZGV0YWlsIChzdWJzdGl0dXRlKiArIHNl
YXJjaC1pbnB1dC1maWxlIC4uLiksIGJ1dCBubyBlcnJvcnMuDQoNCkdyZWV0aW5ncywNCk1h
eGltZS4NCg==
--------------RneJSr4rW60YFuWvSkivYcO6
Content-Type: application/pgp-keys; name="OpenPGP_0x49E3EE22191725EE.asc"
Content-Disposition: attachment; filename="OpenPGP_0x49E3EE22191725EE.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xjMEX4ch6BYJKwYBBAHaRw8BAQdANPb/d6MrGnGi5HyvODCkBUJPRjiFQcRU5V+m
xvMaAa/NL01heGltZSBEZXZvcyA8bWF4aW1lLmRldm9zQHN0dWRlbnQua3VsZXV2
ZW4uYmU+wpAEExYIADgWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCX4ch6AIbAwUL
CQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRBJ4+4iGRcl7japAQC3opZ2KGWzWmRc
/gIWSu0AAcfMwyinFEEPa/QhUt2CogD/e2RdF4CYAgaRHJJmZ9WU7piKbLZ7llB4
LzgezVDHggzNJU1heGltZSBEZXZvcyA8bWF4aW1lZGV2b3NAdGVsZW5ldC5iZT7C
kAQTFggAOBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJf56ycAhsDBQsJCAcDBRUK
CQgLBRYCAwEAAh4BAheAAAoJEEnj7iIZFyXujpQBAKV1SwDDl4f24rXciDlB9L8W
ycZt30CgbewMSRQk4mvbAP9dFMbVVixYBd6C8cfhR+NsOBGiOJnQABlUmgNuqGFJ
Dc44BF+HIegSCisGAQQBl1UBBQEBB0BOlzIWiJzgobMF6/cqwLaLk7jIcFSZ++c0
k9cCNT6YXwMBCAfCeAQYFggAIBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJfhyHo
AhsMAAoJEEnj7iIZFyXuMr0BAJc8cl5PGvVmVuSQVKjleNl4DK1/XAaPAYPe34AE
fZJPAP9IqLCQhH/FeJanHqBP8gNdGNI2qn8RnnLVfRJgUjZ1BA=3D=3D
=3DOVqp
-----END PGP PUBLIC KEY BLOCK-----

--------------RneJSr4rW60YFuWvSkivYcO6--

--------------A60oN2LySqwFEM12Dd7BpjjC--

--------------b304Y9bejnymBhUvwnTF0ap0
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wnsEABYIACMWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYxuJgAUDAAAAAAAKCRBJ4+4iGRcl7op3
AQCYF8cmXphoV90U1eiSpXMlv1ETCRG9s0Prpbm/bTfHPQEAr76d7Ou/26rqpoEkxxsU+Hb6Ubc9
B3HI+QwSS8wO9g4=
=BW3S
-----END PGP SIGNATURE-----

--------------b304Y9bejnymBhUvwnTF0ap0--

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#57598] [PATCH] doc: Update contribution guidelines on patches, etc.
Resent-From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Fri, 09 Sep 2022 20:10:02 +0000
Resent-Message-ID: <handler.57598.B57598.166275417913070 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 57598
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Maxime Devos <maximedevos@HIDDEN>, 57598 <at> debbugs.gnu.org
Received: via spool by 57598-submit <at> debbugs.gnu.org id=B57598.166275417913070
          (code B ref 57598); Fri, 09 Sep 2022 20:10:02 +0000
Received: (at 57598) by debbugs.gnu.org; 9 Sep 2022 20:09:39 +0000
Received: from localhost ([127.0.0.1]:35600 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oWkJl-0003Oj-I0
	for submit <at> debbugs.gnu.org; Fri, 09 Sep 2022 16:09:38 -0400
Received: from mailrelay.tugraz.at ([129.27.2.202]:25110)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <liliana.prikler@HIDDEN>) id 1oWkJe-0003OU-KJ
 for 57598 <at> debbugs.gnu.org; Fri, 09 Sep 2022 16:09:36 -0400
Received: from kagayaki.fritz.box (85-127-52-93.dsl.dynamic.surfer.at
 [85.127.52.93])
 by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4MPRsW2lFpz3wjx;
 Fri,  9 Sep 2022 22:09:19 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at;
 s=mailrelay; t=1662754159;
 bh=1golxioZAdWYz7RxQ0+HVkei2WDNiGf923wwsuDeG10=;
 h=Subject:From:To:Date:In-Reply-To:References;
 b=se1boxWDEeglFEA/kPQ9t3ETNsicCoXp+wKvry4oqike6AAw/HSYGfzG1ZRhF8alf
 1UF3yFwPfnUgOsGmpEYWfE1KL3kzuij3oZ0a4R+ejpCLFMgrsD+6NwxI1BgrbZUi/k
 CwzTNCPOKPZ5q+IzY0Y+eS+jbtjzgztG+ODcARfM=
Message-ID: <4e167aa3c88bdbf86b65af118967bc3d1aeb26a4.camel@HIDDEN>
From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
Date: Fri, 09 Sep 2022 22:09:18 +0200
In-Reply-To: <e9162363-e67b-956e-6346-6a1a6e529abf@HIDDEN>
References: <20220905160048.18173-1-maximedevos@HIDDEN>
 <0f78953d57d8f66a934baf518b7c9e3247b580fd.camel@HIDDEN>
 <d0a48b72-c62b-cc97-e399-22abc0af182d@HIDDEN>
 <44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN>
 <b33540cb-0c72-6170-34d0-b8df4ab79b8f@HIDDEN>
 <1e707c8e345af7b2fb0353c5f1c0e37d716e3308.camel@HIDDEN>
 <a24e8c5c-a986-3f6f-15a4-03caeb801e6d@HIDDEN>
 <b74c40c57dff2a0ac6eee2a7a2124d8ab2d6314e.camel@HIDDEN>
 <e9162363-e67b-956e-6346-6a1a6e529abf@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.1 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-TUG-Backscatter-control: waObeELIUl4ypBWmcn/8wQ
X-Spam-Scanner: SpamAssassin 3.003001 
X-Spam-Score-relay: -0.4
X-Scanned-By: MIMEDefang 2.74 on 129.27.10.117
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Am Freitag, dem 09.09.2022 um 20:44 +0200 schrieb Maxime Devos:
> GNU project encourages reading source code, we put useful 
> information in the source code (e.g. records on what non-free parts
> haven't been replaced yet).
You mean bundled parts not unbundled, right?  IIUC, there should be no
non-free parts in a free software distribution.

> > You can, but it's still wiser to just keep the snippet short enough
> > so you don't have to.
> 
> That's also the case for phases, though?  Conciseness is both good
> for phases and snippets.
Intentionally or otherwise, you're talking past me.

> > >    I would however very
> > > > much prefer a wording that points people toward this practice
> > > > existing,
> > > > even if they have to go look in the code for examples.
> > > > Alternatively,
> > > > a footnote for the most common case (search-input-file inputs
> > > > "bin/command") ought to suffice for the time being.
> > > 
> > > Aside from the typo's and a few rephrasings, I'm done with the
> > > documentation.  If someone wants to extend the section with such
> > > information, they can always do so later.
> > I haven't seen a v2 though.  Am I correct in assuming that none of
> > the
> > points we discussed in the last few mails are going to be
> > addressed?
> 
> I did sent a v2: <https://issues.guix.gnu.org/57598#8>.
> And most were addressed, even if only as me not considering it an
> issue.
Hmm, that was while I was still composing that message.

> > In that case, let me rephrase my criticism: "It passes the
> > guidelines" should not be part of the logical reasoning here. 
> > Otherwise, why not have a guideline checklist at the end of each
> > subsection (which would be silly, obviously, but that's the point).
> 
> Because, as you note, that's a silly structure, putting the premises
> (= guiding principles) after the conclusions (= worked-out cases) is
> an illogical structure, whereas putting the premises _before_ the 
> conclusions is logical
And yet you're putting a premise after a conclusion here.

> > For the record, the exception is the "most convenient" bit you've
> > copied from my patch :)
> 
> That guideline actually predates your patch, it's part of the
> original proposal (of which the wording changed later):
> 
>  >
> https://yhetil.org/guix/c4c0a071-2e03-d4d6-6718-05424d21d146@HIDDEN/
> > Sometimes, there remains more than one acceptable way to accomplish
> > the goal. In that case, choose whatever appears to be most
> > convenient.
Fair enough.
> 

> > Note "should" rather than "shall" or "must", meaning that slightly
> > larger tarballs are still acceptable.
> OK.  The criterium remains overly tight though -- by that criterium, 
> slightly larger tarballs are considered undesirable, even when they
> have useful (and hence, desired) things:
Point taken, but...

> > 
> > > * the source contains documentation that could be built and
> > > installed,
> > >     but Guix doesn't do so yet.  --> should be kept (unless non-
> > > free)
> > > * documentation that isn't meant to be built or installed
> > >     (e.g. HACKING, PACKAGERS, ...) --> useful, shouldn't be
> > > removed.
> > > * .gitignore, .github, ... --> nothing wrong with removing those,
> > >     but pointless, let's not waste our time with looking for
> > > those
> > >     and removing them, even though doing so would make it
> > > smaller.
> > > * source files for platforms the upstream does not support
> > > yet/anymore
> > >     (but with some volunteer effort (e.g. bugfixes), it might
> > > become
> > >     a supported system again)
> > >     --> removing them (e.g. as part of an overly-broad
> > > (delete-file-recursively
> > > "this-dir-has-bundling-albeit-not-all-of-it-is-bundling"))
> > >         can be OK-ish, but removing them for 'minimality' is
> > > pointless.
> 
> > I see you're nitpicking for the sake of the argument,
> 
> I'm not.  It's nitpicking for the sake of the four * examples above.
> 
> > but none of the
> > examples you provide (safe for the bundling one) add much cost to
> > either packing or unpacking.
> 
> Not the point, the point is that having to treat those examples 
> seriously  is a waste of time and even somewhat harmful (removing
> useful stuff).
> 
> > Thus, I'm pretty sure we can ignore them
> > for practical purposes.
> 
> As I've explained, this guideline is inconsistent with what is
> actually recommended.  Here are some practical purposes:
> 
> * minimal dissonance between 'appreciated by policy' and 'appreciated
> by
>    reviewers, packagers, users'.
> * not having to review and accept pointless patches to Guix for
> deleting
>    .github, .gitignore, uninstalled documentation that were written
>    for the sake of minimality
> * not having to (in the sense of: it would be appreciated if you'd do
>    that) write such patches
> 
>    That being said, if you have a better
> > formulation, please do tell.
> 
> The four guiding principles.
That's an awful lot to write rather than "the package's source should
be the corresponding source minus the bits we don't like".  Ludo’
already commented on the length of my patch (and yes, I'm aware that
both of our patches blow up the section by a factor of like 3 at
minimum), so I don't think you're doing anyone a service here by
expanding something into four guidelines that would take, like, a
simple sentence instead if carefully worded.  Let's take the time to
write the shorter letter, shall we?


> By removing the information that 'patches are the most convenient 
> choice' (by replacing it with ‘patches are the preferred choice’),
> the logical structure becomes weaker; a part of the explanation on
> the ‘why’ becomes missing.
I'm going to sound like a broken record, but conciseness is key:
"Patches are preferred when adding functionality to a package.  They
can more easily be shared with upstreams and are easier to work with
when making multi-line changes.  Next item."

> > > > [W]e barely have enough principles to allow the use of a
> > > > plural.
> Your argument is that ‘there aren't a sufficient amount of principles
> to allow the use of a plural’.  
Don't put words into my mouth.

> 'Plural' is a concept of English grammar.  
The concept of a plural is not unique to English grammar.

> As such, you have written an argument about English grammar.
You're failing to read between the lines and it's getting rather
exhausting.

> You appear to have meant some different argument, but all the
> arguments on ‘are they guiding principles or not’ I've read are based
> on the number of principles or on what 'guiding principle' means,
> which are issues of grammar and vocabulary respectively.
> 
> I'm still not seeing how they aren't guiding principles.  Maybe you
> have a different meaning of ‘guiding principles’ in mind?  Or maybe
> you would like to name them 'guidelines' or 'general recommendations'
> instead.
Call it whatever you want, my point is twofold:
1. By proper counting and simplification, you will have at most two.
2. At least one of those two doesn't feel very "guiding" to me.
Further, I think you're doing a bad job of splitting mandatory and
optional "recommendations" by lumping them together.

> > > 
> > > The introduction has a set of guiding principles, from with
> > > concrete cases are built.  By adding another principle at the
> > > end, the cases cannot make use of the "use [...] convenient"
> > > principle.
> > > 
> > > Additionally, now the user has to look at _two_ places to find
> > > the guiding principles -- at the beginning, and at the end. 
> > > Worse, the beginning does not have a cross-reference to the end,
> > > so since the set at the beginning is presented as exhaustive, the
> > > user might not know there is another guiding principle.
> > > 
> > > And even if they did read through the whole section (even though
> > > they should only have to read the introduction and the relevant
> > > worked-out case), assuming they read through it in a linear
> > > fashion, due to the new guiding principle that wasn't alluded to
> > > at the beginning, they have to redo their mental model of
> > > "Modifying Sources" as this principle could invalidate things.
> > This shows both a problem with your structure,
> 
> I'm not seeing the problem.  How does this show a problem?
You're writing three paragraphs to lament how necessary the principle
of "use whatever is convenient" – which mind you I believe should never
be used outside of resolving conflicts between otherwise equally
applicable choices – is to your reasoning.

> > but more importantly, a failure to understand what I meant when I
> > wrote "use whatever is convenient" in my own patch.  This principle
> > *can* only work for cases in which there is *no clearly established
> > practice*, thus putting it at the end *after having enumerated all
> > practices* is the logical choice.
> > With your structure, you have to bend it sideways to shoehorn it in
> > with the other principles.
> 
> You appear to have meant it as a kind of ‘fallback principle’, in
> which case putting it at the end does indeed make sense.
> 
> In my patch, the principle works differently, it is also used for 
> explaining already established practices, for the cases where there
> are multiple technically allowed [technique] but still often a single
> _recommended_ [technique].  E.g.:
> 
> > Usually, a bug fix comes in the form of a patch copied from
> > upstream or another distribution.  In that case, simply adding the
> > patch to the @code{patches} field is the most convenient and
> > usually does not cause any problems; there is no need to rewrite it
> > as a snippet or a phase.
> > 
> > If no ready-made patch already exists, then ...]
> 
> and
> 
> > To add new functionality, a patch is almost always the most
> > convenient choice of the three 
> 
> .
> 
> To go from the principle as used in your patch to the principle as
> used  in my patch, perhaps in the process it is bent sideways and
> shoehorned.
> But after all the bending and shoehorning, it seems to fit well now
> in the beginning (and not well at all the end), so I'm not seeing any
> problems here.
And here I must disagree with the nature of your patch, because
elevating this into a guiding principle makes what feels most
convenient to you (or any other writer at the time of editing the
manual) most convenient to everyone.  My patch allows for deliberation
by both the packager and reviewer, which might lead to some conflicts
of opinion, but unless either solution can be shown clearly superior by
appeal to *another reason*, which mind you is lacking here, both
solutions should be accepted.
> 

> > in a way that might
> > inhibit natural information flow.
> 
> I'm not seeing it.  As I've explained previously, putting the
> premises (= guiding principles) before the conclusions (= worked out
> cases / solutions) is a logical (hence, natural) information flow,
> and introducing them on-the-way or implicitly is ad-hoc (unnatural).


> > I think we might be disagreeing about what constitutes "solving the
> > problem" here.  Correct me if I'm wrong, but to me it seems any
> > scenario that is not covered by whatever patch is applied counts as
> > "not having solved the problem".
> 
> It doesn't -- I consider the Shepherd problem to be solved by my
> patch (albeit rather weakly, see later), and the wider problem of
> unclear guidelines and policy on snippet/phase/patch to be, perhaps
> not really solved, but still much improved (this time not weakly).
> 
> > I personally find this line of reasoning questionable, as there are
> > perfectly valid reasons why multiple tools could apply.
> 
> See previous paragraph.


> > Take the problem of embedding a store path.  You could for instance
> > replace all occurences of "sh" with /gnu/store/.../bin/sh, or you
> > could first replace them in a patch with "@sh@" and then replace
> > that with /gnu/store/.../bin/sh.  Of course, you rarely have to do
> > the latter and the former is simpler, hence why you will often see
> > the former, but that doesn't mean the latter is invalid.
> 
> It's contrary to 'It preferably should also work on non-Guix systems’
> -- 
> not invalid, but still usually (*) against (proposed) policy because
> a direct substitute* is at the same time more convenient and follows
> all the the principles.
> 
> (*) sometimes, in case of shell scripts, a substitute* is fragile 
> (substituting too much), in which case a "sh" -> "@sh@" becomes more 
> convenient and hence the violation of the 'non-Guix system' rules 
> becomes acceptable.
Fair enough, guess I'll have to update configure.ac in the same patch
to honour the guiding principles.

> > > > > 
> > > In both patches, if the user only reads the
> > > introduction and conclusion (if any) and doesn't read the actual
> > > (relevant examples)/(explanation of patches, snippets, phases),
> > > then that's their problem.
> > I do think a table in the middle of the section is hard to ignore,
> 
> I think so too, hence my previous response.
> 
> > but suppose for the sake of argument that they do, [...]
> 
> Given this response, I assume I've misinterpreted what you meant with
> ‘not having looked at the worked-out cases yet’.
I think you understood it elsewhere, see the fallback guiding
principle.

> > No particular order is problematic,
> 
> I'm not seeing why.
Why have a structure, when you won't have a structure?  Sounds a little
counterintuitive, does it not?

>   but more importantly if a
> > technology appears more than once (guaranteed by the pigeonhole
> > principle), then either its properties get repeated (not good for
> > length) or scattered (not good for the flow you want).  Again, a
> > structural problem.
> 
> That's equally applies to your patch too, though?  (Switching 
> "technology" with "problem".)
Not really, since most problems that are to be uniquely solved with a
given tool can be uniquely named under that tool.  I do expand a little
on using patches and phases in combination for a more complicated job,
but that use case is notably missing from your patch.  I also repeat
shared characteristics of patches and snippets, which I could condense
to save some space, but in comparison to your patch, space is no issue.

> Also, I've re-read my patch, and I didn't find any repeated
> properties or scattering, except for a single property (patches are
> upstreamable):
> 
>  > First, when the fix is not Guix-specific, upstreaming the fix is
>  > strongly desired to avoid the additional maintenance cost to Guix.
>  > [...]
> > As such, patches are preferred.  However, as with bug
> > fixes, upstreaming the new functionality is desired.
> 
> As such, I'm not following your point here.
The trend of you not seeing continues.  Look at your first two
subsubsections (both v1 and v2).
> 

> > Point taken, but imho cross-references are nice for those who just
> > learned "okay, I now know I need to solve my technical problem with
> > a phase, how do I do that?"
> 
> They are indeed.  But I'm not following what you mean with "But"
> here.  I didn't claim anything about cross-references there?
> 
> Do you want me to add a few cross-references (for 'patch', 'snippet'
> and 'phases')?
I don't think you have a useful location to put them though, owing once
again to structure :)

> 
> > I do get the impression that this patch simply codifies what you
> > feel is right based on the shepherd situation
> 
> True, except for the 'simply'
Okay, I'll correct myself: This patch complicatedly codifies what you
feel is right based on the shepherd situation.

Jokes aside,

> I also considered several other situations (Removing bundled
> libraries, Removing non-free software, Adding new functionality).  I
> do not see the problem with this -- the proposed policy was
> considered workable even if some would like it to be a little bit
> different, and if others feel strongly about they could, I don't,
> maybe set up a vote system or such.
I think this is not the place for the kind of democracy where you put
everything barely the half of people can agree is the worst tradeoff
into "law".  Even worse if we had an anonymous online vote, because
those aren't susceptible to manipulation at all.

I think we should rather exercise caution and document what if not the
entire community then at least the reviewers can agree on.

> > rather than thinking about the general case,
> 
> See: several other cases that should cover most situations
> encountered in practice, and for the parts of the general case that
> aren't worked-out yet, there are the guiding principles.
"guiding" principle"s"

> > which is why my patch makes weaker statements here.  If
> > this issue could have been avoided with a #:make-flag, we would
> > have used that.
> > 
> > More importantly, I fail to see the superiority of your patch here
> > > IIUC neither patch offers a unique solution to the shepherd
> > thing, so
> > the room for debate remains
> 
> In my patch, multiple options remain, but there is no real room for 
> debate.  More concretely:
> 
> > When there is more than one way to do something, choose whichever
> > method is the simplest.  Sometimes this is subjective, which is
> > also fine.
> > What matters is that you use techniques that are common within the
> > community (i.e., patterns that appear throughout
> > @code{gnu/packages/...})
> > and are thus clearly legible for reviewers.
> 
> it is considered subjective, having multiple options if fine!  To 
> correct a packaging following the other option (to help with
> following the policies), you don't have to debate on what's the
> proper option to get a fix in, as both are considered acceptable.  In
> many cases, no need for debate, just pick one and move on.  (Also the
> case for your patch IIUC.)
I do think elevating this into a guiding principle somewhat undermines
what you're stating here though.

> Things are also phrased reconciliatory, e;g.:
> 
> > To make things more concrete and to resolve conflicts between the
> > principles, a few cases have been worked out:
> 
> However, in your patch, there is more opportunity for conflicts.
> E.g.:
> 
> > Each one has its strengths and drawbacks, along with intended
> > andhistorically derived use cases.
> 
> By this line, arguments like 'X was historically the intended purpose
> of Y, using Y for Z is incorrect' become reasonable, which makes 
> disagreements more difficult to resolve (as you know need to consult 
> history and because history is fixed, so no improvements would be 
> possible anymore in areas where there is a historically intended use
> case).
The intended and historically derived use cases are those that ought to
be explicitly named in the following.  If it's not documented, there is
no historic precedent.

> > > > In particular, for review purposes, mine should be easier to
> > > > work with.  For instance, the reviewer sees a hash embedded in
> > > > a snippet, sees in the snippet entry that you shouldn't do
> > > > that, and can thus say "nope, don't do a snippet here".
> 
> That is also the case for problem->solution?  A "sh" -> #$(file-
> append bash-minimal "/bin/sh") substitution can be recognised on
> sight as not possibly being anything else than a technical fix, and
> then the subsubsection on technical fixes mentions that those must be
> done in phases.
> 
> Or, another explanation: reviewers usually have seen a lot of more 
> packages than a new packager.  Because of that, and because they have
> familiarised theirselves with policy, they have over time
> automatically built a mental 'reverse index' of solutions->problems.
I wouldn't put too much value in this experience.  It can also blind
you to the point of producing old-style inputs, for example.

> > 
> > > I think we should optimise for packagers before reviewers
> > Code is more often read than written, so optimising for the reader
> > is optimizing for the packager as well.
> 
> While all reviewers are readers, not all readers are reviewers, and 
> reviewing usually happens only once, maybe twice per patch.
That's not a problem, though? You can take my guidelines, apply it to
any random package in the Guix source and see whether things (still)
fit.  That's more troublesome with the problem->solution style.  In
other words, that the solution passes is apparent from the written form
rather than requiring the process of writing it.

> > > > Regardless of which patch we pick, it should not mandate a
> > > > particular solution in potentially contentious cases,
> > > 
> > > Actually the whole point was to mandate a particular solution for
> > > the
> > > contentious cases, see Shepherd.
> > But I disagree.
> > 
> > Memes aside, please refrain from the "I'm right, do this" style
> > (which is another problem with the "problem-centric" approach),
> 
> Is this referring to the style of the documentation patch?  If so: it
> does explain why the "do this" is right, so I don't see the problem. 
> Do you have a particular point of the documentation in mind you
> consider wrong (*)?
> 
> (*) points I know of:
> * keep lists / remove lists (for the footnote about not-yet-policy on
> removing things in patches)
> * the guiding principles aren't guiding principles
For one, you seriously erred on the test cases thing.  I also wonder if
we're drawing the wrong conclusions for Makefiles from the Shepherd
incident.  Historically, patching build files in a phase has been very
fine.

> > but rather focus on writing a patch that makes reviewers not
> > discard a patch due to formalities.
> 
> I think the patch (v1 and v2) satisfies that.
I'm getting slightly different vibes, but sure.

Cheers

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#57598] [PATCH] doc: Update contribution guidelines on patches, etc.
Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Sat, 24 Sep 2022 13:04:02 +0000
Resent-Message-ID: <handler.57598.B57598.16640246205112 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 57598
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Maxime Devos <maximedevos@HIDDEN>
Cc: 57598 <at> debbugs.gnu.org, guix-maintainers@HIDDEN
Received: via spool by 57598-submit <at> debbugs.gnu.org id=B57598.16640246205112
          (code B ref 57598); Sat, 24 Sep 2022 13:04:02 +0000
Received: (at 57598) by debbugs.gnu.org; 24 Sep 2022 13:03:40 +0000
Received: from localhost ([127.0.0.1]:42643 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oc4ol-0001KM-Nm
	for submit <at> debbugs.gnu.org; Sat, 24 Sep 2022 09:03:40 -0400
Received: from eggs.gnu.org ([209.51.188.92]:55108)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ludo@HIDDEN>) id 1oc4oj-0001K8-7a
 for 57598 <at> debbugs.gnu.org; Sat, 24 Sep 2022 09:03:38 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:48228)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <ludo@HIDDEN>)
 id 1oc4od-00061E-2N; Sat, 24 Sep 2022 09:03:31 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To:
 From; bh=AxObal4qm450UT8ANxsL5PWP3Hia809U6SipdDNiwh4=; b=BSso5tYjZxv1BuEETzpl
 z9h01AsF1wkUr3HJZ/FoQXp2izxJIL4sWia3PnKrFPZBwz9/HTR9TclMhpYOX83yh9lQOSeRTDrVG
 vjEelJ3376mWRCyXtsZyiXZP+tXhO9I4P6isMaNAUsmzrMqb93USuYes7tGAITHriLq1RVziEuMwO
 jfB+TxqJkrmu+vmEf/dfTU+hcpORGfiSHTMnjLgQ86uaL4sqpF76ubzzw8GOKFNwd0JL41F/XrQKD
 3+NVSG/aRMk0mk07H1xYLizkijkSTa7qqO3mpvOA6AKAFBO/kbuTcSLdp4WAfjJklsyQhqEDKAuQZ
 I2ZQ0IcRvgFvlQ==;
Received: from 91-160-117-201.subs.proxad.net ([91.160.117.201]:55887
 helo=ribbon)
 by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <ludo@HIDDEN>)
 id 1oc4oc-0003q9-E3; Sat, 24 Sep 2022 09:03:30 -0400
From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
References: <20220905160048.18173-1-maximedevos@HIDDEN>
 <20220909123051.15747-1-maximedevos@HIDDEN>
Date: Sat, 24 Sep 2022 15:03:27 +0200
In-Reply-To: <20220909123051.15747-1-maximedevos@HIDDEN> (Maxime Devos's
 message of "Fri, 9 Sep 2022 14:30:51 +0200")
Message-ID: <87zgeoapr4.fsf_-_@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Hi!

Thanks for this welcome addition!  Modulo the cosmetic suggestions
below, I think it=E2=80=99s fine.

Maintainers, if you have something to say on the guidelines, now=E2=80=99s =
the
time!

  https://issues.guix.gnu.org/57598

Maxime Devos <maximedevos@HIDDEN> skribis:

> * doc/contributing.texi (Modifying Sources): Replaced with ...
> ("Modifying Sources"): ... this.  List more use cases and some principles.
>
> This patch incorporates some text written by Liliana Marie Prikler.  The
> structure is based on a proposal by Julien Lepiller.  The text has been
> revised based on reviews by David Larsson and blake.
>
> (! remove following text before committing !)

You can write comments below the --- and diffstats.  That way, =E2=80=98git=
 am=E2=80=99
will ignore them when applying the patch.

> +Guix has tree main ways of modifying the source code of a package, that
> +you as a packager may use.  These are patches, snippets and phases.
                            ^
=E2=80=9Cmay use: patches, snippets, and build phases.=E2=80=9D

> +Each one has its strengths and drawbacks.  To decide between the three,

s/decide between the three/choose among these/

> +there are a few guiding principles to satisfy simultanuously where
> +possible:
> +
> +@itemize
> +@item
> +In principle, Guix only has free software; when the upstream source

s/In principle, Guix only has free software/Every package in Guix is
free software/g

> +community (i.e., patterns that appear throughout @code{gnu/packages/...})

Normally such parenthetical expressions go between em dashes:

  community---i.e., patterns that appear throughout
  @file{gnu/packages}---and =E2=80=A6

> +To make things more concrete and to resolve conflicts between the
> +principles, a few cases have been worked out:
> +
> +@subsubsection Removing non-free software
> +Non-free software has to be removed in snippets; the reason is that
> +patches or phases will not work.

You can=E2=80=99t have a colon between the section heading.  Instead, you c=
an
write =E2=80=9Ca few cases have been worked out and will be illustrated in =
the
following sections.=E2=80=9D

Section titles should be capitalized.

Leave a blank line after the section title.

(Same comment for the sections that come after.)

Instead of =E2=80=9Cwill not work=E2=80=9D, which is vague, I=E2=80=99d sug=
gest more explicit
wording: =E2=80=9Cwould not be appropriate because they would expose the
offending code.=E2=80=9D

> +For patches, the problem is that a patch removing a non-free file
> +automatically contains the non-free file@footnote{It has been noted that
> +git patches support removing files without including the file in the
> +patch in
> +@url{https://yhetil.org/guix/8b13e899-eb60-490b-a268-639249698c81@@www.f=
astmail.com/}. If
> +it is verified that the @command{patch} utility supports such patches,
> +this method can be used and this policy adjusted appropriately.}, and we
> +do not want anything non-free in Guix even if only in its patches.

I=E2=80=99d drop the footnote, it=E2=80=99s already dense enough.

> +@code{delete-file-recursively}. There are a few benefits for snippets he=
re:
> +
> +When using snippets, the bundled library does not occur in the source

s/snippets here:/snippets here./
s/When using snippets/First, when using snippets/

> +As such, snippets are recommended here.

s/are recommended here/are the recommended way to delete non-free material/

> +@subsubsection Fixing technical issues (compilation errors, test failure=
s, other bugs ...)

In addition to capitalizing, please remove the parenthetical bit.

> +@subsubsection Adding new functionality
> +To add new functionality, a patch is almost always the most convenient
> +choice of the three -- patches are usually multi-line changes, which are

s/three -- patches/three---patches/

That=E2=80=99s all I have to say!

I think what the text says is fine.  It=E2=80=99s dense and rather long tho=
ugh,
which means that people may overlook things.  OTOH it=E2=80=99s structured =
so
it=E2=80=99s easier to skim through it, and I wouldn=E2=80=99t know what to=
 remove.

Could you send an updated version?

Thanks,
Ludo=E2=80=99.

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#57598] [PATCH] doc: Update contribution guidelines on patches, etc.
Resent-From: Maxime Devos <maximedevos@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Sun, 25 Sep 2022 18:00:02 +0000
Resent-Message-ID: <handler.57598.B57598.16641287991713 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 57598
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Cc: 57598 <at> debbugs.gnu.org, guix-maintainers@HIDDEN
Received: via spool by 57598-submit <at> debbugs.gnu.org id=B57598.16641287991713
          (code B ref 57598); Sun, 25 Sep 2022 18:00:02 +0000
Received: (at 57598) by debbugs.gnu.org; 25 Sep 2022 17:59:59 +0000
Received: from localhost ([127.0.0.1]:48506 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ocVv4-0000RZ-PI
	for submit <at> debbugs.gnu.org; Sun, 25 Sep 2022 13:59:59 -0400
Received: from andre.telenet-ops.be ([195.130.132.53]:34726)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <maximedevos@HIDDEN>) id 1ocVv3-0000RR-9r
 for 57598 <at> debbugs.gnu.org; Sun, 25 Sep 2022 13:59:57 -0400
Received: from [IPV6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16]
 ([IPv6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16])
 by andre.telenet-ops.be with bizsmtp
 id QHzv2800R20ykKC01HzwHl; Sun, 25 Sep 2022 19:59:56 +0200
Message-ID: <66417bb1-f81e-b2e6-6f37-c5dc9bb39dc9@HIDDEN>
Date: Sun, 25 Sep 2022 19:59:55 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.12.0
Content-Language: en-US
References: <20220905160048.18173-1-maximedevos@HIDDEN>
 <20220909123051.15747-1-maximedevos@HIDDEN> <87zgeoapr4.fsf_-_@HIDDEN>
From: Maxime Devos <maximedevos@HIDDEN>
In-Reply-To: <87zgeoapr4.fsf_-_@HIDDEN>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------6QnkPfuL5ILUpfCso4m5K8P9"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r22;
 t=1664128796; bh=9A6DPaRxmSLRlnHSSOBBnN4fmlDzfqObdvpFNQu9Rvc=;
 h=Date:Subject:To:Cc:References:From:In-Reply-To;
 b=e25LzUsllnmO8cSC6GLkUehH9Gd4g0E0uVtn6AuVqtdfxYcAg8jIxX8NCx4Eqo6H9
 xWW7eLVx8P36Z5GPRLwekztdb7uPMB/56GoXdCbMz765sRkf6p5kkT0RkqnCxqHwoM
 ws7GgB+nhCq5RKNgagUDvke+wZAVL+GTw5u12/vq96OARefpL0eXxLR09DeTtMrrNp
 s0x7wg91EoLgxt/PNiPOwgKDk2raQCZ/etnEkN6LwrvSzSTiy5pUTn9TG0kGp76Sea
 b1zMOolrgSrIajeD5qo2i7ay06U1AZQxLjeN1ojN5B058IDWxV16SPHgdCYZNGBNJp
 Zwu/3sN1T5tUQ==
X-Spam-Score: -2.5 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.5 (---)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------6QnkPfuL5ILUpfCso4m5K8P9
Content-Type: multipart/mixed; boundary="------------zgJHLE0uRRZmtVO075t1fQ8n";
 protected-headers="v1"
From: Maxime Devos <maximedevos@HIDDEN>
To: =?UTF-8?Q?Ludovic_Court=c3=a8s?= <ludo@HIDDEN>
Cc: 57598 <at> debbugs.gnu.org, guix-maintainers@HIDDEN
Message-ID: <66417bb1-f81e-b2e6-6f37-c5dc9bb39dc9@HIDDEN>
Subject: Re: bug#57598: [PATCH] doc: Update contribution guidelines on
 patches, etc.
References: <20220905160048.18173-1-maximedevos@HIDDEN>
 <20220909123051.15747-1-maximedevos@HIDDEN> <87zgeoapr4.fsf_-_@HIDDEN>
In-Reply-To: <87zgeoapr4.fsf_-_@HIDDEN>

--------------zgJHLE0uRRZmtVO075t1fQ8n
Content-Type: multipart/mixed; boundary="------------8v09X0mmvj1s6LeOTCnT0f91"

--------------8v09X0mmvj1s6LeOTCnT0f91
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

DQoNCk9uIDI0LTA5LTIwMjIgMTU6MDMsIEx1ZG92aWMgQ291cnTDqHMgd3JvdGU6DQo+IEhp
IQ0KPiANCj4gVGhhbmtzIGZvciB0aGlzIHdlbGNvbWUgYWRkaXRpb24hICBNb2R1bG8gdGhl
IGNvc21ldGljIHN1Z2dlc3Rpb25zDQo+IGJlbG93LCBJIHRoaW5rIGl04oCZcyBmaW5lLg0K
PiANCj4gTWFpbnRhaW5lcnMsIGlmIHlvdSBoYXZlIHNvbWV0aGluZyB0byBzYXkgb24gdGhl
IGd1aWRlbGluZXMsIG5vd+KAmXMgdGhlDQo+IHRpbWUhDQo+IA0KPiAgICBodHRwczovL2lz
c3Vlcy5ndWl4LmdudS5vcmcvNTc1OTgNCj4gDQo+IE1heGltZSBEZXZvcyA8bWF4aW1lZGV2
b3NAdGVsZW5ldC5iZT4gc2tyaWJpczoNCj4gDQo+PiAqIGRvYy9jb250cmlidXRpbmcudGV4
aSAoTW9kaWZ5aW5nIFNvdXJjZXMpOiBSZXBsYWNlZCB3aXRoIC4uLg0KPj4gKCJNb2RpZnlp
bmcgU291cmNlcyIpOiAuLi4gdGhpcy4gIExpc3QgbW9yZSB1c2UgY2FzZXMgYW5kIHNvbWUg
cHJpbmNpcGxlcy4NCj4+DQo+PiBUaGlzIHBhdGNoIGluY29ycG9yYXRlcyBzb21lIHRleHQg
d3JpdHRlbiBieSBMaWxpYW5hIE1hcmllIFByaWtsZXIuICBUaGUNCj4+IHN0cnVjdHVyZSBp
cyBiYXNlZCBvbiBhIHByb3Bvc2FsIGJ5IEp1bGllbiBMZXBpbGxlci4gIFRoZSB0ZXh0IGhh
cyBiZWVuDQo+PiByZXZpc2VkIGJhc2VkIG9uIHJldmlld3MgYnkgRGF2aWQgTGFyc3NvbiBh
bmQgYmxha2UuDQo+Pg0KPj4gKCEgcmVtb3ZlIGZvbGxvd2luZyB0ZXh0IGJlZm9yZSBjb21t
aXR0aW5nICEpDQo+IA0KPiBZb3UgY2FuIHdyaXRlIGNvbW1lbnRzIGJlbG93IHRoZSAtLS0g
YW5kIGRpZmZzdGF0cy4gIFRoYXQgd2F5LCDigJhnaXQgYW3igJkNCj4gd2lsbCBpZ25vcmUg
dGhlbSB3aGVuIGFwcGx5aW5nIHRoZSBwYXRjaC4NCg0KSSBrbm93IG9mICctLS0nLCBidXQg
QUZBSUNUIHRoaXMgaXMgdW5kb2N1bWVudGVkIGJlaGF2aW91ciwgc28gSSdtIA0KaGVzaXRh
bnQgdG8gcmVseSBvbiB0aGF0Lg0KDQogPiBbLi4uXQ0KPiBDb3VsZCB5b3Ugc2VuZCBhbiB1
cGRhdGVkIHZlcnNpb24/DQoNCkkgaW50ZW5kIHRvIGRvIHNvIGFmdGVyIGJyaW5naW5nIGFu
dGlveCB0byAxMDAlLg0KDQpHcmVldGluZ3MsDQpNYXhpbWUuDQo=
--------------8v09X0mmvj1s6LeOTCnT0f91
Content-Type: application/pgp-keys; name="OpenPGP_0x49E3EE22191725EE.asc"
Content-Disposition: attachment; filename="OpenPGP_0x49E3EE22191725EE.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xjMEX4ch6BYJKwYBBAHaRw8BAQdANPb/d6MrGnGi5HyvODCkBUJPRjiFQcRU5V+m
xvMaAa/NL01heGltZSBEZXZvcyA8bWF4aW1lLmRldm9zQHN0dWRlbnQua3VsZXV2
ZW4uYmU+wpAEExYIADgWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCX4ch6AIbAwUL
CQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRBJ4+4iGRcl7japAQC3opZ2KGWzWmRc
/gIWSu0AAcfMwyinFEEPa/QhUt2CogD/e2RdF4CYAgaRHJJmZ9WU7piKbLZ7llB4
LzgezVDHggzNJU1heGltZSBEZXZvcyA8bWF4aW1lZGV2b3NAdGVsZW5ldC5iZT7C
kAQTFggAOBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJf56ycAhsDBQsJCAcDBRUK
CQgLBRYCAwEAAh4BAheAAAoJEEnj7iIZFyXujpQBAKV1SwDDl4f24rXciDlB9L8W
ycZt30CgbewMSRQk4mvbAP9dFMbVVixYBd6C8cfhR+NsOBGiOJnQABlUmgNuqGFJ
Dc44BF+HIegSCisGAQQBl1UBBQEBB0BOlzIWiJzgobMF6/cqwLaLk7jIcFSZ++c0
k9cCNT6YXwMBCAfCeAQYFggAIBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJfhyHo
AhsMAAoJEEnj7iIZFyXuMr0BAJc8cl5PGvVmVuSQVKjleNl4DK1/XAaPAYPe34AE
fZJPAP9IqLCQhH/FeJanHqBP8gNdGNI2qn8RnnLVfRJgUjZ1BA=3D=3D
=3DOVqp
-----END PGP PUBLIC KEY BLOCK-----

--------------8v09X0mmvj1s6LeOTCnT0f91--

--------------zgJHLE0uRRZmtVO075t1fQ8n--

--------------6QnkPfuL5ILUpfCso4m5K8P9
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wnsEABYIACMWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYzCXGwUDAAAAAAAKCRBJ4+4iGRcl7idc
AQDyYd2N/m9nZVFDUTNqnqhjgE3wgfLoLrORdds23fg4XAD/dfvUg7nmZM8xLSztCuUAtrJ1DYVI
wZ20bdiaFUEvWw0=
=LaNJ
-----END PGP SIGNATURE-----

--------------6QnkPfuL5ILUpfCso4m5K8P9--

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#57598] [PATCH] doc: Update contribution guidelines on patches, etc.
Resent-From: Kyle Meyer <kyle@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Sun, 25 Sep 2022 18:59:01 +0000
Resent-Message-ID: <handler.57598.B57598.16641323407289 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 57598
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Maxime Devos <maximedevos@HIDDEN>
Cc: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>, 57598 <at> debbugs.gnu.org, guix-maintainers@HIDDEN
Received: via spool by 57598-submit <at> debbugs.gnu.org id=B57598.16641323407289
          (code B ref 57598); Sun, 25 Sep 2022 18:59:01 +0000
Received: (at 57598) by debbugs.gnu.org; 25 Sep 2022 18:59:00 +0000
Received: from localhost ([127.0.0.1]:48547 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ocWqC-0001tS-4g
	for submit <at> debbugs.gnu.org; Sun, 25 Sep 2022 14:59:00 -0400
Received: from out2.migadu.com ([188.165.223.204]:50140)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <kyle@HIDDEN>) id 1ocWq6-0001tF-8g
 for 57598 <at> debbugs.gnu.org; Sun, 25 Sep 2022 14:58:58 -0400
X-Report-Abuse: Please report any abuse attempt to abuse@HIDDEN and
 include these headers.
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kyleam.com; s=key1;
 t=1664132332;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
 content-transfer-encoding:content-transfer-encoding:
 in-reply-to:in-reply-to:references:references;
 bh=o71eCuQbift4kMDDGFhPtKQOaxXkgc0D4XPBNDednJk=;
 b=R9+WWBpGDmt2LqNh9IhlHzb//zYI79J7TYZC3ctTuddD4zY/itN2zIQ63RN05BjwohKRdk
 69Z4xzMEvQnIzH6ntQ8bmr4KT7WOlNFLDT8UWZnW8TB/WhfY89CtMWAgJedcTazFnAKi8r
 24UFR1E/i4AcUSQquU5raFAPuAqmfSaRrdtxUTlbezczsSlXaMMlY+KM55ZC3dP5afvFSQ
 1i93KomEiKG1a0mIV1Zevx6bcSucEJyBYJqwsOzppurDgjpA+cE6hFXw2+NviszMYwUHQE
 i2BycebNMQ5alzkK/1FrsuWLtmw1PEYz6fwScfobqfbXsI675C+3zQ5XLc56ZQ==
From: Kyle Meyer <kyle@HIDDEN>
In-Reply-To: <66417bb1-f81e-b2e6-6f37-c5dc9bb39dc9@HIDDEN>
References: <20220905160048.18173-1-maximedevos@HIDDEN>
 <20220909123051.15747-1-maximedevos@HIDDEN>
 <87zgeoapr4.fsf_-_@HIDDEN>
 <66417bb1-f81e-b2e6-6f37-c5dc9bb39dc9@HIDDEN>
Date: Sun, 25 Sep 2022 14:58:50 -0400
Message-ID: <87pmfj1dsl.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Migadu-Flow: FLOW_OUT
X-Migadu-Auth-User: kyleam.com
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Maxime Devos writes:

> On 24-09-2022 15:03, Ludovic Court=C3=A8s wrote:
[...]
>> You can write comments below the --- and diffstats.  That way, =E2=80=98=
git am=E2=80=99
>> will ignore them when applying the patch.
>
> I know of '---', but AFAICT this is undocumented behaviour, so I'm=20
> hesitant to rely on that.

I don't think you should be worried about Git changing that behavior.
It's used heavily by the Git project itself as well as many other
projects.

Here are some mentions in git.git (4fd6c5e444):

,----[ Documentation/SubmittingPatches ]
| You often want to add additional explanation about the patch,
| other than the commit message itself.  Place such "cover letter"
| material between the three-dash line and the diffstat.  For
| patches requiring multiple iterations of review and discussion,
| an explanation of changes between each iteration can be kept in
| Git-notes and inserted automatically following the three-dash
| line via `git format-patch --notes`.
`----

,----[ Documentation/git-notes.txt ]
| Notes can also be added to patches prepared with `git format-patch` by
| using the `--notes` option. Such notes are added as a patch commentary
| after a three dash separator line.
`----

,----[ Documentation/user-manual.txt ]
| `git format-patch` can include an initial "cover letter". You can insert
| commentary on individual patches after the three dash line which
| `format-patch` places after the commit message but before the patch
| itself.  If you use `git notes` to track your cover letter material,
| `git format-patch --notes` will include the commit's notes in a similar
| manner.
`----

,----[ Documentation/git-format-patch.txt ]
| Typically it will be placed in a MUA's drafts folder, edited to add
| timely commentary that should not go in the changelog after the three
| dashes, and then sent as a message whose body, in our example, starts
| with "arch/arm config files were...".  On the receiving end, readers [...]
`----

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#57598] [PATCH] doc: Update contribution guidelines on patches, etc.
Resent-From: Maxim Cournoyer <maxim.cournoyer@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Mon, 26 Sep 2022 00:48:01 +0000
Resent-Message-ID: <handler.57598.B57598.16641532607881 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 57598
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Cc: Maxime Devos <maximedevos@HIDDEN>, 57598 <at> debbugs.gnu.org, guix-maintainers@HIDDEN
Received: via spool by 57598-submit <at> debbugs.gnu.org id=B57598.16641532607881
          (code B ref 57598); Mon, 26 Sep 2022 00:48:01 +0000
Received: (at 57598) by debbugs.gnu.org; 26 Sep 2022 00:47:40 +0000
Received: from localhost ([127.0.0.1]:48751 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1occHc-000230-Fq
	for submit <at> debbugs.gnu.org; Sun, 25 Sep 2022 20:47:40 -0400
Received: from mail-qv1-f45.google.com ([209.85.219.45]:41766)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <maxim.cournoyer@HIDDEN>) id 1occHZ-00022K-Kd
 for 57598 <at> debbugs.gnu.org; Sun, 25 Sep 2022 20:47:38 -0400
Received: by mail-qv1-f45.google.com with SMTP id l14so3491313qvq.8
 for <57598 <at> debbugs.gnu.org>; Sun, 25 Sep 2022 17:47:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=content-transfer-encoding:mime-version:user-agent:message-id
 :in-reply-to:date:references:subject:cc:to:from:from:to:cc:subject
 :date; bh=Jm7/wvws2HaMGhoVs7Rkc/13pq705R/qLkD3gHDTGzc=;
 b=KJFDjWYEdX4L6+JCdHvWgSD/F5yQg4T6cKtncIwSc7LMJbuz8aKElPmTR3ObZS8ehN
 0Ji6qf+FPn8wo/moIuqsZIy+sj65RbRlHcP2/V8SVnEVCfuuqPrRVMO3V2Sjkk7oQ6G3
 RZod9UMwNJFX9lAKRKtFejmsofXh4mjVGOydt1JU0PxGJaAaf8EqllRocom74HsmyLCf
 NDTbp8hSHsgG7exAzVIGhc6eLKuTDvOqo/SQOYOXTdpk+IVW8wKGXJsbuuBARWcMtmVz
 mP32rSuuGW6GbPQ8xkHt8phqwW6WS6Y9+1ZNhB6+FSfesYkDtWZSO2nFTYfXhnKIzz3P
 ouXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:mime-version:user-agent:message-id
 :in-reply-to:date:references:subject:cc:to:from:x-gm-message-state
 :from:to:cc:subject:date;
 bh=Jm7/wvws2HaMGhoVs7Rkc/13pq705R/qLkD3gHDTGzc=;
 b=jCmICaLcIOugADpG/ZsspY+fVfRWHk0op2vYi6I/rcEqmMlC7bwhq6EkrIBwy8Xwu0
 jLSt68fWFC39upEy2CjbS3I50+xVKfr44yAx/9xK2ejRSxOKm7YZ3Lnjgq8G4EKMzXiT
 Gf9oG5jb8teZuRwFMFY+h0bO1wpOx22udlTL8n8AyNHSkdZFadmQEqTgr6fRk6XkR0P0
 3zoZ+o60Gi6244cTYN7zdU19+PFl0LA1WmTDsjtopQkkJEA9SuapCehkJuskxLVJn6vn
 f0+q10qBUWgOEBgWWkILsxf5HqA6RwYoFXc4h9qp2LhwAItg+JH3urhpF0QnotYoZRNI
 NboQ==
X-Gm-Message-State: ACrzQf3lEAxNVtC6223s5NDOUWBtUv3/IslaYru94f1zcnVqKas8doGn
 OR+EoIN9j3zPD2yBX9s6Phu4D9/JO5w=
X-Google-Smtp-Source: AMsMyM79NgbhQqbUTgnwn4Q9Jts9mOe+NcHeUlYELZAw987bSHSC+WhMv78MotAzJ7i3BaDKSJRUCg==
X-Received: by 2002:a05:6214:20aa:b0:4ac:a951:11d6 with SMTP id
 10-20020a05621420aa00b004aca95111d6mr15371758qvd.88.1664153251999; 
 Sun, 25 Sep 2022 17:47:31 -0700 (PDT)
Received: from hurd (dsl-10-132-99.b2b2c.ca. [72.10.132.99])
 by smtp.gmail.com with ESMTPSA id
 u2-20020ae9d802000000b006ce407b996asm10450989qkf.69.2022.09.25.17.47.30
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 25 Sep 2022 17:47:31 -0700 (PDT)
From: Maxim Cournoyer <maxim.cournoyer@HIDDEN>
References: <20220905160048.18173-1-maximedevos@HIDDEN>
 <20220909123051.15747-1-maximedevos@HIDDEN>
 <87zgeoapr4.fsf_-_@HIDDEN>
Date: Sun, 25 Sep 2022 20:47:29 -0400
In-Reply-To: <87zgeoapr4.fsf_-_@HIDDEN> ("Ludovic =?UTF-8?Q?Court=C3=A8s?="'s message of "Sat, 24 Sep 2022 15:03:27 +0200")
Message-ID: <87h70v6jxa.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hi,

Ludovic Court=C3=A8s <ludo@HIDDEN> writes:

> Hi!
>
> Thanks for this welcome addition!  Modulo the cosmetic suggestions
> below, I think it=E2=80=99s fine.
>
> Maintainers, if you have something to say on the guidelines, now=E2=80=99=
s the
> time!
>
>   https://issues.guix.gnu.org/57598

A couple things, on top of things you spot yourself and discussed by
Liliana (although I haven't read the full thread, which is getting
rather long):

1. s/tree/three/

2. I think it'd be nice to mention that that the work of freeing
software should not be done in Guix, but in upstream or if that fails as
a second upstream project.  That's easier to maintain longer term (more
interested parties can share the burden), and friendlier to other FSDG
distributions.  Also, software containing nonfree software is risky: we
have no reasons to trust they won't add more nonfree things to it,
putting our users at risk, so deciding to include such software should
be made carefully.  It may be preferable to simply not include it, if
the risks outweighs the benefits.

3. "guiding principles" sounds a bit too serious/strong to my taste.  I
think it's more guidelines we're discussing.

4.

    The source of the package needs to correspond to what is actually built
    (i.e., act as the corresponding source), to fulfill our ethical and
    legal obligations.

This also seems worded too strongly -- I don't think Guix is bound to
the concept of the "corresponding source", although it is a nice
property.

I find the new text rather long but it does add value, and I wouldn't
know how to structure or improve it much, so I'm in favor of including
it.

Thanks,

Maxim

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#57598] [PATCH] doc: Update contribution guidelines on patches, etc.
Resent-From: zimoun <zimon.toutoune@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Fri, 04 Nov 2022 16:40:01 +0000
Resent-Message-ID: <handler.57598.B57598.166757995115041 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 57598
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Maxime Devos <maximedevos@HIDDEN>
Cc: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>, Kyle Meyer <kyle@HIDDEN>, 57598 <at> debbugs.gnu.org, Maxim Cournoyer <maxim.cournoyer@HIDDEN>, Liliana Marie Prikler <liliana.prikler@HIDDEN>
Received: via spool by 57598-submit <at> debbugs.gnu.org id=B57598.166757995115041
          (code B ref 57598); Fri, 04 Nov 2022 16:40:01 +0000
Received: (at 57598) by debbugs.gnu.org; 4 Nov 2022 16:39:11 +0000
Received: from localhost ([127.0.0.1]:54673 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oqzip-0003uX-1r
	for submit <at> debbugs.gnu.org; Fri, 04 Nov 2022 12:39:11 -0400
Received: from mail-wr1-f50.google.com ([209.85.221.50]:42658)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <zimon.toutoune@HIDDEN>) id 1oqzim-0003uH-PU
 for 57598 <at> debbugs.gnu.org; Fri, 04 Nov 2022 12:39:09 -0400
Received: by mail-wr1-f50.google.com with SMTP id cl5so7802818wrb.9
 for <57598 <at> debbugs.gnu.org>; Fri, 04 Nov 2022 09:39:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:user-agent:message-id:in-reply-to:date:references
 :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to;
 bh=tP3ri0gawcTtJd58/IEs5J/Rb1+/sKQNnLtG2/guAQk=;
 b=a3M2OuCRja+E4LRt8QGoqdweQrQrVvAI7bRe+qcswMDJ+mmTp3G06Cjx6ROsVpr1oy
 wnYO8afhqfGlp/gXGoPpD01ZWs5dRa39p0OHyOC/N+DqxgLPB9N+lKP5oNghJhePXpXv
 gXyDWX5K3LnS0bgVFR0AojgktY5bSELHxz5hGNcl1h1rBvqQizz2iSou2A2FQHTzYcAo
 qpDSeGe+mfVz5T7DbRqgdmlaXRtGvhoPhgGsr6uDEpzyq1xHuWHmMrlN/tUtNMKxDsxP
 EpzJqVjiwGs/c84v19MGJWOGCexhLGVJ2dUATXGmTvbn/5fzWuWfuuw/zUpoUSHB2pw5
 tfgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=mime-version:user-agent:message-id:in-reply-to:date:references
 :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date
 :message-id:reply-to;
 bh=tP3ri0gawcTtJd58/IEs5J/Rb1+/sKQNnLtG2/guAQk=;
 b=t0w+qedqijdrMJNDaBk7M8m6CFgcPttIDf/BRrYIIjYI7k1KZ1DvVk6R3EMttr2bHk
 j+T9oN992Y4OqksOtaDkgCcIntM2ZQXaBZGDMJQsazWuWK/hqkzTtTvBCzTyVMSLBUGx
 X8xW5S1wBehgLyYhlovIR3UuYrAEF6sDmlM4iFbCtcFUdOUqDS0cwKGAeW/GUD7ItM0Y
 zFINY355JQXbNRf6Pn6rJxhhMP/oiH8kGoHnPyDrLLjVdysRdACwcoMV48TAOEP1clXB
 XbWHFCcP8nkwk/lgR1PWFoT8DRCKnfv4L1DRRiMtAeQRtXbsPV5XTqYOeiFVZnrRow0t
 OZGA==
X-Gm-Message-State: ACrzQf3JivQj3A4dlG78yEtStkdoRWmH94c/nmcYqUY8NdUrHoRTVer2
 5ap9TnArlmUmCH6UfpOopD0=
X-Google-Smtp-Source: AMsMyM44FiI0TcJMFTmKC5pIz85tYg9Tw3xRP13ED+tVgLkW6rUgARBE4v6KWXOzcOW7uGipSPE3Yw==
X-Received: by 2002:a5d:6d02:0:b0:236:ed2d:b3eb with SMTP id
 e2-20020a5d6d02000000b00236ed2db3ebmr11071577wrq.456.1667579942296; 
 Fri, 04 Nov 2022 09:39:02 -0700 (PDT)
Received: from lili ([2a01:e0a:59b:9120:65d2:2476:f637:db1e])
 by smtp.gmail.com with ESMTPSA id
 l21-20020a05600c4f1500b003c6bd12ac27sm3772897wmq.37.2022.11.04.09.39.00
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 04 Nov 2022 09:39:01 -0700 (PDT)
From: zimoun <zimon.toutoune@HIDDEN>
References: <20220905160048.18173-1-maximedevos@HIDDEN>
 <20220909123051.15747-1-maximedevos@HIDDEN>
Date: Fri, 04 Nov 2022 17:07:53 +0100
In-Reply-To: <20220909123051.15747-1-maximedevos@HIDDEN> (Maxime Devos's
 message of "Fri, 9 Sep 2022 14:30:51 +0200")
Message-ID: <86pme24s9y.fsf_-_@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hi,

Some work and energy had been put in these patches #57598 [1,2] and they
appear to me a nice improvement.

So what is missing?  Some rewording here or there?  Merge some wording
from one to the other?


1: <https://issues.guix.gnu.org/issue/57598#msgid-1ba11b761cf81336b9788d5f0650b3742eed9d7f>
2: <https://issues.guix.gnu.org/issue/57598#msgid-7b0e5632669defb4d951b1cec54515bacc1c0a89>


Cheers,
simon

Message received at control <at> debbugs.gnu.org:

Received: (at control) by debbugs.gnu.org; 24 Nov 2022 09:00:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Nov 24 04:00:14 2022
Received: from localhost ([127.0.0.1]:57213 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oy85e-0001ss-3a
	for submit <at> debbugs.gnu.org; Thu, 24 Nov 2022 04:00:14 -0500
Received: from mira.cbaines.net ([212.71.252.8]:41972)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mail@HIDDEN>) id 1oy85b-0001sd-Nr
 for control <at> debbugs.gnu.org; Thu, 24 Nov 2022 04:00:12 -0500
Received: from localhost (unknown [IPv6:2a02:8010:68c1:0:54d1:d5d4:280e:f699])
 by mira.cbaines.net (Postfix) with ESMTPSA id 4A1C827BBE9
 for <control <at> debbugs.gnu.org>; Thu, 24 Nov 2022 09:00:11 +0000 (GMT)
Received: from localhost (localhost [local])
 by localhost (OpenSMTPD) with ESMTPA id 3907d70b
 for <control <at> debbugs.gnu.org>; Thu, 24 Nov 2022 09:00:11 +0000 (UTC)
From: Christopher Baines <mail@HIDDEN>
To: control <at> debbugs.gnu.org
Subject: tag 57598 moreinfo
Date: Thu, 24 Nov 2022 09:00:11 +0000
Message-ID: <87leo0hgmc.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: control
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

tags 57598 + moreinfo
quit

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#57598] [PATCH] doc: Update contribution guidelines on patches, etc.
References: <20220905160048.18173-1-maximedevos@HIDDEN>
In-Reply-To: <20220905160048.18173-1-maximedevos@HIDDEN>
Resent-From: Maxime Devos <maximedevos@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Fri, 13 Oct 2023 14:16:02 +0000
Resent-Message-ID: <handler.57598.B57598.16972065335236 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 57598
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: moreinfo patch
To: 57598 <at> debbugs.gnu.org, Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Received: via spool by 57598-submit <at> debbugs.gnu.org id=B57598.16972065335236
          (code B ref 57598); Fri, 13 Oct 2023 14:16:02 +0000
Received: (at 57598) by debbugs.gnu.org; 13 Oct 2023 14:15:33 +0000
Received: from localhost ([127.0.0.1]:47015 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qrIwu-0001MO-B8
	for submit <at> debbugs.gnu.org; Fri, 13 Oct 2023 10:15:32 -0400
Received: from baptiste.telenet-ops.be ([2a02:1800:120:4::f00:13]:51132)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <maximedevos@HIDDEN>) id 1qrIwn-0001M2-EU
 for 57598 <at> debbugs.gnu.org; Fri, 13 Oct 2023 10:15:30 -0400
Received: from [IPV6:2a02:1808:87:3d3a:d21a:b3f4:d302:52bc]
 ([IPv6:2a02:1808:87:3d3a:d21a:b3f4:d302:52bc])
 by baptiste.telenet-ops.be with bizsmtp
 id xSEu2A00R26bbaT01SEv9D; Fri, 13 Oct 2023 16:14:56 +0200
Message-ID: <a11dbe65-ad8c-0e3f-cfdd-7ce90e5db46f@HIDDEN>
Date: Fri, 13 Oct 2023 16:14:53 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.13.0
Content-Language: en-US
From: Maxime Devos <maximedevos@HIDDEN>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------F9b0xHfWx2yLlTzzDl8Ar42J"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r23;
 t=1697206496; bh=TspZ6n5zhFXDFulpwMVnyNCZsrEhVjJCtEM/fcU/O9o=;
 h=Date:To:From:Subject;
 b=FP8Owaz0hQ7YSJ/ma75otujrLTP9PPnadLVGdtqBBjMR9yonTC2wum5VjqZanCyIm
 TVAiX0ozDpkLZHgkH81PPKlY8JetpQYJvsabyEMJzc6Wt/ER4SixqiUfOf5KStGbs+
 BKPQEfAieCUeGWoelbl1+VrEJ1quxuMk+ewbaX7UgXGlABGcdl1OFT+p41mcXo9RaZ
 fmwCqhxWLnvoFzlVQetbsgznCHcIEtTOzlPHyphXsCwORyho8Em6dL5ouPLzCuBbfX
 wUEnVB9UxjQcD1kq/Wb/+EYSTdZwUW0KwR+9kRd0Dembh4BolVrFke86Gj/5OOitMi
 VFQDQyM2iskAg==
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------F9b0xHfWx2yLlTzzDl8Ar42J
Content-Type: multipart/mixed; boundary="------------YuWL9z5PnyeAGoTKCiXBNRQ6";
 protected-headers="v1"
From: Maxime Devos <maximedevos@HIDDEN>
To: 57598 <at> debbugs.gnu.org, =?UTF-8?Q?Ludovic_Court=c3=a8s?= <ludo@HIDDEN>
Message-ID: <a11dbe65-ad8c-0e3f-cfdd-7ce90e5db46f@HIDDEN>
Subject: Re: [PATCH] doc: Update contribution guidelines on patches, etc.

--------------YuWL9z5PnyeAGoTKCiXBNRQ6
Content-Type: multipart/mixed; boundary="------------mKQHC2belrlmtdGnqsSDj182"

--------------mKQHC2belrlmtdGnqsSDj182
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

Pj4gK0d1aXggaGFzIHRyZWUgbWFpbiB3YXlzIG9mIG1vZGlmeWluZyB0aGUgc291cmNlIGNv
ZGUgb2YgYSBwYWNrYWdlLCB0aGF0DQo+PiAreW91IGFzIGEgcGFja2FnZXIgbWF5IHVzZS4g
IFRoZXNlIGFyZSBwYXRjaGVzLCBzbmlwcGV0cyBhbmQgcGhhc2VzLg0KPiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgXg0KPiDigJxtYXkgdXNlOiBwYXRjaGVzLCBzbmlwcGV0cywg
YW5kIGJ1aWxkIHBoYXNlcy7igJ0NCg0KT0ssIGZvciB0aGUgbmV4dCB2ZXJzaW9uIG9mIHRo
ZSBwYXRjaCBJIHdvbid0IHdyaXRlLg0KDQo+PiArRWFjaCBvbmUgaGFzIGl0cyBzdHJlbmd0
aHMgYW5kIGRyYXdiYWNrcy4gIFRvIGRlY2lkZSBiZXR3ZWVuIHRoZSB0aHJlZSwNCj4gDQo+
IHMvZGVjaWRlIGJldHdlZW4gdGhlIHRocmVlL2Nob29zZSBhbW9uZyB0aGVzZS8NCg0KV2h5
Pw0KDQo+IFRvZ2dsZSBxdW90ZSAoNyBsaW5lcykNCj4+ICt0aGVyZSBhcmUgYSBmZXcgZ3Vp
ZGluZyBwcmluY2lwbGVzIHRvIHNhdGlzZnkgc2ltdWx0YW51b3VzbHkgd2hlcmUNCj4+ICtw
b3NzaWJsZToNCj4+ICsNCj4+ICtAaXRlbWl6ZQ0KPj4gK0BpdGVtDQo+PiArSW4gcHJpbmNp
cGxlLCBHdWl4IG9ubHkgaGFzIGZyZWUgc29mdHdhcmU7IHdoZW4gdGhlIHVwc3RyZWFtIHNv
dXJjZQ0KPiANCj4gcy9JbiBwcmluY2lwbGUsIEd1aXggb25seSBoYXMgZnJlZSBzb2Z0d2Fy
ZS9FdmVyeSBwYWNrYWdlIGluIEd1aXggaXMNCj4gZnJlZSBzb2Z0d2FyZS9nDQoNClRoaXMg
bmV3IHNlbnRlbmNlIGlzIG1vc3QgbGlrZWx5IGZhbHNlLiAgVGhlcmUgaGF2ZSBiZWVuIHBh
Y2thZ2VzIGluIA0KR3VpeCB0aGF0IHdlcmUgbm9uLWZyZWUgYW5kIGhhdmUgYmVlbiBub24t
ZnJlZSwgcXVpdGUgbGlrZWx5IHRoZXJlIHdpbGwgDQpiZSBub24tZnJlZSBwYWNrYWdlcyBp
biBHdWl4IGluIHRoZSBmdXR1cmUuICBJIHdvdWxkIHJhdGhlciBoYXZlIHRoYXQgDQpHdWl4
IGRvZXNuJ3QgbGllIGFib3V0IGl0c2VsZi4NCg0KPj4gK2NvbW11bml0eSAoaS5lLiwgcGF0
dGVybnMgdGhhdCBhcHBlYXIgdGhyb3VnaG91dCBAY29kZXtnbnUvcGFja2FnZXMvLi4ufSkN
Cj4gDQo+IE5vcm1hbGx5IHN1Y2ggcGFyZW50aGV0aWNhbCBleHByZXNzaW9ucyBnbyBiZXR3
ZWVuIGVtIGRhc2hlczoNCj4gDQo+ICAgY29tbXVuaXR5LS0taS5lLiwgcGF0dGVybnMgdGhh
dCBhcHBlYXIgdGhyb3VnaG91dA0KPiAgIEBmaWxle2dudS9wYWNrYWdlc30tLS1hbmQg4oCm
DQoNCkVyciwgc291cmNlPyAgTm9ybWFsbHkgcGFyZW50aGV0aWNhbCBleHByZXNzaW9ucyBn
byBiZXR3ZWVuIHBhcmVudGhlc2VzLiANCiAgQWxzbywgbm9ybWFsaXR5IGlzIGlycmVsZXZh
bnQuDQoNCj4+ICtUbyBtYWtlIHRoaW5ncyBtb3JlIGNvbmNyZXRlIGFuZCB0byByZXNvbHZl
IGNvbmZsaWN0cyBiZXR3ZWVuIHRoZQ0KPj4gK3ByaW5jaXBsZXMsIGEgZmV3IGNhc2VzIGhh
dmUgYmVlbiB3b3JrZWQgb3V0Og0KPj4gKw0KPj4gK0BzdWJzdWJzZWN0aW9uIFJlbW92aW5n
IG5vbi1mcmVlIHNvZnR3YXJlDQo+PiArTm9uLWZyZWUgc29mdHdhcmUgaGFzIHRvIGJlIHJl
bW92ZWQgaW4gc25pcHBldHM7IHRoZSByZWFzb24gaXMgdGhhdA0KPj4gK3BhdGNoZXMgb3Ig
cGhhc2VzIHdpbGwgbm90IHdvcmsuDQo+IA0KPiBZb3UgY2Fu4oCZdCBoYXZlIGEgY29sb24g
YmV0d2VlbiB0aGUgc2VjdGlvbiBoZWFkaW5nLiAgSW5zdGVhZCwgeW91IGNhbg0KPiB3cml0
ZSDigJxhIGZldyBjYXNlcyBoYXZlIGJlZW4gd29ya2VkIG91dCBhbmQgd2lsbCBiZSBpbGx1
c3RyYXRlZCBpbiB0aGUNCj4gZm9sbG93aW5nIHNlY3Rpb25zLuKAnQ0KDQpZb3UgZGVmaW5p
dGVseSBjYW4gaGF2ZSBhIGNvbG9uIGJldHdlZW4gdGhlIHNlY3Rpb24gaGVhZGluZywgSSBq
dXN0IGRpZCANCnNvLiAgQWxzbywgdGhhdCBuZXcgc2VudGVuY2UgaGFzIGEgZGlmZmVyZW50
IG1lYW5pbmcuDQoNCiA+IFNlY3Rpb24gdGl0bGVzIHNob3VsZCBiZSBjYXBpdGFsaXplZC4N
Cg0KVGhlIGxldHRlciBSIGlzIGNhcGl0YWxpemVkLiAgSSBkaXNhZ3JlZSB0aGF0IG5vbi1m
aXJzdCB3b3JkcyBzaG91bGQgYmUgDQpjYXBpdGFsaXplZCwgYnV0IEkgc3VwcG9zZSB0aGF0
J3MgYSBzdHlsZSBjaGFuZ2UgdGhhdCwgaWYgZG9uZSwgc2hvdWxkIA0KYmUgc2VwYXJhdGUg
ZnJvbSB0aGlzIHBhdGNoLg0KDQo+IExlYXZlIGEgYmxhbmsgbGluZSBhZnRlciB0aGUgc2Vj
dGlvbiB0aXRsZS4NCg0KV2h5Pw0KDQo+IEluc3RlYWQgb2Yg4oCcd2lsbCBub3Qgd29ya+KA
nSwgd2hpY2ggaXMgdmFndWUsIEnigJlkIHN1Z2dlc3QgbW9yZSBleHBsaWNpdA0KPiB3b3Jk
aW5nOiDigJx3b3VsZCBub3QgYmUgYXBwcm9wcmlhdGUgYmVjYXVzZSB0aGV5IHdvdWxkIGV4
cG9zZSB0aGUNCj4gb2ZmZW5kaW5nIGNvZGUu4oCdDQoNClRvIGJlIG1vcmUgcHJlY2lzZToN
Cg0Kcy93b3VsZCBub3QgYmUgYXBwcm9wcmlhdGUvd291bGQgYmUgaW5hcHByb3ByaWF0ZQ0K
DQrigJhleHBvc2UgY29kZeKAmSBhbmQg4oCYb2ZmZW5kaW5nIGNvZGXigJkgc2VlbXMgcmF0
aGVyIHZhZ3VlIHRvIG1lLiAg4oCYd2lsbCBub3QgDQp3b3Jr4oCZIG1pZ2h0IGJlIHNsaWdo
dGx5IHZhZ3VlLCBidXQgaXQncyBjbGVhciBmcm9tIGNvbnRleHQgKGkuZS4sIHRoZSANCndv
cmRzIGJlZm9yZSB0aGUgc2VtaWNvbG9uKS4gIEFsc28sIGRpZG4ndCB5b3UgaGF2ZSBjb21w
bGFpbnRzIGFib3V0IA0KZGVuc2VuZXNzPw0KDQo+PiArRm9yIHBhdGNoZXMsIHRoZSBwcm9i
bGVtIGlzIHRoYXQgYSBwYXRjaCByZW1vdmluZyBhIG5vbi1mcmVlIGZpbGUNCj4+ICthdXRv
bWF0aWNhbGx5IGNvbnRhaW5zIHRoZSBub24tZnJlZSBmaWxlQGZvb3Rub3Rle0l0IGhhcyBi
ZWVuIG5vdGVkIHRoYXQNCj4+ICtnaXQgcGF0Y2hlcyBzdXBwb3J0IHJlbW92aW5nIGZpbGVz
IHdpdGhvdXQgaW5jbHVkaW5nIHRoZSBmaWxlIGluIHRoZQ0KPj4gK3BhdGNoIGluDQo+PiAr
QHVybHtodHRwczovL3loZXRpbC5vcmcvZ3VpeC84YjEzZTg5OS1lYjYwLTQ5MGItYTI2OC02
MzkyNDk2OThjODFAQHd3dy5mYXN0bWFpbC5jb20vfS4gSWYNCj4+ICtpdCBpcyB2ZXJpZmll
ZCB0aGF0IHRoZSBAY29tbWFuZHtwYXRjaH0gdXRpbGl0eSBzdXBwb3J0cyBzdWNoIHBhdGNo
ZXMsDQo+PiArdGhpcyBtZXRob2QgY2FuIGJlIHVzZWQgYW5kIHRoaXMgcG9saWN5IGFkanVz
dGVkIGFwcHJvcHJpYXRlbHkufSwgYW5kIHdlDQo+PiArZG8gbm90IHdhbnQgYW55dGhpbmcg
bm9uLWZyZWUgaW4gR3VpeCBldmVuIGlmIG9ubHkgaW4gaXRzIHBhdGNoZXMuDQo+IA0KPiBJ
4oCZZCBkcm9wIHRoZSBmb290bm90ZSwgaXTigJlzIGFscmVhZHkgZGVuc2UgZW5vdWdoLg0K
DQpJIHdvdWxkIHJhdGhlciBrZWVwIHRoZSBmb290bm90ZSAtLSB0aGVyZSBhcmUgbm8gZmls
ZSBzaXplIGNvbmNlcm5zIGZvciANCmluZm8gZmlsZXMsIGl0IGNvbnRhaW5zIHVzZWZ1bCBp
bmZvcm1hdGlvbiwgYW5kIGl0J3MgYSBfZm9vdG5vdGVfLiAgT25lIA0Kb2YgdGhlIG1haW4g
YmVuZWZpdHMgb2YgZm9vdG5vdGVzIGlzIHRoYXQgdGhleSBhcmUgb3V0IG9mIHRoZSB3YXkg
YW5kIA0KeW91IGNhbiBqdXN0IHNraXAgdGhlbSBpZiB5b3UgZG9uJ3Qgd2FudCB0byByZWFk
IHRoZW0/DQoNCj4gcy9zbmlwcGV0cyBoZXJlOi9zbmlwcGV0cyBoZXJlLi8NCg0KRXJyLCBu
bz8gRGlyZWN0bHkgYWZ0ZXIgdGhpcyBzZW50ZW5jZSBJJ20gc2F5aW5nIHdoaWNoIHRoZSBi
ZW5lZml0cyBhcmUsIA0Kc28gdGhpcyBzaG91bGQgYmUgJzonLCBub3QgJy4nIC0tICc6JyBp
cyBzdHJpY3RseSBiZXR0ZXIgaGVyZS4NCg0KPiBzL1doZW4gdXNpbmcgc25pcHBldHMvRmly
c3QsIHdoZW4gdXNpbmcgc25pcHBldHMvDQoNClRoZSBuZXh0IHNlbnRlbmNlcyBkb24ndCBk
byDigJhTZWNvbmQsIC4uLuKAmSwg4oCYVGhpcmQsIC4uLuKAmSwgc28gbm8uDQoNCj4gVG9n
Z2xlIHF1b3RlICgyIGxpbmVzKQ0KPj4gK0FzIHN1Y2gsIHNuaXBwZXRzIGFyZSByZWNvbW1l
bmRlZCBoZXJlLg0KPiANCj4gcy9hcmUgcmVjb21tZW5kZWQgaGVyZS9hcmUgdGhlIHJlY29t
bWVuZGVkIHdheSB0byBkZWxldGUgbm9uLWZyZWUgbWF0ZXJpYWwvDQoNCk5vLiAgUGxlYXNl
IHNlZSBzZWUgdGhlIHN1YnN1YnNlY3Rpb24gdGl0bGU6DQoNCiA+ICtAc3Vic3Vic2VjdGlv
biBSZW1vdmluZyBidW5kbGVkIGxpYnJhcmllcw0KDQpJdCdzIG5vdCBtZXJlbHkgYWJvdXQg
bm9uLWZyZWUgbWF0ZXJpYWwgaW4gaW4gYnVuZGxlZCBsaWJyYXJpZXMsIGl0IGlzIA0KYWJv
dXQgYWxsIGJ1bmRsZWQgbGlicmFyaWVzLiAgSXQgaXMgbm90IGFib3V0IGFsbCBub24tZnJl
ZSBtYXRlcmlhbCwgYnV0IA0Kb25seSBhYm91dCBtYXRlcmlhbCBpbiBidW5kbGVkIGxpYnJh
cmllcyAodW5idW5kbGVkIG5vbi1mcmVlIG1hdGVyaWFsIA0KYXJlIHRyZWF0ZWQgaW4gdGhl
IHByZXZpb3VzIHN1YnN1YnNlY3Rpb24pLg0KDQpBcyBzdWNoLCB0aGUgcHJvcG9zZWQgbmV3
IHNlbnRlbmNlIGRvZXMgbm90IGZpdCB0aGUgc3Vic3Vic2VjdGlvbi4NCg0KPiBUb2dnbGUg
cXVvdGUgKDIgbGluZXMpDQo+PiArQHN1YnN1YnNlY3Rpb24gRml4aW5nIHRlY2huaWNhbCBp
c3N1ZXMgKGNvbXBpbGF0aW9uIGVycm9ycywgdGVzdCBmYWlsdXJlcywgb3RoZXIgYnVncyAu
Li4pDQo+IA0KPiBJbiBhZGRpdGlvbiB0byBjYXBpdGFsaXppbmcsIHBsZWFzZSByZW1vdmUg
dGhlIHBhcmVudGhldGljYWwgYml0Lg0KDQpOby4gIOKAmFRlY2huaWNhbCBpc3N1ZXPigJkg
aXMgdmFndWUsIHRoZSBwYXJlbnRoZXRpY2FsIGJpdCBjbGFyaWZpZXMgDQp0aGluZ3MuICBC
ZXNpZGVzLCBpbiBhbm90aGVyIGNvbW1lbnQgZm9yIHNvbWV0aGluZyBlbHNlIHlvdSB3YW50
ZWQgDQp0aGluZ3MgdG8gYmUgbGVzcyB2YWd1ZSBieSBhZGRpbmcgYWRkaXRpb25hbCB0ZXh0
Lg0KDQogPiBDb3VsZCB5b3Ugc2VuZCBhbiB1cGRhdGVkIHZlcnNpb24/DQoNCk5vLiAgVGhl
IGNvbnRpbnVlZCBtaXN1bmRlcnN0YW5kaW5nIGVsc2V3aGVyZSBpbiB0aGUgdGhyZWFkIGFu
ZCB0aGUgDQppbmNvbnNpc3RlbmN5IGFuZCBvY2Nhc2lvbmFsIHZhZ3VlbmVzcyBpbiBhcmd1
bWVudHMgaXMgdGlyZXNvbWUuDQoNCkJlc3QgcmVnYXJkcywNCk1heGltZSBEZXZvcy4NCg==

--------------mKQHC2belrlmtdGnqsSDj182
Content-Type: application/pgp-keys; name="OpenPGP_0x49E3EE22191725EE.asc"
Content-Disposition: attachment; filename="OpenPGP_0x49E3EE22191725EE.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xjMEX4ch6BYJKwYBBAHaRw8BAQdANPb/d6MrGnGi5HyvODCkBUJPRjiFQcRU5V+m
xvMaAa/NL01heGltZSBEZXZvcyA8bWF4aW1lLmRldm9zQHN0dWRlbnQua3VsZXV2
ZW4uYmU+wpAEExYIADgWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCX4ch6AIbAwUL
CQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRBJ4+4iGRcl7japAQC3opZ2KGWzWmRc
/gIWSu0AAcfMwyinFEEPa/QhUt2CogD/e2RdF4CYAgaRHJJmZ9WU7piKbLZ7llB4
LzgezVDHggzNJU1heGltZSBEZXZvcyA8bWF4aW1lZGV2b3NAdGVsZW5ldC5iZT7C
kAQTFggAOBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJf56ycAhsDBQsJCAcDBRUK
CQgLBRYCAwEAAh4BAheAAAoJEEnj7iIZFyXujpQBAKV1SwDDl4f24rXciDlB9L8W
ycZt30CgbewMSRQk4mvbAP9dFMbVVixYBd6C8cfhR+NsOBGiOJnQABlUmgNuqGFJ
Dc44BF+HIegSCisGAQQBl1UBBQEBB0BOlzIWiJzgobMF6/cqwLaLk7jIcFSZ++c0
k9cCNT6YXwMBCAfCeAQYFggAIBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJfhyHo
AhsMAAoJEEnj7iIZFyXuMr0BAJc8cl5PGvVmVuSQVKjleNl4DK1/XAaPAYPe34AE
fZJPAP9IqLCQhH/FeJanHqBP8gNdGNI2qn8RnnLVfRJgUjZ1BA=3D=3D
=3DOVqp
-----END PGP PUBLIC KEY BLOCK-----

--------------mKQHC2belrlmtdGnqsSDj182--

--------------YuWL9z5PnyeAGoTKCiXBNRQ6--

--------------F9b0xHfWx2yLlTzzDl8Ar42J
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wnsEABYIACMWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCZSlQ3QUDAAAAAAAKCRBJ4+4iGRcl7kbF
APsF4aNm31Y2pABe7MvA8/Fz6vs5FoytQl8KIkKj36ELLQEA+iID5WeiMr3M70cPbZ9j3svgnQBW
2zZSq+13EKO64QM=
=6JlF
-----END PGP SIGNATURE-----

--------------F9b0xHfWx2yLlTzzDl8Ar42J--

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#57598] [PATCH] doc: Update contribution guidelines on patches, etc.
References: <20220905160048.18173-1-maximedevos@HIDDEN>
In-Reply-To: <20220905160048.18173-1-maximedevos@HIDDEN>
Resent-From: Maxime Devos <maximedevos@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Fri, 13 Oct 2023 14:24:01 +0000
Resent-Message-ID: <handler.57598.B57598.16972069876146 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 57598
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: moreinfo patch
To: 57598 <at> debbugs.gnu.org, Maxim Cournoyer <maxim.cournoyer@HIDDEN>
Received: via spool by 57598-submit <at> debbugs.gnu.org id=B57598.16972069876146
          (code B ref 57598); Fri, 13 Oct 2023 14:24:01 +0000
Received: (at 57598) by debbugs.gnu.org; 13 Oct 2023 14:23:07 +0000
Received: from localhost ([127.0.0.1]:47035 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qrJ4E-0001b4-NA
	for submit <at> debbugs.gnu.org; Fri, 13 Oct 2023 10:23:07 -0400
Received: from albert.telenet-ops.be ([2a02:1800:110:4::f00:1a]:41982)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <maximedevos@HIDDEN>) id 1qrJ4C-0001aH-9I
 for 57598 <at> debbugs.gnu.org; Fri, 13 Oct 2023 10:23:05 -0400
Received: from [IPV6:2a02:1808:87:3d3a:d21a:b3f4:d302:52bc]
 ([IPv6:2a02:1808:87:3d3a:d21a:b3f4:d302:52bc])
 by albert.telenet-ops.be with bizsmtp
 id xSNX2A00P26bbaT06SNYUK; Fri, 13 Oct 2023 16:22:33 +0200
Message-ID: <e1efb06c-13ad-5824-7adf-cc2f00dc4026@HIDDEN>
Date: Fri, 13 Oct 2023 16:22:31 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.13.0
Content-Language: en-US
From: Maxime Devos <maximedevos@HIDDEN>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------PQR6XHaqTAIATYck8XUdJcNa"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r23;
 t=1697206953; bh=phwJz3pgIN+BtxI3Ee341Qn/GofU+66VJfglQfyxo3c=;
 h=Date:To:From:Subject;
 b=e5gw9BNZHqG539oaGD8fM4I8Wpz/bLckaPWet9+/y399WbH7BD9PSfmA9YlHgdi9u
 sha19vUsktxX59fFX3a9RY3nBUKiSrfz7EpoWn2J0imFngstnarGLU8Co1WNLL597d
 kurff0Z3Uw77tdVFGV3W44Pk9P8eo34jfsdREWnx/GumpiUIzcJLI3K+BiNRxcJvrO
 hkMNSGsJA32DOvXt7K7SEYrULPRo69bPzRjhcln3V3Em9NzGxb5wrRTEFJPc9rtgnx
 CUi8fjTGGgopjHSV8qPizFy99AKuophYxcQblN1Q9Zj8nShOcNe9Wu002HIu8982FQ
 Ccymnb3wETefw==
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------PQR6XHaqTAIATYck8XUdJcNa
Content-Type: multipart/mixed; boundary="------------QH8AmV6REWg7w11pORmG77Tf";
 protected-headers="v1"
From: Maxime Devos <maximedevos@HIDDEN>
To: 57598 <at> debbugs.gnu.org, Maxim Cournoyer <maxim.cournoyer@HIDDEN>
Message-ID: <e1efb06c-13ad-5824-7adf-cc2f00dc4026@HIDDEN>
Subject: Re: [PATCH] doc: Update contribution guidelines on patches, etc.

--------------QH8AmV6REWg7w11pORmG77Tf
Content-Type: multipart/mixed; boundary="------------7dgZ2hXDJQVhbPfvPEpqflqG"

--------------7dgZ2hXDJQVhbPfvPEpqflqG
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

PiANCj4gICAgIFRoZSBzb3VyY2Ugb2YgdGhlIHBhY2thZ2UgbmVlZHMgdG8gY29ycmVzcG9u
ZCB0byB3aGF0IGlzIGFjdHVhbGx5IGJ1aWx0DQo+ICAgICAoaS5lLiwgYWN0IGFzIHRoZSBj
b3JyZXNwb25kaW5nIHNvdXJjZSksIHRvIGZ1bGZpbGwgb3VyIGV0aGljYWwgYW5kDQo+ICAg
ICBsZWdhbCBvYmxpZ2F0aW9ucy4NCg0KKE5vdGU6IHRoaXMgbWF5IG5lZWQgdG8gYmUgY2hh
bmdlZCBhIGJpdCwgaW4gdGhlIHNlbnNlIG9mICJndWl4IGJ1aWxkIA0KLS1zb3VyY2U9dHJh
bnNpdGl2ZSxhbGwiIGluc3RlYWQgIG9mICJndWl4IGJ1aWxkIC0tc291cmNlIi4pDQoNCj4g
VGhpcyBhbHNvIHNlZW1zIHdvcmRlZCB0b28gc3Ryb25nbHkgLS0gSSBkb24ndCB0aGluayBH
dWl4IGlzIGJvdW5kIHRvDQo+IHRoZSBjb25jZXB0IG9mIHRoZSAiY29ycmVzcG9uZGluZyBz
b3VyY2UiLCBhbHRob3VnaCBpdCBpcyBhIG5pY2UNCj4gcHJvcGVydHkuDQoNCkFzIGxvbmcg
YXMgY29weXJpZ2h0IGxhdyBleGlzdHMgaW4gc29tZXRoaW5nIHN1ZmZpY2llbnRseSBjbG9z
ZSB0byBpdHMgDQpjdXJyZW50IGZvcm0sIGFzIGxvbmcgYXMgR3VpeCBjb250YWlucyBHUEwg
c29mdHdhcmUgYW5kIGFzIGxvbmcgYXMgR3VpeCANCmludGVuZHMgdG8gYmUgbGVnYWwsIEd1
aXggaXMgYm91bmQgdG8gdGhlIGNvbmNlcHQgb2YgY29ycmVzcG9uZGluZyBzb3VyY2UuDQoN
CklmIEd1aXggZGVjaWRlcyBpdCBpc24ndCBib3VuZCBieSB0aGUgY29uY2VwdCBvZiBjb3Jy
ZXNwb25kaW5nIHNvdXJjZSwgDQp0aGVyZSBpcyBzb21lIHNvZnR3YXJlIGluIEd1aXggSSBh
bSBhIGNvcHlyaWdodCBob2xkZXIgb2YgYW5kIHRoZSBHUEwgDQpoYXMgYSBzZWN0aW9uIOKA
mDguICBUZXJtaW5hdGlvbuKAmS4gIElJUkMsIGxhc3QgdGltZSBJIGNoZWNrZWQsICJndWl4
IGJ1aWxkIA0KLS1zb3VyY2VzPXRyYW5zaXRpdmUsYWxsIHNjaGVtZS1nbnVuZXQgZ3VpbGUt
ZmliZXJzIiBzdGlsbCB3b3JrcywgYnV0IGlmIA0KdGhhdCBmdW5jdGlvbmFsaXR5IGlzIHJl
bW92ZWQgd2l0aG91dCBhIHJlcGxhY2VtZW50IC4uLg0KDQpCZXN0IHJlZ2FyZHMsDQpNYXhp
bWUgRGV2b3MNCg==
--------------7dgZ2hXDJQVhbPfvPEpqflqG
Content-Type: application/pgp-keys; name="OpenPGP_0x49E3EE22191725EE.asc"
Content-Disposition: attachment; filename="OpenPGP_0x49E3EE22191725EE.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xjMEX4ch6BYJKwYBBAHaRw8BAQdANPb/d6MrGnGi5HyvODCkBUJPRjiFQcRU5V+m
xvMaAa/NL01heGltZSBEZXZvcyA8bWF4aW1lLmRldm9zQHN0dWRlbnQua3VsZXV2
ZW4uYmU+wpAEExYIADgWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCX4ch6AIbAwUL
CQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRBJ4+4iGRcl7japAQC3opZ2KGWzWmRc
/gIWSu0AAcfMwyinFEEPa/QhUt2CogD/e2RdF4CYAgaRHJJmZ9WU7piKbLZ7llB4
LzgezVDHggzNJU1heGltZSBEZXZvcyA8bWF4aW1lZGV2b3NAdGVsZW5ldC5iZT7C
kAQTFggAOBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJf56ycAhsDBQsJCAcDBRUK
CQgLBRYCAwEAAh4BAheAAAoJEEnj7iIZFyXujpQBAKV1SwDDl4f24rXciDlB9L8W
ycZt30CgbewMSRQk4mvbAP9dFMbVVixYBd6C8cfhR+NsOBGiOJnQABlUmgNuqGFJ
Dc44BF+HIegSCisGAQQBl1UBBQEBB0BOlzIWiJzgobMF6/cqwLaLk7jIcFSZ++c0
k9cCNT6YXwMBCAfCeAQYFggAIBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJfhyHo
AhsMAAoJEEnj7iIZFyXuMr0BAJc8cl5PGvVmVuSQVKjleNl4DK1/XAaPAYPe34AE
fZJPAP9IqLCQhH/FeJanHqBP8gNdGNI2qn8RnnLVfRJgUjZ1BA=3D=3D
=3DOVqp
-----END PGP PUBLIC KEY BLOCK-----

--------------7dgZ2hXDJQVhbPfvPEpqflqG--

--------------QH8AmV6REWg7w11pORmG77Tf--

--------------PQR6XHaqTAIATYck8XUdJcNa
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wnsEABYIACMWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCZSlSpwUDAAAAAAAKCRBJ4+4iGRcl7txr
AQD6owrhNNysD2fTlNXg0LVmvlEMOKyhWnxBlbLN+A8CkQD8Du9RDc0+UbPY2CclSrLOoGSd9x/B
nGBOxYw9UEZEtwo=
=ATVO
-----END PGP SIGNATURE-----

--------------PQR6XHaqTAIATYck8XUdJcNa--

Last modified: Fri, 13 Oct 2023 14:30:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.