-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

2015-11-08 19:01:59<@K_F> 1h until meeting start
2015-11-08 19:16:38<@WilliamH> K_F: Afternoon. :-)
2015-11-08 19:19:00<@K_F> WilliamH: hi there
2015-11-08 19:39:41<@WilliamH> K_F: How are things going?
2015-11-08 19:41:33<@K_F> WilliamH: I'm lifting all services/websites etc off of a very old server of mine, sorting through things in the process, so good sunday :)
2015-11-08 19:41:43<@rich0> Another week, another meeting :)
2015-11-08 19:41:57<@K_F> rich0: in all fairness, none last w/e :)
2015-11-08 19:42:23<@WilliamH> rich0: Afternoon. :-)
2015-11-08 19:59:59<@K_F> 1) Roll call
2015-11-08 20:00:09<@K_F> !expn council
2015-11-08 20:00:09< willikins> K_F: council = jlec,k_f,blueness,dilfridge,rich0,williamh,ulm,
2015-11-08 20:00:14 * dilfridge here
2015-11-08 20:00:17 * K_F here
2015-11-08 20:00:18 * rich0 here
2015-11-08 20:00:25 * ulm here
2015-11-08 20:00:26 * WilliamH here
2015-11-08 20:01:24 * jlec here
2015-11-08 20:02:03<@K_F> ok, propose we wait a few minutes to see if blueness shows up
2015-11-08 20:04:28<@K_F> anyone got his # readily available and can send an SMS?
2015-11-08 20:04:49 * WilliamH is looking
2015-11-08 20:06:08<@K_F> ok, unless I missed up area code should be sent now
2015-11-08 20:06:35<@K_F> lets just start in the mean time
2015-11-08 20:06:56<@jlec> alright. schedule is short :)
2015-11-08 20:07:01<@K_F> Only one non-standard agenda item today
2015-11-08 20:07:07<@K_F> 2) EAPI 6 approval
2015-11-08 20:07:33<@K_F> ulm: You mentioned you wanted to do a few case-by-case votes before the final acceptance
2015-11-08 20:07:55<@K_F> maybe you can do a short intro and walk through them?
2015-11-08 20:08:17<@ulm> K_F: I think it would be best to vote on three of the features separately
2015-11-08 20:08:25<@ulm> and on the rest in one go
2015-11-08 20:08:47<@ulm> first separate vote would be "The package manager should set a bash compatibility level"
2015-11-08 20:08:55<@ulm> https://gitweb.gentoo.org/proj/pms.git/commit/?h=eapi-6&id=e6cfa80244f6c5976712f39667abff4b99afdb19
2015-11-08 20:09:20<@dilfridge> is there an obvious disadvantage to that?
2015-11-08 20:09:28<@ulm> I don't see any
2015-11-08 20:09:43<@dilfridge> I mean, the obvious advantage is that it keeps people from using out-of-spec code.
2015-11-08 20:09:49<@ulm> in fact, it doesn't disable any new bash features
2015-11-08 20:10:12<@ulm> only restores old behaviour in cases where there was an incompatible change
2015-11-08 20:10:20<@dilfridge> sounds good
2015-11-08 20:10:28<@jlec> to me too
2015-11-08 20:10:31<@jlec> voting?
2015-11-08 20:10:44<@K_F> Vote: 2a) "The package manager should set a bash compatibility level"
2015-11-08 20:10:49 * dilfridge yes
2015-11-08 20:10:50 * K_F yes
2015-11-08 20:10:53 * ulm yes
2015-11-08 20:10:53 * rich0 byes
2015-11-08 20:10:53 * jlec yes
2015-11-08 20:11:00<@rich0> er,  yes
2015-11-08 20:11:32 * WilliamH yes
2015-11-08 20:11:58<@K_F> ok, so that passes with 6 yes, 1 absent
2015-11-08 20:12:23<@ulm> second vote would be about eapply_user being idempotent
2015-11-08 20:12:27<@ulm> https://gitweb.gentoo.org/proj/pms.git/commit/?h=eapi-6&id=bcba2ba2bc49dae254e491cc60e25ce9556d4899
2015-11-08 20:13:01<@ulm> i.e. eapply_user must be called (at least) once but any subsequent calls will do nothing
2015-11-08 20:13:12<@rich0> I can't really think of that many practical issues with it.
2015-11-08 20:13:16<@dilfridge> sounds good
2015-11-08 20:13:31<@ulm> rationale is that the command may be called from multiple eclasses
2015-11-08 20:13:50<@jlec> Plus the src_prepare() of the ebuild. I like it
2015-11-08 20:14:43<@K_F> Proposed voting phrase: 2b) eapply_user shall be idempotent and must be called at least once
2015-11-08 20:15:10<@ulm> lgtm
2015-11-08 20:15:17 * ulm yes
2015-11-08 20:15:20 * rich0 yes
2015-11-08 20:15:23 * K_F yes
2015-11-08 20:15:25 * dilfridge yes
2015-11-08 20:15:32 * WilliamH yes
2015-11-08 20:15:45 * jlec yes
2015-11-08 20:15:52<@K_F> Ok, motion passed, 6 yes, 1 absent
2015-11-08 20:17:05<@ulm> third, unfortunately it turned out that the spec for package.* and use.* directories doesn't describe what people originally requested
2015-11-08 20:17:24<@ulm> see my e-mail message at https://archives.gentoo.org/gentoo-project/message/25ab5997c34fe7281ac4680106ecd972
2015-11-08 20:17:47<@WilliamH> Why can't we just fix the spec?
2015-11-08 20:18:06<@ulm> I would propose to leave this out of EAPI 6
2015-11-08 20:18:21<@ulm> as it's not intended to be used in the gentoo repository anyway
2015-11-08 20:18:56<@ulm> also it isn't entirely clear what should be the list of files
2015-11-08 20:19:10<@ulm> see my last comment in bug 282296
2015-11-08 20:19:13< willikins> ulm: https://bugs.gentoo.org/282296 "[Future EAPI] Allow directories for use.* and package.* entries in profiles"; Gentoo Hosted Projects, PMS/EAPI; CONF; rbu:pms-bugs
2015-11-08 20:20:34<@ulm> it certainly can be fixed but I think it needs some more time
2015-11-08 20:21:04<@ulm> and IMHO the feature is not important enough to delay eapi 6 because of it
2015-11-08 20:21:42<@jlec> I would like to see it implemented correctly and that's why I would also see it moved to post EAPI 6 times
2015-11-08 20:21:43<@K_F> yeah, better do something right than to do it too quickly. My understanding is that we don't consider it important enough to hold up EAPI6 and the changes will not affect the main Gentoo tree to a great extent
2015-11-08 20:21:44<@WilliamH> ulm: No, I'm not saying delay eapi 6, I'm just thinking about how many years it took us to come up with eapi 6. Is eapi 7 going to take that long? ;-)
2015-11-08 20:22:01<@ulm> WilliamH: I hope 7 will be faster
2015-11-08 20:22:09<@jlec> 7 must be faster
2015-11-08 20:22:23<@ulm> however, the feature in question was proposed for eapi 4 originally
2015-11-08 20:22:23<@WilliamH> How many years did eapi 6 take? 4? 5?
2015-11-08 20:22:23<@rich0> I think in general it is better to do less and release more often, but a big part of that is avoiding stuff that isn't ready.
2015-11-08 20:22:35<@ulm> WilliamH: about 3 since eapi 5
2015-11-08 20:23:46<@ulm> proposed vote: support for package.* and use.* directories will not be included in eapi 6
2015-11-08 20:23:52<@WilliamH> I can go with removing it as long as we  can move faster on newer eapis ;-)
2015-11-08 20:24:06<@K_F> ulm: just a sec, writing up a bit more verbose
2015-11-08 20:24:08<@K_F> Poposed vote: 2c) "[Future EAPI] Allow directories for use.* and package.* entries in profiles" (Bug #282296) is not considered ready for inclusion in EAPI6 and consideration for the feature is delayed until a future EAPI
2015-11-08 20:24:09< willikins> K_F: https://bugs.gentoo.org/282296 "[Future EAPI] Allow directories for use.* and package.* entries in profiles"; Gentoo Hosted Projects, PMS/EAPI; CONF; rbu:pms-bugs
2015-11-08 20:24:38<@ulm> K_F: yeah, even better
2015-11-08 20:24:39 * dilfridge yes, do delay to later EAPI
2015-11-08 20:24:47 * jlec yes
2015-11-08 20:24:47 * K_F yes
2015-11-08 20:24:50 * ulm yes, postpone to later
2015-11-08 20:25:33 * WilliamH yes
2015-11-08 20:25:48 * rich0 yes 
2015-11-08 20:25:55<@K_F> Ok, passes 6 yes, 1 absent
2015-11-08 20:26:04<@ulm> and finally ...
2015-11-08 20:26:07<@ulm> drumroll
2015-11-08 20:26:15<@ulm> EAPI 6 approval
2015-11-08 20:26:37<@jlec> Congratulations!!!
2015-11-08 20:26:45<@ulm> http://dev.gentoo.org/~ulm/pms/6-draft/
2015-11-08 20:26:47 * WilliamH yes, let's get it done
2015-11-08 20:26:54 * dilfridge yes
2015-11-08 20:26:54<@ulm> jlec: we still have to vote on it :)
2015-11-08 20:26:56<@K_F> Vote: 2d) EAPI6 is approved taking into consideration the results of votes from 2a through 2c
2015-11-08 20:26:57 * ulm yes
2015-11-08 20:27:09 * jlec yes
2015-11-08 20:27:09 * dilfridge yes yes yes yeeeeah
2015-11-08 20:27:12 * K_F yes
2015-11-08 20:27:14 * WilliamH yes lets' get it done ;-)
2015-11-08 20:27:28 * rich0 yes
2015-11-08 20:27:38<@K_F> passes 6 yes, 1 absent
2015-11-08 20:27:45<@K_F> congrats ulm! great job
2015-11-08 20:27:47<@ulm> thank you :)
2015-11-08 20:28:06<@K_F> ok, that brings us on to 
2015-11-08 20:28:07<@K_F> 3) Bugs with council participation
2015-11-08 20:28:12<@K_F> bug 503382
2015-11-08 20:28:14< 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-11-08 20:28:23<@ulm> I'll cherry-pick to master what has been accepted and tag it in the usual way
2015-11-08 20:28:32<@dilfridge> ++
2015-11-08 20:28:50<@ulm> only the 20140225 summary is missing
2015-11-08 20:28:52<@K_F> Nothing much to say about that bug at this point I guess
2015-11-08 20:28:56<@dilfridge> the last meeting is also still missing. soon...
2015-11-08 20:29:37< mgorny> ulm: i'll try to update portage in the next few days
2015-11-08 20:29:46<@ulm> mgorny: good
2015-11-08 20:29:55<@K_F> ok, unless anyone have anything to add re "20140225: still missing" I propose we go to Open Floor
2015-11-08 20:30:14<@dilfridge> just a reminder,
2015-11-08 20:30:23<@dilfridge> the new eapi can be used in ~arch ebuilds as soon as ~arch portage for it is available
2015-11-08 20:30:30<@dilfridge> and the same for stable /stable, right?
2015-11-08 20:30:52<@jlec> That's how it has been before
2015-11-08 20:30:59<@WilliamH> Correct
2015-11-08 20:30:59<@ulm> dilfridge: yeah, we used to do it that way
2015-11-08 20:31:00< Arfrever> Firstly new Portage would have to be installed on a infra server used to generated metadata cache.
2015-11-08 20:31:03<@dilfridge> good
2015-11-08 20:31:13< Arfrever> s/generated/generate/
2015-11-08 20:32:11<@dilfridge> well I guess infra will keep eyes on that
2015-11-08 20:33:13<@K_F> should we make a note in the records that it shouldn't be stabilized until acked by infra?
2015-11-08 20:34:05<@K_F> or do we have the issue anyway with ~arch already?
2015-11-08 20:34:27<@K_F> i.e. the release shouldn't be made without communication with infra
2015-11-08 20:34:32<@dilfridge> nah, I guess the ciritical part is just that the metadata generation should not fail with EAPI=6 ebuilds
2015-11-08 20:34:34<@dilfridge> that always worked in the past
2015-11-08 20:34:34<@WilliamH> We have always just started using the new eapi when portage with it hits ~arch.
2015-11-08 20:34:57<@K_F> ok, standard procedure and no note then..
2015-11-08 20:35:14<@dilfridge> http://www.akhuettel.de/~huettel/plots/eapi.php < the plotter is already prepared :D
2015-11-08 20:35:16<@WilliamH> Then when that portage stabilizes ebuilds with the new eapi can stabilize.
2015-11-08 20:35:37<@K_F> 4) Open floor
2015-11-08 20:36:02<@WilliamH> A question I asked in #dev but really didn't get an answer...
2015-11-08 20:36:10<@WilliamH> I know that dohtml is going away.
2015-11-08 20:36:17<@WilliamH> What is the replacement?
2015-11-08 20:36:40< mgorny> dodoc
2015-11-08 20:38:06<@WilliamH> mgorny: so we have to use docinto <dir>/html... dodoc *.html ...
2015-11-08 20:38:06<@ulm> more specifically, docinto html; dodoc -r
2015-11-08 20:38:25<@WilliamH> Oh ok.
2015-11-08 20:38:50<@K_F> ok, that sounds good. Other items?
2015-11-08 20:38:58<@ulm> about ChangeLog generation from git
2015-11-08 20:39:01< mgorny> well, i expect it would be more often as dodoc -r docs/html or alike
2015-11-08 20:39:15< mgorny> and sometimes 'html' subdir doesn't really make sense, e.g. when that's just one html file
2015-11-08 20:39:29<@ulm> IMHO ChangeLog-2014, ChangeLog, ChangeLog.git is not such a good idea
2015-11-08 20:39:42<@ulm> I would like ChangeLog-2014, ChangeLog-2015, ChangeLog much more
2015-11-08 20:39:52<@ulm> basically, what aballier suggested
2015-11-08 20:40:00< mgorny> ulm: but that only makes sense if the split is on year's boundary
2015-11-08 20:40:06< mgorny> and that was my original idea
2015-11-08 20:40:13< mgorny> but then, gitmig was delayed half a year..
2015-11-08 20:40:34<@dilfridge> so what's hurt if we statically generate the rest of 2015 once
2015-11-08 20:40:47<@ulm> mgorny: unless we split at the end of 2015 I think it's not an issue
2015-11-08 20:41:06< mgorny> ulm: well, one thing that was supposed to be changed was changelog order
2015-11-08 20:41:11<@ulm> ChangeLog-2015 will be a minor misnomer only
2015-11-08 20:41:16< mgorny> robbat2 wants to do oldest-first
2015-11-08 20:41:24< mgorny> so rsync can do them incrementally
2015-11-08 20:41:25<@blueness> i'm here now
2015-11-08 20:41:25<@ulm> what?
2015-11-08 20:41:40<@ulm> mgorny: nobody does oldest first for changelogs
2015-11-08 20:41:55<@ulm> including git log
2015-11-08 20:41:55< mgorny> otherwise rsync needs to resend the whole file
2015-11-08 20:42:20<@K_F> that is actually a fair point of sorts
2015-11-08 20:42:30<@ulm> sounds more like rsync should be fixed :)
2015-11-08 20:42:30<@dilfridge> so half of the logs would be forward and half backward?
2015-11-08 20:43:00<@ulm> that too
2015-11-08 20:43:15< mgorny> i'd guess that would be the difference between ChangeLog-20* and ChangeLog(.git)?
2015-11-08 20:43:18<@WilliamH> dilfridge: the pre-git changelogs would be backward, yes, then the git-generated portions would be forward.
2015-11-08 20:43:25<@K_F> just as a point of order, we're not going to vote on anything regarding it today, so this is just an open discussion, so bringing up wide-scope is appropriate
2015-11-08 20:43:38< mgorny> but i'm only relaying what i know
2015-11-08 20:43:51<@blueness> K_F:  can i be recognized when the floor is free
2015-11-08 20:43:56 * WilliamH would rather nix changelogs, but that's a whole other debate
2015-11-08 20:43:56<@dilfridge> I kinda see the rsync point, but it worked fine so far...
2015-11-08 20:43:59< mgorny> robbat2 specifically requested reversing order and changing filename in portage code
2015-11-08 20:44:05<@K_F> blueness: sure
2015-11-08 20:44:16<@ulm> git log is newest first, so reverting that in the generated changelog would be confusing
2015-11-08 20:44:35<@blueness> K_F:  i just want the minutes to show that i approve of eapi 6 and while absent would have voted for it
2015-11-08 20:44:37< mgorny> dilfridge: i can imagine git-generated changelogs will simple have more entries
2015-11-08 20:44:45<@blueness> time change screwed me up :(
2015-11-08 20:44:48< mgorny> commits are more lightweight than manual changelog entries
2015-11-08 20:44:48<@K_F> blueness: noted
2015-11-08 20:44:49<@ulm> first priority should be readability for your users
2015-11-08 20:45:04<@ulm> then any technical issues like efficiency of rsync
2015-11-08 20:45:07<@K_F> blueness: will that be for 2d specifically or for 2a-2c as well?
2015-11-08 20:45:08<@jlec> exactly.
2015-11-08 20:45:12<@dilfridge> mgorny: yeah... but I guess we'll still do oversize splits
2015-11-08 20:45:17<@jlec> Reverse CangeLogs are hard to read
2015-11-08 20:45:25<@ulm> and it's not like half of our changelog would change every day
2015-11-08 20:45:51<@blueness> K_F:  well since 2d depended on 2a-2c I would say all the whole lot
2015-11-08 20:46:15<@blueness> but specifically i wanted to see eapi 6 passed today, i know there's always nuances, but overall i approve
2015-11-08 20:46:15< mgorny> just to be clear, i don't think we can really get somewhere with this while _robbat2|irssi is not around
2015-11-08 20:46:20<@K_F> blueness: since the meeting isn't closed, I'm fine to have that reflected in the official vote tally unless anyone objects to it
2015-11-08 20:46:49<@blueness> K_F:  okay
2015-11-08 20:47:44<@blueness> K_F:  there was nothing contraversial
2015-11-08 20:47:57<@blueness> it looks unanimous all the way
2015-11-08 20:48:00<@K_F> yup
2015-11-08 20:48:47<@blueness> this happened last year too when daylight savings time ended, but last year i was 1 minute from my computer, this time i was 30 mins away
2015-11-08 20:48:58<@K_F> ulm: I agree re priorities, not sure how much BW it generates overall though 
2015-11-08 20:49:31<@K_F> so users thrumph technical matter, but if it influence usability for users other than reading that might mitigate it
2015-11-08 20:50:05<@WilliamH> We need to find out from _robbat2|irssi  whether changing the start of a file or changing the end of it causes rsync to use more bandwidth.
2015-11-08 20:50:09<@K_F> blueness: I have the calendar entry recorded in UTC; solves the issue :)
2015-11-08 20:50:26<@blueness> K_F:  i know its my fault
2015-11-08 20:50:28<@K_F> blueness: but no worries, nothing contoversial today
2015-11-08 20:50:57<@blueness> K_F:  because everything else here changes with the time change so you don't notice it
2015-11-08 20:51:05<@blueness> and habit rules supreme
2015-11-08 20:51:25<@blueness> the US should give up day light savings time
2015-11-08 20:51:29<@ulm> K_F: another possibility would be to reverse the existing ChangeLogs too
2015-11-08 20:51:42<@K_F> ulm: yeah, I think that would make sense if we change the order
2015-11-08 20:51:59<@K_F> ensure consistency
2015-11-08 20:52:27<@blueness> are we trying to join the old cvs logs to the new git logs?
2015-11-08 20:54:08<@ulm> no, just make their ordering consistent
2015-11-08 20:54:26<@ulm> and I would strongly prefer newest first for all of them
2015-11-08 20:54:48<@WilliamH> ulm: can git log even do that?
2015-11-08 20:54:49< mgorny> i personally don't care about changelogs or rsync
2015-11-08 20:54:58< mgorny> but i'd agree it's better to have some consistency
2015-11-08 20:55:19< mgorny> having cvs changelogs with no git changelogs is bad
2015-11-08 20:55:19<@K_F> WilliamH: git log --reverse
2015-11-08 20:55:26< mgorny> so is having two changelogs in different orders
2015-11-08 20:55:37<@WilliamH> K_F: ok cool.
2015-11-08 20:55:46<@blueness> ulm:  yeah i agree on the ordering
2015-11-08 20:56:12 * rich0 has to run - will check logs and catch up in 20min if we're still discussing changelogs.  :)
2015-11-08 20:56:23<@K_F> rich0: enjoy
2015-11-08 20:56:33<@K_F> lets close the meeting, discussion can continue anyways
2015-11-08 20:56:36 * K_F bangs the gavel
2015-11-08 20:57:01<@jlec> thansk for chairing
2015-11-08 20:57:13<@K_F> jlec: got lucky with this one :)
2015-11-08 20:57:28<@jlec> And again, ulm thanks for your EAPI work
2015-11-08 20:57:32<@jlec> K_F: indeed
2015-11-08 20:57:45< mgorny> when we're done with changelogs, i'd like to ask opinion on the metadata.xml/projects glep if some of you have more remarks
2015-11-08 20:57:50<@ulm> oh my, rsync has many options
2015-11-08 20:58:18<@WilliamH> ulm: Yeah rsync is pretty complex. I've briefly looked at it.
2015-11-08 21:00:29<@dilfridge> thanks!
2015-11-08 21:01:43<@ulm> WilliamH: I wonder, rsync should be transferring the delta between the files only
2015-11-08 21:02:00<@ulm> regardless if it's at the beginning or end of the file
2015-11-08 21:02:42<@K_F> ulm: I'm not sure if it handles offsets like that, so having a reverse order ensures exactly that
2015-11-08 21:02:54<@WilliamH> ulm: It could be argued that the delta is bigger if you change the top of the file vs if you change the end.
2015-11-08 21:02:57<@K_F> but been a while since I looked into it
2015-11-08 21:03:33 * WilliamH has no idea wrt rsync internals
2015-11-08 21:03:37<@ulm> "It is famous for its delta-transfer algorithm, which reduces the amount of data sent over the network by sending only the differences between the source files and the existing files in the destination."
2015-11-08 21:03:43<@ulm> ^^ from rsync manpage
2015-11-08 21:03:55<@dilfridge> afaik the delta is disabled in our rsync mirrors to save cpu
2015-11-08 21:03:56<@K_F> ulm: yeah, but changing from start will likely increase that delta
2015-11-08 21:04:13<@dilfridge> so a file is re-sent whole if changed
2015-11-08 21:04:48<@WilliamH> mgorny: shoot me the link again for that glep?
2015-11-08 21:04:51<@K_F> dilfridge: if that is the case, unless we're talking about changing the paramenters used, there will be no change by order reversal
2015-11-08 21:04:57<@ulm> right
2015-11-08 21:04:59<@dilfridge> indeed
2015-11-08 21:05:05<@dilfridge> I only just remembered about this
2015-11-08 21:05:05<@K_F> WilliamH: https://wiki.gentoo.org/wiki/User:MGorny/GLEP:Maintainership_structure
2015-11-08 21:05:26< mgorny> oh u, faster than me
2015-11-08 21:09:07<@WilliamH> mgorny: Hmm, I don't agree with part of how you describe the current system.
2015-11-08 21:09:15<@WilliamH> mgorny: a herd was never a maintainer.
2015-11-08 21:09:29<@WilliamH> mgorny:  maintainers maintain herds of packages.
2015-11-08 21:09:43< mgorny> words
2015-11-08 21:09:47< mgorny> names
2015-11-08 21:09:47<@WilliamH> mgorny: I'm not sure how to reword it though.
2015-11-08 21:12:42<@WilliamH> mgorny: but the whole concept you have of maintainers being in herds is wrong; it was never that way.
2015-11-08 21:13:05<@WilliamH> mgorny: for example the gnome herd referrs to all of the gnome packages
2015-11-08 21:13:46<@WilliamH> mgorny: Yes, it is messed up, that's why we voted to kill herds
2015-11-08 21:15:57< mgorny> WilliamH: in the past the naming was changed to make herds mean developers, as far as i recall
2015-11-08 21:16:03< mgorny> but i don't recall who told me that
2015-11-08 21:16:15< mgorny> maybe even by council
2015-11-08 21:17:52<@WilliamH> mgorny: No, it was never changed.
2015-11-08 21:18:18<@WilliamH> mgorny: I don't know who told you that either, but they were incorrect.
2015-11-08 21:18:34<@WilliamH> mgorny: herds have always meant packages.
2015-11-08 21:20:18< mgorny> does it really matter for the future?
2015-11-08 21:23:54<@WilliamH> mgorny: Well, we voted to kill them, so not for the future, but for documenting the current system it does.
2015-11-08 21:50:20<@ulm> WilliamH: <gentoovcs> ulm → proj/pms:eapi-7 (/) New branch: eapi-7
2015-11-08 21:50:37<@ulm> since you were concerned about the long delay :)
2015-11-08 22:33:18< mgorny> ulm: is eapi-6 branch final already or are you still updating it?
2015-11-08 22:35:53<@WilliamH> ulm: heh :-)
2015-11-08 23:01:10<@ulm> mgorny: https://gitweb.gentoo.org/proj/pms.git/commit/?id=b92a940c1627b64f0eef9dce4fcafb2795f7a414
2015-11-08 23:01:32<@ulm> ^^ this is the final version, merged to master
2015-11-08 23:08:37< mgorny> thanks
2015-11-08 23:09:11-!- ulm changed the topic of #gentoo-council to: Next meeting: 2015-12-13 19:00 UTC | http://www.timeanddate.com/worldclock/fixedtime.html?hour=19&min=0&sec=0 | https://wiki.gentoo.org/wiki/Project:Council
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJWSMEQAAoJECULev7WN52FBCUH/iaLCyz/Iqe4cVTIunVBgqJD
XXd9gKzfddvVKcwJK1GsKz2wVzwNyd4JWDq5TEbLkfUkMLkrc77zVMU0OWIOdC89
iRLlBM3z1XrUbFj+6hwFwQAGfmdNrzMJzjB8V3WPrQP+3gaRtbUQ2aAYloEa3bCZ
Wb9gx9cQN+ndvdm5tWWGPrPsg7LzBLa/DL4JUhfhKC0xbSYct0I36H/MWdvcpnjn
IRwwSgSQ5hq6v74iTFtyZsgeXnXIfIvOYnw3pY0391opAZ/1/3KTLgS+3KcKx3gW
p2D4k+W3AJ50ZT2GyeMvgoGVbV9DRThOrKddxMrlm13P/RGkq6/e2A0w+CHFVj8=
=Tnpa
-----END PGP SIGNATURE-----