path: root/meeting-logs/20140826.txt

<ulm> 19:00, so let's start the meeting                                 [21:00]
<ulm> agenda is here: http://article.gmane.org/gmane.linux.gentoo.project/4014
<ulm> roll call
<radhermit> here
<rich0> here
<dilfridge> here
<WilliamH> here
<blueness> here
<ulm> dberkholz?                                                        [21:01]
<ulm> anyone has donnie's number?                                       [21:02]
<blueness> lets start
<radhermit> he sent it to the list
<radhermit> or alias
<dilfridge> sent him a text...                                          [21:03]
<blueness> dilfridge, were you going to compile a list?
<blueness> :)
<dilfridge> yes, soon...
<ulm> anyway, let's start
<ulm> first topic: dynamic dependencies in portage
<ulm> http://thread.gmane.org/gmane.linux.gentoo.project/3943
<dilfridge> wheeee                                                      [21:04]
<ulm> any opinions?
<dilfridge> two things from me...
<rich0> So, I believe the portage team indicated that they plan to remove
        dynamic deps the way they are now, but to come up with another
        solution to the rebuild problem.
<rich0> As long as the latter accompanies the former when it goes mainstream,
        I don't have a problem with it.                                 [21:05]
<dilfridge> 1) some eclasses add dependencies which need to be changed every
            now and then... e.g. minimal perl version in perl-module.eclass,
            or minimal qt version for kde ebuilds
<ulm> I'd say this is up to the portage team. they had added the feature, so
      they can change or remove it as well
<dilfridge> noone's come up with a real solution for this yet, except for a
            true mass rebuild
<WilliamH> There is a solution that mgorny came up with, a new @changed-deps
           set that would rebuild everything.                           [21:06]
<WilliamH> with new dependencies
<dilfridge> yes... wanna rebuild all perl-related ebuilds in your system? :)
<ulm> WilliamH: IIUC this has the same problem as dynamic dependencies
<ulm> if the ebuild is gone, the package won't be rebuilt               [21:07]
<blueness> i haven't seen a solution that satisfies my so i'm not sure what we
           are resolving here.  i'd say ask the portage team to come up with
           something.
<ulm> so it would bite users who haven't upgraded for a long time
<dilfridge> 2) that said, I dont intend to fully block this move by the
            portage team, but before it's actually disabled fully, we need a
            working, reliable alternative and a good idea for the needed
            workflow and tree policies.
<blueness> ulm, the ebuild is still in vardb
<radhermit> as a pkgcore guy, I've never been pro-dynamic deps due a number of
            issues most of which have been raised in the various threads
<rich0> dilfridge: ++
<ulm> blueness: the one with the old dependencies                       [21:08]
<blueness> ah
<blueness> yes
<radhermit> imo, we should really spec out a vdb format
<rich0> That is my concern.  I'm fine with one step back and two steps
        forward, but we can't do the latter without plans to do the former.
<rich0> Err, the other way around :)
<blueness> radhermit, take a look at https://wiki.gentoo.org/wiki/GLEP:64
<rich0> Sure, to some extent the portage team should take the lead on this,
        but this affects the whole tree and how it is maintained.
<ulm> so, should we ask the portage team to outline their solution, before
      they remove the current feature?                                  [21:09]
<dilfridge> this does not so much affect the maintainer of a single package,
<radhermit> blueness: ah gotcha
<dilfridge> but much more the people maintaining virtuals and eclasses...
<Arfrever> There is no consensus in Portage team to remove dynamic
           dependencies.
<WilliamH> Arfrever: I thought there was.                               [21:10]
<dilfridge> Sorry can you type louder, I didn't hear you...
<radhermit> anyway, I also agree that the support shouldn't just be yanked out
            of portage since it's been the default for a long time
<radhermit> and devs have become implicitly used to its mostly hidden workings
                                                                        [21:11]
<dilfridge> exactly.
<rich0> I think a long-term plan would alleviate a lot of concerns.  It isn't
        enough to say dynamic deps are broken.  We need to talk about what the
        better solution actually is. I'm sure it will be supported then.
<ulm> Arfrever: the portage team meeting summary posted on 2014-07-25 says
      that dynamic dependencies will be turned off
<dilfridge> right now the bigger surprise is that sometimes dynamic deps dont
            work...
<ulm> that's the most official statement we have
<ulm> so we should go from there                                        [21:12]
<ulm> anyone wants to come up with a motion?                            [21:13]
<WilliamH> I'm thinking that if they are turned off by default that will be ok
           as long as we can turn them on until a fix is developed.
<WilliamH> We won't know what is broken by them being turned off until they
           are turned off...                                            [21:15]
<Arfrever> ulm: This "meeting" was even not announced before it (mailing lists
           were down). I have received e-mail about announcement of meeting
           after meeting. Probably very small number of members of team
           participated in meeting.
<WilliamH> Arfrever: you should be able to check that by the meeting log if it
           is posted.                                                   [21:16]
<ulm> How about this: "The council asks the portage team to outline their
      long-term plan regarding removal or replacement of dynamic dependencies,
      before they actually remove this feature."
<dilfridge> ulm: that plus:
<blueness> yes
<dilfridge> "Especially tree policies and the handling of eclasses and
            virtuals need to be clarified."                             [21:17]
<Arfrever> (Anyway I am one of Portage team members, who would vote for
           keeping dynamic dependencies.)
<ulm> good
<rich0> wfm
<ulm> "The council asks the portage team to first outline their long-term plan
      regarding removal or replacement of dynamic dependencies, before they
      remove this feature. Especially tree policies and the handling of
      eclasses and virtuals need to be clarified."
<blueness> dilfridge, "especially" -> "In particular"  (very minor change but
           sounds better)
<ulm> Please vote
* dilfridge yes
<blueness> yes
<radhermit> yes
<rich0> yes                                                             [21:18]
<ulm> ok, with blueness's change of wording
<ulm> yes
<blueness> yes
<WilliamH> yes
<radhermit> sure
<ulm> unanimous, for the council members present
<ulm> anything else for this topic?
<dilfridge> just the remark                                             [21:19]
<dilfridge> that this is much more critical for slow arches as e.g. arm or ppc
            where the rebuilds are more time-consuming.
<ulm> do you want this in the summary?
* dilfridge pulls up the obligatory remark about a "beowulf cluster of
  those"...                                                             [21:20]
<dilfridge> nah, log is enough :)
<ulm> next topic: additional features for EAPI 6
<ulm> http://thread.gmane.org/gmane.linux.gentoo.project/4002
<ulm> mgorny asks us to reopen the list of features                     [21:21]
<Arfrever> ulm: (It was never closed anyway...)
<radhermit> were they closed? I didn't think so yet
<ulm> k
<ulm> I suggest we discuss features individually                        [21:22]
<dilfridge> +
<ulm> 1. passing additional configure options, namely --docdir and --htmldir
<ulm> I would be in favour of this
<radhermit> imo, should be fine
* dilfridge abstains
<ulm> looks pretty safe
<WilliamH> should be ok                                                 [21:23]
<ulm> and mgorny has done a tree-wide scan IIUC
<ulm> so let's just vote
* ulm yes
<radhermit> yes
* dilfridge abstain
<blueness> yes
* rich0 yes
* WilliamH yes
<ulm> passes with 5 yes 1 abstention 1 absent                           [21:24]
<ulm> 2. additional default suffixes for dohtml
<ulm> IMHO changing the default is pointless
<WilliamH> What are the requested suffixes?                             [21:25]
<ulm> it's just a default, and there are options -a and -A to change the list
      of suffixes
<ulm> .xml .xhtml .ico .svg
<ulm> bug 423245
<willikins> ulm: https://bugs.gentoo.org/423245 "[Future EAPI] dohtml: Extend
            default list of extensions"; Gentoo Hosted Projects, PMS/EAPI;
            UNCO; arfrever.fta:pms-bugs
<ulm> I have some ideas about moving the dohtml function from the PM to an
      eclass                                                            [21:26]
<blueness> this is minor, imo.  its harmless to change the default but there's
           no strong reason to do so.
<ulm> blueness: well, devs have to learn the difference between EAPIs then
                                                                        [21:27]
<dilfridge> right. let's keep it as it is.
<blueness> ulm, yeah i guess
<ulm> and you'd have to check the set of installed files for every EAPI bump
      from 5 to 6
<ulm> more discussion?
<ulm> seems not, so let's vote                                          [21:28]
* ulm no
* dilfridge no
<blueness> no
<rich0> no
* WilliamH abstains
<radhermit> no
<ulm> rejected, 5 no 1 abstention 1 absent
<ulm> 3. build-time switching variant of || ()                          [21:29]
<ulm> bug 489458
<willikins> ulm: https://bugs.gentoo.org/489458 "[Future EAPI] Replace || with
            something less ambiguous"; Gentoo Hosted Projects, PMS/EAPI; CONF;
            ciaran.mccreesh:pms-bugs
<ulm> I would be very much in favour of this feature if there was proof of
      concept ready
<rich0> I think mgorny's proposal seemed reasonable enough.
<dilfridge> well, right now we're only saying what things people should work
            on... this is not the final decision on EAPI features (since that
            needs the implementation)                                   [21:30]
<rich0> ulm: well, that seems to be the point of pre-voting on EAPIs
<blueness> rich0, you mean comment #14?
<rich0> blueness: yes
<ulm> we could provisionally approve it, with the condition that it will only
      be included in EAPI 6 if an implementation is ready
<dilfridge> comment 14 is the one to go for, yes
<rich0> We'll have to re-vote on the final PMS once there is a reference
        implemenation.                                                  [21:31]
<dilfridge> ulm: isn't that true for everything right now?
<rich0> dilfridge: yes
<rich0> PMS policy is that we don't put stuff in until implemented in portage
<rich0> This is basically to help devs avoid wasting time on stuff only to
        have it yanked back out
<rich0> I think it makes sense to do it this way.
<ulm> dilfridge: mgorny has implemented everything else in his branch of
      portage already
<rich0> People can still work on stuff we vote no on, or not work on stuff we
        vote yes on.  It just gives them a sense of where we stand.
                                                                        [21:32]
<dilfridge> right... but that wasn't the case at the time of the first votes
            :P
<ulm> o.k.
* radhermit will need to look at pkgcore code a bit, but it seems ok-ish
<blueness> rich0, i agree that this resolves one ambiguity, but to be honest,
           i can't fully get my head around all the possibilities here, and
           i'm not sure mgorny's solution really nails everything
<ulm> so please vote on provisional approvement, with the condition that it
      will only be included if an implementation is ready
* ulm yes
* dilfridge yes                                                         [21:33]
<blueness> yes
<rich0> yes
<radhermit> yes
<ulm> WilliamH?
<rich0> blueness: agree that when you get into nesting the actual use gets
        murky.  However, I think that the rules are straightforward enough.  I
        guess if you get ||= embedded in || you have to decide if the ||=
        propagates through.
* WilliamH yes                                                          [21:34]
<ulm> rich0: these things are what makes the implementation difficult ;)
<radhermit> it will probably need some more forceful or better defined
            boundaries though, I'm assuming that'll happen if it gets into PMS
<ulm> passes unanimously (1 absent)
<ulm> we're perfectly in time :)                                        [21:35]
<ulm> next: open bugs
<ulm> bug 424647
<willikins> ulm: https://bugs.gentoo.org/424647 "archives.gentoo.org: Broken
            URLs for e.g. gentoo-dev-announce and others"; Gentoo
            Infrastructure, Other; CONF; darkside:infra-bugs
<dilfridge> I think infra has bigger problems atm...                    [21:36]
<ulm> yeah
<ulm> no progress there
<rich0> agree, but how is this a council issue anyway?
<ulm> and no action by council
<rich0> we basically look at this every month and say, yes, it is a problem
<blueness> heh yeah                                                     [21:37]
<rich0> Either somebody volunteers to fix it, or maybe we beg the trustees to
        pay somebody to fix it for us
<ulm> we could remove council from cc
<blueness> let's do that
<ulm> and forget about the problem
<rich0> I don't think we're adding any value
<dilfridge> which problem?                                              [21:38]
<rich0> :)
<blueness> dilfridge, the broken archives
<ulm> dilfridge: that we have no archives
<blueness> email archives
<dilfridge> ... :)
<radhermit> pretty sure he was joking
<ulm> any objections against removing us from cc?
<dilfridge> no objections.                                              [21:39]
<rich0> We should use discourse.  :)
<blueness> ulm, i agree, remove us
<ulm> next, bug 477030
<willikins> https://bugs.gentoo.org/477030 "Missing summary for 20130611
            council meeting"; Doc Other, Project-specific documentation; CONF;
            ulm:council
<ulm> I became impatient and wrote a summary :)                         [21:40]
<ulm> http://www.gentoo.org/proj/en/council/meeting-logs/20130611-summary.txt
<ulm> asking for approval here
<blueness> ulm, were you at the meeting?
<ulm> you should also have received the draft by e-mail
<ulm> blueness: yes
<blueness> okay then, do it                                             [21:41]
<radhermit> looks fine, imo
<ulm> I don't see any objections                                        [21:42]
<rich0> I say go ahead
<ulm> so I'll add the link to the council page
<blueness> well i have not basis to disagree since i wasn't there
<ulm> finally, 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> but donnie is not here :(                                         [21:43]
<ulm> so again no progress, I fear
<ulm> hm, there's another bug actually                                  [21:44]
<ulm> bug 520074
<willikins> ulm: https://bugs.gentoo.org/520074 "GLEP 39 rump council
            privilege escalation in secret meeting"; Doc Other, GLEP Changes;
            UNCO; wking:glep
<ulm> rich0: you've participated in the discussion there, so do you want to
      comment?                                                          [21:45]
<rich0> I think it is much ado about nothing.
<rich0> :)
<ulm> yeah, that's my impression too
* WilliamH agrees
<ulm> from a theoretical pov he might have a point                      [21:46]
<rich0> Certainly our rules aren't airtight, but we only lead because
        everybody recognizes that we lead.
<blueness> actually, i had a secret meeting yesterday and voted to disband the
           council, so this is now mute
<ulm> but I doubt that it has any practical relevance
<blueness> moot
<dilfridge> yes... it's very much about codifying common sense, which is
            something you can spend all eternity on
<rich0> If we say something that 99% of devs disagree with, they'll just
        ignore us.
<blueness> shoudl we have a quorum for other reasons?
<rich0> Well, we already disband the council anytime half of us don't show up.
                                                                        [21:47]
<rich0> So, that seems to be overkill already.  :)
<WilliamH> Right.
<blueness> yeah
<rich0> I don't care for the slacker rule at all, but that is a separate
        matter.
<ulm> any action?
<ulm> remove council from cc?
<blueness> yeah
<dilfridge> rich0: I would not mind adding that the council with <=50%
            attendance can't decide anything, but if that requires an eternal
            discussion on how to add something, I dont care.
<rich0> I don't object either, but then you get into the whole argument about
        who is allowed to edit GLEP 39                                  [21:48]
<dilfridge> exactly.
<ulm> dilfridge: it was handled that way when it occured
* radhermit doesn't care that much, seems people have replied enough on the
  bug
<ulm> only once, in 2008
<dilfridge> yes.
<rich0> I don't have an issue with just fixing it, but maybe the same folks
        who like the slacker rule might object.  :)
<ulm> ok, I'll remove us from cc                                        [21:49]
<ulm> next, open floor
<ulm> and we're still in time :)                                        [21:50]
<dilfridge> meh
<dilfridge> right.
<dilfridge> [21:47:28] <_AxS_> done!
<dilfridge> official commendation to _AxS_ for revbumping all dev-perl to
            EAPI=5 :)
<rich0> woot!
<ulm> great :)
* WilliamH agrees, that is good news
<blueness> that was a lot of work                                       [21:51]
<WilliamH> That obosoletes perl-cleaner right?
<blueness> so am i to understand this correctly that we won't need
           perl-cleaner anymore
<dilfridge> not yet
<WilliamH> obsoletes *
<ulm> let's finish EAPI 6 so the perl team won't be put out of work :p
<dilfridge> WilliamH: there are some ebuilds left (not many), more complex
            apps that also install perl modules                         [21:52]
<blueness> dilfridge, what will perl-cleaner be needed for?
<blueness> i see
<dilfridge> once these are gone too, we'll ban EAPI<5 in perl-module.eclass
<dilfridge> then it's obsolete.
<blueness> what about perl virtuals?
<dilfridge> well, the new ones are also marked EAPI=5                   [21:53]
<dilfridge> but there's no hurry there
<dilfridge> no eclass, nothing to rebuild
<blueness> i see
<dilfridge> (and the EAPI makes no difference)
<ulm> anything else for open floor?                                     [21:54]
<ulm> seems not to be the case                                          [21:55]
<ulm> next meeting will be on 2014-09-09
<ulm> so I'll send the call for agenda items today                      [21:56]
*** ulm (~ulm@gentoo/developer/ulm) has set the topic for #gentoo-council:
    "Next meeting: Tuesday, 9 Sep 2014 19:00 UTC |
    http://www.gentoo.org/proj/en/council/utctolocal.html?time=19:00 |
    http://wiki.gentoo.org/wiki/Project:Council"