Thursday 12th August 2010

Agenda

Meeting Log

09:02 < slangasek> #startmeeting
09:02 < slangasek> [LINK] https://wiki.linaro.org/Releases/WeeklyReleaseMeeting/2010-08-12
09:02 < lool> hey
09:02 < slangasek> lool: hi there!
09:02 < slangasek> [TOPIC] Bugs
09:03 < lool> None, Linaro has flies instead
09:03 < slangasek> once again, I'm not sure that any of these bugs are applicable to us
09:03 < slangasek> right :)
09:03 -!- fgu!~fgu@cps2.dmz-eu.st.com has joined #linaro-meeting
09:03 < asac> should we really review all the ubuntu bugs?
09:03 < slangasek> no
09:03 < slangasek> but if we have any bugs of our own on there, they probably bear mentioning
09:03 < asac> how about making links to linaro tagged bugs? and then having some effort to tag the right bugs? we could also include "armel" tagged bugs to get a wider picture of what happens in canonical arm
09:04 < slangasek> e.g., bug #615765
09:04 < slangasek> asac: good point.  Do we have a standard set of tags?
09:04 < asac> i think we use a few atm for toolchain etc.
09:05 < asac> armel and armv7 are the tags that ubuntu uses ... i think monitoring those makes sense
09:05 < plars> not yet, but it seems a #linaro tag, or some set of #linaro-something tags would be appropriate here
09:05 < plars> to designate ones that apply to us as well
09:05 < asac> right. i would love to have all linaro bugs at least get linaro tag ... if they want more specific ones they could add two. like linaro linaro-toolchain-topic
09:06 < slangasek> in which case, https://bugs.launchpad.net/ubuntu/maverick/+bugs?field.tag=armel looks a lot more relevant than the whole list :)
09:06 < asac> plars: tags or subscriptions?
09:06 < asac> right ;)
09:06 < plars> asac: either could work... subscriptions mean a team gets spam on those bugs, which is quite possibly the better case
09:06 < slangasek> asac: could you write up the proper use of the linaro tag in the wiki (where?) and email linaro-dev about it?
09:06 < asac> i think we should monitor https://bugs.launchpad.net/ubuntu/maverick/+bugs?field.tag=armel https://bugs.launchpad.net/ubuntu/maverick/+bugs?field.tag=linaro and also subscribe some linaro bug team to all "linaro" tagged bugs
09:07 < asac< slangasek> damn. i knew that was coming. but ok. add that as an action. i hope i can send it by EOW... otherwise on monday
09:07 < slangasek> [ACTION] asac to document use of linaro bug tag in linaro wiki and email linaro-dev
09:07 < slangasek> thanks :)
09:08 < asac> heh
09:08 < slangasek> so, https://bugs.launchpad.net/ubuntu/maverick/+bugs?field.milestone=27563&field.tag=linaro is empty
09:08 < plars> I think we might want more granularity than that
09:08 < slangasek> https://bugs.launchpad.net/ubuntu/maverick/+bugs?field.milestone=27563&field.tag=armel has a few bugs
09:08 < asac> right.
09:09 < asac> lool: can you give me the tag names that you use in your (former) WGs?
09:09 < plars> we have separate teams for things like foundations, toolchain, etc. already
09:09 < slangasek> hmm, including a "java doesn't work" bug
09:09 < asac> lool: like toolchain tags and kernel tags= ... i think that you used something to track bugs of toolchain rebuild
09:09 < slangasek> plars: yes, but there should also be a common tag so that when we want to get high-level reporting, we don't have to enumerate 20 tags
09:09 < plars> toolchain guys may not want to be getting bugmail about kernel bugs, or at least not in the same stream
09:09 < plars< slangasek> I was referring to the subscriptions more than the tags
09:09 < slangasek> ah yes
09:10 < lool> asac: We used tasks and doko was tagging ubuntu toolchain bugs as arm + toolchain
09:10 < lool> Problem is that the armel tag is getting a bit abused IMHO in Ubuntu bugs
09:11 < asac> lool: ok so we cant extract the list for that anymore. kk
09:11 < asac> next time we should insist to use linaro tags ;) ... in that way we can better associate what came out of our work.
09:11 < plars> lool: but in absence of an arch flag, I'm not sure we have many other choices
09:11 -!- fgu!~fgu@cps2.dmz-eu.st.com has quit [Quit: Leaving]
09:11 < lool> I tried arguing for keeping it for bugs which are specific to armel, but there was some friction so I didn't pursue
09:11 < asac> lool: right. i think its fine to have a bit abuse. as long as it at least includes all relevant ones ;)
09:12 < asac> ok i will see if i can find the list of arm + toolchain that doko had. most likely this is now lost and isnt worth fixing just for the sake of statistics
09:12 < lool> the toolchain bugs are decently tagged, if you search for toolchain tag and then filter down to e.g. armel tag, that works ok
09:13 < asac> lool: all armel + toolchain bugs came from linaro?
09:13 < lool> We also have bugs against the linaro-toolchain projcets, that's another story
09:13 < slangasek> I don't think we're going to solve the overall matter of bug tagging in this meeting.  Is there a follow-up action from this?
09:13 < plars> but I agree that we should try to avoid overuse of tags, it creates a maintenance headache.  I would think a common #linaro tag + subscribe to the appropriate team makes the most sense (also respecting tags that come from ubuntu such as armel, armv7)
09:13 < asac< slangasek> i alread have the action to document this
09:14 < asac> i will try to run around and get the info
09:14 < asac> next meeting we can sign this off and then its a policy for now ;)
09:14 < slangasek> asac: there were also questions about use of the armel tags, didn't know if another action would come out of that
09:14 < slangasek> guess not - ok
09:14 < asac> thats the arm team ... i thi kn we cant change it. just keep an I on those bugs as well to spot more bugs that might be of interest for us
09:14 < asac> s/I/eye/
09:15 < slangasek> [TOPIC] Burndown charts
09:16 < slangasek> Overall
09:16 < slangasek> [LINK] http://people.canonical.com/~pitti/workitems/maverick/arm-ubuntu.html
09:16 < slangasek> [LINK] http://people.canonical.com/~pitti/workitems/maverick/arm-foundations.html
09:16 < slangasek> [LINK] http://people.canonical.com/~pitti/workitems/maverick/arm-infrastructure.html
09:16 < slangasek> [LINK] http://people.canonical.com/~pitti/workitems/maverick/arm-user-platforms.html
09:17 < asac> so i think at this point we should be overall further below the trend line ... giving all the freezes etc. ahead
09:17 < asac> if all stuff not yet done isnt archive relevant then its probably fine too.
09:17 < slangasek> we're staying below the trendline overall, though my team needs to bust hump to get ahead on our own work items
09:18 < slangasek> most of the stuff that's outstanding is not archive relevant
09:18 < asac> though some aggressive postponing might help to better steer the focus
09:18 > * slangasek nods
09:19 < asac> is there anything you need help on?
09:19 < slangasek> not that I know of
09:20 < slangasek> a lot of these work items are about getting changes merged into the toolchain packages for cross-compiler support
09:20 < asac< slangasek> how about getting wookey help on on-disk-footprint? or even taking it over? who owns that now?
09:20 < asac> hmm. that spec is gone it seems ;)
09:21 < asac> not sure if we can still do something of the things discussed on mailing list atm. i can clean up caches after image build for sure to pretend more lightweight images
09:21 < asac> also i can probably drop universe from apt line for headless. for the rest of the things mentioned there we would need someone to implement them
09:22 < slangasek> asac: he still has a good deal of work in front of him to get xdeb working the way we want it to for release.  Do you think the disk footprint stuff can still be done post-beta, or do we need to have it vetted before then?
09:22 -!- sjain!~sudipj@122.177.208.42 has quit [Ping timeout: 240 seconds]
09:23 < slangasek> drop universe from apt line for headless> well, amitk is proposing /adding/ packages to the headless image that come from universe
09:23 < slangasek> we don't want to lose updates for those?
09:23 < lool> right
09:23 < asac< slangasek> i can do my image parts post beta. to udnerstand if we can do the rest post-beta we would need to decide what we really want to do
09:23 -!- sjain!~sudipj@122.177.208.42 has joined #linaro-meeting
09:23 < asac> dropping something like a /usr/share/doc repacking hook into dpkg feels dangerous though
09:23 < slangasek> fair enough
09:24 < asac> but that might just be me ;)
09:24 < slangasek> again, though, there's never been a target size set for how big the headless image is supposed to be
09:24 < asac> right
09:25 < slangasek> I don't want to send wookey down a rathole trying to shave off KB by KB when we have no way to say when it's enough
09:25 < asac> maybe stripping down default kernel modules list would be good to do this cycle
09:26 < asac> maybe dmart can work on that and sync with jcrigby so he uses those modules for all our "default" kernels
09:26 < asac< slangasek> right. lets just address the big and obvious chunks. fine tuning can be done later
09:26 < slangasek> ok
09:26 < asac> i see: no caches by default; no universe; stripped down modules list -> done for 10.11
09:27 < slangasek> [ACTION] dmart, jcrigby to work on eliminating modules from the kernel build that will never be used
09:27 < asac> grewat
09:27 < slangasek> asac: if you want to drop universe, perhaps you'd care to follow up to the mailing list thread about seeding more packages?
09:28 < asac> yes. i wanted to wait for comments before following up ... but its time ;)
09:28 < slangasek> ok
09:28 < lool> (/me has a phone call -- brb)
09:29 < slangasek> also, burndown charts for beta:
09:29 < slangasek> http://people.canonical.com/~pitti/workitems/maverick/arm-ubuntu-ubuntu-10.10-beta.html 
09:29 < asac> i dont have a golden rule for headless at hand still :/ ... just thinking that we shouldn't tune our headless too much for developer purpose - i think all the dev utilities etc could better live in a sdk or dev image/meta package
09:29 < slangasek> [LINK] http://people.canonical.com/~pitti/workitems/maverick/arm-ubuntu-ubuntu-10.10-beta.html 
09:29 < slangasek> [LINK] http://people.canonical.com/~pitti/workitems/maverick/arm-foundations-ubuntu-10.10-beta.html 
09:30 < slangasek> [LINK] http://people.canonical.com/~pitti/workitems/maverick/arm-infrastructure-ubuntu-10.10-beta.html 
09:30 < slangasek> [LINK] http://people.canonical.com/~pitti/workitems/maverick/arm-user-platforms-ubuntu-10.10-beta.html 
09:30 < asac> yeah. seems we need to do something ;)
09:30 < slangasek> here, we're all over the target line and are probably going to need to trim
09:31 < slangasek> since most stuff that was targeted to beta shouldn't be postponed to final
09:31 < slangasek> oh, and Feature Freeze is today
09:31 < asac> right
09:31 < slangasek> which has two aspects to it
09:32 < slangasek> first, for any non-bugfix changes we still need in the Ubuntu archive, we need to talk to the Ubuntu release team
09:32 < slangasek> JamieBennett or I can reasonably proxy most of those discussions if that helps
09:32 < asac> i assume it makes sense for the linaro driver TL to directly get the FFe exceptions? rather than proxying everything through our team?
09:33 < slangasek> asac: that's also fine
09:33 < asac> ok if you are fine we can do a two step FFe process. just thought maybe till beta we can live with just ubuntu FFe
09:33 < asac> and only if they say no, we would come to linaro-release to beg for ppa upload permission ;)
09:34 < slangasek> you're stealing my second point :)  second, even for things we've concluded we won't get into the Ubuntu archive as freeze exceptions, we still need to discuss with linaro-release if those should go into ppa
09:35 < asac> sorry! but as always you phrased it much better ;)
09:35 < slangasek> the existence of a ppa option isn't carte blanche to ignore the riskiness of late-landing features
09:35 < asac> *nod*
09:35 < slangasek> any other comments/questions re: feature freeze?
09:36 < asac> on user platform team status page i listed potential FFe candidates in the summary
09:36 < asac> not sure if we still do a per team review here ;) ...
09:36 < asac> https://wiki.linaro.org/Platform/UserPlatforms/WeeklyStatus/2010-08-12
09:36 < asac> maybe i should sort those to a separate "upcoming FFe section"
09:36 < slangasek> [TOPIC] Team Reports
09:36 < asac> hah
09:36 < slangasek> :)
09:38 < asac> am i offline or did the agenda stall ;)?
09:38 < slangasek> oh, sorry
09:38 < * asac>)
09:39 < slangasek> I was inviting you to continue with your userplatforms status
09:39 < slangasek> writing the reports> guilty :(
09:39 < asac> right
09:39 < asac> so summary contains all.
09:39 < asac> most bothering FFe pending is for clutter and hence hopefully happens really soon
09:39 < slangasek> putting the release meeting agenda together took my time for writing the report :(
09:40 < asac> goal is to able to have egl/gl backends to be drop in replacements so we dont need to build two package stacks
09:40 < asac> but alf is pretty close. final reviews are ongoing; we will include a texture pixmap function for egl which is initially bound to a software implementation so we can drop in later
09:41 < asac> the EGL extension probing code that would make this fully accelerated. Alignment on the EGL extension is moving forward, but takes as expected a bit. i hope we move quickly here though as at least everyone seems to have the same ideas
09:41 < asac> ok ... also clutk is being worked on to get ported to EGL/GLES ... atm we have a null-op implementation that still crashes, but dxteam is looking into it.
09:42 < asac> once we have that we should have a complete unity stack (but thats not a linaro task)
09:42 > * slangasek nods
09:42 < asac> besides that, i have problems with geoclue which prevented me from uploading my super cool "me location" app for feature freeze
09:43 < asac> i am trying to get that sorted asap though. must be something really stupid as geoclue just refuses to use any provider for me
09:43 < asac> in worst case we can probably survive with out that app ;) ... given that its not high prio.
09:43 < asac> thats it
09:43 < slangasek> asac: thanks
09:44 < slangasek> any questions re: userplatforms?
09:45 < asac> k thankx
09:45 < slangasek> sbambrough: could you go next please?
09:45 < sbambrough> still writing huh
09:46 < sbambrough> Infrastructure Team:
09:46 < slangasek> yeah :(
09:46 < sbambrough> * LEP/DerivativeDistributions: Backend work under way.  User testing of UI mockups complete.  Feedback being incorporated into mockups for a second round of user testing.
09:46 < sbambrough> * arm-m-private-archive-hosting-infrastructure: Changes to allow LP archive UI to be reskinned should land soon.  Some existing bugs fixed to allow easier testing of vostock.  Several blueprint items in review and waiting to land.  Launchpad monthly release freeze delaying reviews and landing slightly.
09:46 < sbambrough> * arm-m-derived-archive-rebuild: Working together with LP team to consider how to consolidate Linaro/LP changes.  Working on archive deletion.  Analysis and planning complete, work about to begin on actual coding.  Groundwork necessary is not as complete as first thought.  Archive deletion is estimated to take longer than originally thought
09:46 < sbambrough> * arm-m-image-building-tool: Blueprint has one remaining work item, met with Cody, Ian about it.  Will look into documentation changes Cody proposed.
09:47 < sbambrough> * arm-m-image-building-console: Progress made on getting several bugs fixes landed.  Two of the three branches should make it into next LexBuilder release for dogfooding by OEM.  Continuing work on other bugs.  First security review complete, no surprises.  Started process of choosing a new name for release.
09:47 < sbambrough> * arm-m-automated-testing-framework: Reworking authentication code.  Pushed a branch for doing browser startup time benchmarking.  Added software and hardware profile gathering code.  Evaluating OpenPosix and Phoronix test suites on ARM for correctness.  Awaiting Linaro board approval for license.
09:47 < sbambrough> * arm-m-validation-dashboard: JSON schema for dashboard data bundle published.  Changes from sprint still being reviewed.  Should be landed next week.  Initial UI work started.  Work on test tool for interacting with test results repository coming along.  Awaiting Linaro board approval for license.
09:47 < sbambrough> * other:
09:48 < sbambrough> working on hardware pack spec with Alexander
09:48 -!- sjain!~sudipj@122.177.208.42 has quit [Ping timeout: 276 seconds]
09:48 < sbambrough> working on answering TSC questions on infrastructure work, quite a lot of interest in QA tools and LexBuilder
09:49 -!- sjain!~sudipj@122.177.153.198 has joined #linaro-meeting
09:49 < sbambrough> <EOF>
09:49 < asac> sbambrough: great. could you do me a favour and explain to me how the tests of the automated testing framework will be marketed/distributed. I know that we submitted a bunch of graphics tests to some central repository, but i am not sure how users would find them etc.
09:49 < asac> do you plan to release like a "testing pack" ?
09:50 < asac> or will this just be available for those that know somewhere? without proper releases etc.
09:51 < plars> asac: when you feel those are ready, I would like to merge those test definitions into abrek-trunk
09:51 < asac> plars: ok so there is something we havent followed up on?
09:51 < plars> asac: I just need a merge proposal from you or alf__ saying you're ready :)
09:51 < asac> plars: anyway, so we do plan to tag that -trunk branch with all tests and sell that as kind of a 10.11 test-suite release?
09:52 < plars> asac: then users of it could just do 'abrek install gtkperf' for instance, and 'abrek run gtkperf'
09:52 < plars> asac: the plan for this cycle is to have it in a ppa, but would like to get it in the archive after that
09:52 < asac> ok. lets take that offline
09:52 < plars> asac: but if needed, images could still be built with things in the pa right?
09:52 < plars> ok
09:52 < asac> i think i have more questions ;)
09:52 < asac> plars: yes, images can be build with ppa
09:53 < asac> ok thanks
09:53 < asac> no questions from me on infrastructure
09:53 < slangasek> none from me
09:53 < slangasek> my turn, then :)
09:54 < slangasek> * arm-m-ael-alip-evaluation: reproducible bootstrapped toolchain; getting it working now with xdeb
09:54 < slangasek> * arm-m-cross-compilers: toolchain patches to land in the archive this week
09:54 < slangasek> * arm-m-debugging-with-oprofile: works, but needs cleanup; working on final patch
09:54 < slangasek> * arm-m-kernel-version-alignment: tentative stable linaro kernel tree published, Versatile Express packages coming
09:54 < slangasek> * arm-m-memory-footprint: modified bootchart to record memory usage info. TSC just approved license.
09:54 < slangasek> * arm-m-missing-security-features: ASLR to be done next week, requesting FFe
09:54 < slangasek> * arm-m-uboot-features-and-performance: u-boot packages in ppa
09:54 < slangasek> * arm-m-xdeb-cross-compilation-environment: xdeb needs work to support downloading Packages files for the correct architecture and to use these for calculating dependencies; in progress
09:55 < slangasek> * foundations-m-multiarch-support: preliminary library packages in ppa, but need to talk to LSB about standardizing paths
09:55 < slangasek> any questions?
09:56 < sbambrough> not from me
09:56 < asac> let me look
09:56 < asac> is alip on track?
09:56 < asac> tgall_foo: is responsible to do the full-with-desktop seed. is that of any interest for ppearse?
09:57 < slangasek> it's one of the use cases of interest with ael/alip; I don't know if it's of interest to ppearse personally :)
09:58 < asac> hehe
09:58 < asac> nevermind. i think for me the deliverables are just not clear for the alip spec
09:58 < * asac!~asac@debian/developer/asac should do the homework and read the spec more carefully first
09:58 < slangasek> on track> we're not as far as we should be; fortunately this is all out-of-archive work, but I'm still concerned by how long it's taking to get the bootstrapping going
09:59 < asac> right. for me it really feels a bit like this spec - because done out of archive - has no real deliverable. like a good bundle of tools that is of use etc.
09:59 < slangasek> mostly, it's been harder than expected to get the official toolchain in a good state for cross-compiling
09:59 < * lool!~lool@debian/developer/lool would just like to quickly mention that a new toolchain release came out, with out first 4.5 release; we aim at developing more runtime library optimizations before the release, but no clear timeline there yet
10:00 < lool< slangasek> This looks like it's approaching the final rnu though
10:00 < asac> rnu?
10:00 < slangasek> lool: yes
10:00 < asac> "Republican Network for Unity" ;)
10:00 < lool> And on the kernel consolidation side of things, I'm working with jcrigby, slangasek and will probably involve more people, on setting up a daily build infrastructure which is really missing right now
10:00 < slangasek> asac: "run" :)
10:00 < asac> ah ;)
10:01 < slangasek> [TOPIC] Working Groups reports
10:01 < slangasek> lool: go on, please :-)
10:01 < lool> Ah sorry
10:01 < lool> So basically what I just said when I feared we'd have to end the meeting early
10:02 < asac> lets wrap up ... we have a call ;)
10:02 < lool> No breaking news; main news is this toolchain release of 4.4 with all bug fixed. first 4.5 release. and linux-linaro rebased to 2.6.35 final
10:02 < lool> need to branch linux-linaro in a stable and a -next flavour
10:02 < lool> </eof>
10:03 < slangasek> btw, is lool still the only one representing the working groups at this meeting?  should we be extending an invitation to the other WG leads?
10:03 < lool> problem is the time for michaelh
10:03 < slangasek> (I know this is a terrible time for michaelh)
10:03 < asac> yes, powermgmt and toolchain
10:03 < lool> amitk should be able to make it though
10:03 < asac> we can change time as long as its not terrible for me *cough* ;)
10:03 < lool> I'm inviting him now
10:03 < asac> line opened btw
10:03 < lool> done
10:04 < lool> I'm out tomorrow and Jamie is at a conference, do we have someone for the ubutnu release meeting
10:04 < lool> ?
10:04 < slangasek> I can cover
10:04 < asac> not me please. thx
10:05 < slangasek> that's it then, yes? :)
10:05 < lool> Ok; anything else for today?
10:05 < asac> nope
10:05 < lool> Ok; thanks folks!
10:05 < slangasek> #endmeeting

Cycles/WeeklyReleaseMeeting/2010-08-12 (last modified 2011-04-15 19:37:28)