diff options
Diffstat (limited to 'wiki/Chat_log/20170329-core-chatlog')
| -rw-r--r-- | wiki/Chat_log/20170329-core-chatlog | 362 |
1 files changed, 362 insertions, 0 deletions
diff --git a/wiki/Chat_log/20170329-core-chatlog b/wiki/Chat_log/20170329-core-chatlog new file mode 100644 index 0000000..154230e --- /dev/null +++ b/wiki/Chat_log/20170329-core-chatlog @@ -0,0 +1,362 @@ +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! |