Log for 20140909 meeting.

1 files changed, 262 insertions, 0 deletions

diff --git a/meeting-logs/20140909.txt b/meeting-logs/20140909.txt
new file mode 100644
index 0000000..9fcaa81
--- /dev/null
+++ b/meeting-logs/20140909.txt
@@ -0,0 +1,262 @@
+<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