Wednesday 3 Nov 2010

People Present

  • TBA
  • slangasek
  • JamieBennett

  • dmart
  • hrw
  • jcrigby
  • ppearse
  • wookey
  • npitre
  • aviksil


  • Review action items from last meeting
  • Linaro@UDS show-and-tell
  • Reminder of 10.11 release candidate testing
  • Spec drafting

Action Items from this Meeting

  • slangasek, JamieBennett to discuss concerns raised at ELC about the new armhf port

Action Items from Previous Meeting

  • npitre to produce status from git about volume of Linaro kernel patch upstreaming
  • slangasek to nudge Keybuk to review bootchart changes rather than redirecting to upstream, since Ubuntu and upstream are quite out of sync (DONE)
  • everyone to look at the UDS schedule and subscribe to other sessions they're interested in attending (DONE)

Status Reports

  • TBA

Meeting Log

Meeting opened by slangasek at 15:07

  • <wookey_> slangasek: arm people pumpkin at 4:30 (i.e 1hr 20) for local UDS review meeting

    <wookey_> hopefully we'll be done by then

    <slangasek> yes, I'll try to make this a quick meeting

    <slangasek> I've mixed up the agenda for a change; "blueprint status" is still on there, but in fact the blueprint status for 10.11 is what it is at this point - so if you have anything to bring up about your existing blueprints, feel free to, but I'm mostly focused on the output from last week

    <slangasek> [TOPIC] Review action items from last meeting

Review action items from last meeting

  • <slangasek> * npitre to produce status from git about volume of Linaro kernel patch upstreaming

    <slangasek> * slangasek to nudge Keybuk to review bootchart changes rather than redirecting to upstream, since Ubuntu and upstream are quite out of sync (DONE)

    <slangasek> * everyone to look at the UDS schedule and subscribe to other sessions they're interested in attending (DONE)

    <slangasek> npitre: do you know when you might have a chance to pull some statistics from git? (I'll get our meeting minutes out in a timely manner this week, so you have a reminder...)

    <npitre> I did for anmar a while ago

    <npitre> from memory this was something like 13 patches

    <slangasek> oh, ok

    <slangasek> could you bounce me a copy of that?

    <npitre> I should check again with latest kernel, but nothing record breaking in any case

    <npitre> sure, well I'll just redo the stat

    <slangasek> ok, thanks :)

    <slangasek> [TOPIC] Blueprint status; Linaro@UDS show-and-tell

Blueprint status; Linaro@UDS show-and-tell

  • <slangasek> so as I said above, rather than talking about the status of all current blueprints, I'd like everyone to talk a bit about last week - something they've learned, or some exciting thing they know we'll be working on this cycle that they want the team to know about

    <slangasek> last week was busy for all of us, so I want to make sure we reconnect now and have a chance to share :)

    <slangasek> $ echo $(shuf -e hrw npitre jcrigby dmart wookey slangasek ppearse JamieBennett aviksil)

    <slangasek> JamieBennett slangasek wookey ppearse hrw jcrigby dmart npitre aviksil

    <slangasek> JamieBennett: if you're still around and not sucked back into Plumbers doings

    <JamieBennett> sorry, guys, not much to report, preparing for the release on the 10th in my main objective

    <JamieBennett> Please test the images to death :)

    <slangasek> right :)

    <slangasek> I'll go next

    <slangasek> so one of the exciting things we discussed last week was bringing up a new hardfloat ARM port

    <wookey_> which is actually going back to the original 'arm' way of doing things in the old ABI - :-)

    <wookey_> just this time round there actually _is_ some FP hardware

    <hrw> wookey_: when men were men and used NWFPE?

    <slangasek> that will give measurable performance / responsiveness benefits over the current port - but won't work on all hardware, so we'll continue to see the armel port around for a while in parallel

    <JamieBennett> slangasek: we need to carefully investigate the impact of switching to HF for the wider community

    <hrw> slangasek: are there armv7a without fpu?

    <ppearse> slangasek: I've been asked - what's your estimate of "a while"?

    <ppearse> slangasek: I said two cycles.....

    <slangasek> but particularly exciting is that, since we're bootstrapping a port from scratch, we will be able to make it natively multiarch-friendly from the start - i.e., an ELF loader path that we can guarantee won't conflict with (and will be coinstallable with) armel's

    <slangasek> so we may be able to support soft migrations from armel to armhf in 11.11, for those who are interested in such things :)

    <wookey_> that would be very nice...

    <slangasek> ppearse: armhf will still be in the bootstrapping phase for 11.05, so armel will be around at least that long - whether it stays longer mostly depends on how much demand there is for it elsewhere

    <ppearse> slangasek: Good practice for the next ARM architecture

    <JamieBennett> slangasek: there was some concern at ELC about the switch

    <wookey_> JamieBennett: from whom?

    <slangasek> i.e., Canonical is more likely to continue carrying it in the archive and working on it for a couple of cycles if they have contractual demands for it

    <wookey_> (I agree it's a big deal)

    <JamieBennett> wookey_: Not sure who but Philippe has the details

    <slangasek> JamieBennett: sounds like something we should discuss after the meeting?

    <wookey_> I'd expect binary providers to have most issues

    <JamieBennett> slangasek: right

    <slangasek> [ACTION] slangasek, JamieBennett to discuss concerns raised at ELC about the new armhf port

slangasek, JamieBennett to discuss concerns raised at ELC about the new armhf port

  • <slangasek> wookey_: your turn

    <wookey_> O, well you done armhf - except to say Debian sprint on subject is being organised, which should help cooridnate things

    <wookey_> I Attemped remote attendenace of UDS -

    <wookey_> not terribly satisfying experience due to networking outages (and a

    <wookey_> flat batt), and people not necessarily reading IRC

    <wookey_> But still got some useful input of cross-=building use cases and development direction

    <slangasek> hrw: armv7a w/o fpu> maybe not... maybe everything Ubuntu currently supports will want to switch, I haven't looked closely yet

    <wookey_> mostly I was at CELF (ELC-E)

    <wookey_> Yocto is new Linux foundation build system. (appears to be OBS+bitbake). Will review to see if it is relevant.

    <wookey_> lots of good stuff. met people making openJVM crossbuild properly and AC100 hackers,

    <wookey_> won a pandaboard (coming 'soon') and intel black sand board

    <hrw> wookey_: Yocto is more then just build system

    <wookey_> flash filesystem benchmarks from Michael opdenaker very interesting - showed YAFFS to usually be fastest (unlike 2 years ago)

    <wookey_> slangasek: I'm not totally clear on what users had to say about cross-uilding that we all agree was relevant

    <hrw> personally I like Yocto - more visibility for Poky and OpenEmbedded + OE has more pushes to update/reorganize some things

    <slangasek> wookey_: right - we can work together this week to distill that down and set our focus for this cycle

    <wookey_> I mailed you and loic about it, which I guess is your opportunity to add input

    <slangasek> ack :)

    <wookey_> I suspect multiarch stuff may be even more signifcant if we want to use it soon for armhf

    <wookey_> might need to start there

    <wookey_> Currently in middle of upgrading to maverick

    <wookey_> and I think that's all for now

    <slangasek> ok, thanks

    <slangasek> ppearse:

    <ppearse> OK - leaving aside tech stuff I was excited to (finally) realize what linaro is for.

    <ppearse> Apologies to dmart who has heard all this before

    <ppearse> If one is a large manufacturer (possibly named after a fruit) one can produce a set of gadgets that all draw from the same software stack

    <ppearse> Providing your users with a warm fuzzy all my gadgets love each other feeling

    <ppearse> But if your an individual OEM making say an MP3 player you've got to find that all somewhere.

    <slangasek> I guess we won't put a "Who we are" explanation that involves fruit on, though :)

    <ppearse> I see Linaro providing the tools to allow individual manufacturesrs to pull frm the Ubuntu stack, whittle it down to fit and push it on to the market

    <wookey_> are cherry still going? :-)

    <ppearse> Except to say we take the I out & put the you (U ubuntu) back

    <slangasek> heh

    <hrw> ppearse: I skip Ubuntu from this

    <ppearse> Ti seemed to like that anyway

    <slangasek> ppearse: nice summary :)

    <dmart> hrw: in principle, ARMv7-A without fpu is permitted but crazy. Nobody I've talked to has ever seen this.

    <slangasek> ppearse: anything interesting on the technical side from last week?

    <ppearse> That's me all ranted out

    <hrw> dmart: so for now we can just assume that armv7a == vfp3 mostly with neon

    <ppearse> hrw: We need to keep the linaro tools general enough to work on other distros....

    <dmart> hrw: we can't assume NEON is present

    <hrw> ppearse: exactly

    <hrw> dmart: and we do not assume that

    <wookey_> indeed. I worry about that too

    <dmart> ...but it's sufficiently common that it's worth enabling optimisations for it, provided we don't break others

    <ppearse> slangasek: Mainly I ended up with the eclipse potato

    <dmart> (I'm sure this is what you meant, but just clarifying)

    <hrw> exactly

    <hrw> ppearse: but aren't armltd people like eclipse?

  • dmart 's first Linux distro was Debian potato ... but I digress

  • hrw started from slink

    <ppearse> hrw: As?

    <slangasek> ppearse: alright :)

    <slangasek> hrw: your turn

    <hrw> ppearse: joking - DS5 presentation related

    <hrw> ok, me then

    <hrw> interesting things from uds... hardware part: smartbook and pandaboard went home with me

    <hrw> I hope to get smartbook working state (with provided kernel) in 2 weeks - under natty.

  • npitre brought home only t-shirts ;-(

    <hrw> kubuntu guys already shown some interest in how good with it work

    <hrw> npitre: pandaboard got TI -> davidm -> JamieBennett -> uds -> me -> home just because TI has bad experience with sending hw to @canonical people

    <hrw> pandaboard is up and running. need to get full 1GB ram working. works as build machine now (320GB sata disk)

    <slangasek> hrw: it's a general problem with TI being able to ship overseas to individual addresses, not specifically Canonical people, AIUI

    <hrw> did some performance tests for davidgiluk

    <npitre> hrw: 1GB with 2g:2g split, not highmem

    <hrw> npitre: thx

    <hrw> when will solve router problems then Yao from toolchain wg will use my board for cortex-a9 tests

    <hrw> software part:

    <hrw> we agreed that Linaro armel crosscompilers will be provided for lts + current + current-1 (lucid, natty, maverick now)

    <hrw> arm-linux-none will be provided for uboot builds

    <jcrigby> woot!

    <slangasek> :)

    <hrw> arm-none-none (bare metal) for people with cortex-m[01234] chips

    <wookey_> hrw: any prgress on doing all that in Debian too? I think that's important

    <hrw> multilib will be checked and enabled if will work - so softfp/hardfp + vfp/neon

    <hrw> wookey_: this is on my list too

    <hrw> I added workitems to my blueprint:

    <ppearse> hrw: I got requests for ARMv7, no thumb, 2 here

    <hrw> ~20 of them this time and list will probably change

    <hrw> ppearse: doable when I will rewrite flavours support

    <ppearse> hrw: ;-)

    <hrw> and tarball releases of toolchain are on a list too

    <wookey_> good

    <hrw> but for tarballs I would rather enable sysroot feature

  • slangasek nods

    <slangasek> hrw: anything else?

    <hrw> done I think

    <slangasek> jcrigby:

    <jcrigby> first uds was great because I got to put more faces with irc nicks

    <jcrigby> the DS5 presentation reinforced an old problem I have

    <wookey_> DS5?

    <npitre> wookey: the $5k debug solution from ARM

    <jcrigby> ARM development suite base on eclipse

    <ppearse> wookey: Developer Studio 5

    <jcrigby> ahh

    <ppearse> jcrigby: Command line too

    <slangasek> wookey_: find Pawel Moll and walk down the hall to his office for a demo :-)

    <hrw> jcrigby: it can be used without eclipse

    <wookey_> ah. we want openOCD+jtagtiny for 60 euro

    <ppearse> slangasek: He travels the globe for next two weeks

    <slangasek> ah :)

    <jcrigby> it just seems a shame that ARM and all the SOC vendors duplicating work

    <slangasek> jcrigby: an old problem - you mean "debugging", or something more specific?

    <npitre> wookey_: cheers!

    <ppearse> Don't knock it - it took seven years to persuade ARM we needed to profile software

    <jcrigby> nevermind

    <jcrigby> just an old rant of mine

    <hrw> slangasek: Pawel is in boston

    <npitre> jcrigby: your escape route is OpenOCD

    <wookey_> jcrigby: maybe linaro can improve matters there?

    <slangasek> hrw: right, so it's a bit longer of a walk

    <hrw> slangasek: and can get wet

    <ppearse> Not if Boston Lincolnshire UK

    <jcrigby> on another front I think maybe Linaro could do something like AppNotes

    <jcrigby> guidelines on how to approach a problem but not a complete solution

    <ppearse> Suggest wiki/blogs are better solutions

    <jcrigby> yes, wiki is fine

    <dmart> We need to work hard to maintain the wiki

    <slangasek> the wiki is certainly a good place to start, though

    <dmart> Currently it's not very friendly to non-linaro users, and very hard to find what you're looking for

    <ppearse> But not so hard as to publish an AppNote

    <jcrigby> but my point is we need to be able to take time to do stuff that is not necessarily general enough for ubuntu or even linaro

    <dmart> ... because ... an app note has to be self-contained and coherent

    <jcrigby> the boot time discussion is what makes me say this

    <jcrigby> lots of good ideas were shot down because they would not work on hw xyz

    <wookey_> ah yes - CELF had a 0.7s boot into QT app on a MIPS board

    <jcrigby> wow

    <wookey_> nice piece of work to show what you can do with some (signifncant) effort

    <wookey_> removing all the guff and optimsing carefully

    <slangasek> jcrigby: I would be happy to see such wiki documentation included as a workitem for the boot performance spec

    <jcrigby> slangasek, ok

    <dmart> "removing all the guff" = distro work

    <dmart> still not clear to me how much of that we expect to do

    <npitre> boot time optimization is all about customization, this is not generic work much

    <wookey_> very hard to do in a binary distro

    <wookey_> npitre: exactly

    <wookey_> we have to provide tools and info

    <ppearse> We need the tools to reduce footprint

    <slangasek> dmart: documentation is the better approach for us

    <ppearse> or the wiki page with suggestions ....

    <slangasek> and improvement of general solutions that make a better point of departure for anyone doing customization

    <wookey_> wiki page with suggestions =='info'

    <dmart> sure

    <slangasek> so I think we're all in agreement here :)

    <slangasek> jcrigby: anything else to add?

    <jcrigby> not really

    <slangasek> ok, thanks

    <slangasek> dmart:

    <dmart> Much stuff has already been covered

    <dmart> Worth summarising the memory footprint session though ...

    <dmart> There were some useful suggestions, and it sounds like a useful direction for this cycle is to improve instrumentation and automated regression tracking

    <dmart> As with the previous discussion, this may be the best approach so that users of linaro have the visibility to know how to optimise for their use case

    <dmart> There were some good new suggestions too - such as tracking use of X resources

    <hrw> xrestop?

    <dmart> yes (at least as a starting point)

    <dmart> still haven't played much with it

    <dmart> One slightly trivial point about UDS -

    <dmart> It could be a good idea if the session leader appoints someone to watch IRC

    <dmart> I didn't do this, but there were a couple of occasions where it took a long time for anyone to notice a contribution

    <slangasek> definitely agreed

    <ppearse> And rooms with quiet doors

    <wookey_> yes. IRC is weak feedback at best of times

    <ppearse> Is there a ubuntu page for these suggestions

    <npitre> the IRC screen should blank a couple times when it receives some updates

    <slangasek> in fast-moving sessions it can be hard to keep track of IRC as well, but it's important to involve folks who are remote

    <wookey_> remove the timeliness and it's confusing

    <dmart> Generally good discussions though

    <hrw> ppearse: there will be survey

    <slangasek> ppearse: there will be a survey sent out asking attendees for feedback, I believe

    <wookey_> Oh, and fix gobby server :-)

    <ppearse> OK

    <slangasek> heck, fix gobby *client* to be able to reconnect properly :/

    <dmart> wookey_: did you just take that action? ;)

    <ppearse> No I didn't just volunteer to fix gobby

    <slangasek> :-)

  • dmart sniggers

    <dmart> anyway, I think that's it for points not already made

    <slangasek> npitre:

    <npitre> someone from TI is about to send me 4 patches to enable Panda in the linaro 2.6.35 kernel

    <npitre> also contemplating a stable branch based on 2.6.36

    <npitre> and I should kick linaro-next again

    <npitre> that's about it

    <slangasek> ok :)

    <slangasek> aviksil:

    <aviksil> OK... attended few LDS sessions remotely

    <aviksil> Mailed Nicolas and you regarding LTTng merge.

    <aviksil> Updated Specification page for LTTng integration in wiki

    <aviksil> Drafted preliminary specification for "Improve boot-time performance on ARM, from power-on to user-space" based on the gobby note

    <aviksil> that's it :)

    <slangasek> aviksil: can you incorporate the point about providing wiki documentation on customizing systems for fast booting to that spec?

    <aviksil> slangasek: OK, i'll

    <slangasek> great, thanks

    <slangasek> [TOPIC] Reminder of 10.11 release candidate testing

Reminder of 10.11 release candidate testing - RC testing process has many presentations from elc-e

  • <hrw> has many presentations from elc-e

    <hrw> I used it in the uds-n mornings to have a hand on news

    <aviksil> ok, i'll go through it

    <slangasek> btw, testing of the RC should be coordinated through

    <wookey_> the quality is generally very high. It's the most densely-useful conf I go to

    <slangasek> I'm not sure that link was included in the announcement, had to dig a bit to find it

    <slangasek> [TOPIC] Spec drafting

Spec drafting

  • <slangasek> finally - as you all know, now that we've gotten wider input from UDS, we need to finalize our specs so that we can turn them into work plans

    <slangasek> the deadline for all specs is next Friday - so please have your specs marked as ready for review by next Thursday at the very latest

    <hrw> so far I added gobby notes into spec and created set of workitems + notes + rules

    <slangasek> (mark a spec for review by setting the "definition" status in the blueprint to "review")

    <wookey_> should we be putting in everything relevant or trying to size it to fit 1 cycle?

    <wookey_> (sizing does of course depends how many others one has...)

    <slangasek> you should all know by now which specs you're responsible for drafting, and you can find the list at<launchpad-id>/+specs?role=drafter

    <slangasek> if you're surprised by anything you find on that list, come talk to me :)

    <slangasek> wookey_: I recommend putting everything relevant into the spec, but explicitly noting those things that are out of scope for this cycle

    <wookey_> responsible for drafting isn't the same as 'stuff you mught be working on' though?

    <wookey_> OK

    <slangasek> wookey_: correct - in many cases they're the same, but the drafter and assignee may be different

    <hrw> wookey_: you can draft but someone can do

    <slangasek> (and the "assignee" won't be responsible for all work items, since we have finer-grained control over this)

    <wookey_> OK. So bascially 'necessary' and 'would be nice'

    <hrw> slangasek: should not be drafted by doko rather?

    <slangasek> hrw: I prefer that we draft it and the Ubuntu foundations team approves it

    <hrw> ok

    <slangasek> that helps ensure we're on the same page :)

    <hrw> ;D

    <slangasek> any other questions on drafting?

    <slangasek> [TOPIC] AOB


  • <slangasek> or anything else to cover today?

    <ppearse> Not from me

  • hrw done

    <slangasek> #endmeeting

Meeting closed at 16:20

Platform/DevPlatform/Meetings/2010-11-03 (last modified 2011-03-11 11:33:40)