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