This month's meetings

<< <  2011 / 8 >  >>
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 31        

Meeting info

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


Morning Attendees

  • Loïc Minier: x
  • Paul McKenney:

  • Arnd Bergmann: x
  • Anand Gadyar:
  • Per Forlin: x
  • Mian Yousaf Kaukab:
  • Nicolas Pitre: x
  • Dave Martin:
  • Shawn Guo: x
  • Mounir Bsaibes: x
  • Grant Likely: x
  • Andy Green:
  • Kiko: x
  • Zach: x

Evening Attendees

  • John Stultz: x
  • Jeremy Kerr:
  • Jason Hui:
  • Grant Likely:
  • Aneesh V:
  • Thomas Abraham
  • Sanjeev Premi:
  • Nishant Kamat:
  • Paul McKenney:

  • Mounir Bsaibes: x
  • Shawn Guo:
  • Zach: x


  1. Blueprints / Around the table
  2. 11.11 Cycle Planning
  3. BUGS review

Action Items from Previous Meetings

To see the completed action items:

Minutes From Today's Meetings

  • Updates on 11.05 Work Items
  • Cycle 11.11
    • Per has concern about TR K7 Storage performance, there are bp's with no drafters/assignees, 7.2, 7.5 or 7.7, 7.8, 7.9 7.11
      • 7.2, 7.5, 7.7 are low priorities
      • 7.8 per Arnd seems like a non-item, SDXC does not require any device driver support
      • 7.9 per tixy Debian's 2.6.32 ARM kernel runs eSata. So this work may already been done.
      • In summary we Will skip 7.2, 7.5. 7.7, 7.8 & 7.9

      • What is left is 7.11 to look for a drafter for
    • Need to find out whether to keep a separate session for RAS or combine it with other session, if we decide to run a session, we need an owner for the session
    • K3.7 Recommended Hardware Changes for Device Discoverability , isn't really a device tree topic, but rather getting the hw vendors to make discoverable hardware. It is low priority and can be handled by a PDF how-to document with a few examples, and a follow-up call with vendors
    • There's not any specific duplication between the kernel android session and the linaro-android track.
    • There might be an issue having to pass each linaro kernel change through gerrit review that may be slow.

Action Items From Today's Meetings

IRC Logs

Morning meeting IRC log

* kiko ( has joined #linaro-kernel
* dsaxena_ ( has joined #linaro-kernel
<kiko> good morning
<kiko> dsaxena_!
<gcl> dsaxena_: welcome!  (for real this week)  :-)
<dsaxena_> kiko: good morning!
<dsaxena_> gcl: tnx :)
<kiko> dsaxena_, plumber still to arrive or all sorted?
<dsaxena_>  kiko: I wasn't able to resched plumber, but I figured out enough about what's happening that I think I can just point him at the problem ignore him
<kiko> dsaxena_, gotta hate plumbing :-/
<dsaxena_> s/ignore/and ignore/
<dsaxena_> yeah...luckilly I found a temp measure so I didn't have to empty buckets all night
<kiko> you won't believe this
<kiko> lool is having a... PLUMBING EMERGENCY
<dsaxena_> kiko: you jest?
<kiko> an absent neighbor in his building has water running out of his door, so loic is with the firemen sorting it out
<kiko> I wish
<kiko> that's a pretty unusual coincidence
* tixy ( has joined #linaro-kernel
<kiko> but I guess coincidences are always like that
<kiko> anyway
<kiko> mounir, around?
<mounir> kiko: yes
<kiko> mounir, paul will be absent today, and lool as well (see above); could you help run the meeting and dsaxena_ and I will help out?
* arnd ( has joined #linaro-kernel
<mounir> kiko: sure, please see the link for the agenda 
<kiko> excellent. let's get started!
<kiko> heya arnd, tixy
<kiko> just waiting for mounir to get started
<arnd> hi
<kiko> mounir?
<dsaxena_> arnd: greetings
<mounir> we need to wrap up cycle 11.05,  everyone need to update their work items status - let us gor around the table to get a quick update
* bones10 ( has joined #linaro-kernel
* JohnLinn (~IceChat7@ has joined #linaro-kernel
<kiko> actually, I had some comments about the status
<mounir> kiko, go ahead
<kiko> the device tree for more socs spec
<kiko> covers samsung orion and the st-ericsson u8500 as well
<kiko> however, I'm unsure about the status of the support for either of these boards
<kiko> I know that OMAP and mx51 are actively being used in images already, which means the kernel work is done
<kiko> and versatile is waiting for an updated release
<kiko> but orion and u8500 are mysteries to me
<kiko> I /think/ thomas finished the orion work, and arnd (?) is scheduled to work on the u8500
<kiko> but is that actually the case? gcl may know more
<arnd> I have the u8500 board and wanted to do some work on that, but I haven't actually started
<npitre> kiko: I'm in conversation with the corresponding landing team leads to merge those
<kiko> npitre, for orion, u8500 or both?
* pfefferz ( has joined #linaro-kernel
<kiko> hey pfefferz
<npitre> kiko: both
<pfefferz> hey kiko
<npitre> kiko: no idea of the extent of the support for them yet though
<kiko> npitre, my understanding is that the u8500 work isn't started at all and that arnd was tasked with it -- am I wrong?
<kiko> hmmm
<kiko> well, I see a work item marked DONE by thomas on samsung
<gcl> kiko: I believe you're right, but I'm checking my email archives to be sure
<kiko> i..e
<kiko> Thomas Abraham done other-kernel-device-tree-for-more-socs Essential Enable and test basic DT on s5pv310
<kiko> sounds like it's in a black hole
<kiko> does anyone know where this work with thomas lives?
<kiko> or what the status of it is?
<kiko> and is there additional u-boot work necessary as well?
<kiko> (I know tushar has an orion u-boot branch at least)
<kiko> arnd, will you have time to work on the u8500 in the next 3 weeks? I'd love to see this done as at the moment we can't announce support across all boards
<arnd> kiko: very unlikely, unfortunately
<gcl> kiko: s5pv310 is done
<kiko> gcl, mmm so what's missing to get it live in our images
<arnd> I haven't even been able to boot the board so far, I'd probably need this week to get a work environment
<arnd> and will be travelling the next two weeks
<kiko> arnd, could we preempt something else and focus on this?
<kiko> arnd, a not-yet-booting board is a bad sign, indeed
<kiko> mm
<gcl> hmmm; everything should be there; I'll investigate
<shawnguo> kiko, gcl: maybe it's because lmc does not support s5pv310 dt
<dsaxena_> kiko, arnd:  or is there someone else with spare cycles to this?
<kiko> mounir, okay, let's record an action for gcl to chase down what's missing to get DT for the orion delivered in the form of images and linux-linaro
<gcl> kiko: igep is the other missing bit
<kiko> gcl, IGEP was on you ;)
<gcl> but there is a bug filed against that
<mounir> kiko, ok 
<gcl> actually, I don't have an IGEP, but mounir volunteered to test if I wrote the patch
<gcl> both of which got done, but there is a bug somewhere
<mounir> kiko, I have tested it and opened a bug against IGEP 
<kiko> gcl, mm, I have an IGEP in fact, as I believe do asac and lool
<kiko> gcl, if we brought an IGEP to UDS, would that help?
<mounir> kiko, with the help of gcl and loic
<gcl> best case would be for someone with hardware and spare cycles to take on the bug report
<gcl> kiko: yes
<gcl> it's probably easy to fix
<kiko> mounir, okay, record an action for me to organize an IGEP and U8500 to be taken to UDS
<pfefferz> Are we officially supporting IGEP?
<mounir> kiko, ok 
<kiko> pfefferz, officially is a scary word
<pfefferz> Let me rephrase that, should we be doing daily builds for IGEP
<kiko> pfefferz, well, I believe we do, at the moment, generate a daily igep hardware pack
<kiko> that doesn't extend at the moment to android and I don't believe it will
<pfefferz> okay, thanks
<pfefferz> I'll make a note
<arnd> kiko: I can probably hand on my u8500 to someone else if needed, and I can write some of the device driver patches
<kiko> arnd, could you at least bring it with you to hungary? that way I can complain to deepak about it and it might even get done ;)
<dsaxena_> kiko: :)
<arnd> yes, I'll definitely bring it along
<kiko> that's great
<kiko> mounir, can you bring your IGEP to hungary?
<kiko> if that's a yes, that closes the topic of that blueprint
<mounir> kiko,  I can - any issue for custom, etc...?
<arnd> I can also bring my igep
<arnd> no customs for me
<mounir> arnd, if you can bring yours it may be better  
<arnd> ok
<kiko> okay, sounds like a deal
<kiko> arnd, we owe you extra beer this time
<mounir> kiko, you are off the hook from the action :-)
<kiko> yay
<kiko> okay
* JohnLinn has quit (Quit: Light travels faster then sound, which is why some people appear bright, until you hear them speak)
<kiko> okay
<kiko> two more blueprints I wanted to know more about
<kiko> there's a single task for aneesh on
* CosmicPenguin ( has joined #linaro-kernel
<kiko> I don't think aneesh is on, but npitre, the item that is stated as inprogress says:
<kiko> Implement caching and factoring out of cache geometry at runtime
<mounir> kiko, I have not heard from Aneesh in a while  - I believe he was busy with other tasks
<kiko> I wanted to know whether this is something important that we should aim to get to or not
<kiko> mounir, if he is, he's keeping it pretty secret:
<npitre> kiko: I don't think it is that important
<kiko> mounir, can you take an action to sync up with aneesh on this today? CC dsaxena_ so he knows as well
<kiko> npitre, what do we miss if we don't have this? just a need for a bit more configuration?
<mounir> kiko, ok will do  
<npitre> kiko: maybe a slight decrease in performances
<kiko> npitre, non-critical then -- cool.
<kiko> okay
<kiko> last blueprint I'll bother the meeting about:
<kiko> one last item in-progress with dave martin
<kiko> which is ensuring core dump NEON handling
<kiko> does anyone have status on this?
<npitre> kiko: as far as I know, the work has been done
<kiko> npitre, is this kernel or tool work?
<npitre> kiko:  both
<mounir> the work item that is left: make sure that NEON is handled by userspace core dumps: INPROGRESS
<npitre> kiko: I certainly merged dmart's patches for that in the Linaro kernel, and I think that the equivalent gdb patch also was done by someone in the tools group
<mounir> kiko, I will check with Dave, whether he just need to update the Work Item Status
<kiko> npitre, I'll check the latter with michael hope then, thanks -- mounir, perfect
<arnd> mounir: uweigand should know about the upstream status in gdb
<kiko> okay, end of my specific blueprint questions
<mounir> arnd, ok, will ask uweigand
* kiko apologies for bulldozing 20 mins of call
<mounir> kiko, that is fine all on the same spirit to check on cycle 11.05
<mounir> arnd, any update from your side on finsihing your Work items?
<arnd> sorry, no update. I've spent most time since ELC wrapping my head around the memory management stuff
<kiko> arnd, the only item I'm aware of with you is that virtio work item
<kiko> what is it again?
<kiko> arnd, something about PCI I/O mapping in ARM versatile?
<kiko> arnd, think you'll get that done for this week?
<kiko> arnd, and then there's a qemu and kernel patches TODO
<kiko> ah, the whole BP is deferred
<arnd> I can definitely mark the one INPROGRESS item as done
<arnd> I had the patches ready ages ago, but then lost track
<kiko> arnd, ah, shame, would be an easy win then :)
<lool> Hi folks
<kiko> heya lool
<lool> Sorry for missing the meeting -- emergency here  :-)
<npitre> arnd: you can send your patches my way and fight them with rmk another day
<kiko> "in the wake of bin laden's death, plumbing emergencies strike USA and Europe simultaneously?"
<lool> eh, at least 4 flats with water, 4 floors, 1 elevator
<kiko> arnd, now that's some good advice
<arnd> npitre: ok, I'll dig them out and make sure they apply on arm-next
<kiko> rock on
<mounir> npitre, anything from your side any updates on 11.05 work items?
<npitre> I'll have to start using some forceful tactics for landing team's work to be sent my way in time for the release
<kiko> that's the spirit
<npitre> I'd like to have everything merged _this_ week
<mounir> perfor, you want to go next?
<npitre> let's forget about next week as everyone will be on the party all week long
<gcl> npitre: indeed
<npitre> so that doesn't leave much time to deal with possible fallouts
<dsaxena_> npitre: are you not getting regular drops from landing teams?
<npitre> dsaxena_: not really, unfortunately
<kiko> npitre, I can talk to scottb about this today, we have a call in about 3h
<mounir> shawnguo, r u there?
<npitre> kiko: Scott and I already discussed this issue
<shawnguo> mounir: yes, I'm here
<mounir> shawnguo, any update on your WI's?
<npitre> kiko: I'm prodding the LT leads directly at the moment
<kiko> npitre, funny, I was going to say exactly that
<kiko> npitre, I have a call with the leads shortly too, I'll remind them of the looming deadline
<shawnguo> mounir: I do not own any 11.05 blueprint, as I join the team pretty late
<perfor> mounir, yes I had some concerns regarding planning for storage for LDS
<mounir> perfor, just one sec let us finish inquiring on 11.05 - will start 11.11 in a sec
<mounir> anyone else like to talk about 11.05 items?
<kiko> one quick one
<perfor> mounir, good point
<kiko> npitre, there's an item on you about the non-NEON memcpy routes from TCWG
<kiko> npitre, did that get done, and if not do you need help getting it done?
<npitre> kiko: I'm unaware of it, or I forgot about it ;-)
<kiko> npitre, mmm, well, I see it in
<kiko> page even has your name in it :)
<kiko> npitre, I guess the short story is that there are a few optimized implementations of memcpy that the TCWG has delivered
<kiko> npitre, if you want to try merging one of them I'll get dr. david gilbert to talk to you
<npitre> kiko: OK now remember
<npitre> kiko: well, I think that toolchain ppl were supposed to provide some code
<mounir> few minutes left for 11.11 discussion:
<npitre> kiko: I saw a comment from david gilbert saying that the kernel routines were pretty good already
<kiko> hmmm
<kiko> npitre, they do have the code -- mounir, okay, action with me to get somebody from the TCWG to comment on this
<npitre> (obviously, since that code is mine)  ;-D
<mounir> kiko, ok
<mounir> 11.11 cycle we are doing pretty good in session setup, we have few concerns and session ownership issues.
<mounir> but let us start with perfor concerns
<mounir> perfor, go ahead 
<perfor> I raised my concerns in a reply to your email mounir on Linaro@UDS.
<perfor> let bring it up here as well
<perfor> there are 5 blueprints under storage performance that don't have an drafter or assignee
<mounir> yes - I saw the email -  K7.2, K7.5 and K7.7 have no drafters
<mounir> perfor, you also prefer someone else to handle k7.9 
<mounir> for description of thes items, see the link:
<perfor> I depends what the ambition are for those blueprint. I can add a few comments on all of them but there may not be any details.
<mounir> kiko, dsaxena, this is an issue we need to resolve for UDS otherwise these topics will not be handled
<perfor> If the goal is to define WI during the session the blueprints need to well prepared
<kiko> perfor, mounir: it's not clear what you are saying or asking for
<kiko> perfor, are you not the assignee for them?
<perfor> kiko, sorry.
<perfor> kiko: I want someone to become drafter for the missing ones
<perfor> 7.2, 7.5 7.7
<kiko> gotcha, you need a drafter
<perfor> yes :)
<kiko> perfor, who else has done with in storage apart from arnd?
<kiko> s/with //
<perfor> I can add some comments to them but it wont be enough
<kiko> perfor, we give you free reign to coerce fellow KWG members to draft for you
<kiko> do you need help identifying people, or coercing them? :)
<perfor> I would need  help identifying them too
<mounir> perfor, do you also need someone to handle the discussion for these items in UDs, or you can cover them in your session which I have to make 2 hours instead of 1
<perfor> I think one session is enough
<mounir> perfor,  very good, I will make sure your session is 2 hours long
<perfor> I can handle all of them if I get help drafting blueprints
<kiko> perfor, okay, I suggest arnd as a drafter for one of them, dmart for one of them, and the new guy, venkat, to draft the third?
<mounir> gcl - I thinkyou are set, But I have one question for you: For K3.7 Recommended Hardware Changes for Device Discoverability , is it covered or you need abother session?
<mounir> s /abother session/ another session/ 
* robher has quit (Read error: Connection reset by peer)
<gcl> mounir: I sent an email about that about 1/2 hour ago
<perfor> I also made a assumption that low prio is not very important and a proper spec is not needed. Is this a valid assumpption?
<mounir> gcl - ok did not see the email, will check after the meeting
<mounir> Shawnguo, r u going to be at UDS?
<gcl> mounir: that isn't really a device tree topic, but rather beating on hw vendors to make discoverable hardware
<kiko> perfor, if you don't plan on doing the work in the next 3 months, don't discuss it or draft it
<shawnguo> mounir: yes, I am
<kiko> gcl, and mmm, how are we going to make that a successful effort?
<perfor> kiko: thanks for clarifying
<gcl> kiko: I don't know.  I'm not sure if a session at uds will be valuable or not
<kiko> gcl, it would probably be valuable if davidrusling made an effort to get the right people there
<arnd> perfor: I have no idea what 7.2, 7.5 or 7.7 are about
<gcl> and it's not very high on the priority list
<gcl> kiko: part of the problem is I don't even know what we should be asking for yet
<kiko> gcl, more cheaply, I could give some suggestions: a nice PDF how-to document with a few examples, and a follow-up call with vendors
<kiko> gcl, ah, I see
<mounir> shawnguo, can you handle the Improve Linux RAS session? I have sent a note to Jason, But I am not sure he will be at UDS
<perfor> arnd: now I see... they are alll low prio ones. I wanted help on drafting 7.8 7.9 and 7.11
<shawnguo> mounir: I'm ramping up with K9.1, and has no idea about others
<perfor> arnd: my typo
<npitre> gcl: discoverable hardware is useless if it isn't common to at least a few different SOCs
<tixy> perfor, mounir: I don't know if this is useful info... K7.9 is "verify eSATA works in current kernel".
<tixy> Debian's 2.6.32 ARM kernel runs my eSata Sheevaplug fine (ARMv5 Kirkwood SoC).
<shawnguo> mounir: if Jason will not be there, I'm unsure if RAS deserves a session.
<gcl> npitre: right
<shawnguo> mounir: unsure if how many people will be interested in the session
<shawnguo> s/if//
<arnd> perfor: 7.8 sounds like a non-item to me, AFAIK SDXC does not require any device driver support
<perfor> there are no drafters for 7.2, 7.5 or 7.7 but that is less important since the prio is low. Still they need drafters if we intend to discuss it at LDS
<mounir> shawnguo, kiko, dsaxena_  K9.3 has kexe and 9.2 is offline CPU's to boot-loader node, what do you think?
<perfor> arnd: Itsn't it about adding support for SD 3.0 ?
<arnd> perfor: I'd be surprised if 7.9 had any development work, that one sounds like hw-specific ATA driver writing, i.e. landing teams, not kernel wg
<arnd> perfor: I thought we do support SD 3.0 already
<arnd> if there is anything missing, I can find out and write up what needs to be done
<perfor> arnd: well then we are done.
<perfor> arnd: there are patches but I haven't seen it merged yet.
<arnd> perfor: the hard part about SDXC support is missing ExFAT file system support, but I don't know if that is something Linaro can even work on
<arnd> perfor: the patches were about SDHCI 3.0 support, not SD base spec 3.0
<arnd> at least the patches I saw last
<mounir>  shawnguo, kiko, dsaxena_ should we have a session for RAS or not?
<kiko> mounir, can I get a link so I can understand a bit more about it
<kiko> arnd, perfor: I'd not take on any SDXC work for now
<npitre> RAS is Paul's nomenclature
<mounir> kiko, go to the bottom of the table, there are links to the TR's
<kiko> oh, now I remember this silly acronym
<kiko> mounir, yes, we need a session for kernel testing
<mounir> kiko, npitre has a session for monthly release which we invited Paul larson to it, if that is what you mean
<kiko> mounir, well, I think they aren't the same thing
<kiko> they are related
<kiko> one thing is having a meeting about kernel component releases
<kiko> and yes, we should have that and I should probably attend, paul larson too
<mounir> kiko,  we already have a session setup for RAs - we need and owner for the session
<kiko> the other thing is a session for kernel testing/auto-testing (I think that's what RAS means in practice)
<npitre> kiko: I don't think there is enough to talk about in one hour with monthly release, so I suggested that validation of that release be discussed at the same time
<perfor> kiko: ok lets skip 7.8 SDXC.
<kiko> perfor, I think the exfat thing is confusing, so let's not waste time on it until the TSC makes noise about it
<kiko> npitre, ah, that now makes more sense
<kiko> mounir, okay, then what npitre said
<perfor> kiko: I vote for skipping 7.2 and 7.7 too. I kind of came up with those but now I want to drop them.
<npitre> well, I have to leave now and go to vote (Canada election today)
* npitre leaves
<mounir> npitre, may whoever you vote for wins
<perfor> then if 7.9 eSATA is already "done" then there is only one blueprint left for storage, 7.11 usb mass storage
<kiko> perfor, do it, you have /way/ too many items under K7
<mounir> kiko, to clarify we should have 2 sessions? 1) for monthly release + validation and 2) one for RAS?
<kiko> mounir, the one for RAS, you'll need to ask paul mckenney since, as npitre says, that acronym is his
<arnd> perfor: for 7.11 I also have no idea what it's about
<mounir> RAS is reliability, availability and serviceability 
<mounir> kiko, ok will ask Paul
<mounir> that is all i had for this meeting, any other topic to discuss?
<kiko> I know the acronym, but I don't know what emotion it is meant to convey
<kiko> :)
<kiko> thanks
<mounir> going once
<mounir> going twice
<mounir> thank you all - have  a good day - the meeting has ended
<tixy> I'll see people at UDS...
<mounir> tixy - looking forward to see you
* tixy ( has left #linaro-kernel
* robher (~robher@ has joined #linaro-kernel
* robher has quit (Read error: Connection reset by peer)
* bones10 ( has left #linaro-kernel
<kiko> npitre, reminded angus of the deadline, keep me posted if it goes unresponsive
* perfor has quit (Ping timeout: 276 seconds)

Evening meeting IRC log

<jstultz_vm> meeting time?
<mounir> Hi jstultz_vm  - yes
<mounir> anyone on, other than John and myself?
<pfefferz> I'm hear
<pfefferz> s/hear/here/
<mounir> Hi pfefferz 
<pfefferz> hi mounir
<mounir> This morning we talked about ramping up work items from 11.05 cycle and then moved to talk about 11.11 sessions setup and preparation for UDS
<mounir> jstultz_vm,  anything you want to talk about relative to 11.05 
<jstultz_vm> mounir:  not so much for 11.05. i've got a workitem or two to finish, but they aren't deliverables for the 11.05 release..
<mounir> ok then we can move on to 11.11 
<mounir> jstultz_vm, you are set for your sessions, correct?
<jstultz_vm> mounir:  i realized i've not written up a blueprint/spec for the config work (k1.4).. but i'm starting that now
<mounir> actually one session
<jstultz_vm> for the android session, yea. i'm planning on calling in at 1am or whatever time it is..
<jstultz_vm> my main concerns are just making sure the android common kernel tree work is well synced with the android platform team's work.
<jstultz_vm> other then that, the other android work is pretty much just constant chipping away at the android patch set.
<mounir> pfefferz, has sent a note about all the sessions he is conducting
<pfefferz> yeah...sorry for the wide distribution
<mounir> jstultz_vm, do you think there are duplication with those sessions?
<pfefferz> if people could take a look that would be great...if we've dupilating please point it out
<mounir> pfefferz, sorry we could not accommodate changing the name of the session due to the naming convention
<jstultz_vm> mounir:  i don't think there's any specific duplication between the kernel android session and the linaro-android track.
<pfefferz> mounir: no problem
<jstultz_vm> mounir:  upstream-android-build is the onlly one that's close..
<mounir> jstultz_vm,  good to know 
<jstultz_vm> but i suspect that's upstreaming the userland parts
<pfefferz> jstultz: aye
<mounir> jstultz_vm,  you know where to write the specification on the wiki and link into the blueprint?
<pfefferz> my general idea for LDS is to talk about getting a Gerrit continuous integration loop
<jstultz_vm> mounir:  i think so..
<jstultz_vm> pfefferz:  how that interacts with the kernel side will be interesting to hear.
<pfefferz> which would affect all teams, since Android components (kernel, MM, etc...) would go through Gerrit hopefully
<pfefferz> wanted to bring it up in
<pfefferz> and
<jstultz_vm> pfefferz:  that may have some issues with the kernel side.. since we just import the linaro kernel changes.
<jstultz_vm> having to pass each linaro kernel change through gerrit review would be slow.
<pfefferz> jstultz_vm: yeah...would a kernel rep mind coming to one of those sessions?
<jstultz_vm> pfefferz:  but we'll see.
<jstultz_vm> pfefferz:  i'm not going to be there.. would love to hear more about it though..
<jstultz_vm> pfefferz:  you might try getting paulmck, but he's probably going to be busy
<pfefferz> jstultz_vm: yeah...I'll have a lot more, when its all working its fairly glorious
<pfefferz> jstultz_vm: thanks I'll drop him a note
<jstultz_vm> pfefferz:  my suggestion would be to plan for the kernel bit to be optionally in gerrit, and we'll see if we can make it work.
<pfefferz> sounds good, thanks for the feedback
<jstultz_vm> pfefferz:  i know there's already some folks on lkml that are grumpy about seeing gerrit commit ids in commit logs
<jstultz_vm> so culturally it might be a disadvantage to adapt.. but hopefully we can either make it work, or find some midground..
<mounir> anything else to touch base on  in this meeting ?
<mounir> next week we may not have the meeting and the follwing week Deepak probably will run it
<jstultz_vm> mounir:  cool!
<jstultz_vm> mounir:  oh! one more thing.. so blocked items for 11.05..
<jstultz_vm> mounir:  if they're not going to go upstream in the next 19 days, do we postpone them?
<jstultz_vm> some items i have queued for 2.6.40, for instance..
<jstultz_vm> clearly on their way, not blocked on any technical issues, just waiting for the merge window..
<jstultz_vm> but i don't want to wreck the stats by having the unfinished "blocked" items
<mounir> jstultz_vm,  I don't think we should postpone them, as probably the work is done, we are just waiting on upstreaming the work
<jstultz_vm> mounir:  right. ok.. just postponed pulls them off the stats, where as blocked doesn't..
<jstultz_vm> mounir:  so if folks are getting grumpy about the % completed, in some cases there's not action to be done..
<mounir> jstultz_vm, yes - maybe we should have a list of them and keep an eye somehow to track them
<jstultz_vm> mounir:  ok.. no worries. just wanted to bring it up.
<mounir> jstultz_vm,  many WG have the same issue, we need to come to a general agreement how to treat them.
<jstultz_vm> mounir:  yep
<mounir> Michael Hope has suggested that when patches are committed to treat them as done vs waiting until they are released
<mounir> but that may apply to the toolchain more than the kernel
<jstultz_vm> mounir:  yea, but there's the queued bit, which isn't a 100% guarantee, but usually means they're going to go in when the merge window opens.
<jstultz_vm> and for our work its more complex because there's the linaro tree and upstream.
<mounir> yes this is an issue we need to address and make sure from the bean counting perspective the work is counted correctly
<mounir> jstultz_vm, question: sometimes bloked also means that a patch is submitted, but we don't know whether it will be accepted or not (i.e. we are not receiving feedback on it)
* robher has quit (Ping timeout: 240 seconds)
<jstultz_vm> mounir:  right..
<mounir> jstultz_vm, in that case if it is rejected,  the work will have to be re-done - Then we have to allow in the next cycle some time to handle blicked items
<jstultz_vm> mounir:  ok. i think that's all from me.
<jstultz_vm> mounir:  yea, something like that sounds good.

WorkingGroups/KernelArchived/Meetings/2011-05-02 (last modified 2013-01-14 19:33:51)