--- 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  https://archives.gentoo.org/gentoo-project/message/c60f7c1514f175b8cc0d376ae9373e17 and https://archives.gentoo.org/gentoo-project/message/9578d459aee22ca47b1dc19149684662 ?
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 https://archives.gentoo.org/gentoo-project/message/effdb2474965825fdfc06d0276e3318d
2015-12-13 20:28:19<@rich0> Eclass?
2015-12-13 20:28:29<@ulm> rich0: yep
2015-12-13 20:28:31<@ulm> https://archives.gentoo.org/gentoo-project/message/16fc54d2bced9ff51b71d387eb0fb36b
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 asimov.freenode.net
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> https://wiki.gentoo.org/wiki/Project:Metastructure/Herd_to_project_mapping
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: https://wiki.gentoo.org/wiki/GLEP:67
2015-12-13 20:56:57< mgorny> https://wiki.gentoo.org/wiki/GLEP:67
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 desktop@gentoo.org and freedesktop-bugs@gentoo.org referencing the same child, gnome@gentoo.org
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> https://gist.github.com/a3li/38efb778a455af42b95f
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> https://bugs.gentoo.org/568068 "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: https://bugs.gentoo.org/565786 "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: https://bugs.gentoo.org/503382 "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 | http://www.timeanddate.com/worldclock/fixedtime.html?hour=19&min=0&sec=0 | https://wiki.gentoo.org/wiki/Project:Council
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: https://bugs.gentoo.org/261580 "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: https://bugs.gentoo.org/494208 "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: https://bugs.gentoo.org/566498 "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> https://wiki.gentoo.org/wiki/User:MGorny/GLEP:67#Project_structure
2015-12-13 22:34:37< mgorny> new better example, i hope
2015-12-13 22:36:07<@ulm> some-portage-tool@gentoo.org? :)
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. https://de.wikipedia.org/wiki/Datei:Graph_gerichtet.svg 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> https://upload.wikimedia.org/wikipedia/commons/4/4b/Directed_acyclic_graph.svg
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> https://commons.wikimedia.org/wiki/File:8-tournament-transitive.svg
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!