diff options
authorKristian Fiskerstrand <>2016-01-04 20:46:23 +0100
committerKristian Fiskerstrand <>2016-01-04 20:46:23 +0100
commitffeb7c7cddd9f7024015712da541a607f4ab8df7 (patch)
tree566f28d88da6e8390eb53bc63c736d83ae5c2ac9 /meeting-logs
parentAdd missing summary for 20140225 meeting, bug 503382. (diff)
Add summary and log for council meeting 2015-12-13
Diffstat (limited to 'meeting-logs')
2 files changed, 571 insertions, 0 deletions
diff --git a/meeting-logs/20151213-log.txt b/meeting-logs/20151213-log.txt
new file mode 100644
index 0000000..35874fc
--- /dev/null
+++ b/meeting-logs/20151213-log.txt
@@ -0,0 +1,508 @@
+Hash: SHA512
+- --- Log opened Sun Dec 13 12:46:29 2015
+2015-12-13 12:46:29-!- Irssi: #gentoo-council: Total of 41 nicks [6 ops, 0 halfops, 0 voices, 35 normal]
+2015-12-13 12:46:29-!- mode/#gentoo-council [+o K_F] by ChanServ
+2015-12-13 12:46:30-!- Irssi: Join to #gentoo-council was synced in 1 secs
+2015-12-13 18:58:38<@K_F> one hour till meeting start
+2015-12-13 19:05:26<@dilfridge> oh crap :/
+2015-12-13 19:17:27< mgorny> oh, the meeting ;-p
+2015-12-13 19:42:59 * NeddySeagoon looks for the dev lounge soft icecream machine ...
+2015-12-13 19:44:31< awilfox> is this gonna be a popcorn-worthy one, or just a tea-sipping one?
+2015-12-13 19:45:51 * K_F makes some tea..
+2015-12-13 19:51:32<@rich0> It will be pretty quiet for my part. I'm literally phoning this one in... Traveling back from a funeral.
+2015-12-13 19:51:57<@rich0> Fortunately my wife's turn at driving.
+2015-12-13 19:55:25< awilfox> :(
+2015-12-13 19:55:31< awilfox> sorry for your loss
+2015-12-13 19:56:50<@rich0> Thanks.
+2015-12-13 19:58:56<@K_F> !expn council
+2015-12-13 19:59:12<@K_F> jlec,k_f,blueness,dilfridge,rich0,williamh,ulm,
+2015-12-13 19:59:23<@K_F> Roll call?
+2015-12-13 19:59:25 * K_F is here
+2015-12-13 19:59:36 * dilfridge here
+2015-12-13 20:01:35 * WilliamH here
+2015-12-13 20:01:48<@rich0> Here
+2015-12-13 20:02:20-!- Irssi: #gentoo-council: Total of 41 nicks [7 ops, 0 halfops, 0 voices, 34 normal]
+2015-12-13 20:03:15<@K_F> ok, should we give the rest a few more min?
+2015-12-13 20:03:51<@dilfridge> my mobile is broken so I can't text anyone today
+2015-12-13 20:03:55 * jlec here
+2015-12-13 20:04:45<@K_F> ok, ulm and blueness missing
+2015-12-13 20:07:06<@K_F> 20:06 <@ulm> K_F: network issues here :(
+2015-12-13 20:07:23-!- mode/#gentoo-council [+o ulm] by ChanServ
+2015-12-13 20:07:33<@rich0> On cue...
+2015-12-13 20:07:55<@K_F> ok, lets just get started then
+2015-12-13 20:08:09 * ulm here
+2015-12-13 20:09:11<@K_F> I sent a text to blueness, if he shows he shows..
+2015-12-13 20:09:58<@K_F> so, relatively light agenda today, the first is games and some more direct discussion of file-path policy
+2015-12-13 20:10:19<@K_F> ulm: you proposed it, do you want to add anything to the description in and ?
+2015-12-13 20:10:37-!- mode/#gentoo-council [+o ulm] by ChanServ
+2015-12-13 20:10:57<@ulm> that should be complete
+2015-12-13 20:11:01<@K_F> ulm: hmm, not sure how much of that you saw..
+2015-12-13 20:11:52<@ulm> idea is to deprecate /usr/games and /etc/games
+2015-12-13 20:12:06<@ulm> i.e. games packages should be installed like normal packages
+2015-12-13 20:12:20<@ulm> two exceptions: /var/games and /usr/share/games
+2015-12-13 20:12:56<@ulm> it's described better in the linked message though
+2015-12-13 20:12:56<@jlec> I think this is a good way to go
+2015-12-13 20:13:14<@jlec> What are the downsides to consider?
+2015-12-13 20:13:28<@ulm> looong transition period
+2015-12-13 20:13:44<@K_F> I generally don't see why games should be treated differently from any other applications, the only question I see is whether maintainer decisions should be overruled unless there are obvious downsides to it
+2015-12-13 20:13:59<@ulm> jlec: but not all games packages install into /usr/games even now
+2015-12-13 20:14:20<@ulm> so we won't add to the existing mess, but slowly clean it up
+2015-12-13 20:14:22<@K_F> which is fine, given the earlier decision not to force games eclass etc
+2015-12-13 20:14:55<@K_F> but what are the negative consequences of having /usr/games and /etc/games ?
+2015-12-13 20:15:05<@jlec> perfect, even if the progression is long and slow it is always worth it
+2015-12-13 20:15:08 * WilliamH has always wondered why games have special treatment
+2015-12-13 20:15:31< awilfox> I believe part of it was BSD inspired, since they install games in /usr/games
+2015-12-13 20:15:46<@dilfridge> not only bsd
+2015-12-13 20:16:16<@ulm> K_F: no big negative consequences, but /usr/games/bin deviates from the FHS and from every other distro I know
+2015-12-13 20:16:29<@rich0> I'm all for treating games like any other package.
+2015-12-13 20:16:35<@K_F> ulm: if there are no negative consequences, is it really something for council?
+2015-12-13 20:16:51<@K_F> it seems trivial and likely something for games project
+2015-12-13 20:17:14<@dilfridge> K_F: because it won't happen if up to games project?
+2015-12-13 20:17:27<@rich0> Games maintainers are already free to not install in/usr/games.
+2015-12-13 20:17:27< awilfox> I saw that unfold on the ML months ago, not sure if I can find the link, but it was a controversial decision, that was why it got escalated
+2015-12-13 20:17:29<@ulm> earlier we decided that games packages need not be owned by the games project
+2015-12-13 20:17:35<@dilfridge> (alternatively, what games project?)
+2015-12-13 20:17:42<@K_F> dilfridge: which is arguably fine if there aren't negative cosnequences, others can install outside of /usr/games if they want to since not forcing games eclass
+2015-12-13 20:18:00<@K_F> the question now is whether to force it not to be used..
+2015-12-13 20:18:08<@dilfridge> yes but now we're at the question of distro-wide consistency
+2015-12-13 20:18:23<@ulm> K_F: install locations are pretty much across several projects
+2015-12-13 20:18:30<@ulm> dilfridge: +1
+2015-12-13 20:18:56<@K_F> dilfridge: yeah, file path complexity can be noted as a negative consequence, but that seems relatively trivial
+2015-12-13 20:19:32<@ulm> K_F: /usr/games/bin is not in the standard PATH
+2015-12-13 20:20:11<@ulm> so users have to add it manually, or games pkgs must depend on some special package installing an env file for it
+2015-12-13 20:20:16<@ulm> all somewhat messy
+2015-12-13 20:20:33 * WilliamH tends to agree, that's somewhat messy
+2015-12-13 20:20:45<@ulm> RDEPEND on games-misc/games-envd, that is
+2015-12-13 20:21:20<@WilliamH> There is another way, if games want to install things in /usr/games/bin they could be required to symlink them into /usr/bin
+2015-12-13 20:21:34<@K_F> WilliamH: that seems even messier
+2015-12-13 20:21:35<@ulm> WilliamH: that's even more messy :)
+2015-12-13 20:21:43<@ulm> heh
+2015-12-13 20:21:53<@WilliamH> so dosym /usr/games/bin/foo /usr/bin/foo
+2015-12-13 20:22:06<@WilliamH> Sure.
+2015-12-13 20:22:33<@jlec> no, let's go for some clean and simple solution.
+2015-12-13 20:22:55<@jlec> Let it fade out over the years and follow standard PATH and FHS
+2015-12-13 20:22:55<@rich0> Might as well just symlink /usr/games to /usr. Then ask why we're even doing that...
+2015-12-13 20:23:25 * WilliamH tends to agree with jlec and ulm
+2015-12-13 20:23:41<@jlec> those two exceptions for /usr/share/games and /var/games is acceptable
+2015-12-13 20:23:43<@rich0> Yup
+2015-12-13 20:23:49<@jlec> *are
+2015-12-13 20:23:54<@ulm> rich0: reminds me of /usr/X11R6
+2015-12-13 20:24:12<@rich0> Yup
+2015-12-13 20:24:16<@dilfridge> now That was long ago...
+2015-12-13 20:24:34<@ulm> but we shouldn't create a second such thing
+2015-12-13 20:24:37<@K_F> ok, does anyone want to discuss more, or should we put it to a vote?
+2015-12-13 20:24:46<@K_F> Proposed Vote: The /usr/games and /etc/games directories are deprecated.. Games packages should not install any files there, but follow the normal guidelines for install locations instead.
+2015-12-13 20:24:46<@K_F> Two exceptions are made:
+2015-12-13 20:24:46<@K_F> a) Games packages can install files in /usr/share/games (instead of /usr/share) if that is the location used by upstream.
+2015-12-13 20:24:46<@K_F> b) Shared high-score or game state files can be placed in /var/games or a subdirectory of it.
+2015-12-13 20:25:19<@jlec> do we need to say something about ownership and permissions?
+2015-12-13 20:25:28<@ulm> drop one dot after "deprecated"
+2015-12-13 20:25:38<@K_F> ulm: done.
+2015-12-13 20:25:53<@K_F> jlec: My impression is that is covered by the earlier decisions
+2015-12-13 20:26:05<@ulm> jlec: we have deprecated the games user already
+2015-12-13 20:26:09<@jlec> yes, but I just wanted to make sure.
+2015-12-13 20:26:13<@rich0> Var/games should be the special save state user
+2015-12-13 20:26:13<@ulm> should be enough I think
+2015-12-13 20:26:21<@jlec> okay, let's vote
+2015-12-13 20:26:40<@K_F> ok, Putting the proposal to vote (with one less dot)
+2015-12-13 20:26:42 * K_F abstains
+2015-12-13 20:26:47 * ulm yes
+2015-12-13 20:26:54 * jlec yes
+2015-12-13 20:27:03<@rich0> Yes
+2015-12-13 20:27:07 * dilfridge yes
+2015-12-13 20:27:23<@K_F> WilliamH: ?
+2015-12-13 20:27:23 * WilliamH yes
+2015-12-13 20:27:32<@K_F> ok, carries, 5 yes, 1 abstain, 1 absent
+2015-12-13 20:27:48<@jlec> great.
+2015-12-13 20:28:03<@K_F> lets move on to GLEP 67
+2015-12-13 20:28:15<@K_F> Reference for discussion at
+2015-12-13 20:28:19<@rich0> Eclass?
+2015-12-13 20:28:29<@ulm> rich0: yep
+2015-12-13 20:28:31<@ulm>
+2015-12-13 20:28:31<@K_F> rich0: eclass?
+2015-12-13 20:28:44<@ulm> item 3 especially
+2015-12-13 20:29:08<@K_F> right..
+2015-12-13 20:29:22<@rich0> I think we can deprecate it.
+2015-12-13 20:29:45<@ulm> not much left there without games group and paths
+2015-12-13 20:30:02 * WilliamH is reading
+2015-12-13 20:30:21<@rich0> I'll miss the elog every time I update a game...
+2015-12-13 20:30:31<@ulm> i.e. easier to write a replacement from scratch (if that's even needed) than to start from the existing games.eclass
+2015-12-13 20:31:06<@jlec> right
+2015-12-13 20:31:18<@WilliamH> eah I wouldn't mess with the existing eclass.
+2015-12-13 20:31:23<@WilliamH> yeah *
+2015-12-13 20:32:24<@K_F> Proposed vote: Deprecate the use of the current games.eclass.
+2015-12-13 20:32:42<@jlec> K_F: better drop "current"
+2015-12-13 20:32:51<@K_F> jlec: so nobody can create any games.eclass in the future? :)
+2015-12-13 20:33:12<@jlec> no, games-r1.eclass would be better.
+2015-12-13 20:33:14<@K_F> or games-r1 or whatever
+2015-12-13 20:33:14<@jlec> :)
+2015-12-13 20:33:28<@WilliamH> if an eclass is even needed
+2015-12-13 20:33:45<@K_F> I feel being too vague in this case would severely restrict anyone creating any game ebuild
+2015-12-13 20:33:59<@K_F> and I really don't see why we'd treat that any different from other application in tree
+2015-12-13 20:34:20-!- ServerMode/#gentoo-council [+o jlec] by
+2015-12-13 20:34:23 * WilliamH says deprecate the current games eclass.
+2015-12-13 20:35:01<@WilliamH> we shouldn't say noone can create a games.eclass in the future. It isn't our place to do that.
+2015-12-13 20:36:02<@rich0> Well, our place or not nobody can foretell the future
+2015-12-13 20:36:07 * WilliamH agrees with k_f this time
+2015-12-13 20:36:08<@K_F> actually it likely reads better if dropping the dot, so just a reference to the "current games eclass"
+2015-12-13 20:36:09<@blueness> i'm here now sorry
+2015-12-13 20:36:18<@ulm> "new packages should not inherit the current games eclass'
+2015-12-13 20:36:30<@K_F> ulm: I'm fine with that wording
+2015-12-13 20:36:52 * blueness reads backlog
+2015-12-13 20:37:08<@jlec> okay
+2015-12-13 20:37:14<@K_F> blueness: welcome
+2015-12-13 20:37:16<@K_F> Vote: New packages should not inherit the current games eclass
+2015-12-13 20:37:22 * K_F yes
+2015-12-13 20:37:23< mgorny> while at it, i think we should also block support for EAPI 6 in the eclass
+2015-12-13 20:37:28< mgorny> mr_bones_ already attempted adding it without following earlier decisions
+2015-12-13 20:37:43 * ulm yes
+2015-12-13 20:37:50 * WilliamH yes
+2015-12-13 20:37:50 * jlec yes
+2015-12-13 20:37:53 * rich0 yes
+2015-12-13 20:37:58 * blueness yes
+2015-12-13 20:38:10<@blueness> (i did read the backlog so i know what the issue is)
+2015-12-13 20:38:16 * dilfridge yes
+2015-12-13 20:38:24<@K_F> ok, so thats 7 yes :)
+2015-12-13 20:38:31-!- mode/#gentoo-council [+o dilfridge|mobile] by ChanServ
+2015-12-13 20:38:47<@ulm> mgorny: shrug if the eclass is phased out then why would we care?
+2015-12-13 20:39:29< mgorny> ulm: some people just ignore the Council, you know ;-)
+2015-12-13 20:39:48<@ulm> if there's breakage then I'm certain QA can take care of it
+2015-12-13 20:40:36<@WilliamH> I see one thing. The way we worded things, new versions of current packages can still inherit the eclass right?
+2015-12-13 20:40:41<@blueness> mgorny: are new games ebuilds going in using the eclass? because we deprecated the old /usr/game path
+2015-12-13 20:40:45<@K_F> WilliamH: yes
+2015-12-13 20:41:05<@WilliamH> K_F: that means it will never go away and current packages will still install to /usr/games
+2015-12-13 20:41:13<@ulm> WilliamH: I wouldn't forbid it, e.g. because of security bumps
+2015-12-13 20:41:14< mgorny> blueness: i didn't check that but likely yes
+2015-12-13 20:41:21< mgorny> blueness: in particular, mr_bones_ was adding EAPI 6 to it
+2015-12-13 20:41:22<@K_F> I'm with ulm on that one
+2015-12-13 20:42:01<@blueness> WilliamH: its a lot of work to migrate packages away from that old /usr/games model
+2015-12-13 20:42:04<@dilfridge> well
+2015-12-13 20:42:06<@rich0> I suggest blocking eapi 6. Then it goes away with eapi 5.
+2015-12-13 20:42:17<@jlec> that makes sense
+2015-12-13 20:42:21<@WilliamH> rich0: That's one way to do it, sure.
+2015-12-13 20:42:28<@dilfridge> the way we worded it, " New packages should not inherit the current games eclass ", is the weakest possible form of deprecation
+2015-12-13 20:42:43<@K_F> should we see how it goes first and get back to it if it isn't followed through?
+2015-12-13 20:43:12<@ulm> dilfridge: I wouldn't use stronger wording currently
+2015-12-13 20:43:13<@WilliamH> I think we should block eapi6 in games.eclass at least
+2015-12-13 20:43:19<@blueness> by eapi 7 we can think about stronger deprecation criteria
+2015-12-13 20:43:26<@ulm> we can always follow up to it later if necessary
+2015-12-13 20:43:55<@WilliamH> What do others think about blocking eapi 6 in games.eclass?
+2015-12-13 20:44:12<@jlec> I really would do it.
+2015-12-13 20:44:16<@K_F> WilliamH: it seems a bit like micro-managing things to me
+2015-12-13 20:44:30<@WilliamH> K_F: we'are already doing that with the games stuff
+2015-12-13 20:44:35<@WilliamH> K_F: we are
+2015-12-13 20:44:41< mgorny> maybe less strictly
+2015-12-13 20:44:46<@rich0> In for a penny...
+2015-12-13 20:44:51< mgorny> block eapi 6 unless all previous Council decisions are implemented
+2015-12-13 20:45:01<@blueness> K_F WilliamH we cant just block eapi 6 since it would break ebuilds when we deprecated eapi 5
+2015-12-13 20:45:23<@WilliamH> blueness: by that time they need to be reworked to install properly
+2015-12-13 20:45:35<@blueness> WilliamH: that may be too much work
+2015-12-13 20:45:40<@WilliamH> blueness: games.eclass installs in /usr/games
+2015-12-13 20:45:44<@rich0> That's basically the point.
+2015-12-13 20:46:02<@blueness> rich0: what do you mean?
+2015-12-13 20:46:25<@rich0> The ebuilds would need to be lowered
+2015-12-13 20:46:37<@blueness> rich0: that's a lot of ebuils!
+2015-12-13 20:46:38<@rich0> Err ported or removed
+2015-12-13 20:46:47<@rich0> Yup
+2015-12-13 20:47:00<@blueness> i wonder if we could come up with a games-r1.eclass that does the migration automagically
+2015-12-13 20:47:06<@rich0> But, otherwise what was the point of the last 45min?
+2015-12-13 20:47:12<@WilliamH> If they want to maintain that stuff in a way that goes against the council it belongs in an overlay
+2015-12-13 20:47:24< mgorny> blueness: did you mean: an empty file? ;-)
+2015-12-13 20:47:26<@blueness> rich0: it prevents any new packages from inherting games.eclass
+2015-12-13 20:47:27<@ulm> I think we shouldn't mandate anything that will potentially block future EAPI bumps of ebuilds
+2015-12-13 20:47:37<@blueness> mgorny: heh maybe!
+2015-12-13 20:48:05<@K_F> ulm: that'd be my sentiment as well
+2015-12-13 20:48:08<@rich0> I'm fine with a -r1 that implements eapi6.
+2015-12-13 20:48:16<@rich0> And noops
+2015-12-13 20:48:32<@WilliamH> and moves things from /usr/games to standard locations?
+2015-12-13 20:48:42<@rich0> Otherwise all of this amounts to nothing, really.
+2015-12-13 20:48:43<@blueness> WilliamH: it would be nice if possible
+2015-12-13 20:49:12<@rich0> Noop would move to standard locations. Just call the normal dobin and so on.
+2015-12-13 20:49:23<@WilliamH> blueness: I doubt it isimpossible.
+2015-12-13 20:50:01<@WilliamH> blueness: /usr/games is non-standard, so we are the ones who came up with the customizations to make it work.
+2015-12-13 20:50:11<@WilliamH> blueness: so we just undo them.
+2015-12-13 20:51:14<@K_F> ok, we should move this along, so proposal for text: "1c) Vote: EAPI 6 should be blocked in the current games eclass"
+2015-12-13 20:51:21<@dilfridge> just as a reminder, everything that involves work has to be done by someone
+2015-12-13 20:51:42<@WilliamH> dilfridge: Sure.
+2015-12-13 20:51:54<@K_F> any counter-proposal for text to vote on?
+2015-12-13 20:52:04<@rich0> dilfridge I'm fine with tree cleaning if we're still stuck in two years.
+2015-12-13 20:52:22 * rich0 yes on that
+2015-12-13 20:52:25 * WilliamH agrees with rich0 .
+2015-12-13 20:52:28 * WilliamH yes
+2015-12-13 20:52:38<@rich0> I need to run. I'm fine with there glep.
+2015-12-13 20:52:59<@K_F> rich0: for clarity, you're yes to GLEP 67 approval?
+2015-12-13 20:52:59 * ulm abstain
+2015-12-13 20:53:03<@rich0> Yes
+2015-12-13 20:53:07<@K_F> noted
+2015-12-13 20:53:23<@K_F> ok, putting 1c to vote then: 1c) Vote:
+2015-12-13 20:53:23<@K_F> EAPI 6 should be blocked in the current games eclass"
+2015-12-13 20:53:27 * K_F no
+2015-12-13 20:53:38<@rich0> Yes
+2015-12-13 20:53:39 * ulm abstain
+2015-12-13 20:53:41 * blueness no
+2015-12-13 20:53:45 * dilfridge yes
+2015-12-13 20:53:47 * jlec yes
+2015-12-13 20:53:51 * WilliamH yes
+2015-12-13 20:54:14<@K_F> ok, that is 3 yes, 2 no and 1 abstains
+2015-12-13 20:54:33<@ulm> I count 4 yes
+2015-12-13 20:54:35<@K_F> no, 4 yes
+2015-12-13 20:54:41<@K_F> my bad.. indeed, carries
+2015-12-13 20:55:10<@K_F> now, lets move on to GLEP 67
+2015-12-13 20:55:32<@K_F> first of all, thank you again for your work on that mgorny
+2015-12-13 20:55:43< mgorny> np
+2015-12-13 20:55:47<@ulm> mgorny: how is the herd to project mapping progressing?
+2015-12-13 20:55:54< mgorny> sloooowly
+2015-12-13 20:56:12<@ulm>
+2015-12-13 20:56:29< mgorny> but i think it's around 50% done
+2015-12-13 20:56:38< mgorny> maybe more
+2015-12-13 20:56:41<@WilliamH> mgorny: can you link the glep real quick?
+2015-12-13 20:56:55<@K_F> WilliamH:
+2015-12-13 20:56:57< mgorny>
+2015-12-13 20:57:15<@ulm> mgorny: as always, last 10% will take 90% of the time
+2015-12-13 20:57:30< mgorny> yes, there are a few pretty much abandoned herds
+2015-12-13 20:58:09< mgorny> but should be fine to inline the developers or move to maintainer-needed
+2015-12-13 20:58:45<@WilliamH> Currently a maintainer can also be a group of devs that isn't a project.
+2015-12-13 20:58:58 * K_F really isn't in favor of more maintainer-needed packages per se
+2015-12-13 20:59:01<@WilliamH> e.g. udev-bugs@g.o, and there may be others.
+2015-12-13 20:59:08<@ulm> K_F: +1
+2015-12-13 21:00:34<@K_F> but I agree that it can be inlined to existing maintainers listed in herds
+2015-12-13 21:00:42<@K_F> so that shouldn't necessarily cause a blocker
+2015-12-13 21:01:00< mgorny> WilliamH: i think many of them resulted from dislike of herds, and the slow efforts to kill them with fire
+2015-12-13 21:01:50<@WilliamH> mgorny: I think with udev at least, it might have resulted also only because all of base-system wasn't interested in maintaining udev, I'm not sure, because it has been around a while.
+2015-12-13 21:01:52< mgorny> today, herds are officially deprecated with not-that-clear replacement
+2015-12-13 21:02:11<@blueness> mgorny: how does <subproject ref=... > work, is it the child referring to the parent or vice versa?
+2015-12-13 21:02:23<@WilliamH> mgorny: I'm just saying that a maintainer isn't always a single person or a project.
+2015-12-13 21:02:43<@blueness> ie can a subproject inherit from more than one parent project?
+2015-12-13 21:03:06<@ulm> blueness: it's the reverse of parent IIUC
+2015-12-13 21:03:26<@blueness> ulm: not sure what you mean
+2015-12-13 21:03:31<@ulm> i.e. the parent refers to the subproject with <subproject ref=... >
+2015-12-13 21:03:38< mgorny> blueness: parent to child
+2015-12-13 21:04:10< mgorny> blueness: i.e. projects listing its subprojects which are somewhere else in the file
+2015-12-13 21:04:24<@blueness> k
+2015-12-13 21:04:55< mgorny> i didn't want to get into whether it's 1:n or n:n, i think wiki currently restricts it to 1:n
+2015-12-13 21:05:00< mgorny> not sure if that can be changed
+2015-12-13 21:06:30<@blueness> mgorny: because in your example you have both and referencing the same child,
+2015-12-13 21:08:20< mgorny> hmm, ;-D
+2015-12-13 21:08:40< mgorny> that's quite likely because of the current mess in herds.xml
+2015-12-13 21:09:12< mgorny> blueness: do you suggest changing that to 1:n?
+2015-12-13 21:09:23<@blueness> so i would think that we want a project to have many subprojects, but a subproject belongs to one and only one project, ie 1:n
+2015-12-13 21:09:32<@ulm> mgorny: at least the example should be changed
+2015-12-13 21:09:39<@ulm> as it is, it is confusing
+2015-12-13 21:09:56<@K_F> I suggest we put off voting on anything on this meeting, and keep on discussing it. Before the vote we should check what are the existing capabilities of wiki and whether it potentially is trivial (for some measure) to change
+2015-12-13 21:10:12 * WilliamH agrees
+2015-12-13 21:10:32< mgorny> well, the problem for n:n was the freedesktop herd
+2015-12-13 21:10:41< mgorny> that doesn't seem clearly related to desktop
+2015-12-13 21:11:01< mgorny> but combined members of few DEs to maintain a few xdg-related packages
+2015-12-13 21:11:55<@dilfridge> that's a mess from the start
+2015-12-13 21:12:16<@dilfridge> since there is no real relation between the members of the DE projects and the few select people who maintain the xdg packages
+2015-12-13 21:12:27<@WilliamH> mgorny: I think it is tied to fd.o packages
+2015-12-13 21:12:40<@dilfridge> (actually, who does that nowadays, since Samuli is awol?)
+2015-12-13 21:13:04<@blueness> mgorny: doesn bug assignment follow inherit-members="1"
+2015-12-13 21:13:14<@blueness> in expanding the maintainer list
+2015-12-13 21:13:49<@dilfridge> if freedesktop is the only problem, we should probably consider some careful restructuring and make freedesktop another subproject of desktop
+2015-12-13 21:14:05<@dilfridge> whoever cares can join it
+2015-12-13 21:14:18< mgorny> blueness: by spec, yes
+2015-12-13 21:14:56<@blueness> mgorny: that's how i understood it but i just wanted to be sure, i'm reading the glep now
+2015-12-13 21:15:25<@blueness> :Subproject form project-type maintainers which are expanded recursively.
+2015-12-13 21:15:26<@blueness> Rationale"
+2015-12-13 21:15:36<@blueness> just want to make sure i get what this is saying ^^^
+2015-12-13 21:16:41< mgorny> yes
+2015-12-13 21:17:24< mgorny> the goal was pretty much to describe the inheritance without getting too deep into structure that's set by wiki
+2015-12-13 21:17:32<@blueness> except for the 1:n issue and actually finishing the mapping, i can live with this
+2015-12-13 21:17:54<@blueness> i will just join (force myself into!) whatever projects i need to after the dust settles
+2015-12-13 21:18:27<@K_F> so are we fine with voting on it today, or do we want some more certainty before doing so?
+2015-12-13 21:18:37< mgorny> well, we should at least vote on some basics
+2015-12-13 21:18:43< mgorny> like whether projects should have unique e-mail addresses
+2015-12-13 21:18:51< mgorny> so we could at least prepare a bit more
+2015-12-13 21:19:21<@K_F> I'm fine with that, and it sounds implicit in the whole glep as it is used as identifier
+2015-12-13 21:19:45< mgorny> yes, assuming you approve the glep and not request that to change ;-)
+2015-12-13 21:19:50<@ulm> mgorny: I thought that was pretty much a consequence of the proposed new structure?
+2015-12-13 21:20:00<@ulm> the unique e-mail addresses, I mean
+2015-12-13 21:20:06< mgorny> ulm: see above
+2015-12-13 21:20:16< mgorny> if you approve the glep, it all goes implicit
+2015-12-13 21:20:26< mgorny> if you defer voting, we can decide on some details to start preparing earlier
+2015-12-13 21:21:09<@dilfridge> I'm not 100% happy with the details, but it's a nice package, so I'm for it.
+2015-12-13 21:21:45<@jlec> do we need to fix details before we vote?
+2015-12-13 21:21:54<@K_F> jlec: I'd prefer to vote on a ready GLEP
+2015-12-13 21:21:58< mgorny> well, consider the example fixed
+2015-12-13 21:22:13<@jlec> K_F: makes sense
+2015-12-13 21:22:14<@K_F> but I'm fine with moving things along by voting on specifics , as mgorny suggested above
+2015-12-13 21:22:26<@blueness> yeah let's see the whole package, i gave you my one point of objection/confusion
+2015-12-13 21:22:27<@ulm> I'd have preferred short ids, but for simplicity's sake we can go with unique e-mail addresses
+2015-12-13 21:22:45<@ulm> even if I hate splitting emacs@g.o
+2015-12-13 21:22:52<@K_F> Vote 2a) GLEP67: All projects should have unique email addresses as this will be used as identifiers
+2015-12-13 21:22:55 * K_F yes
+2015-12-13 21:23:12 * blueness yes
+2015-12-13 21:23:12<@ulm> "should" or "must"?
+2015-12-13 21:23:13 * jlec yes
+2015-12-13 21:23:18<@jlec> must
+2015-12-13 21:23:19 * dilfridge yes (must)
+2015-12-13 21:23:20<@K_F> ulm: correct, MUST
+2015-12-13 21:23:29 * WilliamH yes must
+2015-12-13 21:23:32 * ulm abstain
+2015-12-13 21:23:50<@dilfridge> before we now go through all the details again,
+2015-12-13 21:24:10<@dilfridge> are there any specific reasons why NOT to vote on the whole glep first?
+2015-12-13 21:24:22<@blueness> must
+2015-12-13 21:24:32<@ulm> dilfridge: it's not complete, e.g. reference impl is still missing
+2015-12-13 21:24:38<@K_F> dilfridge: personally I'd prefer to do that when there isn't discussion on details
+2015-12-13 21:24:59< mgorny> ulm: do you really expect reference impl before you approve it? ;-) it's lotta work
+2015-12-13 21:25:11< mgorny> we already have wiki->projects.xml gen
+2015-12-13 21:25:26< mgorny> K_F: do you happen to have the link or should i search for it?
+2015-12-13 21:25:27<@ulm> we can pre-approve the GLEP's general direction
+2015-12-13 21:25:40<@K_F>
+2015-12-13 21:26:46<@jlec> ulm, that would be good
+2015-12-13 21:27:04<@K_F> ulm: I'm fine with that
+2015-12-13 21:28:15<@K_F> how about "Vote 2b) The council approves the general direction of GLEP 67 but notes that minor alterations might be needed to provide clarity before final approval"
+2015-12-13 21:28:26 * WilliamH yes
+2015-12-13 21:28:30 * dilfridge yes
+2015-12-13 21:28:32 * K_F yes
+2015-12-13 21:28:37 * ulm yes
+2015-12-13 21:28:39 * jlec yes
+2015-12-13 21:28:45 * blueness yes
+2015-12-13 21:28:53 * K_F puts rich0 down for a yes based on earlier comment
+2015-12-13 21:29:05<@K_F> that makes 7 yes
+2015-12-13 21:30:07< mgorny> should i put anything about how many parents can a project have there or leave it undefined as not really relevant to the spec?
+2015-12-13 21:30:25<@dilfridge> well, it's kinda restricted by the wiki
+2015-12-13 21:30:36<@ulm> maybe we want to allow n:n in the future
+2015-12-13 21:30:49<@dilfridge> imho leave it open
+2015-12-13 21:30:56<@ulm> so I wouldn't restrict it via the GLEP unless strictly necessary
+2015-12-13 21:31:03< mgorny> ok
+2015-12-13 21:31:14< mgorny> so do you have any immediate suggestions except for example fix and reference impl?
+2015-12-13 21:31:21<@ulm> don't allow cycles though :p
+2015-12-13 21:31:44< mgorny> though i don't think what else reference impl do we need
+2015-12-13 21:31:56< mgorny> we have projects.xml gen already
+2015-12-13 21:32:09< mgorny> portage doesn't care about metadata.xml
+2015-12-13 21:32:15< mgorny> i guess metadata.dtd update could fit there
+2015-12-13 21:32:41<@blueness> mgorny if you leave it undefined in the specs, then say so, so the issue doesn't come up again and again
+2015-12-13 21:32:49< mgorny> ok
+2015-12-13 21:33:23<@blueness> posix does that, it explicitly says when something is left undeined (ie implementation dependant)
+2015-12-13 21:35:00<@K_F> ok, we can continue discussing that ahead of final approval. for now, thanks for the work so far
+2015-12-13 21:35:06<@K_F> Anything for open floor?
+2015-12-13 21:35:39<@blueness> nothing from me
+2015-12-13 21:36:04<@dilfridge> nope
+2015-12-13 21:36:08< mgorny> EAPI 7? ;-P
+2015-12-13 21:36:14<@WilliamH> mgorny: heh
+2015-12-13 21:36:14<@dilfridge> hehe
+2015-12-13 21:36:17<@K_F> mgorny: :)
+2015-12-13 21:36:24<@ulm> /kick mgorny
+2015-12-13 21:36:38< floppym> Have I missed the meeting?
+2015-12-13 21:36:46<@jlec> yes
+2015-12-13 21:36:47<@K_F> floppym: we're at open floor now
+2015-12-13 21:36:50< mgorny> floppym: you're 1.5hr late ;-p
+2015-12-13 21:36:58< floppym> I had no idea it was today.
+2015-12-13 21:37:30< floppym> Anyway, can I get a council ack on bug 568068?
+2015-12-13 21:37:32< willikins> "GLEP 42: Define support for EAPI 5 dependency atoms in news items"; Doc Other, GLEP Changes; IN_P; floppym:glep
+2015-12-13 21:37:36 * WilliamH points to topic
+2015-12-13 21:37:48< mgorny> oh, that was the item i forgot about!
+2015-12-13 21:38:04<@K_F> ok, lets move on to bugs with council participation then
+2015-12-13 21:38:10<@ulm> floppym: I think you should keep a description of what news item format 1.0 is
+2015-12-13 21:38:13< floppym> I did not care about the meeting at all untill it was suggested that my bug needed a council vote.
+2015-12-13 21:38:16<@ulm> otherwise it is fine
+2015-12-13 21:38:48< mgorny> floppym, ulm: maybe we should add explicit EAPI field ;-p
+2015-12-13 21:38:57< floppym> ulm: News item format 1.0 is rather lacking in detail on that subject.
+2015-12-13 21:39:07<@dilfridge> looks good to me, with the same caveat as expressed by ulm
+2015-12-13 21:39:08< floppym> It just says "dependency atom".
+2015-12-13 21:39:20< floppym> With not real specification of what that means.
+2015-12-13 21:39:22<@ulm> floppym: that's because the glep pre-dates EAPI
+2015-12-13 21:39:33 * WilliamH thinks this is a nitpick
+2015-12-13 21:39:38< floppym> So how should I describe it for 1.0?
+2015-12-13 21:39:47<@dilfridge> just keep the current text
+2015-12-13 21:39:53 * WilliamH really wonders why we need 1.1 just to cover this?
+2015-12-13 21:39:54<@ulm> floppym: and don't say "atom"
+2015-12-13 21:40:17<@K_F> how will this affect older implementations?
+2015-12-13 21:40:20<@ulm> "package dependency specification" is the PMS term
+2015-12-13 21:40:22<@dilfridge> or you could specify it as EAPI=0 since that was the only one around at the time effectively
+2015-12-13 21:41:02<@ulm> a description of 1.0 is needed because the tree contains news items in that format
+2015-12-13 21:41:06< floppym> If someone can submit revised text, that would be more helpful here.
+2015-12-13 21:41:07<@K_F> dilfridge: without having thought very much about it, that seems to be the sane way to go, and have new version for other EAPI
+2015-12-13 21:41:13< floppym> I'm not a docs guy.
+2015-12-13 21:41:29<@ulm> floppym: I'll try to come up with something
+2015-12-13 21:41:37< floppym> Thank you, most appreciated.
+2015-12-13 21:41:37<@ulm> it's not complicated :)
+2015-12-13 21:41:50<@K_F> anyhow, since this came in from the side, lets defer it to next meeting and put it on agenda then
+2015-12-13 21:42:06< floppym> Ok.
+2015-12-13 21:42:53<@K_F> so, bugs with council involvement. We already discussed GLEP 67 (bug 565786) and games eclass (bug 566498)
+2015-12-13 21:42:56< willikins> K_F: "GLEP 67: Package maintenance structure"; Doc Other, New GLEP submissions; IN_P; mgorny:glep
+2015-12-13 21:43:00<@K_F> so that leaves bug 503382
+2015-12-13 21:43:02< willikins> K_F: "Missing summaries for 20131210, 20140114, and 20140225 council meetings"; Doc Other, Project-specific documentation; CONF; ulm:council
+2015-12-13 21:43:21<@K_F> which I expect is status quo?
+2015-12-13 21:43:34<@K_F> i.e. we're missing 20140225
+2015-12-13 21:44:55<@ulm> I've started writing te summary
+2015-12-13 21:44:58<@ulm> *the
+2015-12-13 21:45:13<@K_F> ulm: great :)
+2015-12-13 21:45:19<@ulm> but it's on the backburner
+2015-12-13 21:45:32<@K_F> thats fine, as long as someone is on it
+2015-12-13 21:45:53 * K_F bangs the gavel then, meeting closed. Thanks for participating
+2015-12-13 21:46:10<@jlec> Thanks
+2015-12-13 21:46:24-!- ulm changed the topic of #gentoo-council to: Next meeting: 2016-01-10 19:00 UTC | |
+2015-12-13 21:47:29<@ulm> jlec: you're next chair
+2015-12-13 21:47:41<@jlec> :)
+2015-12-13 21:59:23-!- mode/#gentoo-council [+o rich0] by ChanServ
+2015-12-13 22:04:09< mgorny> hmmmm
+2015-12-13 22:04:29< mgorny> can i have the pleasure of closing all games.eclass featurereqs as WONTFIX? ;-P
+2015-12-13 22:05:27< floppym> You really do hate that thing.
+2015-12-13 22:06:04<@ulm> mgorny: unless they could go to a -r1?
+2015-12-13 22:07:13<@ulm> I see only three such bugs
+2015-12-13 22:07:22<@ulm> bug 261580
+2015-12-13 22:07:24< willikins> ulm: "games.eclass: games_pkg_setup() creates "/usr/games" with games:root"; Gentoo Linux, Games; CONF; karl.r.ernst:games
+2015-12-13 22:07:29<@ulm> bug 494208
+2015-12-13 22:07:31< willikins> ulm: "games.eclass: deprecate base.eclass inherit for EAPI=6"; Gentoo Linux, Eclasses and Profiles; CONF; hasufell:games
+2015-12-13 22:07:42<@ulm> bug 566498
+2015-12-13 22:07:44< willikins> ulm: "games.eclass: use of games group needs to be removed wrt 20151011 Council meeting"; Gentoo Linux, Eclasses and Profiles; CONF; mgorny:games
+2015-12-13 22:13:56< mgorny> ulm: well, i meant the second one
+2015-12-13 22:14:49<@ulm> there are also games-mods.eclass and gnome-games.eclass which inherit games
+2015-12-13 22:14:53< mgorny> but i'm going to focus on glep67 today
+2015-12-13 22:15:08< mgorny> ulm: yeah, i've been complaining to gnome about that some time ago
+2015-12-13 22:15:15< mgorny> they waited for a council decision with it
+2015-12-13 22:15:28<@ulm> ok, so we can expect progress there
+2015-12-13 22:16:21< mgorny> now, i need a good example for project with a subproject and member inheritance ;-)
+2015-12-13 22:17:16< mgorny> hmm, maybe gnome-office!
+2015-12-13 22:17:41< mgorny> or i'll just look at old herds.xml
+2015-12-13 22:19:30< mgorny> hrmm, that doesn't help really
+2015-12-13 22:19:50<@ulm> emacs with gnu-emacs and xemacs
+2015-12-13 22:20:00<@ulm> or lisp with common-lisp, scheme, and emacs
+2015-12-13 22:20:27< mgorny> yeah, i've seen those
+2015-12-13 22:20:44< mgorny> however, i'd like to have an example that both shows subprojects with member inheritance and without
+2015-12-13 22:20:56< mgorny> like desktop -> gnome is purely organizational hierarchy
+2015-12-13 22:34:34< mgorny>
+2015-12-13 22:34:37< mgorny> new better example, i hope
+2015-12-13 22:36:07<@ulm> :)
+2015-12-13 22:44:57< mgorny> yes
+2015-12-13 22:46:46< mgorny> and now changed the text to clear hierarchy a bit
+2015-12-13 22:47:03< mgorny> i've stated that project hierarchy must form an acyclic graph
+2015-12-13 22:47:12< mgorny> i'd appreciate if someone better at maths can confirm that this is correct ;-)
+2015-12-13 22:49:15<@ulm> meh
+2015-12-13 22:49:36<@ulm> an acyclic directed graph I guess
+2015-12-13 22:50:08<@ulm> maybe even more restricted than that
+2015-12-13 22:53:07<@ulm> mgorny: yeah, "acyclic graph" is probably not correct
+2015-12-13 22:53:59<@ulm> e.g. is a directed acyclic graph
+2015-12-13 22:54:04<@ulm> but as undirected graph it contains a cycle
+2015-12-13 22:54:33<@ulm> gah, wrong picture
+2015-12-13 22:54:49<@dilfridge> not acyclic.
+2015-12-13 22:54:50<@dilfridge> :)
+2015-12-13 22:55:09<@ulm> invert the arrow between A and D for the correct example
+2015-12-13 22:55:23<@ulm> then it's acyclic as directed graph
+2015-12-13 22:55:33<@dilfridge> arrgh
+2015-12-13 22:55:34<@ulm> but cyclic as undirected graph
+2015-12-13 22:55:42<@dilfridge> I hate the mediawiki picture viewer
+2015-12-13 22:55:51<@dilfridge>
+2015-12-13 22:56:31<@ulm> yeah, that's a better picture
+2015-12-13 22:58:33< mgorny> ok, changed that
+2015-12-13 23:02:23<@ulm>
+2015-12-13 23:02:29<@ulm> ^^ also acyclic :)
+2015-12-13 23:02:56<@ulm> but makes me wonder if we should allow n:n mapping
+2015-12-13 23:05:20< mgorny> and cleaned up the rationale to avoid suggesting herds are people
+2015-12-13 23:05:29< mgorny> s/rationale/motivation/
+2015-12-13 23:20:57< creffett|irssi> herds are people too!
diff --git a/meeting-logs/20151213-summary.txt b/meeting-logs/20151213-summary.txt
new file mode 100644
index 0000000..64cd1bf
--- /dev/null
+++ b/meeting-logs/20151213-summary.txt
@@ -0,0 +1,63 @@
+Hash: SHA512
+Summary of the Gentoo council meeting 13 December 2015
+Roll call
+blueness, dilfridge, jlec, k_f, rich0, ulm, williamh
+1. Games file-path policy
+The council voted in favor of deprecating the /usr/games and /etc/games
+directories. Games packages should _not_ install any files there, but
+follow the normal guidelines for install locations instead. Two
+exceptions are made: (a) Games packages can install files in
+/usr/share/games (instead of /usr/share) if that is the location used
+by upstream. (b) Shared high-score or game state files can be placed
+in /var/games or a subdirectory of it.
+A vote was conducted and passed stating that new packages should not
+inherit the current games eclass. Following this a vote was held on
+whether "EAPI 6 should be blocked in the current games eclass", which
+passed with a vote count of 4 yes, 2 no and 1 abstainations.
+2. Review, and possibly vote on GLEP 67
+The council unanumously voted in favor of "The council approves the
+general direction of GLEP 67 but notes that minor alterations might
+be needed to provide clarity before final approval"
+3. Bugs with council participation
+The council briefly discussed bug 503382: "Missing summaries for
+20131210, 20140114, and 20140225 council meetings". The current status
+of this bug is a missing summary for the 20140225 meeting. Ulm has
+volunteered to write this and it is ongoing.
+4. Open floor
+The council discussed bug 568068: "GLEP 42: Define support for EAPI 5
+dependency atoms in news items". It was a concensus for defining a new
+news item format for additional EAPI settings and clarify that version
+1.0 uses EAPI 0. In order to be consistent with terminology, the term
+"package dependency specification" should be used rather than
+"dependency atom".