path: root/meeting-logs/20160313.txt

<blueness> time to start                                                [19:54]
<blueness> agenda at
           https://archives.gentoo.org/gentoo-dev-announce/message/106bd518b11a2e9700e7d77606cb7c23
                                                                        [19:55]
<blueness> dilfridge: dilfridge|mobile jlec K_F rich0  ulm WilliamH
<blueness> wierd my computer says 4 minutes to the hour but my computers says
           4 minutes after!                                             [19:56]
<floppym> Sounds like you need to configure NTP on some of your computers.
                                                                        [19:57]
* WilliamH is here, my clock is at 18:57 utc
<blueness> floppym: i do have ntp
<jlec> Same here
<blueness> there’s one central ntp server
<blueness> i think my one computer is off and everything is syncing off of it
<blueness> well it doesn’t hurt to wake people up a bit early           [19:58]
<WilliamH> blueness: heh
<dilfridge> here                                                        [20:00]
<K_F> here
<jlec> Here
* jlec here
* WilliamH here                                                         [20:01]
<blueness> rich0:
<floppym> I'm proxying for ulm.
<blueness> ulm: is probably not going to show up
<blueness> oh okay floppym
<blueness> the agenda is here
           https://archives.gentoo.org/gentoo-dev-announce/message/106bd518b11a2e9700e7d77606cb7c23
<blueness> so the first item is to look at the updates to glep 42 on news
           items                                                        [20:02]
<blueness>
           https://archives.gentoo.org/gentoo-dev/message/b9460b9c8d578c3498c217c17b75afd4
<blueness> ulm also has a prepared update to the glep page at
           https://wiki.gentoo.org/wiki/User:Ulm/GLEP:42                [20:03]
<blueness> take a sec to look it over and then let’s discuss
<K_F> Hvae read through it and the changes seems to be in line with what we
      have previously discussed, including some more definition on backwards
      vs forwards compatible tool vs file format..                      [20:04]
<jlec> I cannot spot anything wrong                                     [20:05]
<jlec> Lgtm
<blueness> you can search for format 2.0 in the proposed wiki page which
           nicely specifies the new featurs
<floppym> I do find it strange that we still cater to 80 column terminals, but
          50 is certainly better than 44.
<blueness> i agree i can’t see anything wrong
<WilliamH> The changes look reasonable to me.                           [20:06]
<K_F> floppym: I rarely use more than 80 cols personally
<dilfridge> lgtm
<jlec> Please no 80 char discussion
<blueness> floppym: for git on gitweb 72+ chars is a problem
<floppym> Ah.
<blueness> so there are still places where the are problems
<floppym> I was just making a comment; no real objection here.
<blueness> lol jlec okay
* dilfridge bites the ears off a chocolate bunny
<blueness> heh                                                          [20:07]
<blueness> are we ready for a vote then?
<jlec> Yes
<blueness> okay “Accept proposed changes to GLEP 42”?
* blueness yes
* WilliamH yes
* dilfridge yes
<floppym> I vote yes, to accept the changes.
* K_F yes
* jlec yes                                                              [20:08]
<blueness> unanimous with one missing rich0
<blueness> wow that was easy
<blueness> okay next item
<blueness> 3. Historical behaviour vs PMS (see above)
<dilfridge> ok one remark from me                                       [20:09]
<K_F> as a point of order I suggest we don't have any decisions /votes today,
      but a discussion
<jlec> ulm: thanks for your work on glep 42
<dilfridge> I suggest that in any case improving PMS should be also considered
            as option.
<dilfridge> (Not just adapting code to current PMS.)
<K_F> dilfridge: certainly, improving PMS might very well be an outcome of
      mismatches                                                        [20:10]
<dilfridge> yeah, this is not clear from the text that I submitted.
<WilliamH> Which mismatches are we specifically talking about?
<dilfridge> All of them. :)
<K_F> the important thing is that the specs and reality matches, which one is
      out of sync will have to be discussed case by case
<blueness> dilfridge regarding point 3?
<dilfridge> well...                                                     [20:11]
<dilfridge> when we're talking about time frames,
<WilliamH> If we are talking about the multislot uselfag issue, kill it hard
           ;-)
<dilfridge> and deadlines,
<dilfridge> I would rather have a shorter deadline (say 6 months) with the
            proviso that anything planned to go into next EAPI is exempt
                                                                        [20:12]
<WilliamH> The slot variable should be a static string not dependent on a use
           flag.
<dilfridge> WilliamH: totally agree with you in that point
<blueness> can i suggest something, i think those points are too harsh, i’d
           like to track the mismatches between specs and package managers,
           but then deal with each mismatch on an ad hoc basis, because we can
           change PMS too
<blueness> we don’t want to throw out the baby with the bath wather
<blueness> water
<K_F> WilliamH: yeah, that one is likely the easiest to decide on
<K_F> blueness: exactly                                                 [20:13]
<floppym> I'm really not sure how a deadline could be applied generally.
<K_F> would need to be a case by case basis
<dilfridge> ok so let me try to re-write the three points
<floppym> It really depends on the nature of the mismatch and the people
          involved.
<blueness> if we find a mismatch, we may want to include the undocumented
           behavior in PMS rather than vice versa
<blueness> so it has to be ad hoc
<dilfridge> 1) All non-PMS-conformant behaviour should be considered a bug,
            and package / eclass / package manager / PMS maintainers should
            work together and to achieve consistent behaviour.          [20:14]
<jlec> If there is take me to solution then things are easy in case there's
       none we will have a problem
<jlec> *technical
<dilfridge> s/and to/and strive to/
<K_F> dilfridge: should it be specified .. bug (either in specs or
      implementation)                                                   [20:15]
<K_F> to avoid ambiguity?
<dilfridge> well, I left it open deliberately
<mgorny> i don't think we can put a generic rule for this
<mgorny> discouraging use of non-PMS compliant behavior if people don't even
         try to get it into PMS would be good though                    [20:16]
<K_F> mgorny: well that is just a general point, and in principle it is
      sound.. just that we need to go through case by case basis to see
      whether PMS needs updating or the behavior does..
<mgorny> i'd say for each behavior, there are three possibilities:
<dilfridge> 2) We encourage the creation of trackers to identify and collect
            non-PMS-conformant behaviour and propose fixes.
<mgorny> a. bad behavior, we deprecate and kill it; b. good behavior, we get
         it into future EAPI and encourage updating ebuilds, c. intended
         behavior, we get it into all EAPIs                             [20:17]
<dilfridge> yep
<blueness> mgorny: there is yet a fourth, an ambiguity in PMS specs which
           happens enough and also leads to discussion
<jlec> But that sounds like b                                           [20:18]
<K_F> well, either a or b depending on situation :)
<jlec> I was optimistic                                                 [20:19]
<blueness> i’m not sure they’re mutually exclusive, but we get different
           behaviours between paludis, portage, pkgcore and PMS specs
<jlec> That's a different thing. Ebuilds and eclasses should only depend on
       pms                                                              [20:20]
<blueness> because each will read PMS differently, we had that with
           =cat/pkg-2.* vs =cat/pkg-2*
<WilliamH> agreed
<jlec> That's what this is all about
<blueness> are we talking just ebuids/eclasses here?
<K_F> blueness: if there are other known issues I suggest we include them in
      scope                                                             [20:21]
<jlec> What else?
<K_F> blueness: but the specific ones that have already been brought up are
      ebuilds/eclass related
<blueness> if we’re just talking multislot that’s pretty much gone
<WilliamH> Aren't we  just talking about compliance with pms?
<xiaomiao> WilliamH: or PMS matching reality                            [20:22]
<dilfridge> 3) The council recognizes that historically there has been a lack
            of cooperation; there is however no current reason why that should
            continue. If in any specific issue no progress at all is reached
            within 6 months, finding the best technical solution is delegated
            to QA.
<K_F> dilfridge: finding the solution is delegated meaning they propose a
      solution for council vote or implement it directly?               [20:23]
<dilfridge> well, pms changes need to be approved by council
<dilfridge> ebuild changes need to be approved by maintainer
<dilfridge> qa can overrule maintainer but likely not council           [20:24]
<mgorny> yes, strictly speaking qa can override maintainer per the current
         rules
<mgorny> and the maintainer can appeal to the council if he disagrees
<blueness> dilfridge let me understand the politics here, are we just trying
           to make a policy cover future situations like multislot?
                                                                        [20:25]
<dilfridge> blueness: we're trying to get rid of a historical stalemate
<K_F> blueness: and/or investigate whether other mismatches exists
<WilliamH> As a member of qa I would mask the multislot use flag right now if
           I felt  comfortable doing it ;-)
<K_F> and indeed, setting a presedence for how to deal with it going forwards
      if one is detected (it is bound to in some way)                   [20:26]
<WilliamH> Masking the use flag is in the scope of qa as the rules are right
           now.
<floppym> WilliamH: Masking the use flag would not be helpful if use is fatal
          in global scope.
<dilfridge> blueness: basically, half of gentoo treating PMS as "the spec" and
            some of gentoo treating PMS as "that funny stuff imposed on us by
            ciaranm"
<dilfridge> so, to break out of this we need to 1) make sure reality and PMS
            agree, 2) make sure that it really is the definitive spec
                                                                        [20:27]
<mgorny> once you're done with the generic problem, we should probably decide
         how to proceed with multislot
<dilfridge> mgorny: I already have a headache.                          [20:28]
<K_F> my suggestion is no decision on single issue today
<dilfridge> just mask it(tm)
<blueness> dilfridge: thanks i misunderstood where this was coming from.  i
           don’t mind the specs lagging behind the package managers and
           ebuilds/eclasses, so let’s just say that bugs have to be opened
           where the specs don’t match either and these have to be dealt with
           in a timely fashion else it escalates to QA first and then the
           council
<K_F> each individual issue should be presented on a case-by case basis and
      discussed with pros and cons on ML before a vote
<WilliamH> K_F: that sounds reasonable. I do think we should open a tracker
           too though for the issues.                                   [20:29]
<K_F> WilliamH: yeah, and/or tracker
<floppym> I like the idea of a documented escalation process for these kind of
          issues; though I thouht we already had that.
<WilliamH> floppym: I think we basically do.                            [20:30]
<blueness> floppym: we have that
<blueness> its like anything else
<blueness> we’re not voting today, are we?                              [20:31]
<WilliamH> I don't think we are
<K_F> blueness: we can vote on procedure
<K_F> but I recommend not voting on a single issue
<dilfridge> no single issues
<blueness> ah okay, dilfridge can we consolidate your 3 points into one
           statement, I can suggest something if you like               [20:32]
<dilfridge> one moment
<blueness> dilfridge: take your time, i’ll wait for you
<WilliamH> wrt multislot, I have a better idea.                         [20:34]
<dilfridge> well, here's the combined text with only one small change
            (s/finding/proposing/):
<K_F> WilliamH: if we set up a discussion for it we can take it in tracker /
      ML perhaps?
<dilfridge> All non-PMS-conformant behaviour should be considered a bug, and
            package / eclass / package manager / PMS maintainers
<dilfridge> should work together and to achieve consistent behaviour. We
            encourage the creation of trackers to identify and
<dilfridge> collect non-PMS-conformant behaviour and propose fixes. The
            council recognizes that historically there has been a
<dilfridge> lack of cooperation; there is however no current reason why that
            should continue. If in any specific issue no progress
<dilfridge> at all is reached within 6 months, proposing the best technical
            solution is delegated to QA.
<mgorny> WilliamH: please talk about multislot separately               [20:35]
<WilliamH> mgorny: ok
<K_F> dilfridge: s/and to/in order to/ perhaps?
<blueness> dilfridge: that sounds fine, how do we promulgate that?  email
           gentoo-dev@g.o ?
<dilfridge> K_F: where?
<WilliamH> blueness: just send it to -dev and maybe -project?           [20:36]
<blueness> WilliamH: 1 sec, let’s get this language out of the way?
<K_F> dilfridge: "should work together and to achieve consistent behaviour."
<WilliamH> blueness: sure
<WilliamH> K_F: s/and to/to/
<K_F> that also works..
<blueness> how do people feel about this?  are we ready for a vote module the
           minor lanuage chagnes?                                       [20:37]
<dilfridge> wait
<dilfridge> new version:
<blueness> k
<dilfridge> ll non-PMS-conformant behaviour should be considered a bug, and
            package / eclass / package manager / PMS                    [20:38]
<dilfridge> maintainers should work together and strive to achieve consistent
            behaviour. We encourage the creation of
<dilfridge> trackers to identify and collect non-PMS-conformant behaviour and
            to propose fixes. The council recognizes
<dilfridge> that historically there has been a lack of cooperation; there is
            however no current reason why that should
<dilfridge> continue. If in any specific issue no progress at all is reached
            within 6 months, proposing the best
<dilfridge> technical solution is delegated to QA.
<jlec> 6 month means busy summer. I are we sure the time frame is good?
<dilfridge> (insert "A" at start)
<floppym> So the guts of this is the 6 month deadline. The rest is just
          reaffirmation of pretty obvious stuff.
<K_F> jlec: 6 months should be sufficient even with summer involved
<K_F> jlec: that is also just a deadlock limit, if there is progress it
      doesn't hit
<jlec> Mmh, okay                                                        [20:39]
<blueness> if people are acting in good faith, we can consider relaxing 6
           months for thorny issues
<jlec> Lgtm
<K_F> I'm fine with that statement
<blueness> i’m okay with the 6 month limit                              [20:40]
<blueness> are we ready for a vote, any other comments?
<K_F> I'm ready for vote                                                [20:41]
* jlec yes
<blueness> okay “The council moves to adopt the above policy”?
* blueness yes
* dilfridge yes
* WilliamH yes                                                          [20:42]
* K_F yes
* jlec yss
<floppym> I abstain.
<blueness> passes, 5 yeses, 1 abstain, 1 missing
<blueness> rich0: are you around?
<blueness> okay do we want to discussion multislot now?
<WilliamH> Here's my thought.                                           [20:43]
<K_F> that is just one of the other single issues, so it should be discussed
      in tracker bug for it and/or ML
<WilliamH> Let me open bugs on the issue assigned to maintainers and cc
           qa/council.
<blueness> go ahead, its slightl off agenda, but we have some time and we’ll
           have to discuss it sooner or later
<WilliamH> I'll ask the maintainers to remove the use flag.
<WilliamH> and add that if they do not qa / council has authorized its removal
           in 30 days.                                                  [20:44]
<K_F> that would require a vote
<mgorny> errr
<mgorny> but we already have a decision wrt multislot
<mgorny> and the discussion
<dilfridge> afaik long ago already there was a qa decision about multislot
<K_F> open the bug as part of tracker for the overall discussion        [20:45]
<WilliamH> hang on folks let me pull up something
<dilfridge> just noone pushed it through so far
<mgorny> last month council decided today's deadline for maintainers applying
         it
<blueness> mgorny: i haven’t looked but didn’t vapier remove multislot from
           toolchain.eclass?
<dilfridge> right :D
<mgorny> blueness: nah
<mgorny> but he proposed a patch
<blueness> never mind, just looked, its still there
<blueness> ah that’s what it was                                        [20:46]
<mgorny> so i wanted to suggest we just apply it or talk to him about applying
         it
<K_F> blueness: binutils was changed
<mgorny> blueness: you seemed to be against it
<WilliamH> K_F: what they are doing violates this:
           https://devmanual.gentoo.org/general-concepts/portage-cache/index.html
<mgorny> or did i understand your comment wrong?
<blueness> mgorny: not exactly gainst it, i was thinking a different approache
<blueness> he’s going to just turn multislot on always, i wanted it off always
<K_F> WilliamH: I'm aware.. there are still good ways and bad ways of
      enforcing it                                                      [20:47]
<blueness> but i can live with his solution
<K_F> WilliamH: and it has been around for so long, another few weeks isn't
      going to kill anyone, at least do it in a civil manner
* mgorny actually uses multislot, so on always sounds better to me
<WilliamH> I don't have a problem with it being on or off for everyone, just
           make a decision either way ;-)
<floppym> It's really up to toolchain how they want to slot it.
<blueness> mgorny: like i said, i can live with it on always
<mgorny> blueness: can you handle this as toolchain member?             [20:48]
<blueness> mgorny: i could but i alway defer to vapier
<WilliamH> The issue is that SLOT= can't be dynamic.
<blueness> let’s see if he’s just not going to do it, and if he isn’t then
           i’ll step in like i did with glibc
<floppym> WilliamH: I think we are all on the same page on the technical side.
<WilliamH> All I'm asking for is for them to make up their mind ;-)     [20:49]
<jlec> Guys, we don't need to discuss this. It needs to go and we know it.
<dilfridge> ++
<mgorny> blueness: could you then talk to him? i think he just needs a
         reminder/push/whatever
<WilliamH> either they do it in a reasonable amount of time or qa does it then
           they fix it without the use flag. :-)                        [20:50]
* WilliamH agrees with mgorny 
<blueness> mgorny: i can
<floppym> What's left on the agenda?
<blueness> okay guys, i think enough discussion on multislot, i’ll email
           vapier and say, let’s get it done!
<blueness> okay guys, i think we’re done here last item                 [20:51]
<blueness> Bugs with council involvement
           https://bugs.gentoo.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=IN_PROGRESS&email2=council%40gentoo.org&emailassigned_to2=1&emailcc2=1&emailreporter2=1&emailtype2=substring&list_id=3101194&query_format=advanced
* ulm is here
<ulm> floppym: just go on, I'm reading the backlog
<blueness> ulm: welcome!                                                [20:52]
<jlec> Don't kick him out
<jlec> He really did a good job
<K_F> I don't understand why council is involved in #575534
<blueness> okay 575534 is wierd                                         [20:53]
<blueness> lol!
<blueness> K_F: jinx
<blueness> okay let me take care of that one right now
<K_F> missing logs in two bugs, who chaired?                            [20:54]
<blueness> i’m going to ask that a3li and mgorny work it out between
           themselves before escaating
<floppym> For what its worth, I hate it when I get a degraded experience on
          mobile too.
<floppym> It's very annoying.
<floppym> (speaking generally, not just about our wiki)                 [20:55]
* mgorny has done enough random gentoo project and certainly isn't going to
  patch this nonsense
<K_F> dilfridge: seems both are yours :)
<dilfridge> :/ meh
<mgorny> and a3li is pretty much 'mgorny does not like it, so i'm going to
         ignore this'
*** viaCrucis (~scott@91.33.233.220.static.exetel.com.au) has joined channel
    #gentoo-council
* WilliamH isn't sure why that was assigned to council
<K_F> WilliamH: it shouldn't have been                                  [20:56]
<WilliamH> There's not a lot we can do there.
<blueness> mgorny: QA can mask the package if its bad enough!
<floppym> Is that a bad joke?
<jlec> Mask the wiki?                                                   [20:57]
* floppym masks bluness' sens of humor
<blueness> floppym: yes it is
<mgorny> well, the council is the entity which decides that wiki is the
         official doc channel
<WilliamH> mgorny: yes, but we didn't mandate anything about which wiki
           software to use etc.                                         [20:58]
<K_F> or triaging of bugs within infra
<blueness> what about bug #574952 mgorny what would you like us to do with
           that since games + QA have been at it for a while
<willikins> blueness: https://bugs.gentoo.org/574952 "Games team intentionally
            ignoring messages and bugs in order to stall QA and Council";
            Community Relations, Developer Relations; CONF; mgorny:comrel
<K_F> this is a regular bug report like any other
<mgorny> yes, www stuff is pretty much a3li deciding whatever he wants by
         himself and with no respect to other developers
<blueness> similarly bug #574080                                        [20:59]
<willikins> blueness: https://bugs.gentoo.org/574080 "games.eclass: Path
            customization needs to be removed wrt 20151213 Council meeting";
            Gentoo Linux, Eclasses and Profiles; CONF; mgorny:games
<mgorny> blueness: that's comrel problem, i'd say
<blueness> yeah
<mgorny> council CC-ed because it was involved and may want to track events
<mgorny> and/or be inquired
<floppym> mgorny: I think we can't really force a3li to implement something,
          but if you find someone else who can do the work we can stop him
          from blocking it if necessary.                                [21:00]
<a3li> wtf?!
<a3li> I said I accept your issue
<blueness> the a3li might escalate there, but let’s see
<blueness> i agree with trakcing the games stuff since its a big issue
<blueness> floppym: i was going to suggest something like that
<blueness> someone to supply a patch
<a3li> also, what's with the borderline slanderous comments mgorny is allowed
       to make her?!°
<blueness> a3li: i don’t like those comments either but can you and mgorny
           just stick to the technical issues wrt to that pkg           [21:01]
<a3li> that's very hard when I get shit shoveled at me at any occasion, you
       know
<blueness> a3li: i understand.  so just take a break from it and don’t think
           you’re isolated here.                                        [21:02]
<a3li> I'm not. I think someone else isolates himself with inane commentary
       atm.                                                             [21:03]
<K_F> in any case, I don't see any more for council to do with open bugs so
      propose we close today's meeting                                  [21:05]
<blueness> mgorny: still not sure how to proceed with the games stuff there
           are 3 bugs there with council involvement
<K_F> a3li: and yeah, I didn't like those comments either..
<blueness> K_F: open floor i have one quick announcement
<mgorny> well, the eclass is deprecated, i thnk
<mgorny> games team doesn't bother replying on the topic
<blueness> okay well continue with the stalement?                       [21:06]
<jlec> Then have QA set a deadline and remove it with all usages        [21:07]
<dilfridge> I guess all the deadlines are over anyway and it just needs
            someone to do the actual work.
<blueness> yeah
<ulm> right, maybe best if qa takes care of the technical issues        [21:08]
<mgorny> well, i wouldn't feel good rewritting packages maintained by games
         team for this
<blueness> mgorny: i’m going to bounce this back to QA to decide what do to
<mgorny> esp. that they didn't really approve any of it
<blueness> ulm: +1
<ulm> and avoid filing bugs with "games team intentionally ignoring ..." in
      the summary
<ulm> that's not going to lead anywhere
<blueness> ulm: +1 again, they’re just not listening
* WilliamH agrees
<K_F> blueness: I wouldn't outright listen to such statements either, tend to
      get the deaf ear..                                                [21:09]
<K_F> so yeah, keep the bug reports factual and neutral in nature
<WilliamH> agreed                                                       [21:10]
<K_F> in particular if involving council...
<mgorny> you could complain if they didn't admit it
<blueness> mgorny: maybe QA can create an overlay and move all the deprecated
           stuff there and then put the onus on games to move it back into the
           tree in a compliant fashion …  i know, its work!
<blueness> mgorny: ^^^ as K_F said, please try to avoid the ad hominems
<blueness> QA needs to be a policy force and at least appear neutral
<blueness> okay let’s move on, i don’t want to get mired in this        [21:11]
<blueness> final point i’ll comment on bug #568068 our decision today
<willikins> blueness: https://bugs.gentoo.org/568068 "GLEP 42: Define support
            for EAPI 5 dependency atoms in news items"; Doc Other, GLEP
            Changes; IN_P; floppym:glep
<blueness> anything else before opne floor
<blueness> okay open floor                                              [21:12]
<blueness> i have one annoucnement
<blueness> last council meeting we spoke about hasufell’s pkgs and work
<WilliamH> There already is a graveyard overlay I think; I don't know who
           maintains it.
<WilliamH> sorry go ahead blueness
<blueness> i’ve started a libressl project and we have dilfridge soap and zn2x
           (forget his nick!) on board                                  [21:13]
<K_F> I expect that to be zx2c4
<dilfridge> r2d2
<blueness> K_F: ty!
<floppym> Any long-term goal for that project? Are you aiming to replace
          openssl, or just provide a perpetual alternative?             [21:14]
<blueness> anyhow, we’ll have a plan for moving forward and we’ll at least
           inform the council
<blueness> floppym: the basic goal is two provide two system wide alternatives
<blueness> either you have an all libressl system or all openssl
<blueness> openssl will not be replaced in any way, just a permanent
           alternative                                                  [21:15]
<floppym> Ok. That's the safer route for sure; I was kind of hoping for a more
          entertaining conflict. :P
<blueness> two steps 1) getting it into the tree 2) provide support to
           maintainers who have packages that depend on openssl so we offset
           any extra work regarding abi mismatches
<blueness> floppym: lol no!
<blueness> floppym:  i think openssl has actually benefited from libressl just
           being an alternative                                         [21:16]
<blueness> anyhow, we’ll meet and report back
<K_F> blueness: sounds good
<floppym> Competition tends to spur innovation, yes.
<blueness> nothing else for now, just FYI
<blueness> floppym: that’s the idea!
<blueness> okay if theres nothign more we’re done!                      [21:17]
<K_F> thanks for chairing
<blueness> np
<blueness> oh crap … ulm  are you there?  did you log this?  can anyone send
           me the logs?
<ulm> floppym: thanks for proxying
<blueness> anyhow meeting over                                          [21:18]