diff options
Diffstat (limited to 'meeting-logs/20151108.txt')
| -rw-r--r-- | meeting-logs/20151108.txt | 300 |
1 files changed, 300 insertions, 0 deletions
diff --git a/meeting-logs/20151108.txt b/meeting-logs/20151108.txt new file mode 100644 index 0000000..dafddbe --- /dev/null +++ b/meeting-logs/20151108.txt @@ -0,0 +1,300 @@ +-----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----- |