Add log for 2017-07-16

1 files changed, 381 insertions, 0 deletions

diff --git a/meeting-logs/20170716.txt b/meeting-logs/20170716.txt
new file mode 100644
index 0000000..c71968b
--- /dev/null
+++ b/meeting-logs/20170716.txt
@@ -0,0 +1,381 @@
+2017-07-09 18:47:58-!- K_F changed the topic of #gentoo-council to: Next meeting: 2017-07-16 19:00 UTC | https://www.timeanddate.com/worldclock/fixedtime.html?iso=20170716T19 | https://wiki.gentoo.org/wiki/Project:Council | http://dev.gentoo.org/~dilfridge/decisions.html
+2017-07-09 18:48:38<@K_F> dwfreed: let me know if you come across it Next meeting: 2017-07-16 19:00 UTC | https://www.timeanddate.com/worldclock/fixedtime.html?iso=20170716T19 | https://wiki.gentoo.org/wiki/Project:Council | http://dev.gentoo.org/~dilfridge/decisions.html
+2017-07-09 19:23:26<@K_F> https://pad.sumptuouscapital.com/p/gentoo-council-agenda-2017-07-16
+2017-07-16 01:41:22-!- mode/#gentoo-council [+o slyfox_] by ChanServ
+2017-07-16 20:01:02<@K_F> 1h warning
+2017-07-16 20:10:37 * shentino whips up a batch of cookies and punch for everyone
+2017-07-16 21:00:41< dwfreed> K_F: 19:00
+2017-07-16 21:00:44 * slyfox_ is around
+2017-07-16 21:00:45<@K_F> !proj council
+2017-07-16 21:00:47< willikins> K_F: (council@gentoo.org) dilfridge, k_f, mgorny, slyfox, tamiko, ulm, williamh
+2017-07-16 21:00:51<@K_F> 1. Roll call
+2017-07-16 21:00:53 * K_F here
+2017-07-16 21:00:56 * dilfridge here
+2017-07-16 21:00:57 * tamiko here
+2017-07-16 21:00:59 * slyfox here
+2017-07-16 21:01:00 * WilliamH here
+2017-07-16 21:01:04 * ulm here
+2017-07-16 21:01:07 * mgorny here
+2017-07-16 21:01:16<@dilfridge> whee
+2017-07-16 21:01:18<@K_F> great, full team on time
+2017-07-16 21:01:29<@K_F> lets jump right to point 2 Constituting the new council
+2017-07-16 21:02:01<@K_F> first off, I propose we continue 2nd sunday every month at 1900 UTC for our regular meetings
+2017-07-16 21:02:08<@K_F> any opposing propositions?
+2017-07-16 21:02:09-!- dilfridge changed the topic of #gentoo-council to: Next meeting: 2017-07-16 19:00 UTC | https://www.timeanddate.com/worldclock/fixedtime.html?iso=20170716T19 | https://wiki.gentoo.org/wiki/Project:Council | http://dev.gentoo.org/~dilfridge/decisions.html | Agenda: https://archives.gentoo.org/gentoo-project/message/ff3547ea67cdb1c3f68f062bdb088134
+2017-07-16 21:02:31<@mgorny> I'd prefer 1hr earlier in summer time
+2017-07-16 21:02:46<@tamiko> Either works for me.
+2017-07-16 21:02:54<@slyfox> 1900 UTC is good for me, hour earlier is also fine
+2017-07-16 21:02:55<@K_F> to avoid confusion, should likely just make it earlier for all meetings, but it anyways works for me
+2017-07-16 21:02:57<@dilfridge> both is fine
+2017-07-16 21:03:17<@dilfridge> but changing it depending on summer time calls for trouble :P
+2017-07-16 21:03:17<@ulm> both work for me, but please keep it at a fixed UTC time
+2017-07-16 21:03:28 * WilliamH agrees with fixed utc time
+2017-07-16 21:03:50<@mgorny> So 1800Z fine for everyone?
+2017-07-16 21:03:55 * dilfridge yes
+2017-07-16 21:03:56<@WilliamH> That's the whole point of a utc time ;-)
+2017-07-16 21:04:11 * WilliamH yes
+2017-07-16 21:04:26<@tamiko> yes
+2017-07-16 21:04:26 * slyfox yes
+2017-07-16 21:04:35 * K_F yes
+2017-07-16 21:04:39 * ulm yes
+2017-07-16 21:04:46 * mgorny yes
+2017-07-16 21:05:18<@K_F> good, then lets move on to workflow
+2017-07-16 21:05:34<@K_F> I propose we keep existing workflow, i.e  * Vote for continuing last council's workflow considering sending call for agenda items (2 weeks in advance), sending the agenda (1 week in advance) and have the meeting focused, i.e., have major discussions on -project ML prior to the meeting
+2017-07-16 21:05:43<@K_F> any opposing proposals?
+2017-07-16 21:06:24 * slyfox is fine with existingworkflow
+2017-07-16 21:06:29<@mgorny> I think it's good enough
+2017-07-16 21:06:38<@tamiko> The current workflow is fine.
+2017-07-16 21:06:54<@K_F> good, then lets move on to chairs
+2017-07-16 21:07:00<@mgorny> Maybe would be worthwhile to collect items continuosly
+2017-07-16 21:07:10<@mgorny> But the end result would be the sane
+2017-07-16 21:07:14<@mgorny> Same *
+2017-07-16 21:07:32<@K_F> mgorny: there isn't anything stopping starting a discussion ahead of call for agenda, it is preferred way anyways
+2017-07-16 21:07:58<@K_F> but right, if someone want to have it on upcomming meeting we can collect that , or a bug can be filed etc
+2017-07-16 21:08:30 * dilfridge volunteers as chair for oct/nov/dec
+2017-07-16 21:08:32<@K_F> the main issue of doing it in email thread outside call for agenda, and not requiring a repeat request there is that it can get lost
+2017-07-16 21:08:41<@ulm> I can take jan and feb
+2017-07-16 21:08:55<@mgorny> K_F: i suppose we can treat 'call for items' as a 'reminder to list your item' ;-)
+2017-07-16 21:08:58<@WilliamH> I can take Aug/Sep
+2017-07-16 21:09:16 * mgorny is fine with whatever's left ;-)
+2017-07-16 21:09:18<@tamiko> March/April is fine for me.
+2017-07-16 21:09:50< dwfreed> all that is missing is may and june now
+2017-07-16 21:10:22<@tamiko> Maybe dilfridge also wants to hand over one month for slyfox ;-)
+2017-07-16 21:10:32<@K_F> was about to ask on that :)
+2017-07-16 21:10:32<@dilfridge> wfm :)
+2017-07-16 21:10:41<@slyfox> sounds good :)
+2017-07-16 21:10:43<@dilfridge> pick one
+2017-07-16 21:10:56 * slyfox takes may
+2017-07-16 21:11:32<@K_F> slyfox: want june as well? and I can take november from dilfridge
+2017-07-16 21:11:43<@slyfox> sounds good
+2017-07-16 21:11:51<@dilfridge> ++
+2017-07-16 21:12:01< dwfreed> mgorny doesn't have any now
+2017-07-16 21:12:17<@mgorny> you tricky people, keeping it all to yourselves ;-D
+2017-07-16 21:12:39<@K_F> https://download.sumptuouscapital.com/gentoo/council-chairs.txt
+2017-07-16 21:12:41<@mgorny> we either need to strip Council down to 6 people, or add 2 months to the term
+2017-07-16 21:12:58<@K_F> mgorny: want November? :)
+2017-07-16 21:13:05<@mgorny> sure, wfm
+2017-07-16 21:13:26<@K_F> ok, updated then
+2017-07-16 21:13:41< dwfreed> the problem with 6 is that it's easier to split 50/50, which is a fail
+2017-07-16 21:14:09< dwfreed> with 7, it's definitively pass/fail
+2017-07-16 21:14:25<@mgorny> dwfreed: that was a joke
+2017-07-16 21:14:34<@WilliamH> Yeah you don't want a council to have an even number of members. ;-)
+2017-07-16 21:14:37<@K_F> so, I don't have anything more listed as action points for this topic, anyone else want something mentioned?
+2017-07-16 21:15:15<@ulm> somebody needs to update the wiki page
+2017-07-16 21:15:23<@K_F> ulm: I'll do that after meeting
+2017-07-16 21:15:26<@ulm> k
+2017-07-16 21:16:14<@K_F> ok, next point then
+2017-07-16 21:16:29<@K_F> 3. Discussion about the current situation of the stable tree
+2017-07-16 21:16:52<@K_F> WilliamH: as mentioned on list, as GLEP 40 would need a replacement , I changed it to a non-voting discussion point
+2017-07-16 21:17:04<@K_F> Discussion about the current status of the stable tree, and whether it makes sense to replace GLEP 40 with something reflecting current state and expectation of Gentoo Developers and users. One possibility here is re-igniting the efforts of wg-stable with additional members now that there seems to be further interest in the discussions.
+2017-07-16 21:17:17<@slyfox> who of council does stabilization/keywording? :)
+2017-07-16 21:17:29<@K_F> WilliamH: do you want to add anything about your intentions for the point/discussion?
+2017-07-16 21:17:37<@dilfridge> slyfox: you
+2017-07-16 21:18:06<@WilliamH> Well, nothing specific other than what we have isn't working and that we should find some way to streamline the process.
+2017-07-16 21:18:19<@tamiko> Does someone have a list of current active developers on arch teams (doing stabilization)?
+2017-07-16 21:18:28<@WilliamH> as well as figure out which arches we should try to maintain stable trees for.
+2017-07-16 21:18:47<@WilliamH> The reason I originally suggested getting rid of glep 40 is it targets one arch.
+2017-07-16 21:18:58< dwfreed> tamiko: ago, klausman, slyfox
+2017-07-16 21:18:59<@mgorny> dilfridge's glep sounds like a precondition to that
+2017-07-16 21:19:03<@K_F> WilliamH: I feel like this is a recurring topic, yet there wasn't many active participants when we started wg-stable
+2017-07-16 21:19:05< dwfreed> tamiko: that's basically the whole list
+2017-07-16 21:19:27<@K_F> WilliamH: my proposal is to re-start the WG, as it seems more are interested in discussing things now
+2017-07-16 21:19:36<@dilfridge> mgorny: I'd like that, but I didnt get to work on it any more so far... in a week or two...
+2017-07-16 21:20:20<@slyfox> what is dilfridge's GLEP? i thin i've missed it completely
+2017-07-16 21:20:34<@dilfridge> arches.desc
+2017-07-16 21:20:44<@tamiko> IMHO, we don't need more formal procedure - we simply need more people doing stabilization. (we already have a fairly formal procedure for stabilization anyway).
+2017-07-16 21:20:44<@slyfox> ah
+2017-07-16 21:20:52<@dilfridge> https://wiki.gentoo.org/wiki/User:Dilfridge/GLEP:72
+2017-07-16 21:21:06<@slyfox> when i've started doing stabilization i've noticed a few things:
+2017-07-16 21:21:32<@slyfox> - there is umbrella proect for arch testing. each team does it's own stuff
+2017-07-16 21:21:45<@WilliamH> tamiko: The formal procedure is that no one but arch team members can stabilize.
+2017-07-16 21:21:49<@dilfridge> s/is /is no /
+2017-07-16 21:22:08<@slyfox> yes, sorry. s/is is NO/
+2017-07-16 21:22:18<@WilliamH> tamiko: unless you have some arrangements with the arch team or the arch team changes the procedure for their arch as amd64 has,
+2017-07-16 21:22:26<@mgorny> i think we can defer to arch teams to decide who can add stable keywords
+2017-07-16 21:22:36<@slyfox> - there is no formal statement of what is required from arch teams to consider an arch supported
+2017-07-16 21:22:37<@WilliamH> tamiko: or you are on x86, which mandates by glep 40 that the arch team does it.
+2017-07-16 21:23:13<@ulm> weren't arch teams subprojects of base system?
+2017-07-16 21:23:23<@dilfridge> originally yes
+2017-07-16 21:23:27<@dilfridge> and still are
+2017-07-16 21:23:35<@dilfridge> but that doesnt really make too much sense
+2017-07-16 21:23:52<@ulm> indeed it doesn't
+2017-07-16 21:24:05<@mgorny> i don't see much of a point of having a dedicated parent project over them
+2017-07-16 21:24:17<@mgorny> it sounds like structure for the sake of structure
+2017-07-16 21:24:43<@mgorny> the team wouldn't really have any power that the arch teams wouldn't have, and shouldn't have more power than they do
+2017-07-16 21:25:38<@dilfridge> I suspect the idea was to somehow share tools and methods more
+2017-07-16 21:25:41<@ulm> yeah, but you probably don't want them as TLPs
+2017-07-16 21:25:44<@ulm> so keeping base as placeholder may be fine
+2017-07-16 21:25:48<@tamiko> It still stands that 3 people in total for 9 stable arches isn't sustainable.
+2017-07-16 21:25:51<@K_F> one point would be sharing policies, documents, tools
+2017-07-16 21:26:06< dwfreed> policies especially
+2017-07-16 21:26:12<@K_F> but yes, the primary issue seem to be one of manpower, and in the sparc case lack of hardware
+2017-07-16 21:26:23<@slyfox> would be nice to have a single place for things like: how to keyword things (including masking per arch profile), what are tools being used to test stuff, what are common bugs(setups) to watch for
+2017-07-16 21:26:38<@WilliamH> tamiko: ++
+2017-07-16 21:26:47<@slyfox> i'm fine with not having a project for that but at least a set of docs arch teams don't disagree on
+2017-07-16 21:26:50<@mgorny> slyfox: you can create a wiki page for that, if there isn't one already
+2017-07-16 21:27:00<@slyfox> i think there isn't
+2017-07-16 21:27:04<@mgorny> i'm afraid creating a new team will only mean we'll have one team for all arches eventually ;-)
+2017-07-16 21:27:18< dwfreed> honestly, I don't see anything wrong with that
+2017-07-16 21:27:34<@tamiko> mgorny: And what exactly is different from the current situation? :-D
+2017-07-16 21:27:46<@mgorny> tamiko: that's what i'm saying
+2017-07-16 21:27:53<@mgorny> but you have a few people who only do specific arches and know specific arches
+2017-07-16 21:28:03< dwfreed> so they can specialize to that arch
+2017-07-16 21:28:14<@mgorny> like if i need something arm64, i talk to someone from the team for arm64
+2017-07-16 21:28:24<@mgorny> instead of trying everyone from one big team and he tells me 'go to x instead'
+2017-07-16 21:28:37<@K_F> mgorny: indeed
+2017-07-16 21:28:40<@ulm> if there's enough users interested in an arch then there should be volunteers for arch testing
+2017-07-16 21:28:44 * slyfox will create a bunch of pages and mail out to #-dev and #-<arch for RFC
+2017-07-16 21:28:45<@ulm> if not, that arch should be dropped to testing
+2017-07-16 21:29:03<@mgorny> again, dilfridge's glep case
+2017-07-16 21:29:08<@mgorny> we should pursue that first
+2017-07-16 21:29:09<@dilfridge> <slyfox> - there is no formal statement of what is required from arch teams to consider an arch supported
+2017-07-16 21:29:30<@mgorny> once we have proper tools to drop things to ~arch and upgrade to stable, we can consider what to do
+2017-07-16 21:29:39<@dilfridge> ^ that would make sense, because if we write that up the decisions become more predictable
+2017-07-16 21:29:44<@mgorny> that said, i think we should make it a priority to mark more profiles stable
+2017-07-16 21:30:02<@mgorny> if everything is half-broken, i can't get CI rolling, and we only get more breakage
+2017-07-16 21:30:08<@dilfridge> ++
+2017-07-16 21:30:38<@mgorny> if we mark even some of the stable arches as ~arch via arches.desc for now, we have a lower target for starting CI
+2017-07-16 21:30:51<@WilliamH> Do we want to consider dropping any arches from stable to dev or exp?
+2017-07-16 21:31:07<@mgorny> WilliamH: no
+2017-07-16 21:31:28<@mgorny> if something has consistent depgraph, we shouldn't let people break that
+2017-07-16 21:31:33<@WilliamH> mgorny: I don't want to get stuck behind an arch team that takes months to stable things.
+2017-07-16 21:31:50<@tamiko> Out of alpha, arm, hppa, ia64, sparc - how many installations do we have?
+2017-07-16 21:31:54<@mgorny> WilliamH: then we drop it to ~arch but keep profile stable; don't confuse profile status with arch status
+2017-07-16 21:32:06<@WilliamH> mgorny: ?
+2017-07-16 21:32:20< dwfreed> tamiko: arm is pretty popular
+2017-07-16 21:32:35<@mgorny> WilliamH: stable profiles = repoman checks depgraph, ~arch status = repoman treats stable equiv to testing
+2017-07-16 21:33:00<@dilfridge> tamiko: except for arm, probably less then 10
+2017-07-16 21:33:06<@dilfridge> (would be my wild guess)
+2017-07-16 21:33:16< dwfreed> WilliamH: mgorny is talking about post arches.desc implementation, in case that wasn't clear
+2017-07-16 21:33:31<@WilliamH> That's not implemented yet then.
+2017-07-16 21:33:33<@tamiko> So what's the point of maintaining stable keywords (except for say @system) for such an arch then?
+2017-07-16 21:33:52<@dilfridge> that my info is only a wild guess
+2017-07-16 21:34:02<@dilfridge> cue gentoostats
+2017-07-16 21:34:14< dwfreed> dilfridge: honestly, I don't think you're very far off
+2017-07-16 21:34:17<@mgorny> dilfridge: someone would have to stabilize it first ;-)
+2017-07-16 21:34:24<@K_F> dilfridge: I doubt we'd get reliable information from gentoostats anyways, I wouldn't activate it on anything at least
+2017-07-16 21:34:29<@ulm> almost sounds like a case for a forums poll
+2017-07-16 21:34:33<@slyfox> if keywording/stabilization would be more automatic then keywording would be not so painful
+2017-07-16 21:34:38 * dilfridge rests forehead on keyboarddddddddddddddddddddddddddddddddddddddddddd
+2017-07-16 21:34:50<@K_F> ulm: heh, 99% for amd64 and removing rest then :)
+2017-07-16 21:35:06 * dwfreed stands up as an x86 user
+2017-07-16 21:35:24<@WilliamH> I could go for auto stabilization after something sits in the tree for 30 days if there's not a blocking bug
+2017-07-16 21:35:37 * dilfridge thinks there are probably more mips users than ia64 and alpha together
+2017-07-16 21:35:37<@ulm> K_F: just to find out number of users interested in particular stable arches
+2017-07-16 21:35:41<@mgorny> WilliamH: that doesn't guarantee that anyone has actually used the package
+2017-07-16 21:35:42<@WilliamH> and if there is an older version stable
+2017-07-16 21:35:49<@tamiko> So, I think we should come up with a good solution for the following two problems:
+2017-07-16 21:36:02<@K_F> WilliamH: I don't like such automation at all
+2017-07-16 21:36:09<@tamiko> - make amd64/x86 stabilization more than a 1 - 1.5 person show.
+2017-07-16 21:36:18<@K_F> maintainer is responsible for testing a package sufficiently to say it can be put in stable tree
+2017-07-16 21:36:42<@WilliamH> tamiko: amd64 is, anyone with the hardware can stabilize their packages.
+2017-07-16 21:36:47<@tamiko> - have a stabilization procedure for all other arches that is sustainable.
+2017-07-16 21:36:48<@mgorny> well, the key point is that maintainer shouldn't be skipped
+2017-07-16 21:37:01<@mgorny> i don't think maintainers are the problem right now
+2017-07-16 21:37:07<@mgorny> we can handle that; worst case by maintainer timeouts
+2017-07-16 21:37:11< dwfreed> WilliamH: still very few people do it
+2017-07-16 21:37:25<@WilliamH> dwfreed: there's the case for auto stabilization
+2017-07-16 21:37:34 * WilliamH is as guilty as the next guy
+2017-07-16 21:37:49<@slyfox> say, if there is 0 users for an arch and there is a tinderbox that does only compile-testing i'd be fine with automatic ~arch -> arch KEYWORDS promotin (with maintainer's consent)
+2017-07-16 21:37:52< dwfreed> I think that's more due to lack of clear documentation that that is allowed
+2017-07-16 21:37:54<@mgorny> another potential help is finally a working and open tinderbox for everyone
+2017-07-16 21:38:04<@dilfridge> ++
+2017-07-16 21:38:14<@mgorny> or even more open developer VMs
+2017-07-16 21:38:14<@dilfridge> toralf might help there
+2017-07-16 21:38:21<@WilliamH> How, out of curiosity, does Debian move things from testing to stable?
+2017-07-16 21:38:29<@WilliamH> Do they have arch testers?
+2017-07-16 21:38:42< dwfreed> WilliamH: nothing moves to stable once stable is released
+2017-07-16 21:38:42<@slyfox> no idea but i suspect they just build things
+2017-07-16 21:38:49<@slyfox> and handholding is bone via bugs
+2017-07-16 21:38:51<@tamiko> WilliamH: They move from experimental to testing automatic if no bug is submitted in ~2 weeks.
+2017-07-16 21:39:00<@slyfox> no bugs => thing gets released
+2017-07-16 21:39:04<@tamiko> WilliamH: testing -> stable happens every other year with a release of a new debian.
+2017-07-16 21:39:26<@WilliamH> ok, so experimental to testing might be like our ~arch to arch?
+2017-07-16 21:39:46<@K_F> WilliamH: no, testing is our ̃~arch, experimental is some overlay or p.masked
+2017-07-16 21:39:55<@WilliamH> or would ~arch to arch be like experimental to stable.
+2017-07-16 21:40:02<@tamiko> WilliamH: For all practical purposes it is.
+2017-07-16 21:40:43<@mgorny> well, we have 'runtime testing required' field on bugzilla already
+2017-07-16 21:40:55<@mgorny> i suppose requests with it set to 'no' could be handled by tinderboxing with FEATURES=test
+2017-07-16 21:42:17<@WilliamH> tamiko, back to you for a sec. what were your situations we need a solution for?
+2017-07-16 21:42:18<@mgorny> that includes developer's consent, build+test phase on the arch, and some time in ~arch to indicate it's actually tested by anyone
+2017-07-16 21:43:18<@tamiko> WilliamH: More people for important arches and a streamlined procedure. Further, simplified stabilization for uncommon arches.
+2017-07-16 21:43:54<@mgorny> 'more people' is not something we can solve
+2017-07-16 21:44:13 * veremitz coughs
+2017-07-16 21:44:15< veremitz> oops sorry
+2017-07-16 21:44:23<@WilliamH> mgorny: 30 days in ~ is the guideline, but developers can request stabilization sooner.
+2017-07-16 21:44:41<@mgorny> WilliamH: it all boils down to common sense
+2017-07-16 21:44:47<@WilliamH> mgorny: right.
+2017-07-16 21:44:57<@dilfridge> anyway, can we agree that 1) maintainer consent is needed,
+2017-07-16 21:45:08<@K_F> yes
+2017-07-16 21:45:16<@dilfridge> 2) if the maintainer says "no runtime testing required", things can be automated
+2017-07-16 21:45:20 * slyfox votes for yes, with well-defined maintainer timeout: say, 2 weeks
+2017-07-16 21:45:47<@WilliamH> dilfridge: ++ on both
+2017-07-16 21:45:54 * slyfox is yes on both
+2017-07-16 21:45:56<@tamiko> dilfridge: These are good general guidelines.
+2017-07-16 21:45:58<@K_F> dilfridge: but if that is a hard requirement it will shift security workflow, we try to encourage devs to call for stabilization themselves but too many cases they don't
+2017-07-16 21:46:21<@slyfox> as a maintainer i'm very lazy to file stablereq bugs
+2017-07-16 21:46:32<@WilliamH> K_F: yes, that's a big part of the problem too
+2017-07-16 21:46:36<@mgorny> K_F: you don't want to stabilize a broken version of package you don't know just because the old one had vulnerability
+2017-07-16 21:46:46 * WilliamH is as guilty as slyfox ;-)
+2017-07-16 21:47:01<@K_F> mgorny: I very much agree, just saying we need more active maintainers on bugs in [stable?] status
+2017-07-16 21:47:11<@mgorny> but i don't think we really need to discuss those things right now
+2017-07-16 21:47:12<@slyfox> i'd be perfectly fine to see some automation files STABLEREQ for each of my packages
+2017-07-16 21:47:24<@dilfridge> well, I usually answer after the second ping by b-man or whissi :D
+2017-07-16 21:47:43<@tamiko> So, what about we codify that in a short GLEP and replace GLEP 40 with it?
+2017-07-16 21:47:44<@mgorny> i mean, the current procedures on that end still fit
+2017-07-16 21:47:44<@K_F> dilfridge: with the number of issues tracked, that isn't really a workable workflow
+2017-07-16 21:48:03<@dilfridge> so automate the ping!
+2017-07-16 21:48:09<@slyfox> ++ for new GLEP. who will champion it? :)
+2017-07-16 21:48:14<@WilliamH> slyfox: ++
+2017-07-16 21:48:18<@dilfridge> that's easily done from sec side with pybugz or similar
+2017-07-16 21:48:38<@K_F> tamiko: I still suggest we can bring that in for stable wg, and restart the efforts there as it seems more are interested in following up on things now
+2017-07-16 21:49:00<@tamiko> K_F: How often did the wg meet and what was the outcome?
+2017-07-16 21:49:06<@mgorny> guys, i think we've exhausted all that could be brainstormed here and it's time we put the topic back to the mailing lists
+2017-07-16 21:49:08<@WilliamH> K_F: the problem with putting it off to the side in a wg is it will die. ;-)
+2017-07-16 21:49:14<@ulm> right, we won't come to a decision today
+2017-07-16 21:49:15<@tamiko> K_F: I have the feeling it might be better to simply let one author write a GLEP and discuss the result.
+2017-07-16 21:49:44<@mgorny> does anyone volunteer to summarize the most important points from today and reboot the discussion on the ml?
+2017-07-16 21:49:55<@K_F> tamiko: most discussions should happen in mail threads, but was very low activity .. we had a few meetings, you can see current draft report at https://download.sumptuouscapital.com/gentoo/wg-stable/main.pdf
+2017-07-16 21:50:12<@K_F> tamiko: the issue with that is that the GLEP might not be touching upon the broader issues of things
+2017-07-16 21:50:43<@mgorny> K_F: the problem with working groups is that more people laugh at creating working groups than actually participate
+2017-07-16 21:50:47<@K_F> tamiko: some of the work required is actually understanding the issues the various arches are facing and what we currently have documented, in order to know what needs updating
+2017-07-16 21:51:00<@K_F> mgorny: thats their problem
+2017-07-16 21:51:55 * WilliamH is for an author writing a glep and kicking off the discussion on the ml
+2017-07-16 21:52:01<@mgorny> i think the topic is important enough to desire broad discussion on -dev, not moving it out to some wgs
+2017-07-16 21:52:23<@slyfox> i can post a stabilization policy summary and start a GLEP
+2017-07-16 21:52:28<@mgorny> i.e. just send it, let people reply if they care, do not expect them to volunteer first
+2017-07-16 21:52:37<@tamiko> Picking up mgorny's suggestion, what about (a) we summarize the result of todays discussion with dilfridge's point on the ML, reboot a discussion and (b) try to get a GLEP fledged out to replace GLEP 40 (that allows for more automated stabilization as mgorny suggests).
+2017-07-16 21:52:59<@mgorny> tamiko: ++
+2017-07-16 21:53:11<@mgorny> would be reasonable to formally approve the bugzilla changes
+2017-07-16 21:53:21<@tamiko> slyfox: You volunteered? :-)
+2017-07-16 21:53:23<@slyfox> ye
+2017-07-16 21:53:34<@K_F> tamiko: works for me, I'm noting down slyfox for sending email and writing up summary of discussion (I'll copy paste that into summary for meeting once you have it as well)
+2017-07-16 21:54:00<@mgorny> slyfox: feel free to prepare it first and ping us to review it, and possibly add more points
+2017-07-16 21:54:01<@K_F> slyfox: likely makes sense to circulate a draft on council@ in case there is input
+2017-07-16 21:54:09<@mgorny> slyfox: or me in particular
+2017-07-16 21:54:14<@slyfox> sound good
+2017-07-16 21:54:40<@K_F> good, movingg on then
+2017-07-16 21:54:44<@mgorny> does someone volunteer to getting more input from exotic arch teams? ;-)
+2017-07-16 21:55:06<@K_F> mgorny: we got some input from a few of them (including alpha)
+2017-07-16 21:55:36<@mgorny> K_F: please send it over to slyfox ;-)
+2017-07-16 21:55:45<@slyfox> i'll post broader announcement to #-<arch> as well and will try to reach active~ish members
+2017-07-16 21:55:57<@tamiko> slyfox++
+2017-07-16 21:56:37<@K_F> slyfox: emails incoming..
+2017-07-16 21:57:03<@mgorny> K_F: no more interruptions from me, please continue with the agenda ;-)
+2017-07-16 21:57:29<@K_F> 4. Open bugs with [council involvement]
+2017-07-16 21:57:46<@K_F> I don't really see any bugs requiring discussion, so unless anyone objects we can move on
+2017-07-16 21:57:52<@ulm> +1
+2017-07-16 21:58:06<@tamiko> K_F: Give me a second to have a look at the list.
+2017-07-16 21:58:10<@dilfridge> wfm
+2017-07-16 21:58:17<@mgorny> fwics we have 1 open public bug and 1 private bug
+2017-07-16 21:58:29<@mgorny> since i'm new, i don't know the status on the latter one
+2017-07-16 21:58:41<@slyfox> can we move council@ to CC in those bugs as it's "resolved" from council standpoint?
+2017-07-16 21:58:55<@dilfridge> in the public one yes
+2017-07-16 21:59:24<@tamiko> What's the bug number of the private one? (Or can this not be disclosed)
+2017-07-16 21:59:26<@K_F> the private one should really just be closed, it is a comrel matter
+2017-07-16 22:00:07<@mgorny> K_F: vote for that?
+2017-07-16 22:00:14<@K_F> tamiko: 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=3591414&query_format=advanced
+2017-07-16 22:00:27<@K_F> tamiko: you should see it in listing there
+2017-07-16 22:00:49<@K_F> mgorny: does it really need a vote? 
+2017-07-16 22:01:10<@mgorny> if it's supposed to be a council decision to close it
+2017-07-16 22:01:24<@mgorny> otherwise i could perceive it as comrel deciding instead of council ;-P
+2017-07-16 22:01:43<@ulm> decision is not implemented IIUC?
+2017-07-16 22:01:48<@K_F> we had a consensus with regards to treatment of it in last council, and should be commented to that extent (but bugzie is slow atm..)
+2017-07-16 22:01:51<@tamiko> K_F: I am not authorized to see the bug in question :-)
+2017-07-16 22:02:12<@mgorny> tamiko: i'll quickly update bugzilla perms
+2017-07-16 22:02:13<@slyfox> sounds like a bug
+2017-07-16 22:02:18<@mgorny> that is, if bugzilla works ;-)
+2017-07-16 22:02:37< dwfreed> for bug 565566, you could just drop council from CC at this point
+2017-07-16 22:02:53<@K_F> tamiko: it is only in Developers group.. so that should work
+2017-07-16 22:03:42< dwfreed> we do not ship changelogs via rsync at present; when they return, they'll be in the requested order
+2017-07-16 22:03:51<@dilfridge> gentlemen I gotta leave (or at least focus on a different window...)
+2017-07-16 22:04:04<@dilfridge> see you later
+2017-07-16 22:04:27<@slyfox> o/
+2017-07-16 22:04:28<@ulm> dwfreed: infra does ship them in a separate rsync module
+2017-07-16 22:04:33<@tamiko> mgorny, K_F: Let's quickly vote on closing.
+2017-07-16 22:04:52 * slyfox votes yes
+2017-07-16 22:04:59<@K_F> tamiko: there was a vote during last meeting, see comment 19..
+2017-07-16 22:05:03<@K_F> but sure, close it
+2017-07-16 22:05:10 * mgorny abstains
+2017-07-16 22:05:16 * tamiko votes yes
+2017-07-16 22:05:27<@ulm> close that private bug? or #565566?
+2017-07-16 22:05:32<@K_F> private bug
+2017-07-16 22:06:10<@mgorny> anyway, updated council group on bugzilla
+2017-07-16 22:07:04< dwfreed> ulm: they have not been updated in a very long time, and nobody uses them anyway because nobody knows they exist
+2017-07-16 22:07:56<@ulm> dwfreed: yes, but why should we take council off cc? the bug remains open as long as the issue exists
+2017-07-16 22:08:37< dwfreed> arguably we're technically not shipping changelogs :P
+2017-07-16 22:08:46<@tamiko> ulm, dilfridge, WilliamH: ping your vote on closing the private bug please.
+2017-07-16 22:08:57< dwfreed> anyway, I'll poke robin to drop the reversed flag and start updating them again
+2017-07-16 22:09:12<@dilfridge> yes close it, it's comrel issue
+2017-07-16 22:09:12 * WilliamH yes per comment 19
+2017-07-16 22:09:18 * ulm votes yes
+2017-07-16 22:09:35<@K_F> good, then we can move on
+2017-07-16 22:09:53<@K_F> 5. Open floor to council members to introduce themselves to the others, and/or raise areas    of interest for the coming council period
+2017-07-16 22:10:02<@K_F> so, anyone want to say something?
+2017-07-16 22:10:33<@slyfox> nope :)
+2017-07-16 22:10:40<@mgorny> well, as food for thought: i think we need to focus on the problem of half-dead projects
+2017-07-16 22:10:53<@tamiko> mgorny: Agreed.
+2017-07-16 22:10:56<@mgorny> better ways to notice when they go defunct, work on getting more members and so on
+2017-07-16 22:11:20<@tamiko> Yes, hi all! And on a more serious side - I want to point out that toolchain isn't doing that well at the moment…
+2017-07-16 22:11:27 * prometheanfire has a project that's basically one person, that's not disallowed
+2017-07-16 22:11:38<@WilliamH> Yes, that is allowed.
+2017-07-16 22:11:48<@slyfox> tamiko: what is the process of joining toolchain@ nowadays? :)
+2017-07-16 22:11:58<@ulm> well, I have several projects of that sort :/
+2017-07-16 22:12:00<@mgorny> well, i'm more worried about projects that are 1-2 people and at some point those people disappear and we have nobody on the bugs
+2017-07-16 22:12:02 * WilliamH is more concerned about the stable tree, but it looks like we are going to reboot that discussion again
+2017-07-16 22:12:04<@tamiko> slyfox: Asking dilfridge and me ;-)
+2017-07-16 22:12:24<@K_F> slyfox: does it necessarily differ from any other project? ask project lead and if project has specific requriements things will be handled there..
+2017-07-16 22:12:39<@dilfridge> except that the lead is still vapier (so, nobody)
+2017-07-16 22:12:53 * dilfridge suggests a lead election
+2017-07-16 22:13:03<@tamiko> dilfridge, slyfox: Reminds me that we should schedule a toolchain meeting and elect a new lead.
+2017-07-16 22:13:04<@ulm> yeah, hold a lead election
+2017-07-16 22:13:04<@K_F> dilfridge: sounds like good reason for a project election, indeed
+2017-07-16 22:13:09<@dilfridge> vapier didnt turn up on any of the last team meetings
+2017-07-16 22:13:20<@tamiko> dilfridge, slyfox: A two month timeout to react to any of my e-mails is enough.
+2017-07-16 22:13:25<@mgorny> isn't he past yearly term anyway?
+2017-07-16 22:13:51<@mgorny> i think it's a reasonable guideline to follow after all
+2017-07-16 22:14:03<@K_F> mgorny: doesn't necessarily matter, anyone can call election any time anyways
+2017-07-16 22:14:09<@WilliamH> mgorny: we don't force projects to have yearly elections...
+2017-07-16 22:14:14<@dilfridge> (or even reply to any of the alias mails)
+2017-07-16 22:14:22<@K_F> but right, yearly elections generally makes sense as a matter of principle
+2017-07-16 22:15:00<@WilliamH> But, yeah, we should probably have a toolchain project lead election.
+2017-07-16 22:15:07<@mgorny> anyway, i just wanted to point out the problem, if someone has extra spare time (haha), feel free to try to ping cjk and some other projects to see if they are open to new people
+2017-07-16 22:15:34<@K_F> but this isn't really needed to discuss in council meeting.. is there anyone else wanting to bring something up for this agenda item?
+2017-07-16 22:15:42<@mgorny> i sometimes feel like just sending a request for volunteers but i think it wouldn't be the nicest thing to ask people to join without getting a reply from the team first
+2017-07-16 22:16:43<@K_F> right.. moving on then
+2017-07-16 22:16:44<@K_F> 6. Open floor to community
+2017-07-16 22:17:07<@slyfox> what does this item mean?
+2017-07-16 22:17:08<@K_F> will leave open for some minutes in case anyone want to add anything
+2017-07-16 22:17:21<@K_F> slyfox: what do you mean?
+2017-07-16 22:17:24<@mgorny> slyfox: it means people can come and ask us stuff
+2017-07-16 22:17:31< b-man> I missed agenda item #3.  Replacing GLEP 40 or no?
+2017-07-16 22:17:34<@slyfox> aha
+2017-07-16 22:17:36<@mgorny> or talk to us on topics not on agenda
+2017-07-16 22:17:55<@mgorny> b-man: it will be discussed on the ml
+2017-07-16 22:18:05<@mgorny> (probably in the direction of replacing)
+2017-07-16 22:18:22< b-man> thanks
+2017-07-16 22:18:28<@WilliamH> b-man: the goal is to formulate a glep replacing glep 40, also ppossible auto stabilization
+2017-07-16 22:18:40< b-man> sounds good!
+2017-07-16 22:19:23<@K_F> ok, doesn't seem like there is anything for open floor..
+2017-07-16 22:19:36 * K_F bangs gavel; meeting adjourned
+2017-07-16 22:19:40-!- ulm changed the topic of #gentoo-council to: Next meeting: 2017-08-13 *** 18:00 UTC *** | https://www.timeanddate.com/worldclock/fixedtime.html?iso=20170813T18 | https://wiki.gentoo.org/wiki/Project:Council | http://dev.gentoo.org/~dilfridge/decisions.html