This month's meetings
<< < 2011 / 4 > >>
- Kernel WG meetings are conducted over IRC: #linaro-kernel on Freenode.
- Arnd Bergmann: x
- Dave Martin: x
- Deepak Saxena: x
- Jason Hui:
- Linus Walleij: x
- Mounir Bsaibes: x
- Nicolas Pitre: x
- Niklas Hernaeus: x
- Per Forlin: x
- Grant Likely: x
- Thomas Abraham: x
- Manjunath Kondaiah:
- Shawn Guo: x
- Venkatraman Sathiyamoorthy:
- rnayak: x
- Logistical announcement
- Around the table: Work Items updates, what's next in pre-announced order
- BUGS review
Action Items from Previous Meeting
- Logistical Annoucnement
- register for Linaro Connect and start working on flights, visa, etc. Please let Arwen know if you need support in that
- For next Monday's meeting, I'd like us to have more of a brainstorm session on what are some things to focus on the next cycle beyond what we are currently working on
- For Linaro connect, our format will be to have morning dedicated to summits/meetings and afternoons dedicated to hacking. If there's a topic you would like to see discussed in detail with a larger group than just the team, please let me know and I can schedule a summit session
- Work Items/ Blueprints. We're still not doing the best at using these to help TSC and management understand what we're getting done. With a team this size it also really is a helpful tool to help me stay on top of what everyone is doing and answer questions like "what's been done for feature X"?
- There's an understanding at Linaro that the BP/WI process doesn't map fully to the way kernel development works, so we'll need to keep thinking of how to use it in a way that does work, I'd like to discuss this at connect
- Mounir to pick up few blueprints and split the Work Items blocks into monthly blueprints. Then we will assess at the end of the month whether this will work.
- Niklas has decided that the Snowball DT development is to go with the uboot track. The blue print updated accordingly.
- Mounir to pick up few blueprints and create monthly blueprints out of the Work Items blocks.
- Deepak to setup a session bp for us to talk about BP's and kernel work, bp/wi's and process@ connect
<dsaxena> good morning <nhe> Hi. <robher> morning <dmart> hi all <dsaxena> let's wait a few minutes to see who else is around <thomas-ab> Hi All. <mounir> Hi <shawnguo> hello everyone <svenkatr> hello * rnayak (~firstname.lastname@example.org) has joined #linaro-kernel <dsaxena> greetings rnayak <rnayak> hi, thanks. <dsaxena> ok, it's 8:05, let's get started. <dsaxena> I want to do a few quick logistical announcements, and then we'll do a go around of what people are working on <linusw_> hi <dsaxena> the go around will be in order of people joning, so nhe, dmart thomas-ab, shawnguo , svenkatr rnayak , linusw_ and then whoever joins <dsaxena> From my end: <gcl> I'm here too (but distracted for the next 10 min) <dsaxena> - Please make sure you're registered for Linaro Connect and started working on flights, visa, etc. Please let Arwen know if you need support in that * npitre here <mounir> Arwen is sick this week, copy Stephen if you need anything from Arwen <dsaxena> tnx <dsaxena> - For next Monday's meeting, I'd like us to have more of a brainstorm session on what are some things to focus on the next cycle beyond what we are currently working on <dsaxena> please think about that, talk to your internal engineer teams <dsaxena> - For Linaro connect, our format will be to have morning dedicated to summits/meetings and afternoons dedicated to hacking. If there's a topic you would like to see discussed in detail with a larger group than just the team, please let me know and I can schedule a summit session <dsaxena> - next topic is work items/bps. We're still not doing the best at using these to help TSC and management understand what we're getting done. With a team this size it also really is a helpful tool to help me stay on top of what everyone is doing and answer questions like "what's been done for feature X"? <dsaxena> There's an understanding at Linaro that the BP/WI process doesn't map fully to the way kernel development works, so we'll need to keep thinking of how to use it in a way that does work, I'd like to discuss this at connect <dsaxena> for now, I'd like mounir to share a bit about what other teams are doing <mounir> as you know, we have partitioned some of the bp Work items in Work items blocks <mounir> each Work item block for each month <mounir> The toolchain and Power Working groups are taking these Work items blocks and creating bp's for each block <mounir> that way they can target each bp for a month (milestone) <mounir> if you like to do similar thing, I can create the bp's in Launchpad <mounir> does this make sense ? <dmart> mounir: maybe, but it already feels like there are too many blueprints <dmart> others might disagree with that, though <dsaxena> i think we could try it... <dsaxena> for one month and then reassess <dsaxena> one thing that is a challenge with us is that the work we do really has nothing do with a Linaro release <dsaxena> we push thing upstream and they release when upstream merges them <mounir> dsaxena, dmart, sure we can try it, we can pick few bp's to try it on we don't have to do it for all the team at the begining <dmart> mounir: agreed, we should certainly give it a try. Part of our problem is that launchpad doesn't understand work items, so having more blueprints might work better <npitre> I must provide a bit of a disagreement here <npitre> the work I do is mainly driven by upstream reactions <npitre> sure the goal is set up upfront <npitre> but the result, and even the way to achieve it is highly unpredictable <npitre> for example, I had to rework my patches many times to accommodate upstream comments <npitre> and then I found new obstacles <npitre> so I now have a patch series that doesn't look like the original that much <npitre> and it took me 3 times the time I originally anticipated <npitre> such is the nature of upstream kernel work * CosmicPenguin (~email@example.com) has joined #linaro-kernel <npitre> so whatever WIs I had establised first, they would all be screwed up by now <mounir> npitre - one way to handle this, is to consider the average number of iteration a patch has to go through ( given, not every patch is the same). But let say on average the patch takes 2 iterations <mounir> npitre, then we should have a WI's that say, get feedback from upstream, fix base on upstream, resubmit <npitre> the patch... well I started with 3 patches: 3 WIs if you want. <mounir> some patches may take one submission, some may take up to 3 times, etc... <npitre> in the end i.e. as of yesterday around midnight I have 21 patches for the same goal <linusw_> for pinmux/pin control I just estimated something high like 10 iterations of the patch set <npitre> never could I have expected this seemingly simple task to end up being a huge patch series <linusw_> it's now at v7 <dmart> I guess we have to consider whether we're just making work -- if the work items are not really expressing or tracking anything meaningful, it may be an overhead for the affected tasks <linusw_> I think the CMA is at v15 IIRC <linusw_> so some kind of guesstimates can be done <npitre> kernel work is more about measuring the deployed _effort_, because _results_ are highly volatile <mounir> and not guaranteed <mounir> so we have to allow for that and need to be smart about it. depending on what the patch is doing <mounir> for example if a patch is invasive and affect many subsystems, we expect to have a lot of push backs <npitre> this is why I'm now revising my guestimate for the single kernel zImage from 3 months to more than a year <mounir> if it is a new few feature no one is yet dependant on it, not so much <dsaxena> but almost anything we do will touch old code and need feedback <dmart> mounir, dsaxena: do you consider the main problem is steering the work and achieving goals; or is it a problem of reporting what we're doing? <mounir> dmart it is actually both <mounir> dmart steering is not so much with this team which highly self driven <dsaxena> both. it is definitely harder for me to make small in-course decisions to re-assign someone w/o a place to track the full affect of that decision on work <mounir> but at the end we have to say we have done and we have to talk about acheivement the roadmap set by the TSC <dmart> I'm just wondering whether we can decouple the two halves of the problem. <dmart> ...but I don't currently see an alternative which would be all that much better * dmart notices that there are 20 minutes left btw <dsaxena> dmart, tnx. <npitre> I think this is worth having a full session at Connect to discuss this issue <dsaxena> I say we try mounir's suggested approach for october and in november at connect we hash this out in more detail <dsaxena> npitre, agree * arnd (arnd@nat/ibm/x-gwqqcopdgpmkoxpk) has joined #linaro-kernel <mounir> dsaxena, I will pick a couple of blueprints and try it out <dsaxena> mounir, tnx <dsaxena> i'll setup a session bp for us to talk about this @ connect <dsaxena> we're a bit tight on time now for a full round of go-arounds at this point <dsaxena> but i think this was an important discussion to have <linusw_> dsaxena: a blueprint for discussing blueprints, I really like that ;-) <arnd> Ah, I'm finally in. I had connection problems with too many people from the one IBM IP address trying to get on freenode simultaneous <dsaxena> arnd, welcome. we've been discussing bp/wi's and process <arnd> ok <dsaxena> does anyone have any major blocking issues that they need to bring up? * npitre wishes time was more extendable <linusw_> nhe: do you have everything needed to work on U8500 DT now? <nhe> Yes. I have decided that the Snowball DT development is to go with the uboot track. The blue print updated accordingly. <linusw_> \o/ <nhe> Now on Snowball device tree development. <nhe> A question though: How do I best handle the uboot patches for snowball device tree? The Snowball DT work will not really be useful without the uboot patches. <nhe> It is not kernel work, and the patches need to be cleaned up a bit if they are going to be mainlined into uboot... <linusw_> nhe: we mainline them, as should've been done ages ago. <nhe> Linus perhaps... ? <dsaxena> nhe, talk to jason hui from KWG. he is a u-boot maintainer <nhe> dsaxena: noted. But still it is not DT work on snowball... <dsaxena> nhe, understood, but if it's needed to enable it, we need to get it done <dsaxena> why does the zImage-append patch not work for you? <nhe> dsaxena: Perhaps Linus is better on explaining that... ;-) <linusw_> nhe: if fixing U-Boot is a prerequisite to working on DT it must take precedence by priority-inheritance <dmart> Can zImage dtb append be used to decouple that dependency? <linusw_> dsaxena: we do not know why it is not working, kernel freezes before earlyprintk <linusw_> dmart: we tried that and failed <nhe> ok. 10 min left... <linusw_> dmart: I also tried it on the RealView PB1176 and failed there too <linusw_> dmart: might be my incompetence tho <dmart> Using npitre's most recent patches, it worked for be on vexpress <dmart> ... I haven't tried it on other platforms though <dmart> I will be posting vexpress DT patches really soon now ... there are some upstream loose ends to be tied, but I'll get things posted and discussions can go from there. <linusw_> dmart: did you append and create a uImage or did you upload an image using JTAG? <svenkatr> dsaxena, arnd: I need some suggestions on the eMMC HPI design problem. I've sent you an email and explained it a bit more on the wiki <dmart> linusw_: uImage <dsaxena> linusw_, nhe , npitre , dmart can you sync up after this meeting over email to try and figure out how to move forward? <linusw_> dmart: h'm! <linusw_> I bet I'm screwing something up trying to use appended DTB :-( <dsaxena> svenkatr, saw that will read and grok after meetings today <npitre> dsaxena: sure, let's just hang around here after the meeting <dmart> ok for me <arnd> svenkatr: I will have a look <nhe> I have to be off after the meeting, unfortunately... but we can continue with email...
WorkingGroups/KernelArchived/Meetings/2011-09-19 (last modified 2013-01-14 19:45:14)