• Actions from last meeting - Tech Lead chasing
  • Review activity reports - All team members
  • Engineer progress reports - All team members
  • Work Item progress and team issues discussion - Tech Lead and Project Manager questions to the team
  • Any Other Business (AOB)

Past Action items

  • Last weeks action items to discuss.

Action Items

  • Action items that came out of this weeks meeting.

Engineers Reports

Paul Sokolovsky <pfalcon>


  • Build system high-level stats scripts (total # of builds, total time spent)
  • Issues with kernel-tilt mirror checkout, turned out *.git.git ghost repos may be created sometimes leading to failure on checking out some revision
  • reduced availability and downtime issues, work towards alleviating them: use our own mirror to fetch repo itself; change to provide per upstream host fresh/stale checks. This way, we can still fetch repos we care about much ( in realtime, but sync less frequently (say, no frequently than once an hour) with selected upstream hosts, reducing upstream downtime impact on us and improving upstream friendliness.
  • 11.11 Blueprints/workitems review
  • Sysrooted android toolchain build: export sysroot from normal android builds, so it can be used for toolchain builds.
  • Provide source and revision-pinned manifests as build artifacts for each build (Android team request)


  • Finish mirror HA work: add soft/hard stale timeouts, tweak timeouts to actually hide random upstream downflips.
  • Return back to toolchain builds work
  • Do final tweaks to 11.11 blueprints


  • Most of last week's work was essentially out-of-band due to unprecedented upstream repos stability issues. But I have high hopes that changes being done together with those done previously will bring good stability and disturbance isolation to our system.

Mattias Backman <mabac>


  • I made some progress on hwpack-create for the updated hwpack format Current state.

  • Extra long weekend so nothing more to report.


  • Finish support in hwpack-create for the basic hwpack config fields that are common to all boards.
  • Adapt l-m-c to handle this first part of the new format.
  • When that is done, extend the format for supporting the board specific needs (imx, 310, snowball).


  • None

Deepti B. Kalakeri <deepti>


  • Working on creating the kernel build package. This will inturn be used in the hwpack which can then be used to test the newly build kernel using the Board.
  • Worked on investigating the qemu failure with the linaro disk image, which has been failing with bug #768650. Have not been successful in this though :(

  • Got access to Evaluated if the jenkins can be used for testing the kernel on the board directly as qemu testing is not working.


  • Work further on the kernel package building and complete it. Planning to try hands on to build hardware pack.
  • Understand linaro-media-create and try to see how we could add an option to include/replace the newly built deb package to it. This could be helpful for someone when they want to test their newly build package by replacing the one existing in the hwpack already.
  • Plan to check with the panda image with qemu, but I read somewhere that panda image is not supported yet with qemu. Does not harm to give a try though.


  • On leave on June 6th, 2011.

Guilherme Salgado <salgado>


  • Finished improving the script that detects patches that have been committed upstream and ran it against the projects for which we have the most patches. We can now see some of our patches that have been accepted upstream:

  • Improved the new PatchMetrics frontpage a bit more and added a FAQ with answers to questions people are likely to be answering

  • Reviewed a bunch of branches


  • Go through all the patchwork changes that won't be submitted upstream and clean things that were left over, possibly adding more tests
  • Will probably need to work with IS a bit on the patchwork deployment (if they finally get around to starting it)
  • Review more branches


  • None

James Tunnicliffe <jamestunnicliffe>


  • Have a clear plan on how to finish GUI for TestDrive. Should be done very soon.


  • Finish TestDrive (at least get a merge request in and hopefully have it ready for weekly testing)


  • None

Your Name <irc nick>


  • Short bullet points of work you've done that week which convey

progress and highlights which can be used to report on how the team is progressing as a whole.


  • Your individual plans for the coming week(s).


  • Your individual plans for the coming week(s).

IRC logs

Meeting opened by james_w at 14:04

  • <james_w> [TOPIC] Action items

Action items

  • <james_w> None

    <james_w> [TOPIC] Review activity reports

Review activity reports

  • <james_w> jamestunnicliff_, is there anything you need in order to get some code merged before weekly testing on Thursday?

    <james_w> except for reviews of course :-)

    <jamestunnicliff_> nope. I think I have it cracked.

    <jamestunnicliff_> (at last!)

    <james_w> great

    <james_w> any other questions about the reports from anyone?

    <mabac> james_w, just to confirm my way forward.

    <mabac> james_w, if you're ok with completing hwpack-create and l-m-c without the special handling of 310 and imx

    <mabac> as a first step and then add those bits?

    <james_w> mabac, I am, as we won't "release" like that, and we won't change the hwpacks to use the new format so no-one else will execute that code for now

    <james_w> does that sound right to you?

    <mabac> james_w, sure. I happy with that, makes my life easier actually

    <james_w> ok

    <james_w> [TOPIC] Work Item progress and team issues discussion

Work Item progress and team issues discussion

  • <james_w> that's our page for the new cycle

    <james_w> please everyone take a look at it and tell me what is missing/wrong from your point of view

    <james_w> I think we may need to team-assign some of our blueprints to get them to show up if we don't have a person to assign yet

    <james_w> [TOPIC] Team meeting time

Team meeting time

  • <mabac> james_w, seems I need to list some workitems since I'm not on there

    <james_w> mabac, ping me after the meeting and we'll find out why

    <james_w> so, Michael is now part of the validation team

    <james_w> and jamestunnicliff_ is now permanently with us

    <james_w> this means that we don't need to other meeting time now

    <james_w> but I wonder if we should move this meeting, or rotate in some other way

    <james_w> deepti1, you are now the most Easterly, how does this time work for you?

    <deepti1> james_w: can we have the meeting an hour earlier if everyone is ok with that ?

    <james_w> deepti1, is one hour enough?

    <salgado> wfm

    <deepti1> james_w: earlier the better for me :)

    <james_w> deepti1, ok

    <mabac> an hour earlier would be better for me too

    <james_w> let's move this meeting one our earlier

    <deepti1> james_w: if its only convenient for everyone

    <james_w> deepti1, I'll move our meeting one our earlier as well?

    <deepti1> james_w: Thanks :)

    <pfalcon> ok for me, 4pm instead of 5pm local ;-)

    <james_w> we could go even earlier in the day, I think that moves it to 10am your time salgado?

    <salgado> right now it's at 11, so we could easily go 2h earlier

    <james_w> that's 8am my time, which I'm ok with

    <mabac> ok for me too

    <deepti1> james_w: fine with me as well

    <james_w> it also makes it 1pm jamestunnicliff_'s time, will that overlap with your lunch jamestunnicliff_?

    <james_w> everyone else should be some time in the afternoon

    <jamestunnicliff_> At the moment it would make it 2pm

    <james_w> deepti1, I think it makes it 5.30pm your time?

    <jamestunnicliff_> so I am happy with that

    <jamestunnicliff_> My lunch time isn't very fixed anyway

    <deepti1> james_w: yes

    <james_w> ok, sounds like we have consensus on two hours earlier and one meeting time working for everyone

    <fabo> it seems everybody acked

    <james_w> which is great

    <james_w> [ACTION] james_w to move the meeting two hours earlier

james_w to move the meeting two hours earlier

  • <james_w> seems #linaro-meeting is free then

    <james_w> and we'll be limited to an hour by the MMWG

    <james_w> great

    <james_w> [TOPIC] change the way the team works?

change the way the team works?

  • <james_w> I've been having a few conversations over the last couple of weeks that have touched on various issues

    <james_w> the outcome is that I'm not at all convinced that the way the team works is the best for the team

    <james_w> there have been a number of solutions suggested, but I'd like to get your suggestions rather than present a solution today

    <james_w> the problems that have been suggested come down to the fact that we are frequently working as a collection of people working on disparate topics rather than a team working together

    <james_w> there are various effects of this, but I first wanted to know what your opinions were

    <james_w> is that the way you feel? is it a problem for you?

    <deepti1> james_w: Hmm! I feel the same.. but that is natural because of the nature of the work. everyone has something diff to work on

    <jamestunnicliff_> With my current task I am reasonably independant of others, but not completely. Not a problem for me. I am happy to work this way, or more closely.

    <mabac> I seem to work separately on the bits I do. But it's not really a problem for mer personally since I almost always get answers and reviews quickly.

    <pfalcon> well, but we indeed cover a wide area of systems/issues so yep, some member specialization would be expectable imho

    <jamestunnicliff_> I can see over specialisation being a problem if one of us has to leave the team at short notice

    <salgado> yes, that's the way I feel as well, and although it's somewhat expected as others pointed out, I think it'd be better if we worked more closely when possible

    <james_w> right, we have disparate areas to work on, but I think we should aim for knowledge sharing

    <james_w> I don't want to have knwoledge silos

    <james_w> I think we do ok with reviews, but there's a difference between reviewing something with a brief look and really understanding it

    <jamestunnicliff_> agreed. I don't know how easy it would be to work more closely day to day.

    <mabac> "knowledge silos" are a pain for both teams and individuals. I wouldn't want to be one.

    <jamestunnicliff_> it is nice to have people around to bounce ideas off though

    <james_w> yeah, it's tricky given that we are remote, so very close collaboration can be tricky

    <deepti1> james_w: True.. I would not mind working closely with someone else .. sometimes I find it difficult to understand the work others are doing due to time constraints , my own work and also to go through all the email threads.

    <james_w> deepti1, yeah, I think you've summed up the problem as I see it

    <james_w> whatever we try it's going to be difficult if you have a project you are driving that is expected to be finished soon, that will tend to push out any investigation of what others are doing

    <pfalcon> well, cloud-buildd, it was nice to work together with Michael, and discuss issues/solutions. and as he moved, I sometime feel need for another head to think of solutions, I just not sure whom to bother with that, everyone seems to be busy with other important tasks

    <mabac> james_w, knowing that it's not a waste of time to read the threads bout other projects is good, that makes it a lot easier to motivate keeping up-to-date.

    <jamestunnicliff_> indeed. I don't keep up with many code reviews because I don't know the code that is being patched, so I am not sure if I will be useful. I also don't like emailing everyone just to discuss ideas.

    <james_w> yeah, I very much support everyone looking at other projects and getting involved (making suggestions, reviewing code, whatever)

    <mabac> james_w, I usually stop at that though since reviewing the new systems feels like it takes too much effort.

    <james_w> but the way work is assigned currently doesn't really back that up

    <jamestunnicliff_> Maybe if we all lurked on #linaro on the private chat or had a new channel on freenode, that would be good for general chat

    <james_w> jamestunnicliff_, that's an interesting point. Do others feel the same way about emailing everyone? How do you feel about the emails that you do get about other people's projects?

    <mabac> I like to get a lot of emails about others merge requests and discussions, easy to get a grip of the basics.

    <mabac> Usually I don't butt in though to avoid wasting other peoples time.

    <salgado> I always email everyone. ;)

    <mabac> I know that is a backwards attitude since asking silly questions is the only way to learn about unknown stuff.

    <pfalcon> I'd prefer to be mailed on other (team) stuff, but myself think if matter is worth linaro-dev, or some specific people ;-)

    <james_w> so the IRC channel is interesting. We are encouraged not to silo discussion that is relevant to others in linaro, but it does mean that people don't use it as much as they would if we had our own channel

    <jamestunnicliff_> Getting the balance right is difficult. I don't mind my discussion being in the open, I just find it frustrating when I am subscribed to channels with poor signal/noise

    <james_w> yeah

    <jamestunnicliff_> It makes them too easty to ignore

    <salgado> yeah, #linaro has now 166 people in it. and the range of topics discussed there is quite broad

    <james_w> ok, so allow me to make a few (hopefully clear) statements about expectations

    <deepti1> james_w: I am waiting for the blueprints to complete to understand what exactly each one is planning to work on. I hope the blueprint overview will give some in sight into what they are upto.

    <deepti1> james_w: that is one way to understand others work without bothering them much I feel..

    <james_w> 1. you are not expected to focus solely on the project you are currently working on. In fact you are expected to gain some knowledge about other projects the team is working on, as you may be expected to pick them up at some point

    <james_w> deepti1, good point

    <james_w> 2. however, you are not expected to know every detail about every project we are doing, that would be too much to ask. Therefore don't feel you have to read everything. You could choose based on project, or just skim every project, it's up to you

    <james_w> 3. the team is expected to support each other. Therefore if you have a problem you should always feel like you can ask the team. Either everyone or a specific person

    <james_w> you could e.g. ask someone to join you on mumble to talk through a problem if that's what you need

    <james_w> do those statements clarify things a bit?

    <james_w> is that what you are all doing already? :-)

    <jamestunnicliff_> that helps thanks

    <deepti1> james_w: sure that does

    <mabac> Thank you, it's good to see that clearly written.

    <james_w> do you think it would help if everyone had one other project that they were to keep an eye on?

    <james_w> so e.g. mabac would be looking at deepti1's work on CI as well as his project

    <james_w> with weekly calls or something to provide an explicit time to focus on that?

    <jamestunnicliff_> That could work, sort of buddying up on a project.

    <mabac> It probably would, since otherwise I usually just skim the emails about other projects and go into very little detail in them.

    <salgado> yeah, sounds good to me

    <james_w> and maybe being the default reviewer on code review etc?

    <jamestunnicliff_> sounds like a good plan to me

    <james_w> (nothing explicit, just a convention)

    <mabac> that would be good too, easier to pick up a review if I'm "first in line" for it

    <james_w> deepti1, pfalcon: what do you think?

    <deepti1> james_w: works for me..

    <pfalcon> james_w: that sounds good, my only concern is that I still feel to be in "firefighting" mode regarding cloud-buildd

    <james_w> pfalcon, and your worry is that it would prevent you having time to look at anything else, or that you won't be able to explain things to someone else as there's no real plan to firefighting?

    <pfalcon> james_w: first reason, that I will need to fix issues to let android team do their work, and won't have much time for sth else (in realtime)

    <pfalcon> james_w: I'm pretty happy to explain and discuss things any time

    <james_w> pfalcon, ok. I'll happily explain the change if it causes problems

    <james_w> you shouldn't feel solely responsible for their productivity though, and if you do because you feel like you can't get enough done then that's something we should deal with anyway

    <james_w> so it sounds like everyone is happy for a pilot of this scheme?

    <james_w> I suggest given the time we take the next step to email

    <james_w> [ACTION] james_w to start email conversation about "buddy" system

james_w to start email conversation about "buddy" system

  • <james_w> and quickly before we run out of time

    <james_w> [TOPIC] AOB


  • <james_w> anything else anyone wanted to bring up?

    <james_w> any last comments on the previous discussion?

    <mabac> Nope.

    <deepti1> james_w: nopes from my side

    <jamestunnicliff_> nope

    <salgado> nope

    <deepti1> Thanks everyone.. I will take leave now..

    <mabac> Bye all, have to rush off too. "See" you tomorrow. :)

    <pfalcon> thanks, see you!

    <dsaxena> For folks here for the kernel public plan review, slides are at:

    <salgado> james_w, don't you need to end the meeting with Mootbot-UK?

    <james_w> oh

    <james_w> you're right

    <james_w> #endmeeting

Meeting closed at 15:02

People Present

  • james_w
  • jamestunnicliff_
  • mabac
  • deepti1
  • salgado
  • pfalcon
  • fabo
  • dsaxena

Actions Recorded

  • james_w to move the meeting two hours earlier
  • james_w to start email conversation about "buddy" system

internal/archive/Platform/Infrastructure/Meetings/2011-06-07 (last modified 2013-08-23 01:59:30)