path: root/wiki/Chat_log/20180607-io-chatlog

09:03 < wsa_> Welcome to this IO meeting
09:03 < wsa_> first the status updates with a focus on the C) parts
09:03 < pinchartl> hello
09:04 < wsa_> A - what have I done since last time
09:04 < wsa_> ------------------------------------
09:04 < wsa_> Geert
09:04 < wsa_> : upported R-Car M3-N HSCIF support (incl. PFC), discovered SCIF work_tx race condition,
09:04 < wsa_>   discussed MSIOF related BSP patch about DMA
09:04 < wsa_> Kaneko-san
09:04 < wsa_> : posted M3-W PCIE support
09:04 < wsa_> Marek
09:04 < wsa_> : has posted multiple iterations of PCIE fixes, with success
09:04 < wsa_> Niklas
09:04 < wsa_> : sent out two SDHI related patch series (tuning behaviour and reset procedure),
09:04 < wsa_>   retested SDIO on Koelsch (still fails, but a step later now)
09:04 < wsa_> Shimoda-san
09:04 < wsa_> : further investigated USB susped/resume issue, sent out new versions for USB role switch feature,
09:04 < wsa_>   upstreamed USB for E3, and communicated various issue from the BSP team to us
09:04 < wsa_> Simon
09:04 < wsa_> : began reworking HS400 patches as per Ulf's feedback
09:04 < wsa_> Wolfram
09:04 < wsa_> : discussed various items and implemented proposed solutions (SDHI WP regression, I2C DMA RX handling,
09:04 < wsa_>   I2C recovery flaw), upported SDHI DATA_STROBE and faster I2C speed patches, discussed periject tool,
09:04 < wsa_>   added new fault injector to i2c-gpio, proposed new QEMU I2C passthrough sketch to Magnus,
09:04 < wsa_>   various patch review and some backporting assistance, prepared travel to Japan
09:04 < wsa_> B - what I want to do until next time
09:04 < wsa_> -------------------------------------
09:04 < wsa_> Geert
09:04 < wsa_> : wants to fix the SCIF work_tx issue
09:04 < wsa_> Kaneko-san
09:04 < wsa_> : wants to continue upporting M3-W and M3-N PCIE support
09:04 < wsa_> Niklas
09:04 < wsa_> : wants to keep upporting SDHI and keep at SDIO testing if time allows
09:04 < wsa_> Shimoda-san
09:04 < wsa_> : wants to keep at the USB role switch patches, continue to plan for GPIO PHY support for E3,
09:04 < wsa_>   learn about KVM and USB virtualization
09:04 < wsa_> Simon
09:04 < wsa_> : wants to continue HS400 upstreaming activity
09:04 < wsa_> Wolfram
09:04 < wsa_> : wants to continue the above discussions, prepare the talk for ALS18, continue
09:04 < wsa_>   SPDX conversion for Renesas drivers, start implementing QEMU solution (f Magnus
09:04 < wsa_>   agrees)
09:04 < wsa_> C - problems I currently have
09:04 < wsa_> -----------------------------
09:04 < wsa_> Niklas
09:04 < wsa_> : is still waiting for Gen3 thermal fuses
09:04 < wsa_> Shimoda-san
09:04 < wsa_> : has to struggle with microB connector on E3 Ebisu instead of microAB
09:04 < wsa_> Simon
09:04 < wsa_> : wants to discuss how to handle different HS400 versions on Gen3
09:04 < wsa_> Wolfram
09:04 < wsa_> : is travelling until after next meeting, so has no direct HW access
09:05 < wsa_> neg: yes, well, I have it in the IO todo file, so it won't be forgotten. I guess no need to wait bi-weekly for it :/
09:06 < wsa_> shimoda: well, not much we can do with the "wrong" connector, or? :)
09:06 < wsa_> horms: so far, I'd think the 0,4,8-tap decision is per-SoC only
09:06 < horms> wsa_: agreed
09:06 < neg> wsa_: check, will drop it from future status updates
09:07 < wsa_> I wonder if such a thing will change from one ES to another?
09:07 < wsa_> does JapaPERI have an idea?
09:07 < horms> My question is like this
09:07 < horms> Currently its between SoCs
09:07 < horms> and traditionally we handled such differences via the compat string
09:07 < horms> which may well be the cleanest option here
09:07 < horms> but it may be also possible to use soc_match
09:08 < neg> horms: in BSP there is a define HS400_USE_4TAP and bsp commit ce12154b826b955b6439546014870d038eff19ce seems to indicate this might be per SoC
09:08 < horms> Keep in mind that the per-SOC compat strings are more or less unimplemented for Gen3 SoCs in the SDHI driver at this time
09:08 < geertu> If there's no need to check for SoC revision, IMHO using the compat string is the easiest.
09:08 < wsa_> I'd agree with geertu
09:08 < horms> ok, let me do that then
09:09 < horms> no objection from my side
09:09 < wsa_> we can switch to soc_device_match when needed`
09:09 < wsa_> ?
09:09 < geertu> If you store (a pointer to) the features in soc_device_id.data, it's easy to retrieve.
09:09 < horms> yes, if its an implementation detail that should be possible
09:09 < horms> geertu: ok, thanks
09:10 < shimoda> wsa_: correct. i cannot development with the wrong connector. So, i intend to use DIP-SW gpio instead of actual ID signal to develop :)
09:10 < geertu> If a SoC revision check is needed later, it can be easily handled by taking the (pointer to) the features) from soc_device_match()->data
09:10 < wsa_> shimoda: role-DIP-switch, nice :D
09:11 < Marex> shimoda: can't you use hotair and replace the connector ? :)
09:11 < geertu> horms: drivers/media/platform/rcar-vin/rcar-core.c is a nice example:
09:11 < geertu>         vin->info = of_device_get_match_data(&pdev->dev);
09:11 < geertu>         attr = soc_device_match(r8a7795es1);
09:11 < geertu>         if (attr)
09:11 < geertu>                 vin->info = attr->data;
09:12 < wsa_> so, with me being on the road already...
09:12 < shimoda> wsa_: :D
09:12 < wsa_> dammsan: can you give me remote access to H3 ES2.0 Salvator-XS? So, I can check stuff remote at least
09:13 < shimoda> Marex: it's difficult to me (my skill and Renesas office rule)
09:13 < horms> geertu: I am confused now. I see that is an exmple of using soc_device_match. And indeed there are already examples in the SDHI driver. But I thought that we decided to use compat strings for the case in question?
09:13 < geertu> horms: You can start with of_device_get_match_data()
09:14 < Marex> shimoda: ah :)
09:14 < geertu> If needed later, you add the next 3 lines enabling soc_device_match(), but needing no further driver logic change
09:14 < horms> Oh, I see. Very nice.
09:15 < wsa_> So, anything more from your side about the status updates?
09:16 < Marex> wsa_: PCIe32 got one reply !
09:16 < wsa_> \o/
09:16 < Marex> wsa_: and I keep resubmitting DA9063L patchset
09:17 < wsa_> Maybe some of the ARM core people are in Tokyo? It seems fastest to me to poke them personally, or get the right group together there...
09:17 < Marex> wsa_: let's see what happens at OSSJ ?
09:18 < Marex> wsa_: although, I doubt that
09:18 < wsa_> I share that feeling, but let's hope a bit...
09:18 < wsa_> okay, for the topic, there is only "add. tasks" from my side
09:18 < wsa_> although there is not much change for the IO group
09:19 < wsa_> pinchartl: notification for you :)
09:19 < wsa_> the focus is still on upporting and we should have increased base time for that
09:19 < wsa_> I'll contact you about upporting individually
09:19 < pinchartl> wsa_: I'm here :-)
09:20 < pinchartl> dammsan: ping
09:20 < pinchartl> we're missing Morimoto-san
09:20 < pinchartl> kbingham: ping
09:20 < wsa_> Add. tasks are possible on request which then are discussed by Renesas
09:20 < dammsan> wsa_: port 9006 is yours
09:20 < wsa_> but no request was made to me, and I don't see one urgent in my list
09:20 < wsa_> dammsan: thanks!
09:21 < kbingham> hola
09:21 < dammsan> pinchartl: whatsup?
09:21 < wsa_> so, doesn't look like add. tasks for IO
09:22 < shimoda> pinchartl: Morimoto-san has a trouble about his PC network setting on Ubuntu 18 :)
09:22 < wsa_> dammsan: unless there is something new I don't know up to now? :)
09:22 < pinchartl> dammsan: Wolfram mentioned additional tasks
09:22 < pinchartl> I requested that to be added to the agenda
09:22 < pinchartl> as this topic concerns all groups, should we discuss it now ?
09:23 < wsa_> Frankly, I am more interested in the base time distribution again
09:23 < dammsan> sure what do you want to know?
09:24 < pinchartl> dammsan: I want to know how we can get additional tasks working
09:24 < pinchartl> as in scheduled in time
09:24 < wsa_> horms: I assume you are so busy backporting LTSI that ravb upporting had to stand back?
09:24 < pinchartl> and not repeat the Q2.2 fiasco
09:24 < dammsan> well i think we need to do two things:
09:24 < pinchartl> we've had a lengthy e-mail discussion but that wasn't public, so I'd like to broaden the audience as I don't think I'm the only one to be bothered by this
09:24 < dammsan> 1) agree on quarterly schedule for meeting dates and additional due dates first
09:25 < horms> wsa_: correct
09:25 < shimoda> wsa_: after discuss about add. task, I'd like to ask you about i2c recovery. Did you see any issues (e.g. write data to a slave wronglty) on your R-Car environment?
09:25 < dammsan> 2) do task break out ahead of time
09:25 < horms> wsa_: also, I think that the ravb backporting is a very low yeild exercise
09:25 < dammsan> pinchartl: who else is bothered?
09:25 < pinchartl> kbingham: the mic is yours :-)
09:26  * kbingham has just about caught up wit hthe mornings mails ...
09:26 < pinchartl> who thinks additional tasks work just fine, and who tihnk they don't ?
09:26 < pinchartl> s/tihnk/thinks/
09:26 < wsa_> shimoda: sure!
09:26 < kbingham> dammsan, I agree where you said this needs an F2F ... and fortunately one is coming up :)
09:26 < kbingham> Lets make sure we have time :)
09:26 < wsa_> horms: "low yield" means most patches are not suitable for upstream?
09:26 < dammsan> unfortunately not all members are present
09:27 < geertu> Personally, I've never been a big fan of additional tasks.
09:27 < horms> wsa_: yes, I think so
09:27 < horms> But I'll go over them again
09:27 < kbingham> Essentially - for me  -the *big* problem is the 'rigid square wave workload' which it causes me.
09:27 < pinchartl> I've never been a big fan of additional tasks either. they were a minor nuisance when they were introduced, but they got more and more annoying over time as they got split in two batches per quarter, and we always got late negotiating them
09:28 < wsa_> "square wave workload" :D
09:28 < kbingham> But in particular - where the due dates are fixed, but tasks are always started late.
09:28 < kbingham> I realise that this last AT is a bit of a special case - but my concerns with planning have started long before.
09:28 < uli___> if i may weigh in: i like that additional tasks tell me what to do; i'm not a self-starter when it comes to work...
09:29 < uli___> the contractual framework is secondary to me
09:29 < kbingham> And it's just this one has been a cliff-edge drop for me :(
09:29 < geertu> kbingham: One very important thing to consider is that this is a prototype
09:29 < dammsan> so historically they were created to allow lower latency operation for our group
09:29 < geertu> which means many more unknowns than "normal" additional tasks
09:30 < dammsan> as opposed to have all the fixed tasks agreed on 3 months ahead
09:30 < pinchartl> dammsan: they have created a much higher latency
09:30 < geertu> IMHO they increase latency.
09:30 < dammsan> sure
09:30 < dammsan> but how can we keep the quality and perform development (not single patch wanking) and reduce paper work?
09:30 < geertu> If something is urgent, there may not be any base time available at that moment, as ATs have a fixed deadline, and thus preempt any base work
09:31 < kbingham> uli___, I also like that an AT specifies what to do - but in the latest case - that didn't happen - until it was too late for me to realistically be able to deliver that.
09:31 < pinchartl> in my opinion, they only advantage in additional tasks, and the reason why they have been introduced, is to give a stick to Renesas to hit developers who don't deliver. with fixed deliverables and fixed due dates the work has to be completed, no excuse
09:31 < pinchartl> apart from that I see no use for additional tasks
09:32 -!- morimoto [~user@relprex2.renesas.com] has joined #periperi
09:32 < geertu> An AT deadline around the closing of a maintainer's merge window causes patches to be delayed by one kernel release.
09:32 < geertu> pinchartl: +1
09:32 < wsa_> horms: if you could add what you currently know to the periupport list? so, we at least know which patches to "drop"
09:32 < dammsan> so we have been discussing dropping AT before
09:33 < dammsan> but at that point i requested some way to get plans from the group leaders
09:33 < horms> wsa_: sure, sorry for not having already done that
09:33 < pinchartl> dammsan: we can reduce paperwork and increase quality by dropping additional tasks completely and measuring performances to make sure we don't slow down (or even sleep)
09:33 < dammsan> this was last year i recall
09:33 < pinchartl> alternatively, we can keep fixed-price, fixed-term tasks, but with a higher latency. they *have* to be negotiated in advance
09:33 < dammsan> it is not a matter of increasing speed
09:34 < pinchartl> that is a contract has to be signed at least 2 months before the due date
09:34 < dammsan> it is a matter of improving visibility and communication
09:34 < jmondi> toothless jmondi's here
09:35 < dammsan> i will ask renesas if they can start considering 2 month delay
09:35 < dammsan> it is perfect for the last quarter of this year
09:35 < pinchartl> if the goal is to improve visibility and communication, then let's focus on that
09:35 < dammsan> until that time perhaps it is best that we drop additional tasks all together? =)
09:36 < dammsan> please note that some pipe lining is required
09:36 < pinchartl> dammsan: and I will also say that I agree we need to measure performances
09:36 < dammsan> one thing is the performance
09:36 < dammsan> another thing is to agree on what to do
09:37 < dammsan> i would like to have both
09:37 < kbingham> I'd like to not have high pressure workloads with short timescales :D
09:37 < dammsan> sure
09:37 < kbingham> I'd go join a tiger team if I wanted that ;D
09:38 < dammsan> but tell me how your 5 weeks can be split onto the existing slots
09:38 < neg> That is what I like about additional contracts, it provieds me with a clear channel from Renesas on what new task/feature is moste valuable for them and therefor I should focus on it.
09:38 < pinchartl> neg: I can only agree partially to that
09:39 < pinchartl> we are tasked with proposing additional tasks
09:39 < Marex> I have to admit, I like my kinda-free reign over U-Boot, since I can focus on doing what needs to be done when it needs to be done
09:39 < pinchartl> without being told what Renesas needs
09:39 < Marex> but maybe Im wrong :)
09:39 < pinchartl> so we try to guess
09:39 < kbingham> Marex, Do you not have additional tasks ?
09:39 < pinchartl> and then we are either told that the guess was right
09:39 < dammsan> he does but he prefers not to consume them
09:39 < pinchartl> or that it was wrong, in which case we are asked to guess again
09:39 < Marex> kbingham: I do, but I can live with that
09:40 < dammsan> what a nice fellow =)
09:40 < pinchartl> neg: I don't count that as being told by Renesas what is valuable for them :-)
09:40 < dammsan> pincharl: you seem to think the content of the bsp up porting list is enough
09:41 < neg> pinchartl: agreed, sometime the planing and late scheduling/decision point for a add. task is messy and creates higher workload. All I'm saying is that for me the task once scheduled provieds value
09:41 < pinchartl> Marex: I think most of us would like to focus on what needs to be done when it needs to be done, with additional inputs from Renesas when they have specific urgent needs
09:42 < dammsan> so may i ask if fixing the quarterly dates ahead of time has any drawback?
09:42 < kbingham> dammsan, What benefit are you addding with fixed dates...
09:42 < dammsan> i am not saying it solves all the problems
09:42 < pinchartl> dammsan: do you mean the Q2.1 and Q2.2 due dates, as in Q+1.5 and Q+2.5 ?
09:42 < kbingham> the 'due dates' are already predictable ...
09:42 < dammsan> this means we are clear about the dates
09:43 < dammsan> yes and meeting dates for chat meetings
09:43 < dammsan> if we agree on these ahead of time
09:43 < pinchartl> kbingham: the due dates are not just predictable, they are fixed :-)
09:43 < dammsan> and yet we fail to schedule tasks, then we won't schedule any tasks
09:43 < kbingham> :)
09:43 < pinchartl> dammsan: but we have already agreed, haven't we ?
09:44 < dammsan> i thought we had agreed to the AT due dates somehow
09:44 < dammsan> but yet it seems that the discussion of no time available and conference timing seems to happen again and again =)
09:44 < geertu> dammsan: Agreed as in: yes, let's use the dates Jinso needs the deliverables?
09:44 < dammsan> so if we know ahead of time..
09:44 < pinchartl> dammsan: no, the problem isn't conference timing, the problem is late scheduling
09:45 < kbingham> If I'm going to 'lose' 3 weeks of work - then I need to know in advance - so I can find another three weeks of work to fill that time. Or Hugo losses his college fund!
09:45 < pinchartl> conferences and other events happen from time to time
09:45 < pinchartl> I can handle them by myself
09:45 < dammsan> kbingham: sure understood
09:45 < pinchartl> if you give me 3 weeks of work 6 weeks ahead of the due date
09:45 < pinchartl> I'll work around the conference that happens during those 6 weeks
09:45 < dammsan> makes sense
09:45 < pinchartl> if you give me 3 weeks of work 3 weeks ahead of the due date, that won't be possible
09:45 < geertu> pinchartl: Now, if you have 2x3 weeks of AT...
09:46 < pinchartl> and that's what is happening all the time
09:46 < pinchartl> in the best case we get the AT for 3 weeks of work 3 weeks ahead of the due date...
09:46 < dammsan> that seems to be because we don't do bre
09:46 < pinchartl> sometimes it's even later
09:46 < wsa_> kbingham: Hugo should be a rich kernel developer at college time, or? ;)
09:46 < dammsan> akout early enough
09:47 < kbingham> wsa_, I'm hoping he'll be a kernel developer at primary school :D
09:47 < pinchartl> dammsan: what do you mean by not breaking out early enough ?
09:47 < dammsan> well
09:47 < dammsan> for instance this virtualization topic
09:47 < dammsan> i wish we could meet and discuss how to proceed with that
09:47 < dammsan> now we have not met so much recently
09:47 < dammsan> and when we met in san sebastian the purpose seemed more to be for hacking than planning
09:48 < dammsan> i would like to meet with group leaders (+ others maybe) to do some planning
09:48 < pinchartl> I don't think we could have planned work for Q2 2018 in detail in San Sebastien
09:48 < pinchartl> there are various ways to meet, face to face or online
09:48 < kbingham> dammsan, I get that it was a communications issue - but in the Virt task - I was only told  that *I* was supposed to write the task descriptoin - well after the point at which I would have expected to start the task - - hence for me - it's just impossible to fit in to a schedule in this current instance.
09:49 < dammsan> ok but i got the impression that you wanted to do the task?
09:49 < dammsan> i was pleasantly surprised that you signed up =)
09:49 < dammsan> obviously it was a too big jump
09:49 < pinchartl> dammsan: in general I think most of us are willing to help with work that is considered to be important by Renesas or you
09:49 < pinchartl> that shouldn't be a surprise :-)
09:49 < geertu> Exactly.
09:50 < dammsan> sure
09:50 < dammsan> i feel that
09:50 < dammsan> thanks for your help
09:50 < geertu> kbingham: You should have had some idea of what the task as about when volunteering, right?
09:50 < dammsan> but how to plan?
09:50 < dammsan> (and break out)
09:50 < kbingham> I knew very little about the task.
09:50 < dammsan> (that makes you the brave man in the room) =)
09:51 < kbingham> We are trying to hunt in the dark for tasks to fit into slots.
09:51 < kbingham> From my perspective - laurent said that dammsan wants us to look into virtualisatoin topics ...
09:51 < dammsan> sorry for being unclear
09:51 < kbingham> And thus I was expeting a virt topic to fill my available slots
09:51 < kbingham> However - I was expecting it to have been planned early - and be clear so that I could ramp up
09:52 < dammsan> but we had not done enough break out
09:52 < dammsan> also i feel we are moving slowly
09:52 < dammsan> probably due to lack of resources
09:52 < kbingham> I don't even mind if it would take me longer than the available time slots to do the investigation / self learning / and ramp up - but for that to happen -
09:52 < kbingham> the task *must start weeeeeellll in advance*
09:52 < dammsan> i would love to ask geertu to focus on virt activities
09:53 < dammsan> but without AT i feel i cannot request stuff
09:53 < kbingham> I see AT time slots as time slots that I reserve in my planning for to allow Renesas to fill with tasks.
09:53 < kbingham> But they can't be booked or not booked with zero notice.
09:53 < dammsan> kbingham: that view makes sense
09:54 < dammsan> but the default IMO is unbooked unless otherwise agreed
09:54 < horms> dammsan: when you say break out, do you mean you think it would help if there were more face-to-face meetings between say yourself and group leaders?
09:54 < dammsan> horms: yes
09:54 < dammsan> thank you
09:54 < horms> ok, I see a farily obvious way to see if that helps
09:54 < pinchartl> dammsan: unbooked unless otherwise agreed isn't something I can agree on as long as we book at the last minute
09:55 < pinchartl> if you want that, then I want to be booked 3 months in advance
09:55 < kbingham> So I should assume that 6/12 weeks of my time are not scheduled - and find another customer to fill that time ?
09:55 < pinchartl> as Kieran said in an e-mail, you don't expect to call a builder for your house and have him show up the next morning
09:55 < dammsan> sure, that fits perfectly fine with current budget situation =)
09:56 < kbingham> Ok - if we have budget restrictions - can we be clear about that!?
09:56 < pinchartl> there were no budget restrictions for Q2, were there ?
09:56 < dammsan> sorry if that has not communicated enough
09:56 < dammsan> but ATs are not guaranteed to be filled
09:56 < pinchartl> dammsan: it has been communicated badly, as in "beware of the big bad wolf"
09:57 < dammsan> never has been, and they are getting closer to be more sparse if budget is going bad
09:57 < kbingham> (beware, followed by - but don't go away)
09:57 < dammsan> well
09:57 < dammsan> it was actually my proposal to renesas side to tell you in advance
09:57 < dammsan> before you signed your base contracts
09:57 < dammsan> that budget is looking bad
09:57 < dammsan> so you should look into other options if you want to sustain
09:58 < neg> I think the budget situation have been communicated and also that there are possibilities that not all additional task slots will be used. Is this not why the base time was adjusted?
09:58 < dammsan> of course i want to work to with you
09:58 < dammsan> neg: yes
09:58 < dammsan> but i can't control our budget
09:58 < kbingham> Ok - but if AT's are not to be filled - they need to be filled with something else
09:58 < dammsan> especially if i can't make plans to show to renesas side
09:58 < kbingham> and tha'ts not possible - if the AT  is filled at the last minute
09:59 < pinchartl> dammsan: why have additional tasks for Q2.2 not been scheduled in time, as there was no budget restriction for that period ?
09:59 < dammsan> kbingham: we seem to have different ideas how the contracts work
10:00 < kbingham> dammsan, I agree :)
10:00 < dammsan> what says that there was no budget restriction that period?
10:00 < dammsan> i was asked to reduce cost
10:00 < dammsan> i asked to reduce travel
10:00 < dammsan> did not to to EU
10:00 < dammsan> now if other members ask renesas directly
10:01 < dammsan> and they change their mind over a week
10:01 < dammsan> then it is not my problem
10:01 < kbingham> It's a shame you could not come to EU brussels - as it would have been good to do F2F then... :(
10:01 < dammsan> i agree
10:01 < pinchartl> dammsan: when we discussed additional tasks for Q2.2 there was no budget issue that was brought up, and tasks were agreed on to fill slots (but too late to be completed on time)
10:02 < dammsan> i have no intention to reduce the slots just for the sake of it
10:02 < dammsan> but we need to know what to do before doing it
10:02 < dammsan> and like my old fried paul said
10:02 < dammsan> you don't pay contractors to learn
10:02 < dammsan> you pay contractors to do what they are good at
10:03 < dammsan> of course some ramp up time is needed
10:03 < dammsan> and acceptable
10:03 < dammsan> but either you can do what you say
10:03 < dammsan> or you cant
10:03 < kbingham> dammsan, I actually agree on that -
10:03 < dammsan> and if we cant agree before the due date
10:03 < dammsan> too bad
10:03 < kbingham> That's why I expected the virt work to be planned well in advance :)
10:03 < dammsan> sure
10:04 < dammsan> so we had a some kerfuffle there
10:04 < dammsan> and in general when it comes to task break out and planning that may happen
10:04 < dammsan> probably my fault as usual
10:04 < dammsan> =(
10:04 < dammsan> but i stand by that we need to know before we do it
10:04 < pinchartl> it's not that it may happen, it happens all the time :-( that's for me a clear indication that the process is wrong
10:05 < dammsan> sure
10:05 < dammsan> but ive asked for plans forever
10:05 < dammsan> i would like to improve the situation
10:05 < pinchartl> I can't make a plan without being able to allocate resources
10:05 < dammsan> well
10:05 < pinchartl> I can't say what we'll do and when we'll do it if I'm not given a predictable amount of development time
10:05 < kbingham> I think we're well in to the territory of best discussed F2F :)
10:06 < kbingham> which is conveniently in 2 weeks or less.
10:06 < dammsan> i would like to separate assignment from planning
10:06 < dammsan> also time required from planning
10:06 < dammsan> only focus on break out and dependencies
10:06 < dammsan> i would like to discuss this with group leaders
10:06 < dammsan> ahead of time
10:07 < dammsan> then from the result of that activity feed AT and base work
10:07 < dammsan> if we manage to move forward with base only then we can skip AT
10:07 < dammsan> but dropping AT without any plans seems insane to me
10:08 < dammsan> kbingham: sorry that it became a mess
10:08 < pinchartl> so how do we move forward ?
10:08 < dammsan> how can we proceed?
10:09 < dammsan> i proposed my two ideas to improve the planning
10:09 < pinchartl> my requirement is that anything with a fixed due date has to be scheduled (as in contracts signed) at due date - max(2 * duration, duration + 2 weeks)
10:09 < dammsan> dates ahead of time + separate planning and breakout
10:09 < pinchartl> (the numbers can be fine-tuned
10:09 < dammsan> pinchartl: i want to agree as early as you
10:10 < dammsan> but we need to work together to break out stuff
10:10 < dammsan> and say that we are late
10:10 < dammsan> what happens then?
10:10 < dammsan> i don't want to be late
10:10 < dammsan> but if we end up there anyway?
10:10 < pinchartl> if you remember, I initially proposed a long list of tasks, and most got rejected with "this should be base time" or "this isn't a priority". I was then suppose to magically come up with new ides
10:11 < dammsan> also, crossi
10:11 < dammsan> ng quarterly boundaries is difficult
10:11 < dammsan> pinchartl: sorry if i made you feel rejected
10:11 < pinchartl> if we always end up being late we'll reach a point where stress and frustration will be so high that we'll lose developers completely. it won't just be a matter of some slots not being filled, people will go away
10:12 < dammsan> i understand. that's no good
10:12 < dammsan> but lets agree on a view with the contracts
10:12 < dammsan> no contract means no agreement
10:12 < dammsan> when it comes to assigned work
10:12 < pinchartl> if Renesas prefer stopping upstream development and only release BSPs, I won't stop them
10:13 < dammsan> well
10:13 < dammsan> if renesas can chose by themselves then we all have been reduced to up-porting machines
10:13 < dammsan> so no development on the horizon there no
10:13 < pinchartl> I'm sure they can find plenty of cheap developers who can write bad code
10:13 < dammsan> yep
10:13 < dammsan> we agree on that
10:13 < dammsan> so question is how to remedy that situation
10:14 < dammsan> without leaving people in a bad situation
10:14 < dammsan> also
10:14 < pinchartl> and if they prefer going that way, I have no issue making sure those bad patches won't make it to mainline
10:14 < dammsan> i don't want people to think they should be spoon fed with work
10:14 < dammsan> i want to share the burden of breaking out stuff with you
10:15 < dammsan> so we can collaborate to learn what next steps we need to take
10:15  * kbingham doesn't full understand what "breaking out stuff" means 
10:15 < kbingham> Is that investigation and planning ?
10:15 < dammsan> kbingham: both perhaps
10:15 < pinchartl> by trying to move away from spoon-feeding and asking people to come up with task ideas for themselves, with such a fine-grained control, we have reached a situation that reminds me of kids in school who have to ask permission to go to the toilet
10:15 < dammsan> i asked for the dma virtualization topic
10:16 < dammsan> but in reality pinchartl found it to be 4 subtasks
10:16 < dammsan> unfortunately the ordering was odd
10:16 < pinchartl> dammsan: and it shouldn't have been my job to breakout a core task...
10:16 < dammsan> so we did the paper work before the so it happened after the contract was finalized =)
10:17 < dammsan> pinchartl: it seems that your role as coworked of kbingham might be conflicting with group leader
10:17 < dammsan> so i think we need to be more clear
10:18 < dammsan> kbingham: do you understand what i mean by breakout now?
10:18 < pinchartl> dammsan: I don't see a conflict. if you expect developers to work with group leaders to break out tasks I'm fine with that. what I disliked here is that Kieran and I were supposed to do the work all by ourselves
10:18 < kbingham> 'breakout = create additional task details'
10:18 < dammsan> kbingham: and split into subtasks
10:18 < kbingham> Yes - I was about to add that ;)
10:19 < dammsan> if we would have broken out ahead of time
10:19 < dammsan> then we could have assigned you something smaller instead
10:19 < dammsan> pinchartl: it was unclear about responsibility for sure
10:20 < dammsan> so how to proceed in the short term?
10:20 < dammsan> i proposed serial pass through only or also include clocks like you mentioned before
10:21 < pinchartl> today is June the 7th. the due date is the 15th. I'll let Kieran decide as this is his task, but personally I think it's too late to do anything
10:22 < dammsan> i have been told we may push back the due date until later this month
10:22 < dammsan> but you have your travels too
10:22 < kbingham> for available time remaining, I think perhaps dropping that to a 5 day task to cover the investigation already completed, and we can consider revisiting the task for next quarter.
10:23 < dammsan> kbingham: so serial pass through only?
10:23 < dammsan> which due date would you like?
10:23 < dammsan> is 15th ok or is later better?
10:23 < kbingham> I have got serial pass through working - so I don't mind the usual due date for that.
10:23 < dammsan> good!
10:24 < dammsan> can you email me your proposal how to change the text?
10:24 < kbingham> Sure I'll do that after the meeting.
10:24 < dammsan> perfect - thanks
10:24 < dammsan> i'll deal with this later today
10:25 < dammsan> so as final topic, how can we agree on the same view for the contracts
10:25 < dammsan> ?
10:25 < kbingham> dammsan, By sitting down with a beer.
10:25 < dammsan> alrighty =)
10:26 < dammsan> geertu: what do you think about agreeing on dates one quarter ahead of time?
10:26 < kbingham> :D
10:26 < geertu> dammsan: due dates and meeting dates?
10:26 < dammsan> wsa_: and what do you think about agreeing on dates one quarter ahead?
10:26 < dammsan> yeah
10:27 < geertu> What does that solve? We know the due dates, and can guess meeting dates (about every two weeks)?
10:27 < wsa_> for add. tasks?
10:27 < pinchartl> dammsan: haven't we agreed on due dates until the end of times already ? they're at Q+1.5 and Q+2.5. what else is there to agree on ?
10:27 < dammsan> chat meeting dates
10:27 < dammsan> so we know when we have to fix the AT titles + descriptions
10:27 < geertu> Do we have an issue with not knowing all future chat meeting dates?
10:28 < dammsan> we have an issue with AT creation which operates on chat meeting tick
10:28 < horms> dammsan: the chat meeting dates seem pretty predictable from my side
10:28 < horms> is the problem that sometimes we skip a week?
10:28 < pinchartl> dammsan: why don't we then decouple AT creation and chat meetings ?
10:28 < pinchartl> we can have ad-hoc meetings to create ATs
10:29 < dammsan> horms: sspinchartl: i agree if we can schedule break out meetings first =)
10:29 < dammsan> horms: no problem i think
10:29 < horms> sorry, the breakout term is very confusing to me
10:30 < horms> do you mean meetings to break out AT tasks?
10:30 < dammsan> tasks in general
10:30 < dammsan> that may or may not turn into AT
10:30 < horms> Ok, so task discussion meetings, separate from our regular meetings?
10:30 < geertu> Don't we usually handle AT titles over email? Decoupled from chat meeting?
10:30 < dammsan> if we have a bunch of tasks already broken out
10:30 < kbingham> https://paste.ubuntu.com/p/JcT9DrMQkT/ :D
10:31 < dammsan> then those should be easier to assign
10:31 < dammsan> horms: these discussions take time
10:31 < dammsan> and usually they get lower priority than actual hacking
10:32 < dammsan> and with travels and conferences and whatnot
10:32 < dammsan> it seems that we so far have not been able to come up with any plan (visible to me)
10:32 < pinchartl> dammsan: what kind of plan to you expect ?
10:32 < dammsan> a good example is the dma virtualization topic
10:33 < dammsan> you broke it out into 4 subtasks
10:33 < pinchartl> as I said, I can't create a plan with dates as I don't have development time I can assign to tasks
10:33 < dammsan> no need for dates
10:33 < dammsan> or time estimates
10:33 < dammsan> only titles and dependencies
10:33 < pinchartl> so if there's no date or time estimate, what kind of plan do you expect ?
10:33 < dammsan> maybe some details if possible
10:33 < pinchartl> a list of tasks ?
10:33 < dammsan> yes
10:33 < dammsan> with dependencies
10:33 < dammsan> for instance, clocks are missing from QEMU
10:33 < dammsan> so lets include a prototype task for that
10:34 < dammsan> before we do real development
10:34 < pinchartl> to find that out, nearly 5 days of work were needed. how could we have found out in a better way ?
10:34 < dammsan> we could have done it at aa different time IMO
10:34 < dammsan> maybe we should have aimed at serial pass through instead of going directly to DMA virt
10:35 < pinchartl> yes, but how ? what should have triggered that investigaion ?
10:35 < dammsan> serial pass through prototype?
10:35 < pinchartl> ok
10:35 < pinchartl> is it acceptable, when we schedule a prototype AT, to not deliver the expected prototype ?
10:35 < dammsan> or us sitting down and looking of
10:35 < dammsan> at what is needed?
10:35 < pinchartl> when features are missing for instance
10:35 < pinchartl> sitting down for 5 days ? :-)
10:35 < dammsan> we need deliverables
10:35 < pinchartl> it really required work
10:36 < dammsan> sure no doubt about that
10:36 < dammsan> (that's why i don't want to do it myself) =)
10:36 < dammsan> anyway
10:36 < dammsan> we can set aside base time
10:36 < pinchartl> in my opinion, there's no guarantee that a prototype can be delivered, ever
10:36 < dammsan> and meet and discuss these things over some time
10:36 < dammsan> then we are aiming too high
10:36 < pinchartl> by definition we create prototypes when the risk is high
10:37 < dammsan> so far all prototypes have been delivered =)
10:37 < pinchartl> and so we can run into blocking issues that can't be solved within the scheduled time frame
10:37 < dammsan> well, you take shortcuts
10:37 < pinchartl> so far we're had a combination of luck and dipping in base time. I don't think that's something we want to rely on as a rule
10:37 < dammsan> and if you cant then you have aimed too high
10:38 < dammsan> i'm open to suggestions though
10:38 < pinchartl> you can't know for sure how to aim, that's the whole point of prototypes
10:38 < dammsan> if you have any other ideas how to figure it out
10:38 < pinchartl> and taking shortcut can be acceptable to some extent
10:38 < pinchartl> but if we end up rushing to deliver something by taking too many shortcuts, then we delivere useless crap
10:38 < pinchartl> and waste time and money
10:38 < dammsan> there is a balance for sure
10:38 < pinchartl> in this specific case
10:39 < pinchartl> you could rush to create lots of hacks that will allow serial pass-through
10:39 < pinchartl> or start working on the missing features and not deliver the pass-through in time
10:39 < pinchartl> in the first came the patches will be garbage, nobody will ever use time
10:39 < kbingham> If a task 'suggestion' has begun - Investigtiaons and breakout - can simply occur in base time - in the quarter before>?
10:39 < dammsan> yeah?
10:39 < pinchartl> while in the second case the time is invested in a more productive and useful way
10:40 < dammsan> pinchartl: except the second does not consider the output of broken out tasks as useful
10:40 < pinchartl> dammsan: sorry, I didn't get that
10:40 < dammsan> kbingham: i agree
10:40 < dammsan> no sane person will take a prototype and put it into production
10:41 < kbingham> dammsan, Great - so we just need to get task suggestions started early.
10:41 < dammsan> but we can learn various things from it
10:41 < pinchartl> it's not about putting things into production
10:41 < dammsan> of course the ultimate goal is to solve the problem
10:41 < dammsan> but we need to learn what the problems are too
10:41 < dammsan> to know what we need to do
10:42 < dammsan> is it any more clear?
10:42 < pinchartl> if you spend 5 days learning about the issues and finding out what has to be solved, and have 5 days of budget left, consuming the remaining 5 days to write throw-away hacks just to tick the "done" box in the report is useless
10:42 < pinchartl> prototypes are valuable to find out about issues
10:43 < pinchartl> but once the issues are known it's pointless to create the dirtiest hacks just to check a box
10:43 < dammsan> if the prototypes happened by themselves then i would be the happiest man on the planet =)
10:43 < pinchartl> some hacks can be useful when they allow moving to the next step and finding about the next problem
10:43 < dammsan> the question is how the issues become known =)
10:43 < geertu> The hacks are useful to unblock you, and continue getting it to work, perhaps finding more issues to solve later.
10:44 < dammsan> geertu: yes
10:44 < pinchartl> or when they make a dependency for another task available faster than the proper solution
10:44 < geertu> Ineed, you won't know about the issues if you don't try.
10:44 < pinchartl> but if nothing else depends on your prototype, more hacks after all problems are known become throw-away code
10:44 < dammsan> i believe prototypes should be quick hacks
10:45 < dammsan> and i think my request to you was over reaching =)
10:45 < pinchartl> I think it's time to wrap this discussion up
10:45 < pinchartl> can we schedule a face to face discussion in Tokyo ?
10:45 < dammsan> sure, but how to make non-present members not feeling omitted?
10:46 < pinchartl> geertu: I think that question is for you
10:46  * geertu is wondering about this recent invention called "tubes", or "the Internet"
10:46 < dammsan> this travel planning is a cluster flower
10:47 < dammsan> geertu: i need to read the friendly manual =)
10:47 < pinchartl> dammsan: we have been told that there's no travel budget, and now we find out a face to face meeting is needed. there's an unavoidable conflict between those two :-)
10:47 < dammsan> i know - welcome to my life
10:47 < dammsan> i don't recommend it
10:48 < pinchartl> dammsan: I have never doubted that I'm not the only person to be frustrated by this :-)
10:48 < geertu> pinchartl: fall-out from the lack of travel budget around FOSDEM?
10:48 < pinchartl> so how can we schedule a meeting ?
10:48 < horms> dammsan: I recommend you have a f2f meeting. If its possible let people know so they can post questions via chat or etherpad. But likely it won't be due to times zones, being in a bar, ... So pleasae provide some sort of summary so a follow-up discussion can occur via chat or email
10:49 < horms> s/please/I recommend/
10:49 < dammsan> horms: sounds good
10:49 < dammsan> thanks
10:49 < dammsan> pinchartl: when are you guys available?
10:50 < pinchartl> for me, Wednesday, Thursday, Saturday, Sunday,
10:50 < kbingham> My talk is on the Thursday.
10:51 < kbingham> but it might be scheduled early - so after would be fine.
10:51 < pinchartl> my talk is on Friday at 15:15, so starting at 16:00 Friday is fine too
10:51 < dammsan> i have some plans sat + sun
10:51 < wsa_> not the weekend, please
10:52 < pinchartl> how about Wednesday then ?
10:52 < wsa_> how about we get some weapons at the NinjaRestaurant and fight it out? ;)
10:52 < neg> All OSS-J days and the weekend works for me
10:52 < dammsan> sure
10:52 < neg> wsa_: I like your style
10:52 < dammsan> 20th, right?
10:53 < wsa_> wednesday morning?
10:53 < wsa_> or did someone here want to go to the keynotes? ;)
10:53 < dammsan> in a ditch in east shinjuku =)
10:53 < pinchartl> wednesday morning sounds good, there are only keynots
10:53 < kbingham> Wednesday morning works :)
10:53 < neg> +1
10:53 < pinchartl> 9:00 on Monday ?
10:54 < pinchartl> we might be able to host the meeting at our apartment
10:54 < pinchartl> who wants to join ?
10:54 < wsa_> monday?
10:54 < pinchartl> sorry
10:54 < pinchartl> Wednesday
10:54 < geertu> If you want people in EU to join, morning meetings may not be the right time...
10:55 < wsa_> wed 09:00 is fine with me
10:55 < wsa_> and if your apartment turns out to be not big enough, we will surely find a place at the conference
10:55 < wsa_> with only keynotes going on
10:56 < pinchartl> geertu: attending remotely would require a properly A/V equipped room. I don't know if we could get that
10:56 -!- shimoda [~shimoda@relprex2.renesas.com] has quit Read error: Connection reset by peer
10:56 < dammsan> morimoto-san seems to suggest 18 or 19 =)
10:57 < dammsan> but from my side
10:57 < dammsan> if we have this kind of business meeting then reneeesas should pay for airfares IMO
10:57 < pinchartl> dammsan: I'll fly in on the 18th, and on the 19th there's a whole day V4L2 meeting that I need to attend to make sure the right design decisions will be taken
10:57 < dammsan> pinchart: gotcha
10:58 < pinchartl> otherwise I would have proposed Tuesday
10:58 -!- shimoda [~shimoda@relprex2.renesas.com] has joined #periperi
10:58 < pinchartl> we might be able to to Tuesday evening, but it's probably better to start fresh
10:58 < wsa_> yes
10:59 < morimoto> all: I'm OK for Web
10:59 < pinchartl> I agree with Simon, I think we should start proposing ideas over e-mail first, so that everybody can express themselves
10:59 < dammsan> for anyone in town the weekend before is also possible from my side
10:59 < pinchartl> send the minutes of the discussions after the meeting
10:59 < pinchartl> and then wrap up with an online discussion for the final agreement so that nobody is left out
10:59 < wsa_> then again, being tired in a bar might also help to keep it short :D
11:00 < dammsan> i think we need several opportunities to vent =)
11:00 < pinchartl> wsa_: I want short and productive, but I'd rather have long and useful than short and useless :-)
11:00 < dammsan> so the more the better
11:00 < dammsan> pinchartl: is this on of those "size matters" discussions?
11:01 < pinchartl> so can we wrap up now ?
11:02 < dammsan> wednesday it is then?
11:02 < pinchartl> yes
11:02 < wsa_> booked
11:03 < neg> 09:00 what location?
11:03 < pinchartl> neg: possibly our apartment, or if it's too small, somewhere else
11:04 < pinchartl> geertu: I think the mic is now yours for the core meeting