Merge remote-tracking branch 'gitlab/wiki' into HEAD

1 files changed, 499 insertions, 0 deletions

diff --git a/wiki/Chat_log/20170510-mm-chatlog b/wiki/Chat_log/20170510-mm-chatlog
new file mode 100644
index 0000000..42ab2d7
--- /dev/null
+++ b/wiki/Chat_log/20170510-mm-chatlog
@@ -0,0 +1,499 @@
+Multimedia-chat-meeting-2017-05-10
+
+<dammsan> pinchartl: if you could distill some additional task candidates that
+	  would be great  [15:59]
+<dammsan> but it does not have to happen right now
+<pinchartl> that's topic 2 isn't it ? :-)
+<dammsan> good point =)
+<dammsan> nice that someone is awake at least  [16:00]
+<pinchartl> :-D
+<pinchartl> let's get started then
+<pinchartl> Topic 1. Status check for the multimedia tasks
+<pinchartl> jmondi: as you're the last one to have posted your status update,
+	    you can start  [16:01]
+<jmondi> that's fair
+<pinchartl> (not sure whether that will be a good enough incentive to get the
+	    reports earlier in the future, let's see)
+<jmondi> at least I can still go from the top of my head
+<jmondi> A)
+<jmondi> - Sent v3 of CEU driver  [16:02]
+<jmondi> - Working on Migo-R remote board to have CEU probe at least
+<jmondi> - trying to build a local test platform with RZ devices
+<jmondi> B)
+<jmondi> - I expect a lot of review comments on CEU driver
+<jmondi> - Have CEU probe on Migo-R  [16:03]
+<jmondi> - Have a test platform where I can at least run mainline and test the
+	 driver
+<jmondi> C  = D = None
+<jmondi> -- eot --
+<pinchartl> thank you  [16:04]
+<pinchartl> speaking of review comments
+<pinchartl> I'd like the rest of the team to feel free to cross-review patches
+<pinchartl> I certainly want to review them myself too
+<pinchartl> but there's no reason for me to be the only reviewer
+<neg> I agree, I will try to do more reviews in MM  [16:05]
+<pinchartl> neg: thank you
+<dammsan> question: Geert seems to have sent a patch to fix the sh7722 PFC
+	  issue, who can test and reply to him?
+<kbingham> Also agree here! - I've started with some of Negs ' :) - but that
+	   was easy becasuse I was looking at his patches directly.
+								        [16:06]
+<jmondi> dammsan:  I will
+<dammsan> great thanks
+<pinchartl> dammsan: I believe that Geert has tested the patches, but it's of
+	    course nice to double-check
+<pinchartl> jmondi: thank you
+<jmondi> I already planned to do so yesterday, but I failed to do so
+<dammsan> nice with a tested-by tag
+<pinchartl> uli___: as you're second last to have posted your status update,
+	    you're next :-)  [16:07]
+<uli___> fair enough :)
+<uli___> so i did a little stub driver for the max9260 using serdev
+<uli___> seems pretty straightforward
+<uli___> but it took me a while to figure out that the max9260 always talks
+	 uart on the controlling side  [16:08]
+<uli___> even though it is capable of both i2c and uart on the same pins
+<uli___> anyway, i got my hands on two chips, and i'll wire them up to the
+	 salvator-x board
+<uli___> and see that i can get it to talk
+<uli___> i have vays...  [16:09]
+<uli___> scnr
+<pinchartl> nice project
+<pinchartl> just out of curiosity, what's the MAX9260 package ?
+<uli___> tqfp
+<uli___> at least mine is
+<pinchartl> 0.65mm or 0.80mm ?
+<uli___> .65
+<pinchartl> that's on the verge of becoming painful  [16:10]
+<dammsan> uli___: any reason for not using remote access?
+<dammsan> if it is not working let me know  [16:11]
+<uli___> nothing wrong with it, i just dislike remote access.
+<neg> uli___: Do you mean that the max9260 only can be controlled using uart
+      in your setup or at all? Is it still capable of beeing controlled over
+      i2c if the hw around it where different?
+<uli___> dammsan: i'll try it eventually, of course, but i'd like to have
+	 something to yell at first  [16:12]
+<dammsan> ok ok
+<uli___> neg: on the local side (the one that sends the commands), it is
+	 always uart
+<uli___> but the link can be configured in both ways, and the other way
+	 around, it can talk either uart or i2c
+<pinchartl> uli___: are you (or do you plan to) use the serdev API ?  [16:13]
+<uli___> i do
+<neg> uli___: ahh I see, thanks for the clearification :-)
+<uli___> and then i intend to look at the gose vin dt thing  [16:15]
+<uli___> that's it for now
+<pinchartl> thank you
+<pinchartl> next in report order, Morimoto-san  [16:16]
+<morimoto> OK
+<morimoto> A) What have I done since last time
+<morimoto> - Finally Sound OF-graph DT which is needed for HDMI sound was
+	   accepted, but not yet applied, because of merge-window.
+<morimoto> - BSP team want to use AGL, and has issue on sound. I had worked
+	   with them. it seems AGL is using SMACK security, and it seems be
+	   reason of sound noise.
+<morimoto> - BSP team noticed 24bit sound data noise (not for AGL), and I'm
+	   helping for debugging. It seems related to HW issue, but not sure
+	   yet.
+<morimoto> - BSP team want to use ADSP on ALSA. We will have meeting with them
+	   tomorrow.
+<morimoto> B) What I plan to do till next time
+<morimoto> - Wait OF-graph DT applying. Then, post HDMI sound patch-set
+<morimoto> - post stalled patches (because of OF-graph) to ML
+<morimoto> - Help BSP team
+<morimoto> C) Problems I have currently
+<morimoto> D) Posted/Accepted bugfix patch
+<morimoto> No, sir
+<morimoto> --EOT--
+<pinchartl> thank you
+<pinchartl> looks like the BSP team always needs your help  [16:17]
+<pinchartl> you're becoming their super hero :-)
+<morimoto> pinchartl: Unfortunately
+<pinchartl> you have in your status report e-mail enquired about multiple work
+	    items, let's go through them  [16:18]
+<pinchartl> * Fence for VSP
+<pinchartl> this is not in my base task, as I have (at least temporarily)
+	    retired from V4L2 upstream development due to conflicts with the
+	    V4L2 maintainer
+<pinchartl> however
+<pinchartl> while I don't want to jinx it by making early announcements
+								        [16:19]
+<pinchartl> I hope to get confirmation at the end of the week that things will
+	    get moving forward in V4L2
+<pinchartl> with a setup of co-maintainers proposed to Mauro
+<pinchartl> please keep this information to yourselves for now  [16:20]
+<pinchartl> Mauro isn't aware of it yet
+<pinchartl> if it works out well, I will be able to go back to working on
+	    upstream MC and V4L2 APIs
+<neg> :-) (wish I could show a bigger smile over irc)  [16:21]
+<pinchartl> :-)
+<pinchartl> I don't expect things to be easy though, but there might be hope
+<morimoto> I don't understand detail of your V4L2 problem, but I hope
+	   everything goes to happy direction
+<pinchartl> morimoto: in a nutshell, the conflict between the V4L2 maintainer
+	    and me got so bad that I had to stop working on upstream V4L2
+								        [16:22]
+<pinchartl> because I had to stop interact with him at all
+<morimoto> him = Mauro ?
+<pinchartl> yes
+<morimoto> OK, so, this means Fence will be delay  [16:23]
+<morimoto> ?
+<pinchartl> in the best case, delayed. in the worst case, if we don't succeed
+	    moving forward on V4L2, it could be delayed undefinitely
+								        [16:24]
+<pinchartl> at least for upstream
+<pinchartl> s/undefinitely/infinitely/
+<pinchartl> fences support in V4L2 requires API extensions  [16:25]
+<pinchartl> and at this time I can't propose new API extensions
+<pinchartl> because the maintainer rejects all my proposals
+<morimoto> Wow !! very serious !
+<pinchartl> yes :-)  [16:26]
+<pinchartl> it's been going on for too long
+<pinchartl> so I've spent the last month or so to try and find a solution by
+	    discussing the problem with many other V4L2 developers
+<pinchartl> if all goes well we will propose something in the next few weeks
+								        [16:27]
+<morimoto> OK, nice to know
+<pinchartl> I'm sorry for the delay and inconvenience all this is causing, but
+	    there was no other option  [16:28]
+<pinchartl> * DU Fence is missing about asynchronous
+<pinchartl> I saw the e-mail you sent a few days ago, I'll investigate and
+	    reply to it soon
+<morimoto> Thank you
+<pinchartl> * Cache (DMA ATTR SKIP CPU) problem  [16:29]
+<pinchartl> it's on my to-do list for the next two weeks
+<pinchartl> I'll rebase the code
+<morimoto> Thanks
+<dammsan> may i interrupt about this topic?
+<pinchartl> dammsan: sure  [16:30]
+<dammsan> it seems to me that the DMA_ATTR_SKIP_CPU prototype patch is a local
+	  reaction to insufficient performance or R-Car Gen3
+<pinchartl> dammsan: partly
+<dammsan> however the root cause for this issue seems ignored
+<pinchartl> the root cause isn't ignored. we're moving forward with cache
+	    handling support in V4L2 and DRM  [16:31]
+<dammsan> at least i was told that the performance on Gen2 is different than
+	  Gen3 and because of that this patch was created
+<pinchartl> I started with the V4L2 side
+<pinchartl> Sakari took my latest patch series and posted a new version a few
+	    days ago
+<pinchartl> I plan to review it
+<dammsan> yeah ithink i know what the plan is
+<pinchartl> so we're moving forward with fixes for the root causes
+<dammsan> but i feel that randomly adjusting cache policy might not be the
+	  best solution
+<pinchartl> but in the meantime I think that using DMA_ATTR_SKIP_CPU makes
+	    sense
+<dammsan> do we know how the performance is affected?  [16:32]
+<pinchartl> yes
+<pinchartl> the issue is that
+<pinchartl> the VSP driver handles the cache
+<pinchartl> and performs a cache cleaning
+<pinchartl> while the memory is actually mapped uncached  [16:33]
+<pinchartl> so it makes sense to set DMA_ATTR_SKIP_CPU because the memory is
+	    always mapped uncached
+<dammsan> well, i can somewhat agree to that
+<dammsan> but i don't understand why this is needed on Gen3 and not on Gen2
+<pinchartl> this will need  to be revisited when we'll implement support for
+	    cached mappings in the DU driver
+<pinchartl> on Gen2 the buffers are allocated in the V4L2 framework  [16:34]
+<dammsan> of course the architecture has changed
+<pinchartl> sorry, I'm mixing two thinks
+<pinchartl> s/thinks/things/
+<pinchartl> on Gen2 DU doesn't use the VSP
+<dammsan> i just want to avoid papering over things
+<pinchartl> the VSP driver function where we need to set DMA_ATTR_SKIP_CPU
+	    isn't called at all on Gen2  [16:35]
+<dammsan> so this is for the DU?
+<pinchartl> yes it's for the DU
+<dammsan> ok
+<dammsan> and it is not needed with V4L2 VSP
+<dammsan> if so i'm ok
+<pinchartl> for V4L2 VSP buffers are handled by videobuf2 and we already do
+	    the right thing
+<dammsan> gotcha thanks  [16:36]
+<pinchartl> you're welcome
+<pinchartl> cache issues are always complex  [16:37]
+<pinchartl> * Request API
+<pinchartl> for the same reason as explained with fences support, I had to
+	    stop working on this upstream  [16:38]
+<pinchartl> I thus passed the project to Google
+<pinchartl> Alexandre Courbot (ex-NVidia, he now works for Google Japan) has
+	    taken over
+<pinchartl> I've had a few meetings with him to discuss the implementation
+<morimoto> Wow ! So, you don't work for "Request API" anymore ?  [16:39]
+<pinchartl> no I don't
+<pinchartl> I had to stop all V4L2 upstream API work  [16:40]
+<pinchartl> I've explained that before (about a month ago I think, or even a
+	    bit more)
+<pinchartl> but clearly not well enough as you're now surprised
+<pinchartl> I'm sorry about that
+<dammsan> i think i explained this to Morimoto-san before as well  [16:41]
+<morimoto> OK
+<dammsan> but we may have some language barrier
+<morimoto> Yes, I think so
+<morimoto> I'm sorry too
+<pinchartl> it's a very unfortunate situation and I did all I could to avoid
+	    it, but unfortunately all I could wasn't enough
+<pinchartl> but I didn't want to give up either, which is why I spent the last
+	    month trying to find a way to short-circuit the V4L2 maintainer
+								        [16:42]
+<pinchartl> again, I can't announce anything yet, but I hope to receive a
+	    confirmation by the end of this week that we'll propose a
+	    co-maintainer setup for V4L2
+<pinchartl> I don't expect Mauro to easily accept it though, but we're doing
+	    all we can to propose a gradual and smooth transition to maximize
+	    the chances he will accept  [16:43]
+<pinchartl> I should be able to tell more next week
+<pinchartl> and again, please don't share this outside of the team  [16:44]
+<pinchartl> * DU / VSP initialize sequence
+<pinchartl> on my to-do list for the next two weeks
+<pinchartl> I've already started looking into it, it needs a bit more work
+<morimoto> pinchartl: can I share this information to BSP team ?
+<pinchartl> you can share the problem, and tell them that we're working on
+	    trying to fix it, and that more information is expected by the end
+	    of this week  [16:45]
+<morimoto> OK, thanks
+<pinchartl> but please don't share the fact that we're trying to go for a
+	    co-maintainers setup
+<pinchartl> * VIN V4L2_FIELD_SEQ_TB/TB feature  [16:46]
+<pinchartl> neg: what's your plan ?
+<pinchartl> still on your to-do list, based on top of the Gen2 cleanup patches
+	    ?  [16:47]
+<neg> yes, was hoping to get the cleanups accepted first
+<pinchartl> is there anything blocking them beside lack of review ?
+<neg> nope
+<pinchartl> ok thank you
+<neg> as I undertood this was a low prio request, but if that changed I can
+      rescedule my plan for V4L2_FIELD_SEQ_TB/TB  [16:48]
+<pinchartl> I'll review them this afternoon. can you send me a pointer to the
+	    patches by e-mail so that I don't forget ? :-)
+<pinchartl> morimoto: what's the priority for V4L2_FIELD_SEQ_TB/TB ?
+<neg> sure will do, thanks
+<pinchartl> (and I assume it's actually V4L2_FIELD_SEQ_TB/BT, not
+	    V4L2_FIELD_SEQ_TB/TB)
+<morimoto> pinchartl: priority is not hi  [16:49]
+<morimoto> but want to have
+<pinchartl> ok. it's definitely on the to-do list
+<pinchartl> next, dammsan  [16:50]
+<morimoto> TB/TB <-> TB/BT. I'm shame ;)
+<pinchartl> (who should actually have been first, as he sent no status report
+	    at all ;-))  [16:51]
+<morimoto> OK, thanks.  [16:52]
+<morimoto> I will share these information with BSP team
+<pinchartl> seems we've lost dammsan
+<pinchartl> I'll go next in the meantime
+<pinchartl> I've reposted the Gen3 HDMI output DT integration patches  [16:53]
+<morimoto> Thanks. I will try it
+<pinchartl> and asked Simon to merge them when v4.12-rc1 will be released
+<pinchartl> I've provided a tag with the patchees
+<dammsan> pinchartl: no update here apart from getting Migo-R going
+<pinchartl> dammsan: thank you  [16:54]
+<pinchartl> now that you're back, I'd like to ask you if you have time for a 5
+	    minutes chat on IRC after this meeting ?
+<pinchartl> (continuing with my report)  [16:55]
+<pinchartl> I've started working on the DU / VSP initialization sequence
+								        [16:56]
+<pinchartl> I've also reviewed Wolfram and Niklas' proposal for the I2C
+	    software architecture for the multi-camera setup
+<dammsan> sure
+<pinchartl> (I'll reply to Wolfram's e-mail about that)  [16:57]
+<pinchartl> last but not least, I've spent a significant amount of time
+	    handling the fallout of the V4L2 conflicts
+<pinchartl> guiding Google with the request API development  [16:58]
+<pinchartl> and trying to find a solution to the human side of the problem
+	    with other V4L2 developers
+<pinchartl> for the next two weeks, I'll  [16:59]
+<pinchartl> - Look into the DU fence issue reported by the BSP team
+<pinchartl> - Cache (DMA ATTR SKIP CPU) performance issue with VSP2
+<pinchartl> - DU / VSP initialization sequence
+<pinchartl> and likely more (patch review hopefully)
+<pinchartl> that's it for me
+<pinchartl> this closes the first topic
+<kbingham> pinchartl: Not quite :)
+<kbingham> pinchartl: Not that I mind !
+<neg> I would also like to give my status report :-)
+<pinchartl> oops sorry :-/  [17:00]
+<morimoto> Hehe :)
+<pinchartl> I had copied your report in my summary e-mail already
+<pinchartl> so I thought you were done :-)
+<pinchartl> neg: you're next
+<morimoto> In this case, Japanese people uses "orz"
+<neg> A)
+<neg>  - [PATCH] v4l2-async: add subnotifier registration for subdevices
+<neg>  - [PATCH 0/2] media: entity: add operation to help map DT node to media
+      pad
+<neg>  - [PATCH v4 00/27] rcar-vin: Add Gen3 with media controller support
+<neg>  - [PATCH v6 0/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 support
+<neg>  - Meeting with Wolfram to discuss DT bindings for 8-ch setup devices.
+								        [17:01]
+<neg>  - Continued discussions about the ADV7482 with Kieran.
+<neg> B)
+<neg>  - Post v2 of incremental v4l2-async and DT node to media patches, work
+      done (available in rcar-vin-fwnode-test-3) just need to convince my self
+      with more testing before posting.
+<neg>  - Post new version of CSI-2 patches (work done (available in
+      rcar-vin-fwnode-test-3), more tests.
+<neg>  - Act on Sakaris comments on Gen3 VIN driver and repost.
+<neg> C)
+<neg>  - None
+<neg> D)
+<neg>  - None
+<neg> -- EOT --
+<pinchartl> thank you
+<morimoto> http://kage-design.com/i/orz1.jpg
+<pinchartl> morimoto: I'm working from a cafe this morning. if I did that I
+	    think people would look at me in a very weird way :-)  [17:02]
+<pinchartl> kbingham: you're last ;)à  [17:03]
+<pinchartl> s/;)à/:-)/
+<kbingham> Keeping mine quick, and not jsut copying the email - I've been
+	   working on ADV, which I feel is making good progress - the main
+	   topic at the moment is the async subdevs which need to be matched
+	   by the async framework. I'll be proposing a change to the matchings
+	   for this framework this week. - Otherwise - the ADV748x driver now
+	   has multiple subdevs to represent the entities.
+<kbingham> http://janet.linuxembedded.co.uk/board-salvator-mc.png shows the
+	   new layouts
+<kbingham> Of course Niklas has helped me with several parts of that - so
+	   thanks neg :)  [17:04]
+<kbingham> I've also been rebasing, reworking, and retesting my older
+	   patchsets - 3/5 of which are reposted and pull-requested.
+<kbingham> The last two caused me a bit more thought and hopefully will be
+	   done soon (partition algorithm work)
+<kbingham> Moving forwards over the next two weeks, I expect to see some good
+	   progress on the v4l2-async subdev matching proposal (which will
+	   require changing all the other users ... ugh) - and I hope that all
+	   my existing patchsets will be freshened with an aim for them
+	   getting closer to integration  [17:05]
+<kbingham> - eot -
+<pinchartl> thank you  [17:06]
+<pinchartl> jmondi: before I forgot, could you try to document the RZ camera
+	    hardware setup you're working on in the elinux.org wiki ?
+<pinchartl> s/forgot/forget/  [17:08]
+<pinchartl> now we're done with the first topic
+<pinchartl> Topic 2. Additional tasks for the second batch of Q2
+<pinchartl> dammsan: how would you like to handle this ?
+<pinchartl> we now have a working multi-camera setup  [17:09]
+<pinchartl> which you considered to be a blocker for the more general
+	    additional tasks that I proposed before
+<dammsan> right
+<dammsan> i'm ok with more generic tasks
+<dammsan> but we may have to adjust the outcome?
+<pinchartl> how do you mean ?  [17:10]
+<jmondi> pinchartl: as soon as I have something assembled together :)
+<pinchartl> jmondi: sure  [17:11]
+<pinchartl> dammsan: have you disappeared again ?  [17:12]
+<dammsan> nah i'm right here sorry  [17:13]
+<dammsan> i believe the old proposal included some fixed deliverables
+<dammsan> but now kieran is working on the ADV driver
+<dammsan> and we have slipped time wise
+<dammsan> so some update may be needed to reflect the current state  [17:14]
+<pinchartl> sure
+<pinchartl> what I propose is
+<pinchartl> - updating the plan to take new developments into account
+<pinchartl> - creating informal tasks based on the plan for the multi-camera
+	    development  [17:15]
+<pinchartl> - assigning those tasks to developers
+<pinchartl> - for those who would work on the multi-camera setup, going
+	    forward with the generic additional task
+<pinchartl> - for those who would work on other tasks, creating classic
+	    additional tasks  [17:16]
+<dammsan> sounds good to me
+<pinchartl> I believe you typed the SGTM line before my last item
+<dammsan> right, SGTM again =)  [17:17]
+<pinchartl> thank you :-)
+<pinchartl> so, I'd like to ask you all to provide me with a list of items not
+	    related to the VIN multi-camera setup that you think you should
+	    work on as additional tasks  [17:18]
+<pinchartl> that can be done on IRC or over e-mail
+<pinchartl> you can use periperi as a source of inspiration
+<pinchartl> and also propose other tasks  [17:19]
+<pinchartl> (such as V4L2_FIELD_SEQ_TB/BT for Niklas for instance)
+<pinchartl> what I'd like to get from this is a good idea of what you'd enjoy
+	    working on
+<pinchartl> I'll compile that into a proposal at the end of this week  [17:20]
+<dammsan> thanks
+<dammsan> if you can get the shared multi-camera task done soonish then i can
+	  review this week in the renesas office =)  [17:21]
+<dammsan> it is up to you
+<pinchartl> dammsan: I'll do my best but it will have to wait for tomorrow
+<dammsan> sure, no problem  [17:22]
+<pinchartl> thank you
+<pinchartl> this closes topic 2
+<pinchartl> Topic 3. OSS Japan trip
+<pinchartl> Magnus has been very nice and booked a meeting space for us
+								        [17:23]
+<pinchartl> https://www.airbnb.com/rooms/17013981
+<pinchartl> accommodation is also available there
+<pinchartl> how is everybody doing with accommodation ?
+* kbingham is very excited for the meeting place.
+<kbingham> dammsan: Good work on the meeting room :)
+<pinchartl> kbingham, neg, jmondi, do you all have a place to stay at a
+	    reasonable price ?
+<neg> I still have my original booking at conference hotel for 28th May  --
+      4th of Jun  [17:24]
+<kbingham> I think me and jmondi will have to share a room on the final
+	   Saturday night at the conference hotel.
+<jmondi> I've been able to reserve the conference hotel for the whole period
+	 at a rate very close to the LF proposed one
+<kbingham> I don't have a room for arrival - I need to find somewhere else
+	   cheap.
+<dammsan> kbingham: thanks, we'll se
+<dammsan> e how it goes  [17:25]
+<jmondi> execept for last day, where price is almost double, but I'll be
+	 sharing with kbingham (as he said)
+<pinchartl> ok
+<pinchartl> dammsan: will you be staying at the Taito-ku building ?
+<jmondi> I'm quite proud of my "hotel room reservation"-foo now.. I had to
+	 make 5 bookings to have the room at those rates :p
+<dammsan> pinchartl: i might do so  [17:26]
+<kbingham> morimoto: dammsan: Could you recommend anywhere (in location terms)
+	   that is good for a new arrival to Japan for lone-ranger sightseeing
+	   upon arrival the weekend before the conference?
+<pinchartl> we now need to work on the agenda for the meeting  [17:27]
+<pinchartl> I want to have time to do hacking all togther
+<pinchartl> but there will also be a more regular meeting
+<dammsan> kbingham: asakusa or shibuya or shinjuku?
+<pinchartl> so please reply to the meeting report with a list of topics you
+	    would like to discuss  [17:28]
+<pinchartl> and I will then draft the agenda
+<pinchartl> I haven't received any proposal for the Saturday after the
+	    conference  [17:29]
+<pinchartl> I can decide on something by myself, but I'd really appreciate if
+	    you could all take just a bit of time to tell me what you would
+	    enjoy seeing/doing  [17:30]
+* kbingham enjoys hiking - and seeing cultural / natural aspects.
+<pinchartl> I expect feedback from everybody else by e-mail :-)  [17:32]
+<neg> You will :-)
+<pinchartl> next and last topic, next meeting
+<pinchartl> two weeks from now is Wednesday 2017-05-24
+<pinchartl> that's the week before the face-to-face meeting
+<pinchartl> we could skip it, but I believe it would be useful to keep it, to
+	    avoid spending time face-to-face discussing about topic that can
+	    be handled during our regular bi-weekly meetings  [17:33]
+<kbingham> I agree..., and keeps the pace.
+<neg> I agree too try keeping it to the 2 week schedule
+<jmondi> agreed  [17:34]
+<pinchartl> and also to finalize the agenda
+<kbingham> The one following OSS might be worth slipping a week though,
+	   otherwise we will all just say "Went to japan"
+<pinchartl> so I propose two weeks from now, same time
+<neg> works for me
+<uli___> ok for me
+<jmondi> booked
+<kbingham> Ack.
+<pinchartl> thank you
+<pinchartl> that's it for today
+*** horms (~horms@217.111.208.18) has quit: Quit: Leaving
+<pinchartl> unless anyone has anything else to discuss, I propose adjourning
+	    the meeting  [17:35]
+<pinchartl> does anyone second ?
+<kbingham> Straight to thirded.
+*** horms (~horms@217.111.208.18) has joined channel #periperi
+<pinchartl> thank you all for attending, and have a nice day !
+<dammsan> thanks, you too
+<neg> thanks all, have a good day/evening
+<jmondi> see you, thanks!
+<uli___> bye
+<morimoto> Thanks
+ERC>