From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id cLRZE6qn92ThwAAAG6o9tA:P1 (envelope-from ) for ; Wed, 06 Sep 2023 00:11:54 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id cLRZE6qn92ThwAAAG6o9tA (envelope-from ) for ; Wed, 06 Sep 2023 00:11:54 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 0F12E3BC09 for ; Wed, 6 Sep 2023 00:11:49 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=wolfsden.cz header.s=mail header.b=K2tGLGZC; dkim=pass header.d=wolfsden.cz header.s=mail header.b=tFJbc5jD; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=wolfsden.cz ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1693951909; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=IpmY5Xs9otMoeshkh91qJiWF88OcZz5JxvFwpGUIlME=; b=poCpOj0QVODna/zcuRG4oINJXJ7AqSOip1/CyEfTigpAD3etBTs/hMvfQXhHypjQl22ugj nx+/e/Wu/XreKQz0RFwUD53cP/bUbttkadNcG3gJW57MXAahjhGxlhD/aVnWnzDYYidNSg 4X7utVALAGO+zbQ27cMN2EHMLgx7ZHctsIuANNzBkv54zXAzbPieVF2vywkygCCOkwCiG0 I5lWuAErwEmFUx4TEfz2C0emsWSiPYV/hjHPO2kOg7TNXeo8bcf89KNwjmlupEEz+VieHP UC63WWyRvyIBZxdANZS7BeHwsSXFcA1TNIbxEg6O7vSRckTF8+uSLln3BS6HHA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=wolfsden.cz header.s=mail header.b=K2tGLGZC; dkim=pass header.d=wolfsden.cz header.s=mail header.b=tFJbc5jD; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=wolfsden.cz ARC-Seal: i=1; s=key1; d=yhetil.org; t=1693951909; a=rsa-sha256; cv=none; b=hn/GXcW0lTc5Lhe3XEzyhYikD1ak0lyFK7oevaxkFuICtivMyiQcI/3T9LyO0Ey+1NJZDB JIgg5o66nZ6s46AqGj2N/+XxARPn8mJ5qx0G3LH8KzsYXA57BaocGdLq6wV3XFNyXuCujs WB3s8oFb88a3MsjCRmoNDR+jcqckyEMOP1pbHtJIJHOV0HK5t8vUmpwzu+Pz1om+pAihpN RZ2j7My2MLoLc21W7ADWjUIA2AvpDVVWf0pP4eftVapnAZd0AVpThf1DUwqlqOVJ3Pj51x 8FjkLlh/pPgeNGB0u1dwv8Hg23y0gKDe8bKOci0ulZeZQAPyza33XQ37Nm/nJQ== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qdeGV-0004hM-QV; Tue, 05 Sep 2023 18:11:20 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qdeGT-0004ge-JC for guix-devel@gnu.org; Tue, 05 Sep 2023 18:11:17 -0400 Received: from wolfsden.cz ([37.205.8.62]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qdeGO-0000ti-3f for guix-devel@gnu.org; Tue, 05 Sep 2023 18:11:15 -0400 Received: by wolfsden.cz (Postfix, from userid 104) id 4458325820B; Tue, 5 Sep 2023 22:11:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wolfsden.cz; s=mail; t=1693951868; bh=hUB4rbwcpc93Su+U3vHuWZ16AkLXa/oul9xGSEJAMzc=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=K2tGLGZChw5QjXT2yx/VoN0bKbMzZFAr5J/Aojx/Jt22IdSGpd4YcR5QUX7N9JYya 8wimjgMyKKMsJpn+eb9qRTtrxDpVdKtY5HbNqFKt+O4E6Gr4QY/6Ust62JKxUr8iRN tPtvzGxElNnKTgR4plb3lh/GhCC7EEJyaaR8KBHRRpdeC2J9BaFv9yOL8ruERR0blD f/XqlBnBrrY1q01le0QAf+ydP4R7qYdPP4HUt5tE6BbpDSVtBSRHrwCZhzWG3PwfdG 4ozC7ZKTEYVCuBPxmgBwWh9vyF/NGgL6ZBf1ePyq9qN8QqMDp5XtAd66uKfhZ1u6Mg D9eEXCZf7Vv9qFp+L1pErEghkBV+omCN7hjN7Z4cgnzMKtSaWtAREVhPAxqo6RUKKJ 17yZlrZYOdvSyJIZBu9vTtaITKxrdmZeVDqZEO0ulLL7gzzCDxhX2K36zRT9bUFlSw SaPnnqtV6Vf+Vu0Qwr0rhBAt6oygiZVzD7cHa4H+Fuap73i6m+aHYmKFu0JpV/2GJX AuT/maYvaGtmErCe1uWi9FRcL4ZU/MYD1+1gzObNlNeQlX+8yJHYKKYEcVE65yZRaX QUhuZWhqgyyHot4V3iHNGl2a4j7botBsWqTQdp5I+vsn8K0Q8KHKm9taXAUsXvddDR +cz63rinBqvwwu8/mtuc0lYc= Received: from localhost (unknown [193.32.127.157]) by wolfsden.cz (Postfix) with ESMTPSA id 2CA4727E671; Tue, 5 Sep 2023 22:11:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wolfsden.cz; s=mail; t=1693951861; bh=hUB4rbwcpc93Su+U3vHuWZ16AkLXa/oul9xGSEJAMzc=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=tFJbc5jDUg4JJBF7/dfElr6W7yFSik9qjlOCGYF66WNyS6ez4ISzgQhV4YlvMrfFH AZgeW/rO0s7Qxf6lYy55kQdMEQzDln/4Zl1p8NJKjwwKT885SQf6wqtbcd7tcr4/4T by6/0TiZKkuRjB9ceuIiZBx39CdHyrZuSBqRiqkw3zP5a+mwrTs4LI/NbDj2HjcbwO wRYWpWvNixZzq1RI4L03M5bLG0YLRxt8+aPCZmjH038db14feR2O/4m1sBUGkSmNQj lX6jGuqfl8CaDbPreRZoHLqCVKSVr5714cjVZGzRh8eThkoCd2l8LZnkM7RzXDXQVc 7iiELtTWx2VpEEX8YmNEh61/5y3casHnDogPueWflVReQrVCy08BGzntm+B0aMLUhd 4CNVz5vmFfWTtBjRn2BTshvZeZ2zFvVDxUr1ahrOrwOiUjo5U0k/WIZFj85zLzgyBa 4ESRC01NoRzKEDJ+YIX3K1jGMHdrCG7bRUIVYj1NgCtFAUuYuV7E3GX6mQ6Sqha2Iv Q5AN7mQ5H4XeKErz1+9WyY8TDfIpxSLZ5Aw5yysawds5qBEHPJszuzG5RilXwDJYWk 4BqpWocBD3qpOvK5QJO2B4eJ9SGIngj7vR4R1NgKmr9s9tWtaUbsE39A/99AaFLN3t wzQcgmHilaFL/54ohtPi44GI= Received: from localhost (localhost [local]) by localhost (OpenSMTPD) with ESMTPA id 6eab378b; Tue, 5 Sep 2023 22:11:00 +0000 (UTC) Date: Wed, 6 Sep 2023 00:11:00 +0200 From: wolf To: Simon Tournier Cc: Katherine Cox-Buday , guix-devel , Vagrant Cascadian Subject: Re: How can we decrease the cognitive overhead for contributors? Message-ID: Mail-Followup-To: Simon Tournier , Katherine Cox-Buday , guix-devel , Vagrant Cascadian References: <871qfsuvad.fsf@gmail.com> <8e74c4ac-a6f3-9127-7e13-593a2eb70432@gmail.com> <87a5ubqxm6.fsf@gmail.com> <861qfcvhw2.fsf@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="eTxH+Aq/Eyy2cfbF" Content-Disposition: inline In-Reply-To: <861qfcvhw2.fsf@gmail.com> Received-SPF: none client-ip=37.205.8.62; envelope-from=ws@wolfsnet.cz; helo=wolfsden.cz X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_PASS=-0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Queue-Id: 0F12E3BC09 X-Migadu-Scanner: mx1.migadu.com X-Migadu-Spam-Score: -5.91 X-Spam-Score: -5.91 X-TUID: GObbEW6ThOPR --eTxH+Aq/Eyy2cfbF Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2023-09-05 16:01:17 +0200, Simon Tournier wrote: > Hi Katherine, >=20 > Thank you for your extensive analysis. I concur. >=20 > On Wed, 30 Aug 2023 at 10:11, Katherine Cox-Buday wrote: >=20 > > 3. We should reify a way for Guix, the project, to measure, and track= =20 > > progress, > > =C2=A0=C2=A0 against long-term goals. Particularly when they're social= and not=20 > > strictly > > =C2=A0=C2=A0 technical. >=20 > That is the most difficult part, IMHO. Well, what are the long-term > goals? :-) >=20 > I am almost sure we will get various answers depending on people. Let > say the long-term goals of the Guix project are: Liberating, Dependable > and Hackable. Then how do you give concrete quantities that we can > measure or track? >=20 > And it is always difficult, if not impossible, to measure or track some > goals that are not technical but social. For example, how do you > measure being welcoming or being a safe place for all? >=20 > Do not take me wrong, I strongly think we must think again and again on > that point for improving. It=E2=80=99s just easier to tackle technical b= ug. :-) >=20 >=20 > > =C2=A0 11. Try and get each commit message close to correct and commit. >=20 > > I view steps 1-10 as pretty standard "development" steps common to most > > projects, although 11 compounds the effort in 10. >=20 > Maybe I am doing incorrectly but I have never thought much about that. >=20 > For that point #11, from my point of view, it is as with any other > project. I start by running =E2=80=9Cgit log --grep=3D=E2=80=9D for gett= ing inspiration. >=20 > Well, as a rule of thumb, I am doing something like: >=20 > --8<---------------cut here---------------start------------->8--- > top-module: submodule: one line summary. >=20 > Fixes . > Reported by Jane Doe >=20 > * path/to/file.scm (variable):[sub-part]: Description of the change. > [otherpart]: Other description. > * path/to/other/file.scm (other-variable): Description. > --8<---------------cut here---------------end--------------->8--- >=20 > In case of doubt, I am just running =E2=80=9Cgit log --grep=3D=E2=80=9D l= ooking for > similar thing, as said. :-) >=20 >=20 > > =C2=A0 12. Run `guix lint` > > =C2=A0 13. Run `guix style` (this is still in the manual although I ha= ve since > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 learned this is not actually advisable). > > =C2=A0 14. Review the changes these tools have made, and fix things. > > =C2=A0 15. Run `guix build --rounds=3D2 ` to check for idempo= tency. > > =C2=A0 16. Run `make` to ensure you didn't break anything elsewhere in= Guix. > > =C2=A0 17. Run `guix size` to ensure the closure isn't becoming bloate= d. > > =C2=A0 18. Build all the packages that depend on this package. > > =C2=A0 19. Run `guix pull --url=3D/path/to/your/checkout=20 > > --profile=3D/tmp/guix.master` to > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ensure you didn't break Guix in a diffe= rent way. >=20 > > In other projects I've worked with, steps 12-19 are commonly done in a = CI > > pipeline, and courteous people will try to save CI resources by running= =20 > > these > > steps locally first using some kind of environment identical to what CI= runs > > (sometimes a container is used for this. I think Guix has better option= s!). > > Sometimes this is not feasible due to asymmetric resources. But having = the > > option to let CI manage this process is very nice. >=20 > For instance, I am not seeing =E2=80=9Cmake check=E2=80=9D. ;-) And that= omission makes > very clear the cognitive overhead we are speaking about! I personally am glad it is not there, since I never (in ~9 months toying wi= th Guix) had all the checks pass on the clear master. There are always one or= two failing tests. But I guess this was supposed to be taken as "run make check' and make sure nothing new is broken". Is there a command for that? >=20 > Here I see two annoyances: >=20 > 1. The number of subcommands and steps. > 2. Each subcommand has a list of options to digest. >=20 > Well, CI is helpful here, for sure. However, it would be helpful to > have a script similar as etc/teams.scm or etc/committer.scm that would > help to run all these steps. >=20 > It does not mean that all these steps need to be run before each > submission. However having a tool would help irregular contributors or > newcomers; it would decrease the cognitive overhead i.e., that overhead > would be pushed to some script and it would reinforce confidence. >=20 > Now someone=E2=84=A2 needs to implement this script. ;-) >=20 >=20 > > =C2=A0 20. Run `git format-patch -1 --cover-letter [--reroll-count]` > > =C2=A0 21. Run `./pre-inst-env ./etc/teams.scm cc-members ` to = get=20 > > the CC flags for Git > > =C2=A0 22. Remember that if you're sending multiple patches, an email = first=20 > > has to be > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sent to `guix-patches@gnu.org` to get a= n ID, and then... > > =C2=A0 23. Run `git send-email --to guix-patches ` >=20 > Well, my grey hair are biasing my opinion. ;-) From my point of view, > the most annoying is #22. >=20 > Vagrant suggested [1] to send patches as attachment. I am not convinced > it will be better. Well, it will for submitting but will not for > following series. For instance, let consider: >=20 > [bug#65010] [PATCH 0/8] Misc Python build system improvements > Lars-Dominik Braun > Wed, 02 Aug 2023 12:37:57 +0200 > id:cover.1690972374.git.lars@6xq.net > https://issues.guix.gnu.org//65010 > https://issues.guix.gnu.org/msgid/cover.1690972374.git.lars@6xq.net > https://yhetil.org/guix/cover.1690972374.git.lars@6xq.net >=20 > then, one will do reply and probably comment one or more patches over > the 8. Then, it is harder for another person to follow. For example, I > would have to open the message in order to know that this series adds, >=20 > guix: toml: Add TOML parser. >=20 > which could be interesting for Julia. And I would probably skip all the > series because the subject is about Python build system improvements > that I am necessary following. However, if I see the subject, >=20 > guix: toml: Add TOML parser. >=20 > then I open the message and read it. >=20 > Therefore, I do not see any =E2=80=9Cgood=E2=80=9D solution for this poin= t #22. One > idea would be to have a kind of proxy. We would send the whole series > to an hypothetical guix-contributions@gnu.org and then a bot would send > to guix-patches for getting an ID and that bot would send the series to > that ID, probably adding some X-Debbugs-CC for the submitter (and for > teams). Bah, too much =E2=80=9Cwould=E2=80=9D. :-) >=20 >=20 > 1: https://yhetil.org/guix/87wmx8m5gb.fsf@wireframe > Re: How can we decrease the cognitive overhead for contributors? > Vagrant Cascadian > Sat, 02 Sep 2023 18:05:40 -0700 > id:87wmx8m5gb.fsf@wireframe > https://lists.gnu.org/archive/html/guix-devel/2023-09 >=20 >=20 > > If I compare this workflow to the workflow of other contributions I mak= e: > > > > =C2=A0 1-10 as usual > > =C2=A0 11. Write a more commonly accepted commit message with no speci= al=20 > > formatting. >=20 > This depends on the project and I am not convinced we can rule for #11. >=20 > BTW, one strong advantage for this commit message format is that grep > can be exploited. For some reasons, I am often looking for some past > versions, for example, >=20 > --8<---------------cut here---------------start------------->8--- > $ git log --pretty=3D"%h %s" | grep Update | grep vlc > 8d342711dd gnu: vlc: Update to 3.0.17.4. > 5a29cc9ade gnu: vlc: Update to 3.0.17.3. > fb0e5874ec gnu: vlc: Update to 3.0.16. > e2ad110f4c gnu: vlc: Update to 3.0.14. > def314d810 gnu: vlc: Update to 3.0.12. > 6ec120b1c7 gnu: vlc: Update to 3.0.11.1. > 0bed485a39 gnu: vlc: Update to 3.0.11. > 178f1d1f75 gnu: vlc: Update to 3.0.8. > cf40f8e4d7 gnu: vlc: Update to 3.0.7.1. > 94f7f9503a gnu: vlc: Update to 3.0.7. > dba326def1 gnu: vlc: Update to 3.0.6. > ea593fe298 gnu: vlc: Update to 3.0.5. > d0e23e3940 gnu: vlc: Update to 3.0.3, and add more inputs. > 7627705293 gnu: vlc: Update to 3.0.3, and add more inputs. > f137f84923 gnu: vlc: Update to 2.2.8 [fixes CVE-2017-9300, CVE-2017-10699= ]. > dd13aa90d6 gnu: vlc: Update to 2.2.6. > 3bc45ad460 gnu: vlc: Update to 2.2.5.1. > a134cc8e93 gnu: vlc: Update to 2.2.4 [fixes CVE-2016-5108]. > c6c86cd7a5 gnu: vlc: Update input Qt to version 5. > 9c55bae607 gnu: vlc: Update to 2.2.1. > 1a189da0e7 gnu: vlc: Update to 2.2.0. > b9156ccc08 Revert "gnu: vlc: Update to 2.2.0" > ad036bda89 gnu: vlc: Update to 2.2.0 > 23466647a8 gnu: vlc: Update to 2.1.5. > --8<---------------cut here---------------end--------------->8--- >=20 > And because there is some variation with the commit message format, > these are not all the updates of VLC, >=20 > --8<---------------cut here---------------start------------->8--- > $ git log --pretty=3D"%h %s" | grep Update | grep VLC > af74211d98 gnu: VLC: Update to 3.0.18. > 5af110868c gnu: VLC: Update to 3.0.10. > 091ef8c97e gnu: VLC: Update to 3.0.4. > 324c049ff6 gnu: VLC: Update to 3.0.3-1 [fixes CVE-2018-11529]. > --8<---------------cut here---------------end--------------->8--- >=20 > Then =E2=80=9Cguix time-machine --commit=3Dfb0e5874ec -- shell vlc=E2=80= =9D and hop I get > 3.0.16. If the commit message format would not be so strict, this would > be impossible and we would need another external tool. >=20 >=20 > > =C2=A0 12. Run `git push` (subsequent changes are still just `git push= `). > > =C2=A0 13. Go to forge website, click button to open a pull-request. > > =C2=A0 14. Wait for CI to tell you if anything is wrong. >=20 > To be fair, here you forget one important blocker: having an account to > the forge website. >=20 > I do not speak about freedom issues. Just about the fact to open an > account to the forge website. For example, let consider this project: >=20 > https://framagit.org/upt/upt >=20 > And if I want to contribute with a Merge-Request, I need to open an > account to the Gitlab instance of FramaGit and push my code to this > instance, even if I already have my fork living on my own Git > repository and I have no plan to use this FramaGit forge. >=20 >=20 > > If you're so inclined, for a bit of fun, and as a crude way of simulati= ng > > compromised executive functioning, imagine that between each of the=20 > > steps above, > > a year passes. And reflect on what it would be like to gather the energ= y to > > start the process of starting a contribution of some kind, let alone=20 > > follow it > > through to completion. >=20 > I like this way of thinking because it helps to spot some blockers. >=20 > Please note that it is not truly about the complexity of the steps but > about how many steps one is able to complete between two interruptions. > Well, it is a well-known issue about task switching [1]. :-) >=20 > 1: https://en.wikipedia.org/wiki/Task_switching_(psychology) >=20 > Cheers, > simon >=20 --=20 There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. --eTxH+Aq/Eyy2cfbF Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEt4NJs4wUfTYpiGikL7/ufbZ/wakFAmT3p3QACgkQL7/ufbZ/ wamyzBAAmeYA+THHHYPc3MIhOumj/phj/htrDueGdmZm/CJhjUb7wLBxK640qI3v iUyplQjPQsiBcrTbNGKqvQJWZjuo1Z2rOgffZQkNUeSnZ3R610fgYSVjISbJB9WM BejTR1FO0UTdOa1G/36Glv9FYX+Ar0WsJkuLlXXm1xN/6j4HdsrieQgt+GD6DelF 71V839lr32eJd4LCzWSwqJhw3rMrwFShcEppYo/DHBnMti8j23B/apBzehECFy01 AMe8RxEXwmNmPKKICAX9cmJgXhGtOVxlG8KDnK9O0fYQ8ryzG/7ZEuyv9Y/KPUNp qNKliRFS71xKEuOmM5bdVdqPAxGYjvEex5lNw5jgUjRrNVDMzGg3k9msJPyWELMb AbaeVvVkWWZR4KI33WiEeRtcOxtpvbxwBl+INWlOsCBr/fEcZX9wv4idKHCthP8M MfLYnQX2uos5UoJrA5zAZBzNTfWlmYsFC3+D6Jie7vJtZX+Qs+wCIL/GiCdD/iMo ohXHQOIVLV5MDOt/Vj7+e3c2gA9pSpHE/yAgp5j0YVEeTNJAGnEcfV+o6LQqPTkY fQAzpOwoA/p/zM/yqwhoprINjjBrXSja61H1mse9h2f9sm9fPXuIh1HjCGVwZh++ kWSYG9y1okkoGWn/CpvkdqT4KcbgeIWRxkNNbL0qcQzSlBErUVI= =NKL8 -----END PGP SIGNATURE----- --eTxH+Aq/Eyy2cfbF--