19:00 UTC, so let's start [21:00] roll call * blueness here! dberkholz, dilfridge, radhermit, rich0, williamh? hi helium-3? [21:01] * rich0_ here *** rich0_ (~quassel@gentoo/developer/rich0) is now known as rich0 I'm around dilfridge and WilliamH still missing [21:02] * blueness taps his fingers impatiently [21:03] I've texted dilfridge k thx :) here can anyone in the US try to contact WilliamH? and hello from Kyparissia / Kalo Nero [21:04] ulm, i can, but i don't recall getting his number I'll text him k dilfridge, did you ever collect everyone's phone number in one email? sent not yet, but I can do it during the next days I have 5 more beach days ahead of me... [21:05] * WilliamH is here sorry folks ok, we're complete then agenda is rather short this time: http://article.gmane.org/gmane.linux.gentoo.project/4021 first topic is about the future of dohtml [21:06] http://thread.gmane.org/gmane.linux.gentoo.project/4017 kill it with fire seems like the perfect job for a utility eclass I have no experience with it, but from the mailing list mails I think we should kill it [21:07] we first have to decide if it should be removed from the PM then the details ditto, it seems like it was redundant and overly complex I think deprecation makes sense. No rush to get rid of it that I can see. shall we just vote on the first question? That creates the demand for an eclass which replaces it. "should dohtml be banned from the package manager?" [21:08] * WilliamH yes (no timeframe implied yet) * dilfridge yes * ulm yes * rich0 yes, eventually has ayes err .. "yes" * radhermit yes dberkholz? [21:09] anyway, I count 6 yes so far [21:10] i'm grepping the tree now to see what uses it so we can discuss the next question I think should it be banned in EAPI 6 already? [21:11] * WilliamH yes blueness: 3665 lines from a grep... it would just be part of the migration to eapi 6 to stop using it. alternative would be to deprecate it now and ban it in one of the next EAPIs * dilfridge yes [21:12] * ulm yes ulm: I don't see the advantage of doing that. ulm, that's what i would like, a deprecation message immediately are we going to pass --htmldir or --docdir or whatever in EAPI 6? that's fine radhermit: yes if so, then sure ban it in 6 dberkholz: was this your vote on the first question? [21:13] dberkholz: "should dohtml be banned from the package manager?" yes to 1 and yes to 2 via deprecation deprecate in 6, obsolete in 7 [21:14] second vote is "should it be banned in EAPI 6 already?" dberkholz: ++ dberkholz: that's a no to the second vote then? I'm fine with both variants (ban in 6 / deprecate in 6, ban in 7) ulm: no to banned in 6. right. [21:15] I'm in favor of deprecation. I don't want to see a lack of an eclass as something that slows EAPI6 adoption. do I count this right? [21:16] Williamh, ulm, radhermit: yes we should have a deprecation process that's part of the eapi, not just randomly deprecating stuff independent of that dberkholz, rich0: no dilfridge: abstain ? who's missing? me i'm in favor of deprecation in 6, ban in 7 so dberkholz, rich0, blueness: no [21:17] correct 3 yes 3 no 1 abstention then motion doesn't pass neither one passes the motion was to ban it in EAPI 6 [21:18] so, the alternative then "deprecate dohtml now, ban it in EAPI 7?" * ulm yes * dilfridge yes * WilliamH no because we should ban it [21:19] yes deprecation will be ignored when people adopt eapi 6. * rich0 yes have we cleanly deprecated and then dropped similar things before? [21:20] radhermit: I think we have just dropped some things before, e.g. dosed There wasn't a deprecation eapi for that. We just told people to start using sed -i radhermit: dosed, dohard [21:21] The problem with dohtml, is that there isn't really a drop-in replacement for it AA, KV* varibles *variables rich0: and as long as we don't drop it there won't be. rich0, you can use dodoc I mean I'm all for having a decent way to deprecate eapi features Yes, you can use docinto/dodoc [21:22] radhermit, you would just add a warning in portage when its called so I'm fine-ish with this radhermit: will be via a repoman warning probably blueness: I'm more thinking how to handle it in pkgcore ;) blueness: and who will ignore the warning? but yes Let's just kill the thing... :( radhermit, yeah i just recently learned about pkgcore! its your baby [21:23] dberkholz: I count you as "yes" from what you said above so this passes with 6 yes 1 no cool I mean I know people will probably just ignore it, but doing the deprecated -> dropped steps for formal specs is generally better imo [21:24] I suggest we change order of the laast two questions should einstalldirs in EAPI 6 use dodoc -r for HTML_DOCS, instead of dohtml? *last oops, that's a typo [21:25] should einstalldocs in EAPI 6 use dodoc -r for HTML_DOCS, instead of dohtml? einstalldocs is a new function in EAPI 6 well if we're deprecating things, yes dohtml shouldn't be used in the default case [21:26] IMHO it doesn't make sense to use a deprecated function right do we even have to vote on this one? ulm just not it as an obvious point err [21:27] ulm just note it as an obvious point anyone against this? speak up now its fine sounds ok k so, do we need a substitute in an eclass? dohtml in portage is written in python so the code cannot simply be copied [21:28] i would have the deprecation notice say "use dodoc -r ..." [21:29] does anyone know in what language dohtml in pkgcore and paludis is implemented in? c++ well c++ in paludis pkgcore is in python pkgcore -> python right blueness: somehow I doubt it for this ebuild helper Technically you could have a python script as a build-time dependency... [21:30] c++, that is ulm, let me look I don't know about paludis http://git.exherbo.org/paludis/paludis.git/tree/paludis/repositories/e/ebuild/utils/dohtml so it's in bash so it could be used (modulo copyright assignment problems) [21:31] anyway, that's a detail yeah but what confused me is its in a Makefile.am too ... [21:32] but you're right its written in bash question is if we want a replacement in an eclass at all why do we need one? I'd say we recommend dodoc -r and if there's a strong need, someone will come up with an eclass function anyway [21:33] we cannot forbid that, I think any further opinions? ulm: ++ [21:34] I think we can deprecate it, and if there is a big unmet need people will fix it. so how about: "the council does not mandate a replacement function in an eclass"? [21:35] ulm: I don't think it is necessary for us to state that even. is "mandate" the right verb? We don't implement nroff, autotools, etc in an eclass either - packages that need them depend on them. (well, autotools are in @system I think) it is the correct verb, but i think we can remain silent on the issue why would we remove it and then say it'll go in an eclass? [21:36] ok, so we don't say anything about eclasses just deprecate -> remove it and people will either move on or complain on the list later :P right just don't say anything agree we are only talking about PMS here, not what someone might upt in an eclass [21:37] We can always hash out on the mailing list. makes sense We aren't going to stop somebody from coming up with a replacement for dohtml, and on the other hand we can't do anything to force one to be created either are we done with this topic? next: open bugs [21:38] pretty much bug 503382 https://bugs.gentoo.org/503382 "Missing summaries for 20131210, 20140114, and 20140225 council meetings"; Doc Other, Project-specific documentation; CONF; ulm:council dberkholz? looks like 20131210 and 20140114 summaries are done [21:39] btw, would anyone object if I move the index of meeting logs to a subpage in the wiki? [21:40] nope [21:41] because loading time for the council project page has become rather long ah good poing point do it, sounds good [21:42] so, some progress with this bug 20140225 summary is still missing and I'll move the meeting logs to a subpage open floor then anything? [21:43] one announcement, i think i'll have GLEP 64 ready for voting by next time k are there any comments from the council yet, i thin there's been good discussion on the ml think (i can't type today!) [21:44] blueness: I haven't found the time yet for going through it thoroughly but I'll do so k [21:45] ulm: yeah i put those two in the wiki, i had uploaded them before but forgot to head back to the wiki page an hour later to add the link sorry for the crazy lag, i'm on a terrible connection and keep dropping dberkholz: any ETA for the february summary? for the next meeting, I expect that we'll discuss einstall removal [21:46] ok [21:47] seems there's nothing from the community next meeting is on October 14th [21:48] who will be chairing? rich0: the council page says it's you yup [21:49] okay *** ulm (~ulm@gentoo/developer/ulm) has set the topic for #gentoo-council: "Next meeting: Tuesday, 14 Oct 2014 19:00 UTC | http://www.gentoo.org/proj/en/council/utctolocal.html?time=19:00 | http://wiki.gentoo.org/wiki/Project:Council" this meeting is closed then thanks all