summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMatthias Maier <tamiko@43-1.org>2018-04-18 16:21:02 -0500
committerMatthias Maier <tamiko@43-1.org>2018-04-18 16:21:02 -0500
commit64da510053eaaa6e0c31d63c2b4a724b3a960928 (patch)
tree47945a4c5ec813bad5168d5a5f3af3e63bb2d62f
parentUse nicer fixed-width font (diff)
downloadcouncil-64da510053eaaa6e0c31d63c2b4a724b3a960928.tar.gz
council-64da510053eaaa6e0c31d63c2b4a724b3a960928.tar.bz2
council-64da510053eaaa6e0c31d63c2b4a724b3a960928.zip
council/meeting-logs: add 20180408 logs summary
-rw-r--r--meeting-logs/20180408-summary.txt162
-rw-r--r--meeting-logs/20180408-summary.txt.asc17
-rw-r--r--meeting-logs/20180408.txt875
-rw-r--r--meeting-logs/20180408.txt.asc17
4 files changed, 1071 insertions, 0 deletions
diff --git a/meeting-logs/20180408-summary.txt b/meeting-logs/20180408-summary.txt
new file mode 100644
index 0000000..4e175ee
--- /dev/null
+++ b/meeting-logs/20180408-summary.txt
@@ -0,0 +1,162 @@
+Summary of Gentoo Council meeting 08 April 2018
+
+
+Agenda
+======
+
+1. Roll call
+2. Vote on the final EAPI 7 draft
+3. Banning EAPI 4 for new ebuilds (and EAPI bumps of existing ebuilds)
+4. Deprecating EAPI 5
+5. Establish a timeline for the switch to the 17.1 profiles
+ (aka SYMLINK_LIB=no)
+5a. Bugs with Council involvement
+6. Cosmetic update to Gentoo Social Contract
+7. Introducing a voting mechanism similar to Debian's "General resolution"
+8. Establish contact with SPI
+9. Open floor
+
+
+Roll call
+=========
+
+7 attendees: dilfridge, K_F, mgorny, slyfox, tamiko, ulm, WilliamH
+
+
+Vote on the final EAPI 7 draft
+==============================
+
+The Council provisionally approves the EAPI 7 version as of commit
+fc07858 of 2018-04-05. EAPI 7 may be used in ~arch as soon as a portage
+version supporting the final draft is marked ~arch. The final EAPI 7
+approval shall be handled on a bug. (Votes: 7 yes, unanimous)
+
+References:
+ https://dev.gentoo.org/~ulm/pms/7-draft/ in the version of 2018-04-05
+ https://archives.gentoo.org/gentoo-project/message/91df2e7bf8485c2c5abba33ea3063809
+ https://bugs.gentoo.org/630422
+ https://bugs.gentoo.org/424283
+ https://bugs.gentoo.org/489458
+
+
+Banning EAPI 4 for new ebuilds (and EAPI bumps of existing ebuilds)
+===================================================================
+
+The Council bans EAPI 4 for new ebuilds effective immediately. (Votes: 7
+yes, unanimous)
+
+References:
+ https://archives.gentoo.org/gentoo-project/message/e453732a4613485ea26bf754c40df087
+
+
+Deprecating EAPI 5
+==================
+
+The Council postponed EAPI 5 deprecation to the next Council meeting.
+
+References:
+ https://archives.gentoo.org/gentoo-project/message/e453732a4613485ea26bf754c40df087
+
+
+Establish a timeline for the switch to the 17.1 profiles (aka SYMLINK_LIB=no)
+=============================================================================
+
+mgorny reports that work on the 17.1 profiles (that set SYMLINK_LIB=no) and
+a corresponding conversion tool has made significant progress - the
+conversion tool can be regarded to be stable. The 17.1 profiles are
+currently experimental.
+
+The Council approves the direction towards 17.1 amd64 profiles, and
+encourages Gentoo developers to convert their systems and test their
+packages against new profiles. (Votes: 7 yes, unanimous)
+
+References:
+ https://archives.gentoo.org/gentoo-project/message/ecd981409a1fad7911a3547e9b0a315f
+ https://bugs.gentoo.org/506276
+
+
+Bugs with Council involvement
+============================
+
+https://bugs.gentoo.org/637328 - GLEP 14
+---------------------------------------
+
+K_F reports that the security project is working on a GLEP 14 replacement.
+
+
+https://bugs.gentoo.org/642072 - Joint venture on copyright issues
+------------------------------------------------------------------
+
+The agenda item has been postponed to the next Council meeting.
+
+
+https://bugs.gentoo.org/650964 - gentoo-dev@ ML whitelisting
+------------------------------------------------------------
+
+Technical difficulties and a rough timeline have been discussed with
+members of the infra team that were present (prometheanfire, antarus).
+
+
+https://bugs.gentoo.org/652784 - GLEP 61
+----------------------------------------
+
+The Council changed GLEP 61 to final. (Votes: 7 yes, unanimous)
+
+
+Cosmetic update to Gentoo Social Contract
+=========================================
+
+The council intends to do a cosmetic update to the Gentoo Social Contract
+to change the mailing list point of contact to
+
+ gentoo-projects@lists.gentoo.org.
+
+The full wording of the first paragraph will read
+
+ »This social contract is intended to clearly describe the overall
+ development policies and standards of the Gentoo project development
+ team. Parts of this document have been derived from the Debian Social
+ Contract. Comments are welcome. Please send them to our
+ gentoo-project@lists.gentoo.org mailing list.«
+
+The Council requests the Foundation Trustees to approve this change in
+their next meeting. Once approved by the Trustees the Gentoo Social
+Contract shall be updated on the websites. (Votes: 7 yes, unanimous)
+
+References:
+ https://archives.gentoo.org/gentoo-project/message/7dc299781f08ccc6f7b5dca08b4acb06
+ https://archives.gentoo.org/gentoo-project/message/8c8534195597ca34ebb3e3bb0a042b3e
+ https://archives.gentoo.org/gentoo-project/message/2a250ad39db7b400072603f4705e8f57
+
+
+Introducing a voting mechanism similar to Debian's "general resolution"
+=======================================================================
+
+The Council and a number of developers quickly discussed advantages and
+disadvantages of formalizing a developer-wide voting system similarly to
+Debian's "general resolution". tamiko promised to work on a GLEP draft
+together with mrueg.
+
+References:
+ https://www.debian.org/devel/constitution#item-4
+ https://archives.gentoo.org/gentoo-project/message/973be0a662b3cc74aa118a1128dcac9e
+
+
+Establish contact with SPI
+==========================
+
+dilfridge suggested to keep the fruitful relationship of the Gentoo
+distribution with the Gentoo Foundation, and open up an additional
+relationship with SPI as a second legal entity for the matter of holding
+assets and accepting donations.
+
+The Council did not reach a consensus with respect to contacting SPI.
+
+References:
+ https://www.spi-inc.org/
+ https://archives.gentoo.org/gentoo-project/message/de1d47212a9c71a40fc1717ea460cad4
+
+Open floor
+==========
+
+No further topics were discussed during the open floor.
diff --git a/meeting-logs/20180408-summary.txt.asc b/meeting-logs/20180408-summary.txt.asc
new file mode 100644
index 0000000..e1119d7
--- /dev/null
+++ b/meeting-logs/20180408-summary.txt.asc
@@ -0,0 +1,17 @@
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v2
+
+iQIzBAABCgAdFiEEfy3LeT5sTLH/IgxSb5XRn46MCPwFAlrXtoUACgkQb5XRn46M
+CPyZKg//T8dCTbouFLTrpA3Htw/Vvr9EdksdIl3HFnIdf6s3Az4+mFbysbuMyZW5
+ShABWCmya3Or3zccgMSLhcoQTaWorKGx8CdW6FxFpBQgU1Q/zokor5UNyPrMxATZ
+k9nGk7OUvAqa4WWJdYj4/tR3tU9wyi4iJnPVAtgtWT5y9HgA4K+VjsnoGU+WSf7s
+PHN3blT2K2zzCNAFn/EkbxS6Fh22qr5DKNJH9GJJxF+Bvrxc0zglxpmxLAk4Akui
+50EQE1xbi6vlbMemxT9nW4SgRgeQidmoL1X7W5mKZ2oOf3cXlKg+/PPCixqqgeKm
+qM7DvqhsCBENRmSbbAtwXV2r35bB5Q3/oMfDxs9g6JaTSIoSBJ59+GT0hgyscibf
+MWVSEXvk1U8afIVfzMJC6IY0wVGLwl4QdVYoZYdvPhwG0NiCN5ch1DjD1CCOsRpT
+O3Cw8Di6EKbHRrjawQZNkHKx5fn9Ba4UZSHXYHY1HTsVpRhVq6VGdwBLh0/E9G7S
+Y0mB2Xu/Pu825qklYRjgye+vezbiiBe78FYV57mNB74h0+cvApUkDvaH79Z5a59E
+XaF/L2Lm2e9k75uW5CcyvEZaxC0GwUo+y18OJw3K/7VP9wp1FLMsiu8N3Z9BBGNc
+AfRHH59K5VGHkLPZUncVhWvuDdjoAXYGGU5CgUQUXZgD583akRs=
+=vhg2
+-----END PGP SIGNATURE-----
diff --git a/meeting-logs/20180408.txt b/meeting-logs/20180408.txt
new file mode 100644
index 0000000..29ac23f
--- /dev/null
+++ b/meeting-logs/20180408.txt
@@ -0,0 +1,875 @@
+18-04-08 - [17:54] [Users #gentoo-council]
+18-04-08 - [17:54] [@dilfridge ] [+alicef ] [+fuzzyray_ ] [+mpagano ] [+Tommy[D] ] [ Moiman ]
+18-04-08 - [17:54] [@dilfridge|mobile] [+b-man ] [+jcallen ] [+mrueg ] [+twitch153 ] [ necrose99]
+18-04-08 - [17:54] [@K_F ] [+blueness ] [+jmbsvicetto] [+mudler ] [+Whissi ] [ Shentino ]
+18-04-08 - [17:54] [@mgorny ] [+bonsaikitten] [+jmorgan ] [+NeddySeagoon ] [+willikins ] [ sultan ]
+18-04-08 - [17:54] [@slyfox ] [+Chewi ] [+johu ] [+NP-Hardass ] [ [Arfrever]] [ zlin ]
+18-04-08 - [17:54] [@tamiko ] [+Chiitoo ] [+kallamej ] [+pchrist ] [ aewyn ]
+18-04-08 - [17:54] [@ulm ] [+chithead ] [+kensington ] [+prometheanfire] [ andreas303]
+18-04-08 - [17:54] [@WilliamH ] [+FamousEccles] [+kent\n ] [+rich0 ] [ antarus ]
+18-04-08 - [17:54] [+alexxy ] [+floppym ] [+leio ] [+TomJBE_ ] [ dwfreed ]
+18-04-08 - [17:54] -!- Irssi: #gentoo-council: Total of 50 nicks [8 ops, 0 halfops, 32 voices, 10 normal]
+18-04-08 - [17:54] ----------- sultan > i didnt got the cat picture completely, only seeing the paws :(
+18-04-08 - [17:54] -----------@tamiko > !proj council
+18-04-08 - [17:54] --------+willikins > (council@gentoo.org) dilfridge, k_f, mgorny, slyfox, tamiko, ulm, williamh
+18-04-08 - [17:55] -----------@tamiko > ^^^ 5 minute warning
+18-04-08 - [17:55] ---------- *** ulm here
+18-04-08 - [17:55] -----------@tamiko > All, 5 minutes of cat admiration.
+18-04-08 - [17:55] ---------- antarus > sultan: I'm trying to consider the cat pipcture in the best way possible ;)
+18-04-08 - [17:55] -----------@slyfox > pipctures are scary
+18-04-08 - [17:55] ---------- antarus > pip install kittens
+18-04-08 - [17:55] ---------- antarus > etc.
+18-04-08 - [17:56] -----------@tamiko > https://i.ytimg.com/vi/zWepFtJtjX0/maxresdefault.jpg
+18-04-08 - [17:56] --------@dilfridge > cute
+18-04-08 - [17:57] ---+prometheanfire > cats?
+18-04-08 - [17:57] ---------- antarus > prometheanfire: someone asked to put cats on the agenda, irrc
+18-04-08 - [17:57] ---------- antarus > read the list ;p
+18-04-08 - [17:57] ---+prometheanfire > https://photos.app.goo.gl/AGCdwpIggWZCLS2E2
+18-04-08 - [17:58] ---+prometheanfire > I did
+18-04-08 - [17:58] ---+prometheanfire > just had to get a link
+18-04-08 - [17:58] ---------- antarus > awww that one is cutest
+18-04-08 - [17:58] ----------- sultan > some1 should call peta, cats in buckets is not correct ;)
+18-04-08 - [17:58] ---------- antarus > if i fits I sits
+18-04-08 - [17:58] ---+prometheanfire > that one is mine
+18-04-08 - [17:58] ---------- antarus > (which is ironic, my cat hates objects like that)
+18-04-08 - [17:58] ---+prometheanfire > https://photos.app.goo.gl/gnPgRAGmWmiZeO1n1
+18-04-08 - [17:59] ---+prometheanfire > https://photos.app.goo.gl/bIzXSvXJZAXzoNv63
+18-04-08 - [18:00] ----- *** WilliamH is here
+18-04-08 - [18:00] -----------@tamiko > Good. Enough cats for today :-)
+18-04-08 - [18:00] -----------@tamiko > !proj council
+18-04-08 - [18:00] --------+willikins > (council@gentoo.org) dilfridge, k_f, mgorny, slyfox, tamiko, ulm, williamh
+18-04-08 - [18:00] -----------@tamiko > ^^^ Let's start
+18-04-08 - [18:00] ------- *** slyfox is here
+18-04-08 - [18:00] ----- *** WilliamH here
+18-04-08 - [18:00] ---- *** dilfridge here
+18-04-08 - [18:00] ---------- *** K_F here
+18-04-08 - [18:00] ------- *** mgorny here
+18-04-08 - [18:00] ------- *** tamiko here
+18-04-08 - [18:00] ---------- *** ulm here
+18-04-08 - [18:01] -----------@tamiko > OK - item 1. roll call done.
+18-04-08 - [18:01] ------------+Chewi > I'm here and so is my cat
+18-04-08 - [18:01] -----------@tamiko > Let's move on to the technical part. I have reserved the non-technical part for the end ;-)
+18-04-08 - [18:01] ------- *** slyfox amendment: is here (without cat)
+18-04-08 - [18:01] -----------@tamiko > 2. Vote on the final EAPI 7 draft [1]; references [2]
+18-04-08 - [18:02] -----------@tamiko > References: https://dev.gentoo.org/~ulm/pms/7-draft/
+18-04-08 - [18:02] -----------@tamiko > https://archives.gentoo.org/gentoo-project/message/91df2e7bf8485c2c5abba33ea3063809
+18-04-08 - [18:02] --------------@ulm > there's one last minute fix, s/non-negative integer/unsigned integer/ in the section about version functions
+18-04-08 - [18:02] -----------@tamiko > ulm, mgorny: Might I ask you two to quickly summarize the last changes? :-)
+18-04-08 - [18:03] --------------@ulm > the version to (provisionally) approve would be commit fc07858 of 2018-04-05 now
+18-04-08 - [18:03] -----------@mgorny > tamiko: the linked mail says it all
+18-04-08 - [18:03] -----------@mgorny > it's what we voted for minus sandbox rm*, IUSE_RUNTIME and ||=
+18-04-08 - [18:03] -----------@mgorny > and with some wording and formatting fixes
+18-04-08 - [18:03] -----------@mgorny > all implemented in Portage except for SYSROOT which is almost ready
+18-04-08 - [18:04] ------------+Chewi > yep, working on SYSROOT, made progress this week
+18-04-08 - [18:04] --------------@ulm > right, 3 features dropped
+18-04-08 - [18:04] --------------@K_F > to have it on the record, this isn't the final approval, but provisional approval to say we're going in the direction we want, right?
+18-04-08 - [18:04] -----------@tamiko > Yes.
+18-04-08 - [18:04] -----------@mgorny > i don't think anything is going to change in the spec
+18-04-08 - [18:04] -----------@tamiko > What about we quickly vote on that and establish a timeline for final approval.
+18-04-08 - [18:04] --------------@ulm > K_F: AIUI it is final except for the cheat sheet
+18-04-08 - [18:04] -----------@mgorny > it's just a manner of finishing implementation of SYSROOT
+18-04-08 - [18:04] -----------@tamiko > What is realistic? A month, two months?
+18-04-08 - [18:05] --------------@ulm > two weeks for the spec
+18-04-08 - [18:05] -----------@mgorny > i think it would be reasonable to set the date based on portage releases
+18-04-08 - [18:05] -----------@mgorny > i.e. portage ~arch with EAPI 7 + n days
+18-04-08 - [18:05] -----------@mgorny > (for in-tree use)
+18-04-08 - [18:05] -----------@tamiko > OK.
+18-04-08 - [18:05] -----------@mgorny > if PMS needs separate approval, we should do that on bug
+18-04-08 - [18:06] --------------@ulm > +1
+18-04-08 - [18:06] -----------@mgorny > (for the finishing touches)
+18-04-08 - [18:06] ---------@WilliamH > What we've always done in the past is, as soon as it goes stable we are allowed to use it.
+18-04-08 - [18:06] --------------@ulm > even before that
+18-04-08 - [18:06] ---------@WilliamH > wrt in-tree use.
+18-04-08 - [18:06] -----------@mgorny > WilliamH: what about ~arch?
+18-04-08 - [18:06] -----------@mgorny > i think in the past we had separate case for arch/~arch
+18-04-08 - [18:06] --------------@ulm > ~arch was allowed as soon as portage supported it
+18-04-08 - [18:06] ---------@WilliamH > mgorny: As soon as it hits ~arch it can be used there, then when it goes stable packages can be stabilized.
+18-04-08 - [18:07] --------@dilfridge > yes, that
+18-04-08 - [18:07] -----------@mgorny > wfm
+18-04-08 - [18:07] -----------@tamiko > So what about the following motion? "The council approves the EAPI 7 version as of commit fc07858 of 2018-04-05/. EAPI 7 may be used in ~arch 7 days after a portage version supporting the final draft is marked ~arch"?
+18-04-08 - [18:08] ---------@WilliamH > s/7 days after//
+18-04-08 - [18:08] ---------@WilliamH > wait
+18-04-08 - [18:08] ---------@WilliamH > s/7 days after/as soon as/
+18-04-08 - [18:08] --------------@ulm > tamiko: s/approves/provisionally &/
+18-04-08 - [18:08] ---------@WilliamH > We have never had a delay for that.
+18-04-08 - [18:08] -----------@tamiko > Roger.
+18-04-08 - [18:08] -----------@tamiko > Motion:
+18-04-08 - [18:08] --------------@ulm > final approval of EAPI 7 will be in a bug
+18-04-08 - [18:09] -----------@tamiko > Vote: "The council provisionally approves the EAPI 7 version as of commit fc07858 of 2018-04-05. EAPI 7 may be used in ~arch as soon as a portage version supporting the final draft is marked ~arch".
+18-04-08 - [18:09] -----------@tamiko > With ammendment: The final EAPI 7 approval shall be handled on a bug.
+18-04-08 - [18:09] --------@dilfridge > lgtm
+18-04-08 - [18:09] --------------@ulm > yes, looks good
+18-04-08 - [18:10] ---------- *** K_F yes
+18-04-08 - [18:10] ---- *** dilfridge yes
+18-04-08 - [18:10] ---------- *** ulm yes
+18-04-08 - [18:10] ------- *** tamiko yes
+18-04-08 - [18:10] ------- *** mgorny yes
+18-04-08 - [18:10] ----- *** WilliamH yes
+18-04-08 - [18:10] ------- *** slyfox yes
+18-04-08 - [18:10] --------------@ulm > \o/
+18-04-08 - [18:10] -----------@tamiko > Result: 7/0/0
+18-04-08 - [18:10] -----------@tamiko > 3. Banning EAPI 4 for new ebuilds (and EAPI bumps of existing ebuilds)
+18-04-08 - [18:11] -----------@tamiko > https://archives.gentoo.org/gentoo-project/message/e453732a4613485ea26bf754c40df087
+18-04-08 - [18:11] --------------@ulm > Chewi: mgorny: thanks for working on the spec :)
+18-04-08 - [18:11] -----------@tamiko > I think we can make that one quick as well.
+18-04-08 - [18:12] -----------@tamiko > What shall be the timeline for banning? I'd say simply "now".
+18-04-08 - [18:12] -----------@slyfox > are new ebuilds being added?
+18-04-08 - [18:12] ------------+Chewi > ulm: thanks your advice on it
+18-04-08 - [18:12] -----------@mgorny > slyfox: checking for that right now
+18-04-08 - [18:12] -----------@slyfox > it the inflow is low then "now" if fine
+18-04-08 - [18:12] --------@dilfridge > well, at least the total number of EAPI=4 is decreasing steadily
+18-04-08 - [18:13] -----------@tamiko > Jup.
+18-04-08 - [18:13] -----------@slyfox > also good signal
+18-04-08 - [18:13] ---------- antarus > "now" or when "eapi7 is stable" ?
+18-04-08 - [18:13] -----------@mgorny > +EAPI=5 # approved 2012.09.11, required by all profiles since 2014.03.12
+18-04-08 - [18:13] --------@dilfridge > https://www.akhuettel.de/~huettel/plots/eapi.php
+18-04-08 - [18:13] -----------@mgorny > that's something new
+18-04-08 - [18:13] ---------@WilliamH > now is fwm
+18-04-08 - [18:13] -----------@tamiko > antarus: It think it is safe to make it now.
+18-04-08 - [18:13] -----------@tamiko > Motion:
+18-04-08 - [18:13] --------@dilfridge > now is fine
+18-04-08 - [18:13] --------------@ulm > mgorny: I have 2012-09-20 as approval date
+18-04-08 - [18:14] -----------@mgorny > 5 Mar 2018
+18-04-08 - [18:14] -----------@mgorny > that's last version bump to EAPI=4
+18-04-08 - [18:14] -----------@tamiko > Vote: "The council bans EAPI 4 for new ebuilds. The change shall be commited to the ::gentoo repository layout within a week."
+18-04-08 - [18:15] --------@dilfridge > no
+18-04-08 - [18:15] -----------@mgorny > looks like an accident though
+18-04-08 - [18:15] --------@dilfridge > can't commit that
+18-04-08 - [18:15] -----------@tamiko > dilfridge: OK. Why?
+18-04-08 - [18:15] --------@dilfridge > because then repoman also bails out when there is an existing EAPI=4 ebuild in a dir where you add a new one
+18-04-08 - [18:15] -----------@mgorny > we don't commit EAPI bans like that
+18-04-08 - [18:15] -----------@tamiko > True.
+18-04-08 - [18:15] -----------@tamiko > Well, well.
+18-04-08 - [18:15] -----------@mgorny > we just state a policy ;-)
+18-04-08 - [18:16] -----------@tamiko > Vote: "The council bans EAPI 4 for new ebuilds effective immediately."
+18-04-08 - [18:16] ---+prometheanfire > repoman won't get updated?
+18-04-08 - [18:16] -----------@slyfox > would be nice to have a feature request in repoman to implement that
+18-04-08 - [18:16] --------@dilfridge > we can ban EAPI=3 once the last 19 ebuilds are gone :P
+18-04-08 - [18:16] --------@dilfridge > slyfox: yes
+18-04-08 - [18:16] ---------- antarus > prometheanfire: there isn't really an implementation for it
+18-04-08 - [18:16] -----------@slyfox > (should be very similat to "straight to stable" check)
+18-04-08 - [18:16] -----------@tamiko > Ammendment: "slyfox volunteered to ask for a repoman feature request to warn for commiting new EAPI 4 ebuilds."
+18-04-08 - [18:16] ----- *** WilliamH agrees with antarus, there isn't really an implementation.
+18-04-08 - [18:17] ---------- antarus > its probably non-trivial (because the EAPI bans have all kinds of exceptions)
+18-04-08 - [18:17] -----------@tamiko > Ammendment: "dilfridge is instructed to commit the EAPI 3 ban to the main repository once the last 19 EAPI 3 ebuilds left the tree."
+18-04-08 - [18:17] -----------@tamiko > ^^
+18-04-08 - [18:17] ---------@WilliamH > Actually doesn't that happen if you mark the eapi deprecated instead of banned?
+18-04-08 - [18:17] --------@dilfridge > hrhr
+18-04-08 - [18:17] --------@dilfridge > with pleasure
+18-04-08 - [18:17] --------@dilfridge > the warning also happens for deprecation, yes
+18-04-08 - [18:17] --------------@ulm > tamiko: we don't need to vote on that amendment
+18-04-08 - [18:17] ---------- antarus > repoman can qawarn, but not error
+18-04-08 - [18:18] -----------@mgorny > EAPI 4 is deprecated already, so repoman complains about it
+18-04-08 - [18:18] -----------@slyfox > let's vote on the matter and leave repoman details for the bug
+18-04-08 - [18:18] -----------@mgorny > but that's really off-topic
+18-04-08 - [18:18] ---------@WilliamH > mgorny: ah ok.
+18-04-08 - [18:18] -----------@tamiko > Jup.
+18-04-08 - [18:18] ---------@WilliamH > mgorny: so people have been getting complaints about it.
+18-04-08 - [18:18] ------------+b-man > Yes, repoman complains.
+18-04-08 - [18:18] -----------@tamiko > Council, please vote on the following motion: "The council bans EAPI 4 for new ebuilds effective immediately."
+18-04-08 - [18:18] ------- *** slyfox yes
+18-04-08 - [18:18] ----- *** WilliamH yes
+18-04-08 - [18:18] ------- *** mgorny yes
+18-04-08 - [18:18] ------- *** tamiko yes
+18-04-08 - [18:18] ---------- *** ulm yes
+18-04-08 - [18:19] ---------- *** K_F yes
+18-04-08 - [18:19] ---- *** dilfridge yes
+18-04-08 - [18:19] -----------@tamiko > Result 7/0/0
+18-04-08 - [18:19] -----------@slyfox > i'll file repoman check bug
+18-04-08 - [18:19] -----------@tamiko > Roger.
+18-04-08 - [18:19] -----------@tamiko > 4. Deprecating EAPI 5
+18-04-08 - [18:20] --------------@ulm > actually, I think it is too early for this
+18-04-08 - [18:20] --------@dilfridge > me too
+18-04-08 - [18:20] ---------@WilliamH > ulm: how long has eapi 5 been stable?
+18-04-08 - [18:20] -----------@tamiko > It would require major rework in toolchain.
+18-04-08 - [18:20] --------------@ulm > in the past we have deprecated EAPI when their use in the tree was between 10 and 15%
+18-04-08 - [18:20] -----------@slyfox > would be nice to have a list of eclasses (+users) stats on how many of them explictly do not support EAPI=5 and higher
+18-04-08 - [18:20] --------------@K_F > well, it depends on how we treat deprecation
+18-04-08 - [18:20] --------------@ulm > EAPI 5 is still used by about 40% of all ebuilds
+18-04-08 - [18:20] -----------@tamiko > What about we establish a timeline?
+18-04-08 - [18:20] -----------@mgorny > the whole point of deprecation is to discourage adding new ebuilds
+18-04-08 - [18:20] --------------@K_F > it wouldn't require rewriting for version bumps etc existing packages, but likely shouldn't be used for new packages
+18-04-08 - [18:21] -----------@tamiko > Something like "the council intends to deprecate EAPI 5 a month after EAPI 7 becomes available."
+18-04-08 - [18:21] --------------@ulm > and looking at dilfridge's graphs it is nicely decreasing
+18-04-08 - [18:21] -----------@mgorny > it is mainly about repoman warning when people do that
+18-04-08 - [18:21] ---------@WilliamH > mgorny: right.
+18-04-08 - [18:21] --------------@ulm > mgorny: that won't have much influence on the decay curve, I think
+18-04-08 - [18:21] --------------@K_F > mgorny: right, but they wouldn't really need to act on that warning immediately
+18-04-08 - [18:21] ---------@WilliamH > repoman starts complaining when you deprecate an eapi, but it doesn't die or anything.
+18-04-08 - [18:21] -----------@mgorny > at proxy-mait, i often have to ask users to use EAPI 6
+18-04-08 - [18:22] ---------@WilliamH > K_F: right, but they would get a heads-up
+18-04-08 - [18:22] -----------@mgorny > if repoman told them EAPI 5 was deprecated, i think some people would actually do that by themselves
+18-04-08 - [18:22] ---------@WilliamH > K_F: that's the idea of the warning.
+18-04-08 - [18:22] --------------@ulm > mgorny: it's standing policy to use the newest EAPI for new ebuilds
+18-04-08 - [18:22] -----------@slyfox > i think warning is a great too to steer people to new EAPI
+18-04-08 - [18:22] -----------@tamiko > mgorny: ack
+18-04-08 - [18:22] ---------@WilliamH > ulm: not really, but it should be.
+18-04-08 - [18:22] -----------@slyfox > newcomers find out that way that you can put a different number to that EAPI thing
+18-04-08 - [18:22] --------------@ulm > WilliamH: do I really have to dig out the council vote on it? :)
+18-04-08 - [18:22] -----------@mgorny > ulm: most of the people don't have time to learn 100 pages of standing unwritten Gentoo policies ;-)
+18-04-08 - [18:23] ---------- antarus > mgorny+1000
+18-04-08 - [18:23] ------------+b-man > mgorny++
+18-04-08 - [18:23] -----------@mgorny > let me put it like this
+18-04-08 - [18:23] -----------@tamiko > We should deprecate it realtively soon so that repoman starts complaining.
+18-04-08 - [18:23] -----------@slyfox > yup
+18-04-08 - [18:23] -----------@mgorny > we can't really make repoman warn 'you are not using the newest EAPI' because there are too many rules to that
+18-04-08 - [18:23] --------------@ulm > mgorny: it's also in the devmanual
+18-04-08 - [18:23] -----------@tamiko > I suggest we do that after EAPI 7 is actually in tree and available.
+18-04-08 - [18:24] -----------@mgorny > but at this point we can make repoman warn 'EAPI 5 is certainly too old'
+18-04-08 - [18:24] --------@dilfridge > we should maybe consider reviewing and updating the devmanual?
+18-04-08 - [18:24] --------------@ulm > I'm against it because of the 40% usage
+18-04-08 - [18:24] --------------@K_F > I'm fine with waiting for EAPI 7 to be available, or making the decision with delay until after
+18-04-08 - [18:24] -----------@tamiko > dilfridge: That's a good point.
+18-04-08 - [18:24] --------------@K_F > dilfridge: that is a good point, we should ensure that being done at same time as deprecation
+18-04-08 - [18:25] ------------+b-man > Would a standing GLEP be an option? (e.g. updated to reflect the latest council decision on EAPI usage)
+18-04-08 - [18:25] --------------@ulm > b-man: doesn't look like the right instrument
+18-04-08 - [18:25] --------------@K_F > the wiki page for PMS is likely better
+18-04-08 - [18:25] --------------@ulm > devmanual is better, or wiki
+18-04-08 - [18:25] -----------@tamiko > Motion: Vote on "The council intends to deprecate EAPI 6 one month after EAPI 7 becomes available. At the same time all resources (devmanual, etc.) sould have been updated to EAPI 6/7."
+18-04-08 - [18:26] ---------- antarus > (GLEPs are pretty heavyweight IMHO)
+18-04-08 - [18:26] --------------@K_F > we already have EAPI life cycle in https://wiki.gentoo.org/wiki/Project:Package_Manager_Specification
+18-04-08 - [18:26] ---------- *** ulm no
+18-04-08 - [18:26] -----------@slyfox > yup. and have a link th that new page from repoman warning
+18-04-08 - [18:26] ---------- antarus > er, 6 or 5 in that motion?
+18-04-08 - [18:26] -----------@slyfox > should be 5 :)
+18-04-08 - [18:26] --------------@K_F > 6 is wrong anyways
+18-04-08 - [18:26] -----------@tamiko > I withdraw the motion.
+18-04-08 - [18:27] -----------@tamiko > Before I try again - is the timeline OK?
+18-04-08 - [18:27] --------------@K_F > I suggest we just postpone vote till next meeting
+18-04-08 - [18:27] -----------@slyfox > why?
+18-04-08 - [18:27] --------------@ulm > I suggest to postpone to the first meeting after EAPI 7 is in place
+18-04-08 - [18:27] --------------@K_F > EAPI 7 won't be available until then and we can do some work to see what needs updating
+18-04-08 - [18:27] -----------@mgorny > i still think there's no harm in deprecating it today
+18-04-08 - [18:27] --------------@ulm > K_F: which may well be next :)
+18-04-08 - [18:28] -----------@tamiko > Roger. Works for me as well. "The council postpones EAPI 5 deprecation to the first meeting after EAPI 7 becomes available".
+18-04-08 - [18:28] ---------@WilliamH > I don't think there's harm in deprecating eapi 5 today either.
+18-04-08 - [18:28] -----------@tamiko > Something like that?
+18-04-08 - [18:28] -----------@mgorny > tamiko: how about we vote for deprecating it today, and discuss other options if that doesn't pass?
+18-04-08 - [18:28] -----------@tamiko > Roger. Why not. :-)
+18-04-08 - [18:29] -----------@mgorny > (probably going to be faster too than discussing multiple options simultaneously)
+18-04-08 - [18:29] -----------@tamiko > Motion: Vote on "The council deprecates EAPI 5. All online resources (devmanual, wiki, etc.) shall be updated to EAPI 6/7."
+18-04-08 - [18:29] ---------- *** K_F no
+18-04-08 - [18:29] ------- *** slyfox yes
+18-04-08 - [18:29] ------- *** mgorny yes
+18-04-08 - [18:29] ----- *** WilliamH yes
+18-04-08 - [18:29] --------------@ulm > what are "all online resources"? does that include profiles?
+18-04-08 - [18:29] ------- *** tamiko abstains
+18-04-08 - [18:29] ---- *** dilfridge no because of profiles
+18-04-08 - [18:30] ---------@WilliamH > profiles can be updated at the same time.
+18-04-08 - [18:30] --------------@ulm > there's no gain in using EAPI 6 in profiles
+18-04-08 - [18:30] -----------@mgorny > i dare say 'eapis-deprecated' does not affect profiles since repoman does not check them
+18-04-08 - [18:30] --------@dilfridge > we need to be careful with updating profiles
+18-04-08 - [18:30] --------------@ulm > absolutely done, because EAPI 6 has no features touching profiles
+18-04-08 - [18:30] --------------@K_F > yeah, we should be careful with profile updates
+18-04-08 - [18:30] --------------@ulm > *none
+18-04-08 - [18:31] --------------@K_F > repoman isn't really the guiding thing if motion is for full deprecation of EAPI, at least it needs to specify "for ebuilds"
+18-04-08 - [18:31] --------@dilfridge > having an unsupported eapi in a few ebuilds just makes these invisible, but emerge can still kinda function
+18-04-08 - [18:31] --------------@ulm > I would even suggest that we skip EAPI 6 for profiles
+18-04-08 - [18:31] ---------@WilliamH > Well, if what mgorny said above is true it isn't relevant
+18-04-08 - [18:31] --------@dilfridge > having an unsupported eapi in profiles makes everything break
+18-04-08 - [18:31] --------------@ulm > and go to 7 immediately when some feature of it is needed
+18-04-08 - [18:31] --------------@K_F > ulm: yeah, that makes sense
+18-04-08 - [18:31] -----------@mgorny > maybe amend the motion to deprecating it in ebuilds
+18-04-08 - [18:31] -----------@slyfox > deprecated is not unsupported
+18-04-08 - [18:31] ---------@WilliamH > slyfox++
+18-04-08 - [18:31] --------------@ulm > anyway
+18-04-08 - [18:31] -----------@mgorny > (while leaving profiles at EAPI 5 for the time being)
+18-04-08 - [18:31] ---------- *** ulm no
+18-04-08 - [18:31] ----- *** WilliamH yes
+18-04-08 - [18:32] --------------@ulm > tamiko: do the count :)
+18-04-08 - [18:32] -----------@tamiko > Result 3/1/3
+18-04-08 - [18:32] -----------@tamiko > Motion didn't pass.
+18-04-08 - [18:32] ----- *** WilliamH grumbles about obstructionists
+18-04-08 - [18:33] -----------@tamiko > dilfridge, ulm: Do you want to have a more careful wording, or shall we bring up EAPI 5 deprecation the next time again?
+18-04-08 - [18:33] ---------- *** ulm passes
+18-04-08 - [18:33] -----------@slyfox > i suggest discussing more in ML
+18-04-08 - [18:33] -----------@mgorny > dilfridge: do we want to retry with explicit notion that it's about ebuilds and not profiles?
+18-04-08 - [18:33] -----------@mgorny > (i suppose your vote might change)
+18-04-08 - [18:33] --------------@K_F > we can bring it up once EAPI 7 is finally approved and in tree, and we can review devmanual etc
+18-04-08 - [18:34] ---------@WilliamH > mgorny++
+18-04-08 - [18:34] --------------@K_F > there really isn't any rush
+18-04-08 - [18:34] --------@dilfridge > i think we should just vote again in a month or two
+18-04-08 - [18:34] -----------@tamiko > Good. Let's vote on that again in a month. I think we don't need to rush that.
+18-04-08 - [18:34] --------------@ulm > yeah, no need for a hurry
+18-04-08 - [18:34] -----------@tamiko > 5. Establish a timeline for the switch to the 17.1 profiles
+18-04-08 - [18:34] -----------@tamiko > https://archives.gentoo.org/gentoo-project/message/ecd981409a1fad7911a3547e9b0a315f
+18-04-08 - [18:35] -----------@tamiko > https://bugs.gentoo.org/506276
+18-04-08 - [18:35] ---------@WilliamH > Does "eselect profile" now let you switch?
+18-04-08 - [18:35] -----------@mgorny > ok, let's move on then
+18-04-08 - [18:35] -----------@mgorny > (sorry, i seem to be having lags)
+18-04-08 - [18:35] -----------@tamiko > I personally switched to 17.1 profiles on two of my machines with minimal problems.
+18-04-08 - [18:35] -----------@slyfox > i had to triage 5 bugs where people broke their systems
+18-04-08 - [18:35] --------------@K_F > how well tested is 17.1 for older installs?
+18-04-08 - [18:36] -----------@slyfox > i think manual switch is a bug hurdle
+18-04-08 - [18:36] --------@dilfridge > mgorny: just out of curiosity, can you give us a very short run-down what the advantage of the new layout is?
+18-04-08 - [18:36] --------------@ulm > WilliamH: no
+18-04-08 - [18:36] ------------+Chewi > went fine for my chroot but I haven't been brave enough to try my old primary system yet
+18-04-08 - [18:36] --------------@ulm > only with --force
+18-04-08 - [18:36] -----------@mgorny > WilliamH: it complains because they're exp
+18-04-08 - [18:37] ---------@WilliamH > dilfridge: the short version is it makes lib and /usr/lib directories instead of symlinks.
+18-04-08 - [18:37] -----------@mgorny > dilfridge: it's compatible with 32-bit x86, so pre-built stuff works without hacks
+18-04-08 - [18:37] --------------@K_F > this also comes very quickly after the 17.0 switch which was enough work
+18-04-08 - [18:37] -----------@slyfox > do we have a doc that explains how new libdirs were chosen? currenthy 17.1 is an amd64 only thing
+18-04-08 - [18:37] --------@dilfridge > well, we're not talking about switching now, we're talking about planning a timeline
+18-04-08 - [18:38] -----------@mgorny > dilfridge: it also makes gentoo stop using one-and-only custom layout which actually requires patching software to work
+18-04-08 - [18:38] --------@dilfridge > ok
+18-04-08 - [18:38] --------@dilfridge > I see
+18-04-08 - [18:38] ---------@WilliamH > dilfridge: symlinking lib to lib64 was a hack back in the day.
+18-04-08 - [18:38] ---------@WilliamH > dilfridge: a very old hack.
+18-04-08 - [18:38] -----------@tamiko > And it was a poor choice.
+18-04-08 - [18:38] ---------@WilliamH > dilfridge: I think it was done before I came on board even.
+18-04-08 - [18:39] -----------@mgorny > technically, this layout also makes it possible to do a 'cleaner' migration from 32-bit x86 to 64-bit amd64
+18-04-08 - [18:39] -----------@mgorny > but this is not something we support in Gentoo
+18-04-08 - [18:40] --------@dilfridge > ok so, what is a realistic time frame for migration?
+18-04-08 - [18:40] -----------@tamiko > It think that the 17.1 profiles are a very good idea. (Debian for example has much more adventurous lib layouts by now, /usr/lib/<arch-triplet>? ^^).
+18-04-08 - [18:40] -----------@tamiko > Personally, I think that we shouldn't make another big profile change too soon.
+18-04-08 - [18:40] -----------@tamiko > So mayber something for the 3rd, or 4th quarter of this year?
+18-04-08 - [18:41] ---------@WilliamH > I think we can start the process.
+18-04-08 - [18:41] --------------@K_F > which makes it a matter for the next council anyways
+18-04-08 - [18:41] ---------@WilliamH > Can we move the profiles out of exp yet?
+18-04-08 - [18:41] --------@dilfridge > wfm - but we could state that the "17.1 layout" is the future, so eventually everyone will migrate
+18-04-08 - [18:41] --------------@ulm > what does this involve exactly? only changing 17.1 from exp to dev (or stable)?
+18-04-08 - [18:41] --------------@ulm > or would stages be built with 17.1 too?
+18-04-08 - [18:42] ---------@WilliamH > ulm: I think it involves moving them out of exp, then there is a manual migration step.
+18-04-08 - [18:42] -----------@tamiko > ulm: Also making sure that the necessary conversion tool is well tested and the process is clearly communicated.
+18-04-08 - [18:42] -----------@mgorny > dilfridge: the main problem are packages with broken libdir uses, so it's something that needs being fixed anyway
+18-04-08 - [18:42] --------------@K_F > I'm also not too happy about making a large change with a 17 -> 17.1 switch
+18-04-08 - [18:42] -----------@mgorny > tooling is stable and i hadn't got issue reports for some time already
+18-04-08 - [18:42] -----------@tamiko > mgorny: Do we have a security mechanism in place that prevents running portage when changing to 17.1 profiles without doing the manual conversion?
+18-04-08 - [18:42] --------------@K_F > there is a real change of breaking real systems here, so should be a major bump
+18-04-08 - [18:43] --------------@ulm > K_F: hm, it's not major versions though, 17.1 simply means second profile of that year
+18-04-08 - [18:43] -----------@mgorny > tamiko: yes, profile.bashrc dies when your libdir is not migrated
+18-04-08 - [18:43] -----------@mgorny > (and tells people which news item to read)
+18-04-08 - [18:43] --------------@K_F > ulm: well, it feels different in any case
+18-04-08 - [18:43] --------------@ulm > so nothing really implies that the step from 17.1 to 18.0 would be larger than the one from 17.0 to 18.1
+18-04-08 - [18:43] ---------@WilliamH > If the tooling is good and doesn't have issues, I think we can move them out of exp.
+18-04-08 - [18:43] -----------@tamiko > mgorny: ic.
+18-04-08 - [18:43] --------------@ulm > *to 17.1
+18-04-08 - [18:43] ---------@WilliamH > s/them/the profiles/
+18-04-08 - [18:44] -----------@mgorny > i think the topic is mostly about pushing something like 'developers, please migrate your systems and start seriously fixing your packages'
+18-04-08 - [18:44] --------@dilfridge > WilliamH just volunteered for the helpline :P
+18-04-08 - [18:44] -----------@tamiko > I reconsider my timeline - how would you feel about an "in 2 months exp -> dev" timeline?
+18-04-08 - [18:44] -----------@slyfox > 19:37:39 <@slyfox> do we have a doc that explains how new libdirs were chosen?
+18-04-08 - [18:45] -----------@mgorny > slyfox: i think i wrote that down on wiki somewhere
+18-04-08 - [18:45] -----------@mgorny > but it's mostly my understanding, the person originally doing it was vapier
+18-04-08 - [18:45] -----------@slyfox > do you have a link?
+18-04-08 - [18:45] -----------@slyfox > i need to retrofit it to ppc64
+18-04-08 - [18:45] -----------@mgorny > https://wiki.gentoo.org/wiki/Project:AMD64/Multilib_layout
+18-04-08 - [18:46] ---------@WilliamH > I think it is just based on gcc behavior?
+18-04-08 - [18:46] -----------@mgorny > yes, and Linux ABI standards
+18-04-08 - [18:46] -----------@slyfox > ok, so it's a ld-linux path
+18-04-08 - [18:47] -----------@mgorny > so how about confirming this direction as a first vote?
+18-04-08 - [18:48] -----------@slyfox > sound good
+18-04-08 - [18:48] -----------@mgorny > and encouraging developers to migrate their development systems and testing 17.1 as a second one
+18-04-08 - [18:49] -----------@tamiko > sounds good.
+18-04-08 - [18:49] ---------@WilliamH > So are we moving the profiles out of exp?
+18-04-08 - [18:49] -----------@mgorny > WilliamH: let's not do that yet
+18-04-08 - [18:49] -----------@tamiko > WilliamH: I would say not today. But we can establish a timeline of let's say, 2 months?
+18-04-08 - [18:49] -----------@mgorny > there's really no reason to increase number of dev profiles right now
+18-04-08 - [18:50] -----------@tamiko > mgorny: So what wording for a motion do you suggest?
+18-04-08 - [18:50] -----------+Whissi > Can anybody point me to a decision when Gentoo decided to take the 17.1 move (/lib) at all?
+18-04-08 - [18:50] -----------@slyfox > let me find a bug
+18-04-08 - [18:50] -----------+Whissi > Thanks.
+18-04-08 - [18:51] -----------@slyfox > https://bugs.gentoo.org/506276
+18-04-08 - [18:51] -----------@mgorny > tamiko: "The Council approves the direction towards 17.1 amd64 profiles, and encourages Gentoo developers to convert their systems and test their packages against new profiles"
+18-04-08 - [18:51] ---------@WilliamH > Whissi: I don't understand your question?
+18-04-08 - [18:51] -----------@tamiko > mgorny: Let's vote on that.
+18-04-08 - [18:51] -----------@tamiko > Motion: Vote on "The Council approves the direction towards 17.1 amd64 profiles, and encourages Gentoo developers to convert their systems and test their packages against new profiles"
+18-04-08 - [18:51] ------- *** tamiko yes
+18-04-08 - [18:52] ------- *** slyfox yes
+18-04-08 - [18:52] ------- *** mgorny yes
+18-04-08 - [18:52] -----------+Whissi > WilliamH: I am not happy with the move. But I don't have technical reasons at the moment. Need to read into that..
+18-04-08 - [18:52] ---- *** dilfridge yes
+18-04-08 - [18:52] ---------- *** ulm yes
+18-04-08 - [18:52] ---------- *** K_F yes
+18-04-08 - [18:52] ----- *** WilliamH yes
+18-04-08 - [18:52] -----------@tamiko > Result 7/0/0
+18-04-08 - [18:52] ---------- antarus > Whissi: my presumption was that we made an arbitrary choice in the past, that choice ended up being wrong, so now we are 'fixing' it
+18-04-08 - [18:53] -----------@tamiko > Whissi: We can discuss the merits and problems in detail later :-)
+18-04-08 - [18:53] -----------@slyfox > Whissi: i think there is 2 things: a) is the final state good, b) is the conversion process good
+18-04-08 - [18:53] --------------@ulm > antarus: the problematic part is the migration
+18-04-08 - [18:53] -----------@tamiko > I agree with the last two statements.
+18-04-08 - [18:53] --------------@ulm > but there's a tool, and news item with a detailed explanation
+18-04-08 - [18:54] ---------- antarus > ulm: oh I understand ;)
+18-04-08 - [18:54] ---------- antarus > the 'fixing' wasn't meant so much as a judgement ;)
+18-04-08 - [18:54] -----------@tamiko > While I personally like cleaner separation (and am personally running a custom profile with split lib / lib32 / lib64 to catch misbehaving ebuilds) I think the rationale behind lib/lib64 is sound.
+18-04-08 - [18:54] -----------+Whissi > antarus: Yeah, like said, I have to read more about it. But given that we fixed the 17.1 mess beginning this year by dropping to exp and now we are voting on this, things are going too fast for me. That's why I asked.
+18-04-08 - [18:54] ---------@WilliamH > antarus++
+18-04-08 - [18:55] -----------@tamiko > Let's postpone further discussion on this to after the meeting.
+18-04-08 - [18:55] --------------@ulm > Whissi: IIRC 17.1 profiles were always exp
+18-04-08 - [18:55] --------------@ulm > what was added was eselect refusing to switch to exp
+18-04-08 - [18:55] -----------@tamiko > Whissi: Rest assured - we haven't established a timeline yet and the profiles won't magically become "dev" in the next months.
+18-04-08 - [18:56] -----------@tamiko > 5a. Bugs with council involvment
+18-04-08 - [18:56] -----------@tamiko > I would like to run quickly through open bugs with council involment at this point before discussing the metastructure items.
+18-04-08 - [18:56] -----------@tamiko > a. GLEP 14 - https://bugs.gentoo.org/637328
+18-04-08 - [18:57] -----------@mgorny > K_F: ^
+18-04-08 - [18:57] --------------@K_F > we're still reviewing that one , as a matter of technical procedure, we might end up with a new GLEP replacing that one
+18-04-08 - [18:57] -----------@slyfox > i remember that item from last time :)
+18-04-08 - [18:57] -----------@slyfox > K_F: can you post the update to the bug as well?
+18-04-08 - [18:57] --------------@K_F > yes, in the mean time the security election is finished etc
+18-04-08 - [18:58] -----------@tamiko > Good.
+18-04-08 - [18:58] --------------@K_F > yeah, we can post an update there
+18-04-08 - [18:58] -----------@slyfox > thanks!
+18-04-08 - [18:58] -----------@tamiko > K_F: Would you mind posting a quick update on the bug?
+18-04-08 - [18:58] -----------@tamiko > What about we defer to @security and move to the next item?
+18-04-08 - [18:58] -----------@slyfox > sounds good
+18-04-08 - [18:59] -----------@slyfox > (we can't do much more, can we?)
+18-04-08 - [18:59] -----------@tamiko > Don't think so.
+18-04-08 - [18:59] --------------@K_F > nope
+18-04-08 - [18:59] -----------@tamiko > K_F: You do a quick update? :-)
+18-04-08 - [19:00] --------------@K_F > already done
+18-04-08 - [19:00] -----------@tamiko > b. Joint venture on copyright issues - https://bugs.gentoo.org/642072
+18-04-08 - [19:00] --------------@ulm > no progress there
+18-04-08 - [19:01] -----------@tamiko > ulm, rich0: Any update here?
+18-04-08 - [19:01] ------------+rich0 > ulm: I'll defer to you - I did update the rationale
+18-04-08 - [19:01] -----------@tamiko > OK. I would say it's also not urgent to discuss that today.
+18-04-08 - [19:01] --------------@ulm > rich0: right, that was in last month?
+18-04-08 - [19:02] --------------@ulm > so some progress
+18-04-08 - [19:02] ------------+rich0 > yes
+18-04-08 - [19:02] -----------@tamiko > OK.
+18-04-08 - [19:02] --------------@ulm > I've slacked, because some things killed my motivation
+18-04-08 - [19:02] ---+prometheanfire > ulm: any action that trustees can take to help?
+18-04-08 - [19:02] --------@dilfridge > ^^
+18-04-08 - [19:03] -----------@tamiko > ulm: Not a problem. all: Let's postpone the topic to the next meeting.
+18-04-08 - [19:03] --------------@ulm > prometheanfire: not sure if to many persons editing it would really help
+18-04-08 - [19:03] --------------@ulm > *too
+18-04-08 - [19:03] -----------@mgorny > in any case, nothing to do today
+18-04-08 - [19:03] ---+prometheanfire > ulm: I've looked over it and it looks good for now anyway, I'll stay out if it unless asked
+18-04-08 - [19:04] --------------@ulm > prometheanfire: sounds good
+18-04-08 - [19:04] -----------@tamiko > Let's move on to our all time favorite:
+18-04-08 - [19:04] -----------@tamiko > c. gentoo-dev ML whitelisting - https://bugs.gentoo.org/650964
+18-04-08 - [19:04] --------------@ulm > I'll come back to you and other trustees if necessary
+18-04-08 - [19:04] ------------+b-man > \o/
+18-04-08 - [19:04] ---------@WilliamH > my opposition to the whitelisting hasn't changed.
+18-04-08 - [19:05] --------------@K_F > nothing for us to do on that bug for now.. I've been travelling a bit too much lately, so haven't gotten around to speaking too much with robbat (whom have also been travelling)
+18-04-08 - [19:05] -----------@tamiko > OK.
+18-04-08 - [19:05] -----------@mgorny > i don't really believe it's going to work anyway
+18-04-08 - [19:05] -----------@tamiko > I would like to see the council decision implemented in a timeline manner, though.
+18-04-08 - [19:05] -----------@mgorny > but i'll leave that to K_F
+18-04-08 - [19:05] --------------@K_F > but it can be implemented using ACLs in current mailing list software so doesn't mandate a switch etc, biggest thing is likely how to update the list, with a likely solution being a git repo that all devs have write access to
+18-04-08 - [19:05] ---------- antarus > prometheanfire: any Mailman update?
+18-04-08 - [19:06] -----------@tamiko > K_F: I like that solution.
+18-04-08 - [19:07] ---------- antarus > tamiko: so you are unhappy with the existing timeframe, or you don't feel like there is an adequate timeframe?
+18-04-08 - [19:07] ---+prometheanfire > antarus: just that I'm done waiting for upstream to make a pure python3 version of docker-mailman
+18-04-08 - [19:08] -----------@tamiko > antarus: Well the timeframe was end of december/ beginning of january. NOt it is April.
+18-04-08 - [19:08] ---+prometheanfire > so I'll be working on that this monthish
+18-04-08 - [19:08] --------@dilfridge > I dont think the mailing list software is relevant here, when it can be implemented with the current software
+18-04-08 - [19:08] -----------@tamiko > s/Not/Now/
+18-04-08 - [19:09] -----------@tamiko > OK. But I see that we don't have to discuss much here today.
+18-04-08 - [19:09] --------------@K_F > well, I don't want to direct infra to a specific solution if they feel otherwise, but it shouldn't be used as a reason to push a new manager either
+18-04-08 - [19:09] ---------- antarus > my point is more about this concept that infra would stall intentionally. Originally we had committed to migrating to mailman to implement
+18-04-08 - [19:09] ---------- antarus > if the timeline is unclear, or you don't like that, or you want it sooner
+18-04-08 - [19:09] ---------- antarus > I'd prefer that be made clear
+18-04-08 - [19:10] --------@dilfridge > aren't we mixing up two things here?
+18-04-08 - [19:10] --------------@K_F > yes, I believe the push for mailman is more on content-moderation features
+18-04-08 - [19:10] --------------@K_F > which is a separate topic anyways
+18-04-08 - [19:11] --------------@K_F > this solution was explicitly applied in order for it to be compatible with current implementation
+18-04-08 - [19:11] --------------@K_F > and also workload-wise
+18-04-08 - [19:11] ---+prometheanfire > K_F: it is, part of the revival of proctors is tooling
+18-04-08 - [19:11] ---+prometheanfire > the other part of the mailman push is to get us off old and mostly unmaintained software
+18-04-08 - [19:11] ---------- antarus > mmlmj is pretty terrible
+18-04-08 - [19:11] -----------@tamiko > Can imagine.
+18-04-08 - [19:12] ---------- antarus > sorry, so I'm not familiar with the content moderation features; but perhaps its because the hubbub was mostly about this topic
+18-04-08 - [19:12] -----------@tamiko > antarus, prometheanfire: So what is your estimate how long switching the infrastructure and getting the whitelist operational will take?
+18-04-08 - [19:12] ---+prometheanfire > it CAN do whitelisting though
+18-04-08 - [19:12] ---------- antarus > tamiko: we could do it on mmlmj in 1-2 weeks, I think the main request is what kind of interface the whitelist has
+18-04-08 - [19:12] ---------- antarus > and defending the whitelist against abuse
+18-04-08 - [19:13] ---------- antarus > like ".*@.*" as an entry
+18-04-08 - [19:13] ---------- antarus > teh mailing list interface is pretty..baroque
+18-04-08 - [19:13] ---+prometheanfire > if antarus can help me out some weekend this month we can move one of the lists there I think
+18-04-08 - [19:13] ---+prometheanfire > I'm more of an lxc guy than a docker one
+18-04-08 - [19:13] ---------- antarus > the whitelisting would only be for gentoo-dev
+18-04-08 - [19:13] ---+prometheanfire > yes
+18-04-08 - [19:13] --------------@K_F > antarus: well, a git repo tracking the changes helps with that, any dev adding such a list should expect a reaction
+18-04-08 - [19:14] --------------@K_F > but that is why git repo is proposed rather than just a file on pecker
+18-04-08 - [19:14] --------------@K_F > also solves the accountability/transparency of whom is watching the user added
+18-04-08 - [19:14] ---------- antarus > K_F: this would be gpg-signed repo yes?
+18-04-08 - [19:14] --------@dilfridge > antarus: if anyone commits that, it can be traced back and dealt with accordingly
+18-04-08 - [19:14] --------------@K_F > antarus: yes
+18-04-08 - [19:15] -----------@tamiko > antarus: So what about infra implements the whitelisting feature with mmlmj this month and after that there is plenty of time migrating to mailman?
+18-04-08 - [19:15] --------@dilfridge > after all we're talking about something that only devs can write to, so we can assume a minimum of common sense (?) and responsibility
+18-04-08 - [19:15] ---------- antarus > dilfridge: I assume nothing ;)
+18-04-08 - [19:15] --------@dilfridge > tamiko++
+18-04-08 - [19:15] -----------@mgorny > dilfridge: good one ;-)
+18-04-08 - [19:15] ---------- antarus > tamiko: where will this be documented
+18-04-08 - [19:16] ---------- antarus > (so I can write the wiki pages0
+18-04-08 - [19:16] -----------@tamiko > antarus: I do not understand the question.
+18-04-08 - [19:16] ---------- antarus > tamiko: like this new policy for gentoo-dev
+18-04-08 - [19:16] ---+prometheanfire > tamiko: I'm fine with that (from an infra perspective), it'd give upstream time to fix their py3 interface stuff
+18-04-08 - [19:16] ---------- antarus > I would prefer it be clearly documented, where the whitelist is, hwo to add people, etc...)
+18-04-08 - [19:16] *** prometheanfire+ still doesn't like whitelisting like this
+18-04-08 - [19:16] --------@dilfridge > it is documented here and now in the log, and in previous council logs and summaries
+18-04-08 - [19:17] -----------@tamiko > antarus: The new policy was subject of two council votes and decisions.
+18-04-08 - [19:17] ---------- antarus > er..
+18-04-08 - [19:17] ---------- antarus > insufficient
+18-04-08 - [19:17] ---------- antarus > where on the wiki do you want the documentation
+18-04-08 - [19:17] ---+prometheanfire > dilfridge: not in detail, I think a wiki page for how users can request access would be good
+18-04-08 - [19:17] ---------- antarus > if I am a dev and I need to whitelist isomeone, how do I figure out how to do it?
+18-04-08 - [19:17] --------@dilfridge > antarus: can you customize the response that somebody non-whitelisted gets by the server?
+18-04-08 - [19:17] ---------- antarus > dilfridge: no idea
+18-04-08 - [19:17] --------@dilfridge > (on a posting attempt)
+18-04-08 - [19:18] -----------@tamiko > antarus, prometheanfire: What about we add that right below our listing here: https://www.gentoo.org/get-involved/mailing-lists/
+18-04-08 - [19:18] --------@dilfridge > then let's find out. because that's the best place to document it.
+18-04-08 - [19:18] ---------- antarus > tamiko: cool, sounds great
+18-04-08 - [19:18] ---------- antarus > I'll update that section
+18-04-08 - [19:18] -----------@tamiko > antarus: We could also mention that "gentoo-announce" is read only. :-)
+18-04-08 - [19:19] --------@dilfridge > (please, please let's NOT do the stupid solution as with gentoo-dev-announce, where everything that doesnt follow strict procedure ends up in nirvana)
+18-04-08 - [19:19] -----------@tamiko > antarus: Roger. Thanks!
+18-04-08 - [19:19] ---------- antarus > dilfridge: haha
+18-04-08 - [19:20] -----------@tamiko > Shall we move on? :-)
+18-04-08 - [19:20] ---------- antarus > dilfridge: I'm serious in that the mmlmj software is atrocious, I have no idea how it works ;)
+18-04-08 - [19:20] --------------@ulm > dilfridge: it's pretty much the same when trying to post while unsubscribed
+18-04-08 - [19:20] --------------@ulm > for any of the lists
+18-04-08 - [19:20] -----------@tamiko > I think we do not need more council votes on anything here.
+18-04-08 - [19:20] ------ *** antarus can barely implement the whitelisted you suggested
+18-04-08 - [19:20] --------------@K_F > tamiko: agreed
+18-04-08 - [19:20] ------------+b-man > Just turn off the mailing list :)
+18-04-08 - [19:21] -----------@tamiko > We can vote on that - the next time ;-)
+18-04-08 - [19:21] -----------@tamiko > d. GLEP 61 - https://bugs.gentoo.org/652784
+18-04-08 - [19:21] --------------@ulm > apologies for sneaking this in at the last minute
+18-04-08 - [19:21] --------@dilfridge > b-man: that's for -project
+18-04-08 - [19:21] -----------@tamiko > ^^
+18-04-08 - [19:21] --------------@ulm > can we get a quick vote that status of GLEP 61 can be updated to final?
+18-04-08 - [19:21] ------------+b-man > dilfridge: that one too
+18-04-08 - [19:21] -----------@tamiko > ulm: My intention.
+18-04-08 - [19:21] -----------@mgorny > i think that case is obvious since its dependee has been marked final
+18-04-08 - [19:21] ---- *** dilfridge yes
+18-04-08 - [19:22] ------- *** mgorny yes
+18-04-08 - [19:22] ------- *** slyfox yes
+18-04-08 - [19:22] ------- *** tamiko yes
+18-04-08 - [19:22] ----- *** WilliamH yes
+18-04-08 - [19:22] ---------- *** ulm yes
+18-04-08 - [19:22] ---------- *** K_F yes
+18-04-08 - [19:22] --------@dilfridge > hallelujah!
+18-04-08 - [19:22] -----------@tamiko > Result 7/0/0 - The council changed GLEP 61 to final.
+18-04-08 - [19:22] -----------@tamiko > Ok. On to the fun part for today.
+18-04-08 - [19:23] -----------@tamiko > 6. The council was requested to provide their input on updating the "Gentoo Social Contract"
+18-04-08 - [19:23] -----------@tamiko > Specifically:
+18-04-08 - [19:23] -----------@tamiko > https://archives.gentoo.org/gentoo-project/message/7dc299781f08ccc6f7b5dca08b4acb06
+18-04-08 - [19:23] -----------@tamiko > https://archives.gentoo.org/gentoo-project/message/8c8534195597ca34ebb3e3bb0a042b3e
+18-04-08 - [19:23] -----------@tamiko > https://archives.gentoo.org/gentoo-project/message/2a250ad39db7b400072603f4705e8f57
+18-04-08 - [19:23] ---- *** dilfridge suggests the alternative wording by ulm
+18-04-08 - [19:23] -----------@slyfox > -ETOOMANYREDIRECTS
+18-04-08 - [19:23] ------ *** antarus +1s dilfridge
+18-04-08 - [19:24] --------@dilfridge > s/suggests/supports/
+18-04-08 - [19:24] --------------@ulm > we really shouldn't drop the Debian attribution
+18-04-08 - [19:24] -----------@tamiko > I suggest we quickly establish, that we (a) only intend to do a cosmetic change of the preamble, (b) support such a change by a vote, (c) ask the Foundation to support such a change as well.
+18-04-08 - [19:24] -----------@mgorny > i'm also for ulm's
+18-04-08 - [19:24] --------------@ulm > because they explicitly ask for it, and our social contract is derived from theirs
+18-04-08 - [19:25] --------@dilfridge > (d) we change it
+18-04-08 - [19:25] -----------@tamiko > I think that as long as we do not change anything else, we do not need a full developer vote on that.
+18-04-08 - [19:25] -----------@tamiko > ulm: Agreed.
+18-04-08 - [19:25] --------------@ulm > it's the preamble only
+18-04-08 - [19:25] --------------@K_F > we don't need a full developer vote for social contract in any case, it is within council domain to begin with
+18-04-08 - [19:25] ---+prometheanfire > I don't see a problem with ulms suggestion, foundation may want to add a section for foundation involvment, but that's it
+18-04-08 - [19:26] --------@dilfridge > I dont see any need for foundation involvment.
+18-04-08 - [19:26] --------------@K_F > but yes, I prefer minor updates and changing the ML reference to correct -project
+18-04-08 - [19:26] -----------@tamiko > prometheanfire: For that we would need a suggestion what you want to add first.
+18-04-08 - [19:26] -----------@tamiko > K_F: Agreed.
+18-04-08 - [19:26] -----------@tamiko > What about the following motion:
+18-04-08 - [19:26] --------------@K_F > any other change we can vote on in a later meeting if there is a proposal for it
+18-04-08 - [19:26] ---+prometheanfire > tamiko: of course, we'd talk to about it in our meeting first
+18-04-08 - [19:30] -----------@tamiko > "The council intends to do a cosmetic update to the Gentoo Social Contract to change the mailing list point of contact to gentoo-projects@lists.gentoo.org. The full wording of the first paragraph will read »This social contract is intended to clearly describe the overall development policies and standards of the Gentoo project development team. Parts of this document have been derived from the
+18-04-08 - [19:30] -----------@tamiko > Debian Social Contract. Comments are welcome. Please send them to our gentoo-project@lists.gentoo.org mailing list.«. The Council requests the Foundation Trustees to approve this change in their next meeting. Once approved by the Trustees the Gentoo Social Contract shall be updated on the websites."
+18-04-08 - [19:30] ------- *** slyfox yes
+18-04-08 - [19:30] ------- *** tamiko yes
+18-04-08 - [19:30] ---------- *** ulm yes
+18-04-08 - [19:30] ---- *** dilfridge yes
+18-04-08 - [19:30] -----------@tamiko > (aka "ulm's wording")
+18-04-08 - [19:31] ----- *** WilliamH yes
+18-04-08 - [19:31] ---------- *** K_F yes
+18-04-08 - [19:31] ------- *** mgorny yes
+18-04-08 - [19:31] -----------@tamiko > Result 7/0/0
+18-04-08 - [19:31] --------------@ulm > it was also suggested to add the date of last modification, but I don't think we need to vote on that
+18-04-08 - [19:31] ---------- antarus > O.o
+18-04-08 - [19:31] ---------- antarus > wow everyone voted yes, colour me surprised ;)
+18-04-08 - [19:31] --------------@ulm > it's something for infra to sort out if it is possible
+18-04-08 - [19:32] -----------@tamiko > ulm: :-D
+18-04-08 - [19:32] -----------@tamiko > antarus: Well, that's a minimal change ;-)
+18-04-08 - [19:32] ---------- antarus > whoa whoa whoa, we can only work on like 1 thing at time ulm, lets not get greedy here ;p
+18-04-08 - [19:32] ---------@WilliamH > It just updates the preamble. ;-)
+18-04-08 - [19:33] -----------@tamiko > 7. The council was requested to discuss the introduction of a voting mechanism similar to the "general resolution" [6] as known to the Debian project
+18-04-08 - [19:33] -----------@tamiko > https://www.debian.org/devel/constitution#item-4
+18-04-08 - [19:33] -----------@tamiko > https://archives.gentoo.org/gentoo-project/message/973be0a662b3cc74aa118a1128dcac9e
+18-04-08 - [19:33] -----------@tamiko > (minus the "comrel" bit)
+18-04-08 - [19:33] -----------@tamiko > mrueg: ^^^
+18-04-08 - [19:33] -----------@tamiko > That would be my little bike shed then. Let me summarize in maybe 1 minute ^^
+18-04-08 - [19:33] ---------@WilliamH > Well, can't anyone call for a full developer vote on something?
+18-04-08 - [19:34] -----------@mgorny > doesn't this require changing GLEP 39?
+18-04-08 - [19:34] -----------@tamiko > mgorny: This would require a full new GLEP outlining everything in detail.
+18-04-08 - [19:34] --------------@ulm > mgorny: GLEP 39, bylaws, and laws of New Mecico :p
+18-04-08 - [19:35] -----------@tamiko > ulm: How does this affect Foundation bylaws?
+18-04-08 - [19:35] ---+prometheanfire > it talks of property
+18-04-08 - [19:35] --------------@ulm > just joking :)
+18-04-08 - [19:35] -----------@mgorny > yeah, so it's purely initial discussion at this moment
+18-04-08 - [19:35] -----------@tamiko > Yes.
+18-04-08 - [19:35] -----------@tamiko > My intention is the following: GLEP 39 states:
+18-04-08 - [19:35] ---+prometheanfire > which is the foundations domain, other than that I generally like the proposal, would like more detail (aka a glep)
+18-04-08 - [19:35] -----------@tamiko > Rationale: "Since everybody gets to vote for the council members, at least in principle the council members represent all developers, not just a particular subset."
+18-04-08 - [19:36] -----------@tamiko > But the last months made it apparent that not everyone is of that opinion - i.e. after a vote on the council, we can do pretty much whatever we want for a one year period.
+18-04-08 - [19:37] -----------@mgorny > well, i would skip the GLEPs part
+18-04-08 - [19:37] --------@dilfridge > which, in a way, is a good thing
+18-04-08 - [19:37] -----------@tamiko > My suggestion would be to introduce a formal voting procedure (similarly to Debian's "general resolution" that can overrule the "technical committe") that would allow to overrule Council decisions by a democratic vote.
+18-04-08 - [19:37] -----------@mgorny > i don't see a reason why would anyone want to use a big cannon to push a glep forward
+18-04-08 - [19:37] -----------@mgorny > so basically overriding Council decisions and/or calling for early reelection
+18-04-08 - [19:37] -----------@tamiko > Yes.
+18-04-08 - [19:37] ---------- antarus > I mean it would help if people actually voted in the council election on a regular basis; as this underlies the basic principle in the existing GLEP
+18-04-08 - [19:37] ---+prometheanfire > tamiko: with the same 2:1 ratio?
+18-04-08 - [19:37] ---------- antarus > afaik the elections always have meager turnout
+18-04-08 - [19:38] -----------@tamiko > antarus: That is also correct.
+18-04-08 - [19:38] ---------- antarus > prometheanfire: ahh my understanding was more general interest like "do we think this is a good idea, and if so, we should dedicate effort to writing the glep"
+18-04-08 - [19:38] ---------- antarus > prometheanfire: I would be surprised if anyone passed anything today
+18-04-08 - [19:38] ---+prometheanfire > antarus: same, I was asking for more detail (aka a glep)
+18-04-08 - [19:38] -----------@tamiko > prometheanfire: I cannot really answer that at the moment. The ratios and minimal supporting votes should be high enough that we do not end up with a "general resolution" (or however we call it) every week - but at most one every other year.
+18-04-08 - [19:38] --------@dilfridge > I'm kinda split on this one. On one hand, one of the principles of representative democracy is that the representatives have free hand for their time of office.
+18-04-08 - [19:39] -----------@tamiko > dilfridge: And German politics beautifully demonstrate why this is very frustrating.
+18-04-08 - [19:39] ---------- antarus > dilfridge: at least in the US if nothing else, there is typically an option to recall your representative
+18-04-08 - [19:39] ------------+b-man > antarus: When was the last time that happened?!
+18-04-08 - [19:40] ---------- antarus > b-man: more typical in state elections tbh
+18-04-08 - [19:40] --------@dilfridge > On the other hand, we do have a lot of heated discussions, and they are often driven by small, noisy groups.
+18-04-08 - [19:40] ---------- antarus > afaik there were some governor recalls recently
+18-04-08 - [19:40] ---------- antarus > (heads of individual states in the US)
+18-04-08 - [19:40] --------@dilfridge > So, being able to tell people "collect enough support and you can change it" would quell that somewhat.
+18-04-08 - [19:40] -----------@tamiko > dilfridge: Such a thing would help us for these discussions - you can simply ask them to prove that they have enough support.
+18-04-08 - [19:40] -----------+Whissi > Keep in mind: Just because someone disagrees in one point he/she isn't automatically disagreeing with all other points and wants to get a new council. I.e. we just don't want a "BASTA" politic (maybe only the Germans knows what I am talking about).
+18-04-08 - [19:40] ------------+b-man > antarus: agreed. I would equate states to maybe projects? the council to congress, trustees to senate, and drobbins to the prez!
+18-04-08 - [19:40] -----------@tamiko > dilfridge: Exactly.
+18-04-08 - [19:40] --------@dilfridge > Yes.
+18-04-08 - [19:40] -------- *** b-man makes himself laugh
+18-04-08 - [19:41] --------------@K_F > my $0.02 is that we shouldn't overburden devs with votes and rather point at council elections for time to make such opinions heard
+18-04-08 - [19:41] ---------- antarus > I originally proposed this again not because I expect devs to actually vote
+18-04-08 - [19:41] --------@dilfridge > make gentoo great again!
+18-04-08 - [19:41] ---------- antarus > but because some people are upset and they need some kind of avenue to feel heard in the opposition
+18-04-08 - [19:41] ------- *** slyfox had hard time following
+18-04-08 - [19:41] -----+bonsaikitten > K_F: I wouldn't call a single vote a burden
+18-04-08 - [19:41] ---- *** dilfridge thinks the US isn't really a great system either.
+18-04-08 - [19:41] ------------+b-man > dilfridge: It has it's flaws too
+18-04-08 - [19:42] --------------@K_F > bonsaikitten: I don't believe it will be a single vote, if anyone can call I fear it will be misused
+18-04-08 - [19:42] -----------@tamiko > K_F: It would only be a burden if enough gentoo developers want to overrule a decision / an new council.
+18-04-08 - [19:42] -----------@mgorny > Well, i support this kind of thing but it needs to be thought out so that it won't be abused
+18-04-08 - [19:42] ---------- antarus > dilfridge: I never claimed it was; but I was intending to propose a middle ground where you cannot over-ride decisions, but may simple call for new elections / a recall vote
+18-04-08 - [19:42] ------------+b-man > dilfridge: like recalling representatives. very difficult, but easier at different levels.
+18-04-08 - [19:42] --------@dilfridge > slyfox: I dont think anything will really be decided today.
+18-04-08 - [19:42] --------------@K_F > so everything a single developer disagrees with, they will call a vote and pushing things ad infinitum
+18-04-08 - [19:42] -----------@tamiko > K_F: Before that you say "no" by doing nothing.
+18-04-08 - [19:42] -----------@tamiko > K_F: No.
+18-04-08 - [19:42] ---------- antarus > dilfridge: in principal I tend to agree with your concept of having power to do whatever once elected
+18-04-08 - [19:42] ---+prometheanfire > has anyone asked debian how they prevent frivolous voting?
+18-04-08 - [19:42] --------------@ulm > K_F: you'd require a quorum for calling such a vote
+18-04-08 - [19:42] -----------@tamiko > K_F: A vote is only initiated if enough active Gentoo developers support the motion.
+18-04-08 - [19:43] -----------@slyfox > does council chair give you that much power except castiong your vote? :)
+18-04-08 - [19:43] ------------+b-man > even teh general resolution could be abused or so strict that it begins to become grass-root movements to overturn things.
+18-04-08 - [19:43] ---------- antarus > prometheanfire: you need 3Q in order to have a vote in debian
+18-04-08 - [19:43] -----------@tamiko > K_F: I intend that this quorum is intentionally high (but doable to reach).
+18-04-08 - [19:43] ---------- antarus > "Q is half of the square root of the number of current Developers"
+18-04-08 - [19:44] -----------@tamiko > slyfox: I can make the channel +m by my power as meeting chair. ;-)
+18-04-08 - [19:44] ---------@WilliamH > I think that would be pretty low?
+18-04-08 - [19:44] ---------@WilliamH > antarus: ^^
+18-04-08 - [19:44] -----------@mgorny > tamiko: are you going to write a glep for this?
+18-04-08 - [19:44] --------------@K_F > WilliamH: currently 7
+18-04-08 - [19:44] -----------@tamiko > mgorny: I intend to write a draft together with mrueg
+18-04-08 - [19:44] -----------@slyfox > woohoo!
+18-04-08 - [19:44] -----------@mgorny > Ok
+18-04-08 - [19:44] -----------@tamiko > This topic certainly deserves a broader discussion.
+18-04-08 - [19:45] --------@dilfridge > yeah doing it right will take some time
+18-04-08 - [19:45] --------------@ulm > antarus: that almost sounds like de Solla Price's law
+18-04-08 - [19:45] -----------@tamiko > I simply wanted to waste our precious time on it for 5 minutes to gather some first comments / impressions.
+18-04-08 - [19:45] -----------@mgorny > So let's defer it for you two and revisit once there's a specific proposal
+18-04-08 - [19:45] -----------@tamiko > Agreed.
+18-04-08 - [19:45] ------------+b-man > bang the gavel!
+18-04-08 - [19:45] ---------- antarus > WilliamH: if number of devs is 1k, than 3Q is ~45. If the number of devs is 2k, then 3Q is 66, for Gentoo the number of devs is between 100-200, so 100 is 15, and 200 is 21)
+18-04-08 - [19:45] -----------@mgorny > Plus ml discussion
+18-04-08 - [19:45] -----------@tamiko > b-man: Not now.
+18-04-08 - [19:45] --------@dilfridge > tamiko: admit you just dont want to proceed to the next agenda item :P
+18-04-08 - [19:45] -----------@tamiko > dilfridge: Correct.
+18-04-08 - [19:45] ---+prometheanfire > K_F: I think it'd be had to find 7 actual devs to recall something
+18-04-08 - [19:45] -----------@tamiko > Thanks a lot for all your input, much appreciated.
+18-04-08 - [19:45] ---------- antarus > good luck getting 15 devs to agree on anyhtin g;)
+18-04-08 - [19:45] -----------@tamiko > Let's move on to the last item.
+18-04-08 - [19:46] -----------@tamiko > antarus: At the moment I only need to get 4 to agree on something ;-)
+18-04-08 - [19:46] -----------@tamiko > 8. The council was requested to discuss and vote on the following motion:
+18-04-08 - [19:46] --------------@K_F > I propose we make the last agenda item a non-voting discussion item
+18-04-08 - [19:46] ---------@WilliamH > K_F++
+18-04-08 - [19:46] -----------@tamiko > Agreed.
+18-04-08 - [19:46] --------@dilfridge > K_F--
+18-04-08 - [19:46] -----------@tamiko > https://archives.gentoo.org/gentoo-project/message/de1d47212a9c71a40fc1717ea460cad4
+18-04-08 - [19:47] ------------+b-man > I propose a vote to make it non-voting :-P
+18-04-08 - [19:47] ---------@WilliamH > K_F++
+18-04-08 - [19:47] -----------@tamiko > "The Gentoo council shall directly contact "Software in the Public Interest Inc." (SPI), with the intention of Gentoo becoming a SPI Associated Project, independent of the Gentoo Foundation."
+18-04-08 - [19:47] ---------@WilliamH > This should be discussion only.
+18-04-08 - [19:47] --------@dilfridge > as a clarification on the wording,
+18-04-08 - [19:47] --------@dilfridge > "independent" refers to the association with SPI
+18-04-08 - [19:48] -----------@tamiko > Let's wait for dilfridge's clarification, after that I would like to quickly say something.
+18-04-08 - [19:48] ----- *** WilliamH wants to say something as well
+18-04-08 - [19:48] --------------@ulm > tamiko: given that we're approaching 2 hours, I move to postpone this item to the next meeting
+18-04-08 - [19:48] --------@dilfridge > *not* that Gentoo shall become independent of the Gentoo Foundation,
+18-04-08 - [19:48] -!- Chewi [~chewi@gentoo/developer/chewi] has left #gentoo-council ["I'm outta here!"]
+18-04-08 - [19:48] --------@dilfridge > but that the Gentoo distribution shall associate directly with SPI
+18-04-08 - [19:49] ---------@WilliamH > dilfridge--
+18-04-08 - [19:49] ---+prometheanfire > my view as president is that SPI will want to deal with another legal entity, further I'm fine with reaching out to them, this could be the first step in reducing the need for the foundation
+18-04-08 - [19:49] -----------@tamiko > I think we should quickly resolve any contentions between developer community/council and the Foundation.
+18-04-08 - [19:49] ---+prometheanfire > dilfridge: uh, prety sure the foundation has that trademarked
+18-04-08 - [19:49] --------@dilfridge > prometheanfire: the whole point of SPI is that they do not *need* another legal entity to deal with
+18-04-08 - [19:49] ---------- antarus > I would prefer this be done in a co-operative fashion, rather than an adversarial fashion
+18-04-08 - [19:50] ---------@WilliamH > antarus++
+18-04-08 - [19:50] ---------@WilliamH > the fighting and mud slinging lately is ridiculous
+18-04-08 - [19:50] ---------- antarus > like i still think the foundation should die, and this be done in alignment with that goal
+18-04-08 - [19:50] ---------- antarus > presuming teh board agrees
+18-04-08 - [19:50] --------@dilfridge > prometheanfire: well, if you want to use that to restrict what we can do, I'm pretty sure that's against the purposes of the distribution
+18-04-08 - [19:50] ---------- antarus > and they just work to complete the taxes and merge under SPI
+18-04-08 - [19:50] -----------@tamiko > What about we find a wording/motion that we can vote on that we request the Foundation Trustees to accept as well?
+18-04-08 - [19:50] ---------@WilliamH > dilfridge--
+18-04-08 - [19:51] ---------@WilliamH > antarus++
+18-04-08 - [19:51] --------@dilfridge > antarus: dream on
+18-04-08 - [19:51] ---+prometheanfire > how about a party consisting of both the foundation and council BOTH work together to eventually get the SPI to take over some work
+18-04-08 - [19:51] --------@dilfridge > that won't happen until I'm retired
+18-04-08 - [19:51] --------@dilfridge > oh please
+18-04-08 - [19:51] ---------@WilliamH > There's no reason for all of this fighting
+18-04-08 - [19:51] -----------@tamiko > It had been a long established working relationship that the Foundation's primary purpose is to hold assets and trademarks and that the developer community is lead by projects and the council.
+18-04-08 - [19:51] --------@dilfridge > not another cooperative project
+18-04-08 - [19:51] --------------@K_F > tamiko: I'd rather put in some more effort to fix the current situation before doing anything, I already proposed to work with trustees to write up a RFP that can be used towards accounting services etc to fix the current IRS mess
+18-04-08 - [19:51] ---+prometheanfire > dilfridge: so you want to do things unilaterally?
+18-04-08 - [19:51] ---------@WilliamH > prometheanfire++
+18-04-08 - [19:51] --------------@K_F > (specifically klondike is trustee liason based on last trustee meeting)
+18-04-08 - [19:52] ---------- antarus > dilfridge: which part is a dream?
+18-04-08 - [19:52] ---------- antarus > teh foundation ever resolving its tax problems?
+18-04-08 - [19:52] ---------- antarus > the foundation disbanding?
+18-04-08 - [19:52] --------@dilfridge > I want to keep the fruitful relationship of the Gentoo distribution with the Gentoo Foundation, and open up an additional relationship with a second legal entity.
+18-04-08 - [19:52] ---+prometheanfire > I'm in favor of doing less work
+18-04-08 - [19:52] --------@dilfridge > antarus: both
+18-04-08 - [19:52] --------@dilfridge > That gives us a lot more flexibility.
+18-04-08 - [19:52] ---------- antarus > and it sa dream because you don't think teh board or foundation members want it ot happen?
+18-04-08 - [19:52] ---------- antarus > or because the board is incompetent?
+18-04-08 - [19:52] -----------@tamiko > prometheanfire: Can you please make a statement what the current tax situation of the Foundation is?
+18-04-08 - [19:52] --------------@K_F > for one thing, reputation wise we anyways need to sort out the financial situation of the foundation
+18-04-08 - [19:52] ---------- antarus > (no offense to the board)
+18-04-08 - [19:53] --------@dilfridge > Also, we gain potentially a lot of money, because donations via SPI will be tax-deductible.
+18-04-08 - [19:53] ---+prometheanfire > tamiko: we need a new tax guy and preferably a new person to run the books
+18-04-08 - [19:53] --------------@K_F > but the reason I proposed to help writing up RFP is the inactivity of the current board
+18-04-08 - [19:53] ---+prometheanfire > both are very hard to find because of the use of non open source software
+18-04-08 - [19:53] ---+prometheanfire > antarus: <3
+18-04-08 - [19:53] --------------@K_F > that is needed to get any kind of quote/feedback from an accounting firm, and will include outsourcing accounting and future filing to a firm accepting it
+18-04-08 - [19:53] -----------@tamiko > prometheanfire: But that makes me worried a bit that the Foundation might be in serious legal troubles and financial jeopardy.
+18-04-08 - [19:53] ---------- antarus > prometheanfire: I was on it too ;p
+18-04-08 - [19:53] ---------@WilliamH > prometheanfire: What's the status of finding someone to do it?
+18-04-08 - [19:54] -----------+Whissi > The person doing Gentoo's taxes is forced to use open source software?
+18-04-08 - [19:54] --------@dilfridge > Lastly, I want to make clear that I don't want to take anything away from the Gentoo Foundation. I'm happy if they keep working,
+18-04-08 - [19:54] --------@dilfridge > if they fix their problems, and contribute fruitfully.
+18-04-08 - [19:54] -----------@tamiko > I think as council it is our duty to ensure that the developer community has all resources (server, git, mailing lists) they need to do their work.
+18-04-08 - [19:54] ---+prometheanfire > Whissi: it part of our rules that we use open source softwhere wherever possible
+18-04-08 - [19:54] ---+prometheanfire > I'm going to propose that it is not possible in this case
+18-04-08 - [19:54] --------------@ulm > follows from the social contract, I think
+18-04-08 - [19:54] --------------@K_F > prometheanfire: I'm not actually sure that non-open source software is an issue if we outsource it altogether
+18-04-08 - [19:54] ---+prometheanfire > that'd allow up to go up to 'any accountant'
+18-04-08 - [19:55] --------------@K_F > prometheanfire: as long as we have a way it can be exported etc
+18-04-08 - [19:55] ---+prometheanfire > K_F: agreed, that's one of the avenues I wish to use to make my arguement
+18-04-08 - [19:55] -----------@tamiko > prometheanfire: Can you make any (semi) binding statement right now what your timeline of resolving the finances is?
+18-04-08 - [19:56] ---+prometheanfire > I am not the treasurer, however, as of 2ish months ago the timeline was july
+18-04-08 - [19:56] --------------@ulm > 2018?
+18-04-08 - [19:56] ---+prometheanfire > yes
+18-04-08 - [19:56] ---------@WilliamH > prometheanfire: ok, so within the year.
+18-04-08 - [19:56] ---+prometheanfire > that was right around the time our current accountant decided to move from the west side of canada to the east side
+18-04-08 - [19:56] ---+prometheanfire > which has stalled things
+18-04-08 - [19:56] --------------@K_F > I do agree that open source is a requirement if we do our own book-keeping, simply to ensure we have access to maintain it, but not if an accounting firm does filing for us as long as there are ways to switch , and usually these software have ways to do that and also online interfaces for us to interact with
+18-04-08 - [19:56] -----------@tamiko > prometheanfire: The one thing I really don't want to see to happen is that we lose our infrastructure due to some legal actions against the Foundation.
+18-04-08 - [19:57] ---+prometheanfire > K_F: ++
+18-04-08 - [19:57] ---+prometheanfire > tamiko: I do not think we are at risk of that
+18-04-08 - [19:57] ---+prometheanfire > even slightly
+18-04-08 - [19:57] ---------- antarus > tamiko: I mean there is always risk; I'm not particularly worried about that for the foundation
+18-04-08 - [19:58] --------@dilfridge > well, part of risk mitigation is not putting all eggs into one basket
+18-04-08 - [19:58] ---------- antarus > dilfridge: I think the trouble is if you use the name, you need the boards support
+18-04-08 - [19:58] ---------@WilliamH > Since it sounds like tthey will get the books resolved within 2018 I'm fine just letting them do that.
+18-04-08 - [19:58] ---------@WilliamH > they *
+18-04-08 - [19:58] -----------@tamiko > dilfridge: That is true - but as a developer community we should support the Foundation as well.
+18-04-08 - [19:59] ---------@WilliamH > tamiko++
+18-04-08 - [19:59] --------@dilfridge > WilliamH: you likely dont know how much I had to push until trustees even realized that the treasurer was unreachable
+18-04-08 - [19:59] -----------@tamiko > So I am not happy with the motion due to the simply reason that it simply creates more in-fighting.
+18-04-08 - [19:59] ---+prometheanfire > K_F: can you speek to the proposal for accounting/bookkeeping?
+18-04-08 - [19:59] ---------@WilliamH > tamiko++
+18-04-08 - [19:59] ---+prometheanfire > I was not a party to putting that together
+18-04-08 - [19:59] ---------- antarus > I think its also completely reasonable to put some kind of time boands on things, right
+18-04-08 - [19:59] --------------@K_F > prometheanfire: can you elaborate on that question?
+18-04-08 - [19:59] ---------- antarus > bounds*
+18-04-08 - [19:59] ---+prometheanfire > K_F: your work with klondike
+18-04-08 - [19:59] -----------@tamiko > That said - I also do not see the Foundation as the only way of holding assets for Gentoo. I.e. I would not rule out a switch to SPI (or similar).
+18-04-08 - [20:00] --------------@K_F > prometheanfire: opened git repo and started on a slight outline, but not much more given I've been travelling the past weeks
+18-04-08 - [20:00] ---------- antarus > Get a reasonable timeline from teh board, with milestones
+18-04-08 - [20:00] --------@dilfridge > antarus: if you use the name publicly sure
+18-04-08 - [20:00] ---+prometheanfire > K_F: ok, thanks
+18-04-08 - [20:00] ---------- antarus > and either the board is meeting those milestones, or it isn't
+18-04-08 - [20:00] ---------- antarus > if you think the board sucks, elect a new board, and then do whatever
+18-04-08 - [20:00] ---------@WilliamH > I want the in-fighting to stop, so yes I'm opposed to this motion.
+18-04-08 - [20:00] -----------@tamiko > antarus: Agreed.
+18-04-08 - [20:00] ---+prometheanfire > K_F: this will be on the agenda for the board meeting
+18-04-08 - [20:01] ---------- antarus > (but of course the council and the board can't be the same people, which is interesting here)
+18-04-08 - [20:01] ---------@WilliamH > antarus++
+18-04-08 - [20:01] --------------@K_F > prometheanfire: the overall idea is presented above though, describe current situation, request quote for fixing the backtaxes and getting properly audited accounts, and outsourcing accounting going forwards
+18-04-08 - [20:01] ---+prometheanfire > I'm in favor of this motion, as long as it's a group of both the council and the board that approaches the SPI
+18-04-08 - [20:01] --------@dilfridge > antarus: that's up to the foundation trustees, who could easily fix their bylaws
+18-04-08 - [20:01] ---------@WilliamH > prometheanfire++
+18-04-08 - [20:01] --------------@K_F > prometheanfire: the latter is to give incentive for firm taking it as it will mean future business, that hopefully reduces cost of getting up to date somewhat
+18-04-08 - [20:01] -----------@tamiko > I have one last, question. prometheanfire: Would the board agree to make a clear commitment to the current role of the foundation and the developer community (i.e. the status quo)?
+18-04-08 - [20:02] --------------@K_F > e.g with a 3 year exclusivity for it
+18-04-08 - [20:02] --------@dilfridge > prometheanfire: the problem with that is, we have to explicitly exclude trustees and officers to keep the two firewalled (for legal reasons)
+18-04-08 - [20:02] ---+prometheanfire > K_F: that's a good point (on going contract of some sort)
+18-04-08 - [20:02] ---------- antarus > tamiko: is this mgorny's request?
+18-04-08 - [20:02] -----------@tamiko > antarus: This is my request.
+18-04-08 - [20:02] -----------@tamiko > mgorny: Did you ask for something simiarl?
+18-04-08 - [20:02] ---------- antarus > I though this was similar
+18-04-08 - [20:02] ---+prometheanfire > tamiko: we'd need a specific proposal, I can't comment without it
+18-04-08 - [20:02] ---------- antarus > mostly that the board would support the council in all legal motions
+18-04-08 - [20:02] ---------- antarus > (afaik)
+18-04-08 - [20:03] ---+prometheanfire > dilfridge: I'm not sure that's true
+18-04-08 - [20:03] -----------@mgorny > tamiko: sorry, can't paste link right now
+18-04-08 - [20:03] ---------- antarus > if i was on the board i wouldn't make that specific; but I'd be open to crafting some kind of statement
+18-04-08 - [20:03] *** prometheanfire+ still wants to combine the board and council into one body with subcommitties
+18-04-08 - [20:03] ---------- antarus > (and i'm not)
+18-04-08 - [20:03] ---------- antarus > maybe we will see more people standing as trustees in the next election ;p
+18-04-08 - [20:03] ---+prometheanfire > antarus: that'd be nice
+18-04-08 - [20:04] -----------@tamiko > prometheanfire: I explicitly would ask the Trustees to not try to combine the board and the council and keep the status quo as is.
+18-04-08 - [20:04] -----------@mgorny > It was about trustees saying they won't be overriding council when people try to play them
+18-04-08 - [20:05] ---+prometheanfire > supporting all 'legal motions' is not something I think we can do, there are many things you can legally do that would go against the project
+18-04-08 - [20:05] --------@dilfridge > the repeated story is now "xyz does not agree with council decision, xyz goes to trustees, tells them they have the real authority, and asks them for support"
+18-04-08 - [20:06] --------@dilfridge > and then the mudslinging starts
+18-04-08 - [20:06] -----------@mgorny > I just meant those that are legally fine, a general statement like "we will be only using override when legal necessity"
+18-04-08 - [20:06] -----------@tamiko > I move the subject to 9. Open floor
+18-04-08 - [20:07] -----+NeddySeagoon > mgorny: Hasn't that been the practice?
+18-04-08 - [20:07] --------------@K_F > mgorny: the thing is, such a statement wouldn't be binding anyways, in particular not across future boards
+18-04-08 - [20:07] ---+prometheanfire > dilfridge: typically, yes, and in almost all cases (I really can't think of one) we would only override a decision if it was clearly bad for the project or had some legal implication
+18-04-08 - [20:07] ---------- antarus > K_F: I think its more to present a united front so people avoid trying it
+18-04-08 - [20:07] ---------- antarus > not to make an actual binding statement
+18-04-08 - [20:07] -----------@mgorny > NeddySeagoon: i didn't notice trustees doing that in 3 late cases
+18-04-08 - [20:08] --------------@K_F > antarus: that would be best demonstrated if trustees reacted in that way when such issues came up and establish a precedent for it
+18-04-08 - [20:08] ---+prometheanfire > I'm fine with a non-binding statement
+18-04-08 - [20:08] ------ *** antarus nods
+18-04-08 - [20:08] ---------- antarus > prometheanfire: :)
+18-04-08 - [20:08] ---+prometheanfire > mgorny: iirc, we requested more info, to determine legal risk, we didn't override anything
+18-04-08 - [20:08] -----+NeddySeagoon > K_F: That would work
+18-04-08 - [20:08] ---------@WilliamH > When have the trustees overridden the council anyway? I can't think of any instance.
+18-04-08 - [20:08] --------@dilfridge > (rolling eyes)
+18-04-08 - [20:09] ---------- antarus > dilfridge: my favorite sushi roll is eyeroll! :)
+18-04-08 - [20:09] ---------@WilliamH > heh
+18-04-08 - [20:09] --------@dilfridge > I see the identification of the Foundation trustees with the persons legally responsible for everything slightly problematic.
+18-04-08 - [20:09] ---+prometheanfire > you are welcome to step up
+18-04-08 - [20:09] --------@dilfridge > At least, everything I do for Gentoo is not "owned" by the foundation in any way.
+18-04-08 - [20:10] -----------@mgorny > prometheanfire: i meant you didn't provide united front
+18-04-08 - [20:10] ---+prometheanfire > dilfridge: ebuilds?
+18-04-08 - [20:10] -----------@tamiko > prometheanfire: A possible draft would be something like this:
+18-04-08 - [20:10] ---------@WilliamH > dilfridge: the trustees do own Gentoo -- they own the name, trademarks, etc.
+18-04-08 - [20:10] -----------@tamiko > prometheanfire: »The council affirms Gentoo's metastructure GLEP 39 as the governing principle of the Gentoo Linux Developer community. In particular, the council acknowledges the split between the council, which is responsible for the Gentoo Linux Developer community, its user base and all technical decisions, and the Gentoo Foundation, whose role is to hold Gentoo's assets (trademark, copyright
+18-04-08 - [20:10] -----------@tamiko > and server infrastructure) and support the developer community. The council requests the Board of Trustees of the Gentoo Foundation to acknowledge and affirm this statement as well.«
+18-04-08 - [20:10] --------@dilfridge > Nope. Copyright can only belong to natural persons.
+18-04-08 - [20:10] ---+prometheanfire > dilfridge: not here :P
+18-04-08 - [20:10] ---+prometheanfire > which is where gentoo 'exists'
+18-04-08 - [20:11] ---------- antarus > I would prefer not to get into an argument around copyright
+18-04-08 - [20:11] -----+NeddySeagoon > dilfridge: Not in some places
+18-04-08 - [20:11] --------@dilfridge > that's an interesting question, given that the majority of devs and many servers are in the eu
+18-04-08 - [20:11] ----- *** WilliamH doesn't want to get into the argument wrt copyright either
+18-04-08 - [20:11] ---------- antarus > I think dilfridge has enough of a point there that debate is pointless
+18-04-08 - [20:12] -----------@tamiko > dilfridge: That's a reason why this is a quick draft - we can remove the "copyright" part. It is wrong anyway.
+18-04-08 - [20:12] -----+NeddySeagoon > tamiko: Lets no do this in a hurry
+18-04-08 - [20:13] -----------@tamiko > NeddySeagoon: We will not vote on this today.
+18-04-08 - [20:13] --------------@ulm > we're currently trying to sort out the copyright part
+18-04-08 - [20:13] -----------@tamiko > I think we can close the meeting for now - everyone is happy to stay and continue the discussion.
+18-04-08 - [20:13] --------------@ulm > and I'd also ask to leave it out of any motion
+18-04-08 - [20:13] ------- *** tamiko bangs the gavel.
diff --git a/meeting-logs/20180408.txt.asc b/meeting-logs/20180408.txt.asc
new file mode 100644
index 0000000..690c036
--- /dev/null
+++ b/meeting-logs/20180408.txt.asc
@@ -0,0 +1,17 @@
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v2
+
+iQIzBAABCgAdFiEEfy3LeT5sTLH/IgxSb5XRn46MCPwFAlrXtmoACgkQb5XRn46M
+CPzzJA/+IwMhBF8fieEZ11YfP1zPAx9uJUQ9pGFhiNoeZNkIAtININBZFy8ozgYN
+u3sEF/MuxdQOtFVv9PojJusj82Vj8tAL0bsGr7sn7kDN9+aZ6tYKuPO+DLhMxwAq
+m8tooRWXwXb/IaVBIIEi+7j629J9X3JMJJWfXxII9aSuZmIxXTWiPdV4oNvzf2VZ
+oc1v98NY0SiBmcJAGcG409INzCoFHDzH9MBksnw0vTCnvMlITBrtDSSlPnnhauWs
+iaxCRBI/4raDcFweEI/1Vut0i0tD+FL5gCPgSXSy3HP3vQvJs1gH0tnKRr1eSdOK
+CKPJquhJUqCiRlSgCtEmcDmKHwr8f+qbfWHXH9P3AHnZB2rrV/T1cZ4+0Y8sHhrj
+uLb0XPJ910DDsWst0v9+B+6tYEefNTVyVw6RX7KyXdCfHYamOWlTN51Pph5WHyiD
+tp/inSuC8czphuiREt74V0y2cfuaOXBbHZVeR7fSPrDD6aM07JP9nI8IoNHJ16lF
+9stAY/CxRa5v9OZ6fTJn5QqGDqjDnEK0DQfQKSfkxV/fzuN50GwYK2iEL+IAP1pV
+SbeSA/a/yrra5XxC9ePEtjdCnHh3p9q2fvOPHKq1JGF1na2hQ0ek8cs+pj5xw00P
+HJeRUkXlBY1F/3I5jNo0qRUjulqxttHxbfSxo4MJHMJ+dszLBOg=
+=BAGC
+-----END PGP SIGNATURE-----