Add council meeting summary/log 20161009

Signed-off-by: Justin Lecher <jlec@gentoo.org>

4 files changed, 266 insertions, 0 deletions

diff --git a/meeting-logs/20161009-summary.txt b/meeting-logs/20161009-summary.txt
new file mode 100644
index 0000000..f2993cb
--- /dev/null
+++ b/meeting-logs/20161009-summary.txt
@@ -0,0 +1,34 @@
+Summary of Gentoo council meeting 11 September 2016
+
+Agenda
+======
+
+1) Roll call
+3) Bugs with council participation
+4) Open floor
+
+
+Roll call
+=========
+Present: dilfridge, jlec, k_f, rich0, ulm, williamh, blueness
+
+
+Bugs with council participation
+===============================
+
+565566: ulm followed this up with robbat2. robbat2 is working on the historical git
+conversion, but no ETA for the fix yet. council invites Infra to give some more 
+insights at the next meeting.
+
+
+Open floor
+==========
+
+WilliamH wanted the council discuss the availability of the graveyard overlay
+through layman. The overlay contains packages dropped out from the main
+gentoo repository due to lastriting. WilliamH wanted to know whether placing
+potentially widely used, but by upstream deprecated, versions of apps,
+e.g. grub:0, should live there. There was a general concern about the additional
+amount of insecure and broken ebuilds to the user with this approach and the
+council suggested to better lastrite those version with longer lead times,
+rather then pointing users to the overlay.
diff --git a/meeting-logs/20161009-summary.txt.asc b/meeting-logs/20161009-summary.txt.asc
new file mode 100644
index 0000000..7423900
--- /dev/null
+++ b/meeting-logs/20161009-summary.txt.asc
@@ -0,0 +1,19 @@
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG/MacGPG2 v2.0
+
+iQJ8BAABCgBmBQJYhKVkXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
+ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF
+OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmihI4QAI/fCPDhydNQNaABLVkVRwfW
+Y7mADs2eNn9cf/Z/szDkc1jiMb/01k+jK4cxp3J6UfkHol5EYAp8HcVmPylNHLqN
+wdlR0eEyRkkKfmhaQy8yd/poZ2Wg26grr6RZPQ+LWiJQv/Pol/yFVYQqRxHveJ9c
+Yvg/Ha7y43ewS16b7rF1yLlcEHD4Q6ADO0tPCT+fz75JE38zrvtRhwyEBYxOPTo2
+wsoM8/JOgqnPQahFhQ2zBExvoHSB/vULDQr+FK78fKR9nyJhX6e+/UtZ4K4Xn0Ta
+D0C4QjKwK8BMyQTzEGwS2EtuHlnieV3YKhSMHXWavPBLkyT6L2e+NEGIuXiB7MTi
+SxU326QBRLPViBhd/gDc+MeaUk72gv3d3LL6nZux4Vbid+O+J/gVIA9mROMrBrAE
+wjFhhVtPnu4YWGEhdPhfNh8gUu4q1tJxtEut2BwYJNCIKIUHlKn860wJwtPt3rkK
+esdaaIPEsbZ0OzC3SPRmLJGgx9AxGd2j1QkZLGNkK7N3/FjRZ5qcyL9o7mHmTABL
+ujxC8WcBQg/+xxH1lNf2Z7hUBumc/5esvwk8v6AgQHIrdsehxkXdzOtrrwUR+IBI
+GcLKdf9uzEATwutoM+faiQaiDV3C4Sh3dFae+juk3P93sikwjuso045Qc1QofKSM
+tL1EeEF74JmiiQqNTF3n
+=E4N9
+-----END PGP SIGNATURE-----
diff --git a/meeting-logs/20161009.txt b/meeting-logs/20161009.txt
new file mode 100644
index 0000000..4d11386
--- /dev/null
+++ b/meeting-logs/20161009.txt
@@ -0,0 +1,194 @@
+[21:00:23] <jlec> !proj council
+[21:00:23] <willikins> (council@gentoo.org) blueness, dilfridge, jlec, k_f, rich0, ulm, williamh
+[21:00:33] * rich0 here
+[21:00:35] <jlec> Shall we wait for K_F
+[21:00:36] <jlec> ?
+[21:00:43] <blueness> meeting in 10 mins
+[21:01:07] <rich0> I suggest we proceed but wait at the end or if anything exciting comes up.  We can probably grind through some of the boring stuff first.
+[21:01:41] *** Joins: ulm_ (~ulm@gentoo/developer/ulm)
+[21:01:41] *** ChanServ sets mode: +o ulm_
+[21:02:05] * blueness here
+[21:02:06] <blueness> agreed
+[21:02:07] <blueness> so who’s here?  just me, rich0 and jlec ?
+[21:02:13] * WilliamH is here
+[21:02:20] * ulm_ here
+[21:02:32] * dilfridge here
+[21:02:51] * jlec here
+[21:03:13] * rich0 here
+[21:03:20] <jlec> Only K_F is missing
+[21:03:38] <jlec> 2) Bugs with council participation[1]
+[21:03:40] <ulm_> he's still on his way back from Prague, I guess
+[21:04:02] <jlec> or did I miss something?
+[21:04:11] <NeddySeagoon> his flight is delayed
+[21:04:14] <jlec> Nobody replied to the call for topics, correct?
+[21:04:33] <jlec> https://bugs.gentoo.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=IN_PROGRESS&email2=council%40gentoo.org&emailassigned_to2=1&emailcc2=1&emailreporter2=1&emailtype2=substring&list_id=3253044&query_format=advanced
+[21:05:22] <blueness> jlec: i didn’t see anything
+[21:05:44] <jlec> bug 565566
+[21:05:46] <willikins> jlec: https://bugs.gentoo.org/565566 "New ChangeLogs are in chronological order"; Gentoo Infrastructure, CVS/SVN/Git; CONF; patrick:infra-bugs
+[21:05:52] <jlec> That's the only interesting one
+[21:06:07] <jlec> Any progress? If not, what actions should we take
+[21:06:17] <ulm_> I shortly talked to robbat2 yesterday
+[21:06:40] <ulm_> IIUC he's working on the historical git conversion
+[21:06:57] <WilliamH> I saw some conversation about another issue wrt the changelogs recently, but I'm not sure what the deal was?
+[21:07:10] <K_F> sorry about delay, online now
+[21:07:19] <jlec> hi K_F
+[21:07:23] <jlec> we just started
+[21:07:29] <jlec> ulm: ETA?
+[21:07:29] <WilliamH> K_F: the only topic is open bugs.
+[21:07:41] <K_F> i added missing summary one earlier
+[21:07:52] <K_F> and did a crossreference/see also on one
+[21:07:56] <ulm_> jlec: I don't know
+[21:08:22] <jlec> So do we need to do something?
+[21:08:32] <K_F> seems changelogs are causing some pf the issues for manifest generation
+[21:09:49] <jlec> What do you think, again a suggestion to infra or more this time?
+[21:09:52] <blueness> i think we need infra’s input on this
+[21:10:09] * WilliamH is looking through meeting logs
+[21:10:27] <rich0> Do we want to send them an email, or ask them to show up to the next meeting (or likely both?).
+[21:10:40] <ulm_> +1
+[21:10:47] <K_F> rich0: makes sense if the issue isnt resolved by then
+[21:10:52] <jlec> good idea, either having resolved this issue or tell us what they are planing.
+[21:11:04] <jlec> okay, I will send them a mial
+[21:11:16] <rich0> K_F: well, we can always invite ask them to show up, and tell them that if it is resolved by then they don't have to.
+[21:11:24] <K_F> yup
+[21:11:34] <rich0> It just feels like this is a pretty serious issue for rsync users, and it is dragging.
+[21:11:59] <dilfridge> it just hit >5 x11 packages right now
+[21:12:04] <jlec> it is and it takes to long time
+[21:12:16] <dilfridge> there's a thread about it on the gentoo-user mailing list
+[21:12:58] <jlec> SO do we agree inviting them is enoigh for now?
+[21:13:29] <rich0> I'd start an email discussion in the meantime.  No sense idling until the next meeting.
+[21:13:39] <K_F> imho we should be more proactive
+[21:13:59] <rich0> And we can always trade messages here or in #-infra
+[21:14:02] <K_F>  work on it between meetings
+[21:14:23] <blueness> jlec: yes
+[21:14:30] <K_F> rich0++
+[21:15:01] <dilfridge> so maybe we should arrange a time when some of us discuss this with the infra people?
+[21:15:17] <K_F> or email
+[21:15:21] <dilfridge> like, in real-time instead of via delayed responses
+[21:15:32] <blueness> email, infra is very loosely organized
+[21:15:40] <blueness> i’m with infra, but i don’t know anything about this system
+[21:15:44] <blueness> i just do the blogs
+[21:16:21] <jlec> okay, I will send a mail and let's see how it goes.
+[21:16:47] <jlec> Or ulm do you like ot go ahead, as you already contacted robbat2
+[21:16:49] <jlec> ?
+[21:17:16] <rich0> Suggest email to kick it off.  We can always tell them to feel free to ping us here, but it will be scattered relatime chat with various groups of us, which I think is fine to keep it moving.
+[21:17:25] <rich0> I think we're mostly aligned on direction anyway.
+[21:17:32] <jlec> All other bugs have same status as last month. Anybody likes to discuss one of them?
+[21:17:53] <ulm_> jlec: no, I'm fine with you writing the e-mail
+[21:18:13] <jlec> good
+[21:18:16] <jlec> next
+[21:18:18] <jlec> 3) Open floor
+[21:18:28] <jlec> Community, anything you like ot bring forward?
+[21:18:48] <WilliamH> Ok, I have a general question, not something to vote on, I'm more looking for opinions.
+[21:19:01] <WilliamH> The graveyard overlay is now in layman.
+[21:19:25] <WilliamH> It was originally supposed to be a place where things can go when they are lastrited.
+[21:19:50] <WilliamH> Is it reasonable to have shorter lastrites periods if the package is going to the overlay?
+[21:20:04] <ulm_> WilliamH: why is it in layman, in the first place?
+[21:20:12] <K_F> not really
+[21:20:17] <dilfridge>  no
+[21:20:28] <WilliamH> ulm_: I put it there, so people can install packages from there if they want them. it is not officially supported.
+[21:20:29] <dilfridge> also, if it is in layman, who is the responsible contact?
+[21:20:31] <rich0> WilliamH: I don't think we should be in a rush to lastrite unless it is holding up something critical.
+[21:20:34] <ulm_> there must be many packages e.g. with security issues
+[21:20:38] <rich0> 30 days isn't that long as it is.
+[21:21:14] <WilliamH> should it not be in layman? I can remove it if that's the case.
+[21:21:15] <ulm_> and I agree that this shouldn't influence the last-rites workflow
+[21:21:49] <WilliamH> rich0: ok, 30 days is reasonable.
+[21:21:52] <jlec> I have a bad feeling with the overlay being in layman
+[21:22:11] <WilliamH> jlec: how so?
+[21:22:17] <jlec> packages get list rited because they have unfixed security problems or are broken
+[21:22:26] <jlec> otherwise they don't get lastrited
+[21:22:36] <jlec> We shouldn't officially make them available
+[21:22:38] <Soap__> jlec: grub:0 is borderline broken
+[21:22:40] <blueness> jlec: can’t overlays be marked as unstable?
+[21:22:55] <WilliamH> blueness: they can be marked unofficial.
+[21:23:06] <K_F> blueness: iirc there isnt an official support of overlays, all are experimental by default
+[21:23:28] <WilliamH> blueness: K_F  is correct.
+[21:23:51] <ulm_> at least the overlay is labelled as "experimental" and "unofficial"
+[21:24:17] <K_F> i'm fine with it being in layman
+[21:24:22] <WilliamH> I wasn't going to  bring up grub:0, but that is myspecific example, yes.
+[21:24:24] <blueness> maybe we should add another catagory
+[21:24:25] <blueness> mark an overlay as “dangerous"
+[21:24:26] <blueness> do we have a GLEP that governs overlays?
+[21:24:38] <K_F> its just convenience, no statement of support
+[21:24:56] <kensington> an overlay certainly can be marked as official
+[21:25:12] <WilliamH> blueness: k_f is correct.
+[21:26:42] <ulm_> kensington: there are two predicates, quality and status
+[21:26:54] <ulm_> status can be official or unofficial
+[21:27:36] <ulm_> and for quality I find "core", "experimental", and "testing"
+[21:27:49] <ulm_> not sure what the difference between the last two is
+[21:28:22] <K_F> ulm_: i see semantic differences there, testing being higher expectatiom
+[21:28:26] <veremitz> you might think 'testing' would work .. whereas experimental might not ..
+[21:28:29] <dilfridge> we probably need another one "b0rken"
+[21:28:42] <dilfridge> or "insecure"
+[21:28:43] <WilliamH> The README in the overlay makes it pretty clear what is going on, but I may remove the comment about proxy-maint.
+[21:29:40] * Soap__ git mv's 'dev-perl' to b0rken
+[21:29:56] <WilliamH> The reason I activated the overlay is for the grub:0  users primarily.
+[21:29:58] <dilfridge> heh
+[21:30:19] <WilliamH> I want to put grub:0 in there.
+[21:30:28] <WilliamH> rather than lastrite and forget about it.
+[21:30:40] <WilliamH> So people can still get at it if they want and we can move on.
+[21:30:54] <ulm_> WilliamH: the problem is that selecting that overlay will make tons of other crap visible to users
+[21:30:58] <Soap__> also, last-riting applies to packages, not SLOTs, right?
+[21:31:18] <kensington> Soap__: last-rite is a process, one can apply it to anything
+[21:31:31] <WilliamH> Soap__: Sure, but go and talk to the reactionaries in Gentoo.
+[21:31:40] <Soap__> kensington: oh, I thought it formally only applied to a CAT/PN
+[21:31:41] <ulm_> Soap__: yeah, but for example we did last rites for Emacs slots in the past
+[21:31:46] <WilliamH> Soap__: I would just remove it, but that would bring down some wrath.
+[21:31:48] <NP-Completeass> Is it worth putting a */*::graveyard in package.mask in the overlay?  that way users have to unmask anything they want from there?
+[21:32:07] <K_F> ulm_: isnt that more an issue of overlay being in full visibility automatically when added, even for stable? I always mask them mulyself and selectively unmask it
+[21:32:12] <kensington> Soap__: right, there's no requirement to last-rite a slot, but one can if they wish
+[21:32:26] <rich0> imo the main use case for that overlay is people who haven't figured out git
+[21:32:40] <rich0> Granted, finding removed stuff in git is a pita.
+[21:32:42] <Soap__> kensington: given the gravity of the package, I sure do does apply here :)
+[21:32:49] <ulm_> K_F: right, it might be an issue of bad default setting
+[21:32:56] <Soap__> it*
+[21:33:15] <WilliamH> rich0: you''re right, that's the main use case for it.
+[21:33:39] *** NP-Completeass is now known as NP-Hardass
+[21:33:55] <kensington> NP-Hardass: depends, I would think packages should only go in there for a reason, rather than adding every random crap
+[21:33:57] <WilliamH> rich0: "git log sys-boot/grub"
+[21:34:16] <WilliamH> rich0: shows you everything that happened to everything in that path.
+[21:34:17] <rich0> WilliamH: does that work if sys-boot/grub isn't in the tree?
+[21:34:31] <rich0> Does it work for a path that doesn't current exist?
+[21:34:52] <veremitz> afaik no..
+[21:34:55] <WilliamH> rich0: I'm not sure.
+[21:34:55] <ulm_> rich0: git log -- sys-boot/grub
+[21:35:20] <ulm_> with the -- it will show removed files/dirs too
+[21:35:21] <NP-Hardass> kensington: sure, but given the unsupported nature of the overlay, making it default manual intervention required would help sell this point
+[21:35:22] <rich0> Well, that's a dealbreaker right there...  :)
+[21:35:30] <WilliamH> rich0: In this example I'm not talking about nuking sys-boot/grub
+[21:35:57] <veremitz> WilliamH: that would be severely unpopular :P
+[21:36:00] <Soap__> NP-Hardass: agreed, thats how it should be
+[21:36:27] <WilliamH> veremitz: heh I'm just wanting to nuke grub:0
+[21:36:52] <NeddySeagoon> Do we want to teach users to get things out of git or maintain an overlay?
+[21:37:13] <NP-Hardass> NeddySeagoon: ideally, both.
+[21:37:21] <K_F> users needing to be thought that likely should stick to the supported software in main tree to begin with
+[21:37:22] <veremitz> -_-
+[21:37:36] <K_F> maintaining an overlay is more advanced use ahead of contributions and becoming a dev
+[21:37:38] <WilliamH> NP-Hardass: the most efficient way would be to write up a wiki page on how to pull things out of git.
+[21:37:41] <NP-Hardass> NeddySeagoon: Though, getting things from git, I did a writeup on using git as an equiv to the CVS attic on the dev ML a while back
+[21:37:46] <NP-Hardass> WilliamH: ^^
+[21:38:40] <WilliamH> K_F: good point.
+[21:38:50] <NeddySeagoon> NP-Hardass: I'll see if I can find that.  I would find it useful anyway.  Thatnk you
+[21:39:13] <NP-Hardass> NeddySeagoon: np.  As WilliamH said, would probably be useful to put it on the wiki
+[21:39:37] <NeddySeagoon> NP-Hardass: maybe I'll do that if I can make it work
+[21:40:23] <WilliamH> wrt grub:0, I wanted to apply lastrites because just removing it would be very unpopular.
+[21:40:30] <WilliamH> Soap__: ^^
+[21:40:34] <jlec>  WilliamH are you good?
+[21:40:37] <veremitz> 90-day last-rites?!
+[21:40:43] <Soap__> WilliamH: I am well aware ;)
+[21:41:02] <WilliamH> veremitz: imo 30 or 60 is reasonable...
+[21:41:04] <NP-Hardass> NeddySeagoon: https://archives.gentoo.org/gentoo-dev/message/305c431c84c39bc74b1077f0b395ce91
+[21:41:17] <NeddySeagoon> NP-Hardass: Thank you
+[21:41:19] <WilliamH> jlec: Yes, I'm basically good.
+[21:41:30] <jlec> fine
+[21:41:37] <WilliamH> another informal question after the meeting closes.
+[21:41:43] <WilliamH> so go ahead with the meeting.
+[21:41:54] <jlec> So ig there is nothng else, Iwould like to close
+[21:42:05] <jlec> anyone?
+[21:42:49] <NP-Hardass> WilliamH: what are the conditions for which something enters graveyard?
+[21:43:11] <K_F> just a PSA. the talks from miniconf in prague should be online now
+[21:43:23] <K_F> so might be interesting for those that didnt participate
+[21:43:35] <WilliamH> NP-Hardass: let's let the meeting go on, I'll answer after.
+[21:43:40] <NP-Hardass> Sure
+[21:43:47] <veremitz> K_F: is there a central location for that jazz?
+[21:43:54] * jlec closes the meeting
diff --git a/meeting-logs/20161009.txt.asc b/meeting-logs/20161009.txt.asc
new file mode 100644
index 0000000..bd20d4f
--- /dev/null
+++ b/meeting-logs/20161009.txt.asc
@@ -0,0 +1,19 @@
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG/MacGPG2 v2.0
+
+iQJ8BAABCgBmBQJYhKFzXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
+ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF
+OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiPkAP/RN1MtSrovmdDVFIA8vWJRY0
+gWiW3j8FCDwG8oPjagosM67IkDqzukR8TebWARXljhv0deAZd4FH8aq5SlvgK6ij
+3JKHY+xamhcenSkRMFGtskRang24DJUQNzv8uQuQhWeKWvXAnzr+MPQmruIOM3G+
+kVRulleo2FIGplHCuEHjg4ufxfk43/jSkLw2fS3cV+2lEqFm11e02Ey0kW8JMbva
+K5796lUIFwcNenICZjVbHONmREYzbNPrVPYB+MAzaadX6T7AA0fBMzy5aKhbdY3U
+/LKevZ4l6gdB2wrimBz6490Jfb3g6kxlVCZRpokob7xAEEo8qKeiSeMvvvrxkh3u
+PgljIkAm1VNZptQQaAcYa5GFBnu8khNStepxeEcuIJz8rpzFpA9sXgMXsZmuCC2O
+roQnaFdNDo5jvAOoxnhV8yPKNCBSAIxZIqt5/dbMv4M0diTQiL9Pq7BBFBSH1M0g
+4B+1GGuodtO8lYVqsene1vOiyAGH+isV4qlOspJ22AyjFPG+yUAT34Dk4xaPPIzg
+N3M1JRz54VVyUxAyNc/ajWxf69v5VEcNyU6FGPjzy72gZO9cnPDHEADJ7nS9MvbR
+2PBP7GIIzrgj0Rz+NxeucFGT+cloyxwHVP4tmfbB9g+gFvZk71VgTP2rZJ2mQCku
+Vd6g0QY7yn/o0OeuDs4X
+=UKL0
+-----END PGP SIGNATURE-----