This month's meetings

WorkingGroups/Kernel/Meetings
<< <  2011 / 4 >  >>
Mon Tue Wed Thu Fri Sat Sun
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  

Meeting info

  • Kernel WG meetings are conducted over IRC: #linaro-kernel on Freenode.

Attendance

  • 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
  • cosmicPenguin

Agenda

  1. Logistical announcement
  2. Around the table: Work Items updates, what's next in pre-announced order
  3. BUGS review

Action Items from Previous Meeting

Minutes

  • 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.

Actions

  • 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

IRC Log

<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 (~a0131687@122.179.48.178) 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 (~nobody@soa.codeaurora.org) 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)