path: root/meeting-logs/20170716.txt

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