path: root/meeting-logs/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