Core-chat-meeting-2017-03-29

10:07 < geertu> Welcome to today's Core Group Chat!
10:07 < geertu> Agenda:
10:07 < geertu> 1. Status updates
10:07 < geertu> 2. PFC drivers for RZ/G1
10:07 < geertu> 3. Additional tasks for 2017/Q2 phase 1
10:07 < geertu> Topic 1. Status updates
10:07 < geertu> A) What have I done since last time
10:07 < geertu> B) What I plan to do till next time
10:07 < geertu> C) Problems I have currently
10:07 < geertu> D) Posted/Accepted bugfix patches
10:07 < geertu> $(sort -r) says Simon is first
10:09 < horms> todo update: NULL
10:09 < horms> A) What have I done since last time
10:09 < horms>         - No core tasks at this time; no updates
10:09 < horms> B) What I plan to do till next time
10:09 < horms>         - Nothing for Core
10:09 < horms> C) Problems I have currently
10:09 < horms>         - None
10:09 < horms> -- end --
10:10 < geertu> Thank you Simon.
10:10 < geertu> Next is Shimoda-san
10:11 < shimoda> A)
10:11 < shimoda>  - Nothing because I focused I/O group things (USB).
10:11 < shimoda> B)
10:11 < shimoda>  - I will make/submit a workaround patch with whilelist.
10:11 < shimoda> C)
10:11 < shimoda>  - Nothing.
10:11 < shimoda> D)
10:11 < shimoda>  - Nothing.
10:12 < shimoda> -- end --
10:12 < geertu> Thank you Shimoda-san!
10:12 < geertu> Next is Niklas
10:12 < neg> a) Posted patches for rcar-dmac resource freeing synchronization
10:12 < neg> b) Noting planed (yet)
10:13 < neg> c) None
10:13 < neg> d) None
10:13 < neg> --EOT--
10:13 < geertu> Thank you Niklas!
10:13 < geertu> Next is Morimoto-san. I'll tell you what he mailed me:
10:14 < geertu> A)
10:14 < geertu>     - I posted "SYS-DMAC + ARM64 + 40bit address + Descriptor Mode" patch,
10:14 < geertu>       and it was accepted (see below for peripelist patch).
10:14 < geertu>     - R-Car Gen3 datasheet export paper work for extended period
10:14 < geertu> B)
10:14 < geertu>     - Nothing for Core
10:14 < geertu> C)
10:14 < geertu>     - No hacking time
10:14 < geertu> D)
10:14 < geertu>       - Nothing
10:14 < geertu> --EOT--
10:15 < geertu> Next is Marek
10:15 < Marex> A) NULL
10:15 < Marex> B) Discuss VC6 and Rohm PMIC with geertu
10:15 < Marex> C) NULL
10:15 < Marex> D) NULL
10:15 < geertu> Thank you, Marek!
10:16 < geertu> Next is Magnus
10:16 < dammsan> A) Some initial update of the IPMMU driver stuff, not posted yet. And IPMMU USB integration.
10:16 < dammsan> B) Keep on hitting my head against the IPMMU driver code base
10:17 < dammsan> C) and D) Nothing
10:17 < geertu> Thank you, Magnus!
10:18 < geertu> Next is Laurent
10:18 < pinchartl> nothing to report, I'm just lurking
10:19 < geertu> Thank you, Laurent!
10:19 < geertu> Next is Jacopo
10:19 < jmondi> A) What have I done since last time
10:19 < jmondi> - 2 rounds of RZ/A1 PFC
10:19 < jmondi> - added ethernet to PFC devices
10:19 < jmondi> - tested RTC patches from Chris (not working on Genmai yet: probably my bad)
10:19 < jmondi> - Killed a GR-PEACH due to poor soldering abilities
10:20 < jmondi> B) What I plan to do
10:20 < jmondi> - close LinusW review feedback and have rz/a1 merged
10:20 < jmondi> - make rtc patches work on Genmai
10:20 < jmondi> - have a new Core/IO task assigned
10:20 < jmondi> C) = D) = NULL
10:20 < jmondi> -- eot --
10:21 < geertu> Thank you, Jacopo! Sorry to hear about the GR-PEACH
10:21 < jmondi> my bad :)
10:21 < geertu> Next (last) is Geert
10:21 < geertu> A) What have I done since last time
10:21 < geertu>   - v2 of resets for R-Car H3 and M3-W DTS
10:21 < geertu>   - v2 of DTS for R-Car H3 ES2.0
10:21 < geertu>   - Reviewed physical pins of R-Car H3 SiP ES2.0 for PFC
10:22 < geertu> B) What I plan to do till next time
10:22 < geertu>   - Finish R-Car H3 ES2.0:
10:22 < geertu>       - Send pull request for clk
10:22 < geertu>       - v3 of pfc (rename pfc-r8a7795es1.c to pfc-r8a7795-es1.c, cfr. BSP)
10:22 < geertu>           + queue and pull request
10:22 < geertu>       - v2 of soc_device_match() fixes + pull request for Greg / Arnd / Simon
10:22 < geertu>       - Send pull request for rcar-sysc
10:22 < geertu>   - R-Car Gen2 CPG/MSSR
10:22 < geertu>   - DTS sharing on H3 ES1.x/ES2.0, Salvator-X/ULCB
10:22 < geertu> C) Problems I have currently
10:22 < geertu>   - None
10:22 < geertu> D) Posted/Accepted bugfix patches
10:22 < geertu>   - Clock fixes detected during R-Car Gen2 CPG/MSSR conversion
10:22 < geertu>   - [PATCH] backlight: pwm_bl: Fix GPIO out for unimplemented .get_direction()
10:22 < geertu>   - [PATCH v2 0/3] serial: sh-sci: Assorted flow control fixes
10:22 < geertu>     (yes, these are really I/O, but better report them early, Wolfram is lurking anyway ;-)
10:22 < wsa_> :D
10:22 < geertu> --eot--
10:23 < geertu> Topic 2. PFC drivers for RZ/G1
10:23 < geertu> Cogent (Sergei) is preparing the upstreaming of the PFC drivers for r8a7743
10:23 < geertu> (RZ/G1M) and r8a7745 (RZ/G1E).
10:23 < geertu> To avoid adding and maintaining 20 kLoC of new pinctrl code, I would like
10:23 < geertu> to reuse the existing drivers for R-Car M2-W and E2.
10:23 < geertu> While RZ/G1 supports less hardware than R-Car Gen2, my point is that if a
10:23 < geertu> device does not exist in r8a7743.dtsi or r8a7745.dtsi, you won't set up
10:23 < geertu> pinctrl for pins/groups/functions for that device, and thus won't use
10:23 < geertu> nonexisting PFC enums.
10:23 < dammsan> makes complete sense
10:23 < geertu> Sergei wants to make sure that adding further support for non-existing
10:23 < geertu> devices won't be possible, and thus wants to have separate drivers.
10:24 < dammsan> as opposed to
10:24 < geertu> Lately, it seems Sergei is becoming convinced.
10:25 < geertu> But perhaps only because I (wearing my sh-pfc hat) have to accept his patches...
10:25 < geertu> Unfortunately, he has less (different) information than we have, cfr. his resistance.
10:26 < geertu> It may be easier if we can share some information with him.
10:26 < dammsan> this different information, i wonder if we can work on that to improve things
10:27 < dammsan> of course sharing info would be nice, but i don't see how that will happen with the different ordering schemes and NDAs and whatnot
10:28 < dammsan> what is he missing?
10:28 < dammsan> (apart from the obvious =) =) =)
10:29 < geertu> However, a nice side-effect of his uninformedness is that he's rigorously comparing r8a7743 and r8a7791 PFC, and discovering bugs in pfc-r8a7791.c
10:29 < dammsan> well that is good
10:31 < dammsan> i think that trying to validate the DT from within a driver is not a very good approach
10:31 < dammsan> basic integration assumes that you input the right stuff into DTS including address ranges, interrupts and of course also pins
10:32 < dammsan> seems that he prefers to do some validation somehow, or perhaps i misunderstand
10:33 < geertu> dammsan: I think the only extra validation he can gain from using a separate driver is the ability to reject pin groups for on-SoC devices that are not documented in the RZ/G1 datasheet.
10:33 < horms> surely the dt describes the hardware and the driver implements some set of features which may overlap with what is described in dt
10:35 < geertu> dammsan: For a specific on-SoC device, I think the pins, groups, and functions will be the same.
10:35 < dammsan> i guess not duplicating information makes sense for sure
10:35 < dammsan> so not duplicating PFC information in different files must be correct
10:35 < geertu> Sure.
10:36 < dammsan> however one question is if the existing PFC code shall take SoC compat string into consideration and reject invalid stuff somehow
10:36 < dammsan> using the same kind of table
10:36 < geertu> It's just a bit difficult to explain the sharing to people not aware of the details.
10:36 < dammsan> yeah i understand
10:37 < dammsan> if it is useful then it seems like a per-soc feature flag or something
10:37 < geertu> That's definitely a possibility.  But what would be the gain?  It's not like people are gonna configure pinctrl for a function that has no corresponding device name in the SoC-specific dtsi
10:37 < dammsan> horms: can you explain about the overlap in driver vs DT in more detail?
10:37 < geertu> s/device name/devcie node/
10:38 < dammsan> geertu: i agree
10:38 < geertu> s/device name/device node/
10:38 < dammsan> if someone copy-pastes DTS wrong and it enables the wrong PFC combo then so be it
10:38 < dammsan> it is like assigning wrong IRQ number in DTS
10:39 < dammsan> simply dont do that
10:39 < horms> I meant; DT could conceivably ask for features that are not yet implemented in the driver (maybe not). And the driver can implement features not used on a particular bit of hw - in which case DT shouldn't ask for them.
10:39 < Marex> indeed, DT is not kindergarten ...
10:39 < horms> copy paste is a big problem for DT; its almost like the system is broken by design
10:40 < Marex> horms: the system is OK, uninformed integrators are the problem here and that cannot really be easily fixed
10:40 < horms> sure, but it is easy to make misakes
10:40 < horms> regardless, i don't think its the role of the driver to verify dt
10:40 < Marex> +1
10:40 -!- morimoto [~user@relprex1.renesas.com] has joined #periperi
10:41 < dammsan> in most cases the driver cant even judge right from wrong
10:41 < dammsan> and spending extra cycles doing so seems stupid
10:41 < geertu> horms: It's not, but in this case (PFC), the pin group/function names are technically part of the binding.
10:41 < horms> I guess one risk is that someone might enable something on RZ/G1, which is documented not to exist but is implemented in the driver for R-Car, and then discover it does exist on RX/G1
10:42 < horms> perhaps this is where Sergei's concern lies
10:42 < horms> I imagine that would conflict with Renesas's marketing goals
10:42 < horms> geertu: ok, i had missed that point
10:42 < neg> One drawback if it's shared is that the debugfs interface will show pins/groups that or not valid for the SoC in question
10:42 < geertu> horms: That someone has to add something to r8a774[34].dtsi first, too
10:43 < horms> sure, but that wouldn't be a problem from a maketing pov
10:43 < horms> anyway, its a non-technical reason
10:43 < geertu> neg: True, hadn't thought about debugfs
10:44 < dammsan> having a list of pin functions available together with compat string matching can't be that difficult
10:44 < dammsan> sergei might even be able to implement it himself
10:45 < geertu> neg: That would be limited to the pinmux_groups[] and pinmux_functions[] arrays
10:45 < dammsan> if he feels strongly about it
10:46 < dammsan> i wonder if the relationship beween M2 and RZ-G is similar to H3 ES2 and M3?
10:46 < horms> it could even be done in parallel with other tasks he may have
10:46 < horms> as i wouldn't think it blocks forward progress
10:46 < geertu> neg: we could sort it (common entries first, RZ/G1 entries last), and change sh_pfc_soc_info.nr_{groups,functions} based on compatible value.
10:46 < dammsan> especially since it goes backwards =)
10:47 < dammsan> horms: jokes aside i agree with you
10:47 < horms> we could ask him to implement it sideways :)
10:47  * geertu may be thinking too much about kernel size
10:47 < horms> I wondered about that too
10:48 < neg> geertu: yes that would work, is the pinmux_pins arrays equal on both SoC ?
10:48 < geertu> neg: I expect it is, both SoCs have the same package and nr. of pins, according to the Renesas website
10:49 < neg> that is good, then yes having some magic for the pinmux_groups[] and pinmux_functions[] would then take care of the debugfs issue
10:51 < geertu> Having separate pinmux_groups[] and pinmux_functions[] arrays would waste ca. 6 KiB
10:51 < geertu> so runtime patching may be worth it.
10:56 < geertu> We could also #ifdef out the various *_pins[] and *_groups[] on kernels not including support for r8a7791.
10:56 < dammsan> geertu: i wonder if the package type may limit exposed pins too on G1M compared to M2-W
10:56 < geertu> dammsan: renesas.com says they have the same package
10:59 < geertu> M2-W: 831 pin Flip Chip BGA (27 mm × 27 mm)
10:59 < dammsan> ok then i'm silent =)
10:59 < geertu> G1M: 831 HBGA (I'm quite sure that used to say Flip Chip BGA, too)
11:00 < geertu> E2: 501-pin Flip Chip BGA (21 mm × 21 mm)
11:00 < geertu> G1E: 501 HBGA
11:01 < dammsan> ok thanks!
11:02 < geertu> OK, I'll ask Sergei to use a separate sh_pfc_soc_info with different pinmux_groups/pinmux_functions
11:02 < neg> Did we not use to have runtime patching for Gen3 ES versions previusly? But now that I look in renesas-drivers I can't find it. In any case is that not something we can reuse?
11:02 < geertu> We have the infrastructure in place for handling that for H3 ES2
11:02 < geertu> neg: Just the .init() callback to override something
11:03 < geertu> neg: patches of the tables is done for clk and rcar-sysc only.
11:03 < neg> I see
11:07 < geertu> Shall we continue?
11:08 < geertu> Topic 3. Additional tasks for 2017/Q2 phase 1
11:08 < geertu> So far I have:
11:08 < geertu>     Gen2,?,plan,geert,Migrate R-Car Gen2 to CPG/MSSR
11:08 < geertu>     generic,?,plan,geert,DTS sharing on H3 ES1.x/ES2.0, Salvator-X/ULCB
11:08 < geertu>     RCAR-DMAC,?,plan,niklas,Add transfer termination synchronization
11:08 < geertu>     Salvator-X,?,plan,marek,BD9571 PMIC driver
11:08 < geertu> It would be good if someone could take over from Khiem:
11:08 < geertu>     CPUFreq,v4.12,public,khiem,R-Car Gen3 CPUFreq support
11:08 < horms> I would be happy to look into that if there are no other takers
11:08 < geertu> Patches for that are pubic (with some comments), and in the BSP
11:09 < geertu> Once the PMIC driver is there, we can start doing DVFS
11:09 < geertu> Jacopo worked on the monitoring part using max9611
11:09 < geertu> So perhaps he's interested as well?
11:09 < wsa_> simon: do you also have room then for the SDHI DMA refactoring task?
11:10 < wsa_> and interest? :)
11:10 < jmondi> geertu: I am :)
11:11 < neg> If horms have too much IO work I can also look at Khiems CPUFreq work
11:11 < Marex> geertu: so what do we do with the PMIC ? And what about the VC6 ? :)
11:12 < horms> Perhaps if I took the SDHI DMA refactoring task and neg could take CPUFreq?
11:13 < wsa_> neg: speaking of IO, there are also "emergency shutdown" and "WakeOnLan for Gen3" tasks for which you have some previous attachment ;)
11:13 < geertu> Marex: I thought you were going to take care of the PMIC, cfr. above? :-)
11:13 < wsa_> neg: but if you are busy, they might be interesting for Jacopo as well?
11:13 < geertu> Marex: VC6 will have to wait for board availability, as the board is expected to arrive before Digi-Key has VC6 devboard stock
11:14 < pinchartl> geertu: if I may, I'd like to discuss how to allocate developers to tasks across groups in a better way than "first group leader who asks will get developers"
11:14 < neg> wsa_: Yes I was hopping to do 'emergency shutdown' for IO sometime during Q2 but WoL for Gen3 is also a possibility
11:14 < pinchartl> there's lots of work to be done on multimedia, and I'm sure core and I/O are nont different from that point of view
11:15 < pinchartl> I could just chime in and say that I need Niklas and Jacopo full time, but that wouldn't be very nice to you :-)
11:15 < pinchartl> so how can we do better ?
11:15 < dammsan> pinchartl:
11:16 < geertu> Ah, the load balancer among groups has arrived ;-)
11:16 < dammsan> i think you may have the most complex dependencies
11:17 < Marex> geertu: got it
11:17 < pinchartl> dammsan: possibly (although I don't want to make it a contest :-))
11:17 < Marex> geertu: sorry, got a little stuck discussing how to fix jmondi's peach
11:17 < dammsan> noneed =)
11:17 < pinchartl> dammsan: so how can we proceed ?
11:18 < pinchartl> I can't plan anything ahead if at the last minute I have to do with half of the developers I thought could work on multimedia
11:18 < dammsan> in case we have some super emergency in some group we nee
11:18 < pinchartl> so I need a way to plan ahead
11:18 < dammsan> d to allocate based on that
11:18 < geertu> pinchartl: So we need to increase base allocation?
11:18 < pinchartl> you told me yesterday during the multimedia meeting that you wanted to wait before assigning additional tasks for the multimedia group
11:18 < pinchartl> so core and I/O will come first
11:19 < pinchartl> and I'll be left without anyone
11:19 < dammsan> however, i would like to decide based on how each guy
11:19 < dammsan> prefers to work really
11:19 < dammsan> pinchartl: i don't think anyone will steal all the developers
11:19 < pinchartl> if you want me to plan ahead and stick to the plan, I need to know in advance who will be available
11:19 < dammsan> but without working hardware platform it is kind of hard to start a big project
11:19 < wsa_> pinchartl: for me, it is not about "coming first". My picture of the meeting today is that we are all here and discuss how to proceed
11:19 < geertu> marex: 800-3138-ND stil has 18 weeks lead time, 12/6/2016 - Delivery Date Past Due - Contact Digi-Key
11:20 < dammsan> right
11:20 < pinchartl> wsa_: the issue is that we allocate tasks seperately for each group
11:20 < Marex> geertu: yeah :(
11:20 < dammsan> so i would like each developer to join at least two groups
11:21 < dammsan> and in a perfect world i think additional tasks from two groups should be handled
11:21 < geertu> Marex: Buy a 5P49V6901A and put it on a protoboard?
11:21 < wsa_> pinchartl: my hope is that today we will do it differently
11:21 < pinchartl> dammsan: we're talking about half a quarter of additional tasks, so that's 60 / 2 / 2 = 15 days
11:21 < pinchartl> joining two groups seems quite dubious to me with such a short amount of time
11:22 < dammsan> pinchartl: it is possible to assign more than one batch of work too
11:22 < wsa_> one problem is, I don't know priorities from other groups, so I'd like to know about those as well
11:22 < dammsan> it depends on the kind of task
11:22 < dammsan> neg: how would you like to spend your time? =)
11:22 < wsa_> I mainly threw in the topics I have, so people know what is around
11:22 < Marex> geertu: well I can immediatelly get me a 6901 in a VFQFPN
11:22 < wsa_> I'd prefer if we can agree on priorities together
11:22 < pinchartl> 5 days tasks really don't make sense in most cases. the scheduling overhead is too large
11:22 < Marex> geertu: I guess I could wirebond it to a breadboard ...
11:22 < pinchartl> wsa_: I agree
11:23 < neg> dammsan: I would like to help as much as possible where the need is greatest. But I also like to if possible have tasks from two groups
11:23 < pinchartl> that would require a whole team meeting though
11:23 < dammsan> neg: so in case more work is needed for multimedia then perhaps allocating mroe slots there makes sense
11:24 < Marex> geertu: problem might be the external components ^_^'
11:24 < neg> dammsan: I also have quiet a lot of base-task time in April which currently is not fully allocated to tasks so I can do some tasks in that timeframe
11:24 < dammsan> makes sense
11:25 < dammsan> so the number of Core and I/O tasks are that not many, are they?
11:25 < wsa_> neg: how about doing "emergency shutdown" as a base task then?
11:25 < wsa_> neg: as I understood, you'd like to do that, and from my side it has not the highes priority
11:26 < neg> wsa_: sounds good to me, but if it's not high prio I can do something else as part of my base. Only problem is that IO is not listed as a group I should do work for in my base contract ATM
11:27 < dammsan> geertu: do you have some tasks that will cause delays for everyone if they are not executed before other groups?
11:27 < dammsan> PFC/CPG/SYSC something
11:28 < dammsan> i think not
11:28 < geertu> dammsan: I don't think I have any urgent core tasks
11:28 < neg> One crazy idea is to allocate more base contract time to multimeda tasks since there are so many dependecies there to provied flexability and do less complex tasks as additional contracts?
11:28 < dammsan> neg: whatever rocks your boat
11:28 < geertu> So "additional" is for the already-known tasks, and "base
11:28 < geertu> " for the unexpected ;-)
11:29 < pinchartl> neg: the proposal for multimedia additional tasks is already quite generic, so it's not very different from the base contract in that regard
11:29 < dammsan> geertu: ok, nothing urgent
11:29 < pinchartl> if we want detailed additional tasks, at this point of time I'd prefer using them for core or I/O
11:29 < pinchartl> I personally don't care in which report a patch will be included
11:30 < pinchartl> my concern is getting the work done in time
11:30 < dammsan> pinchartl: totally agree
11:31 < dammsan> neg: so how about assigning one slot of additional task per group per quarter? and base goes mainly to multimedia?
11:32 < neg> works for me. most setups works for me, as long as everyone is happy so am I
11:32 < dammsan> just a random proposal
11:32 < pinchartl> dammsan: personally I wouldn't agree to have a 5 days additional multimedia task as it would become too painful from a report overhead point of view, but if people want to bother, I don't care
11:32 < pinchartl> (good luck coming up with deliverables that jinzai could test though)
11:32 < dammsan> pinchartl: doesn't it depend on what kaind of task?
11:33 < dammsan> say a prototype to get that V2H camera going?
11:33 < pinchartl> dammsan: generally speaking it does, but with the tasks we have now, there's nothing suitable for 5 days
11:33 < dammsan> you can achieve a lot with 5 days
11:33 < pinchartl> you can write a report in 5 days, yes
11:34 < dammsan> perhaps it is possible to reduce the complexity of the reporting =)
11:34 < pinchartl> with a 5 days task I personally allocate at least 20% of the time to the report
11:34 < pinchartl> that's way too much
11:34 < dammsan> i agree
11:34 < pinchartl> (and with the time I spend negotiating the task descriptions with you, it goes to 30%)
11:34 < dammsan> if it takes more than one hour then something i wrong IMO
11:34 < dammsan> pinchartl: the task negotiation time is part of your base task as group leader
11:34 < pinchartl> beside, jinzai is pretty much useless when testing deliverables
11:35 < pinchartl> so it's really wasted time
11:35 < dammsan> it depends on what kind of task it is
11:35 < dammsan> no need to make it more complex than it has to be
11:35 < pinchartl> we've been making things more and more complex over time for the past 12 months ;-)
11:35 < dammsan> so lets try to make it easier to move
11:36 < wsa_> same here with 20%, an actually useful elinux page needs time
11:36 < dammsan> i feel this might be the case mainly for multimedia
11:36 < wsa_> they are not bad, though, but they do need time
11:36 < dammsan> wsa_: i didn't mean to include the wiki in that reporting time
11:36 < dammsan> not all tasks require wiki edit
11:36 < dammsan> some do
11:37 < dammsan> it is up to discussion when we make the tasks
11:37 < wsa_> i see
11:37 < dammsan> i was mainly counting time for the PDF report to jinzai
11:37 < pinchartl> dammsan: my concern isn't so much about time needed to write documentation or reports. it's roughly a fixed amount of time. with a 15 days task, the overhead is acceptable. with a 5 days task, it isn't
11:37 < dammsan> ok if you say so
11:38 < dammsan> last time i got a contiguous 5 days to work on something was a loong time ago
11:38 < dammsan> so i feel it would be a great luxury
11:38 < pinchartl> see, that's the problem :-)
11:38 < dammsan> but it is perhaps just me
11:38 < pinchartl> we have too much scheduling overhead
11:38 < pinchartl> no, it's not just you
11:39 < dammsan> ok that's good to know =)
11:39 < dammsan> so i wonder what the other members think?
11:39 < dammsan> especially the group leaders
11:40 < horms> fwiw, I agree there tends to be quite a lot of reporting overhead for extra tasks, especially 5 day ones
11:40 < dammsan> horms: even if you exclude wiki and testing?
11:40 < wsa_> when speaking about the tasks themselves, i assume IO tasks are better suited to 5 days contracts
11:40 < geertu> testing needs to be done.
11:40 < geertu> wiki can be useful (depending on the task)
11:40 < horms> dammsan: not if excluded wiki and testing
11:41 < dammsan> horms: right then we agree i think
11:41 < dammsan> so if we need wiki and testing included then 5 days is pushing it
11:41 < pinchartl> dammsan: don't forget to include babysitting jinzai in the overhead :-)
11:41 < pinchartl> I don't know if it happens to the other groups too
11:42 < dammsan> pinchartl: the multimedia group has the most complex dependencies and most code not-yet-upstream
11:42 < wsa_> plain reporting (excluding wiki and testing) is OK
11:42 < wsa_> it's the testing and documentation which fragments the 5 days tasks for me
11:42 < dammsan> so allocate two slots if testing and wiki is needed
11:43 < dammsan> end of story =)
11:43 < wsa_> aye aye, sir
11:43 < geertu> Sorry, guys, I have to go.
11:43 < geertu> Shall we conclude the official meeting?
11:43 < dammsan> i still think that there is plenty to do with 5 days in case you do some feature or protoype without additional documentation and testing
11:43 < dammsan> sure
11:44 < geertu> For next meeting, I propose Tuesday, April 11, same time
11:44 < jmondi> I have to leave in ~20 mins as well... I would like to write down what's my contract situation for next quarter, so group leaders know what I can do and when.. Can I?
11:44 < geertu> Thanks for joining, have a nice continued day!