24th January 2011
- Actions from previous meeting
- Dispatcher implementations
Work item progress (http://status.linaro.org/linaro-validation.html)
- Brief Progress
- Any other business
Action Items from last Meeting
plars to help springz with serial connection issues
Done - spring has a workaround
Action Items this Meeting
merge new dispatcher branch
email his outstanding questions to plars and JamieBennett before the next phone call
Minutes IRC (Transcript)
<plars> that's the link for the meeting minutes, agenda, actions, etc
<plars> [TOPIC] Actions from previous meeting
Actions from previous meeting
<plars> plars to help springz with serial connection issues
<plars> we took a look at it, I saw similar problems with cu
<plars> I believe that you are happy with the workaround though, right springz?
<springz> I can use minicom, it's ok
<plars> ok, done then
<plars> [TOPIC] Dispatcher implementations
<plars> so the dispatcher is starting to take form
<springz> we have discussed a lot
<plars> and zygmunt has some neat ideas in the parasitic-cone branch that I don't want to lose site of
<plars> but unless there is disagreement, I think we should call that one the experimental branch for now, and put it on the back burner
<plars> in the interest of making some forward progress, I think a simpler, more straightforward approach will help us achieve that
<plars> so unless there are objections, I'm planning to try to do some cleanup on the one I propsed, and we can move forward on that
<springz> so can we base your implementation and head for zygmunt's?
<zyga> plars, just bzr mv lava (the one in trunk now) to something else so that it's easier to merge later
<plars> zyga: oh, you want to keep it in trunk?
<zyga> plars, if you keep it we'll keep history, just store it somewhere on the side
<plars> zyga: I was going to recommend we toss it, because we still have history in parasitic-cone, since that's the one you've been merging against
<plars> and that way it's less confusing
<zyga> yeah that's okay I guess, as long as we keep the history this way
<plars> keep parasitic-cone though
<plars> springz: at some point, they might merge, but what I expect is that will likely not be this cycle
<springz> plars: ok
<plars> springz: more likely is that we will consider that an experimental branch for future development, and may cherry-pick ideas from it, or take the whole thing if it shapes up.
<zyga> plars, I hope it can be, just not this next week or two
<zyga> plars, I don't want to stray that long, that would be pointless
<plars> springz: for now though, I think we will be able to make faster progress on the one I proposed recently
<springz> plars: I think so
<plars> zyga: no, it's not pointless
<plars> zyga: but I think we all need to be working against the same codebase
<zyga> plars, if we keep them apart for so long without evolving p-c then we might just abandon it
<plars> zyga: but working on two parallel implementations is going to take too much time away I think
<JamieBennett> why are you working on two different implementations?
<plars> zyga: we are still a bit shorthanded for now
<zyga> JamieBennett, we're not, we're just trying to figure out what to do
<robtaylor> plars: zyga: can I ask, what are the benefits are to the different paths?
<plars> JamieBennett: will give you the details offline, they basically emerged about the same time, trying to figure out the best approach
<JamieBennett> plars: if one has been chosen not it should be all steam ahead on that one
<plars> JamieBennett: that's what I'm saying
<plars> any disagreement?
<zyga> robtaylor, plars idea is somewhat shorter and perhaps easier to understand, my idea is IMHO better to work with in the long term and more focused on maintainability
<robtaylor> zyga: thanks
<plars> ok, moving on then
<plars> [TOPIC] Work item progress (http://status.linaro.org/linaro-validation.html)
Work item progress (http://status.linaro.org/linaro-validation.html)
<plars> we shrunk our line a little more over the last week, but I think this was due in part to work item reshuffling
<plars> will continue to harp on this, please try to be finding things from your work items that you can mark as done
<zyga> I'm a little confused about what to mark as done with the advent of two branches
<JamieBennett> plars is there a problem with Mirsad Vojnikovic's work items?
<JamieBennett> 38 items, 0% done
<zyga> but I'll leave that to you because those are not my blueprints
<springz> for dispatcher work items, we discussed last week, and i will update it and I want to finalize them
<plars> mirsad: ?
<springz> JamieBennett: some status need to update I think
<mirsad> JamieBennett, I haven't started implementing yet, therefore no progress
<JamieBennett> mirsad: work items shouldn't just be implementation ones
<JamieBennett> mirsad: at this stage half your work items should be done ideally
<JamieBennett> not all implementations ones of course
<mirsad> JamieBennett, ok, didn't know that, so I could put my experimental work as work item?
<plars> mirsad: eh
<JamieBennett> mirsad: best to show progress, no matter what it is. Going this long with no work items done in theory means you've done no work which is not of course what has happened
<plars> the work items should all be something that is productive against getting the overall blueprint accomplished
<plars> but sometimes there are design type things on there, if that's what you mean
<JamieBennett> right but unless there are work items done its hard to track progress
<JamieBennett> 0% done means nothing done
<JamieBennett> anyway, something to think about
JamieBennett lets plars move on
<plars> [TOPIC] Brief Progress
<plars> For me, you've seen the dispatcher example that I submitted
<plars> needs some cleanup, but it's a start
zyga also told everything in status updates recently so no point to double that here
<plars> I'll work on that some more today assuming I can find some time
<plars> and I was off yesterday, but I see some merge proposals and questions rolled in
<plars> it is early morning for me, and I'll get to them as soon as I can
<plars> but I should not be the choke-point for all of this
<plars> please help each other out where you can
<plars> it will not scale with me having to review everything
<JamieBennett> plars: please put this kind of thing in your weekly team report as issues if necessary
<plars> mirsad: progress?
<mirsad> plars, yes, I have put some code out, but didn't sent a merge request, need a first-time advise
<paulm_> plars: on getting reviews done maybe you can pair up to share work reviews
<plars> mirsad: did you have a specific question you wanted to bring up here?
<mirsad> no, it's practical question, just how to do merge
<plars> paulm_: we could try that, but you may or may not know... we are not geographically in the same place, and separated by a lot of time zones
<plars> mirsad: either zyga or I can help you with that
<paulm_> plars: eyeball reviews should be ok
<zyga> it's easy
<plars> mirsad: also, I think there were some mentor contacts you made at the sprint right?
<plars> mirsad: if you ever have a question about process/tools sorts of things, and one of us is not around, that would be a good place to start as well
<mirsad> plars, yes, but this was more about folders I put in the delivery, I see that it might be wrong
<plars> zyga: can you take a look at it with him? I'm unlikely to have an opening to look at it for several hours
<mirsad> plars, I have updated scheduler spec and put it in pending approval, since no more comments received
<zyga> plars, I'd rather not today unless it's just a few minutes, I have a meeting just after this one and then I need to leave to pickup board components
<plars> mirsad: ok, will try to look at that today as well
<plars> springz: progress?
<springz> plars: yes
<springz> from yesterday's report, based on paul's branch, I move on the dispatcher work today, enabling generating test image tarball from original hwpack and rootfs, I have send the code merge request.
<zyga> mirsad, I can work with you for the next 30 minutese
<springz> I set up an apache server to place the test image tarball to simulate the dispatcher environment
<mirsad> zyga, that would be good
<springz> but for the merge request, it confused me that i intend to push the code to your branch but it goes to lp:lava
<plars> springz: I didn't see a merge request
<plars> springz: let me do a few cleanup items on mine and we'll take a look at it together then
<springz> plars: I also sent the mail to you all
<plars> springz: I skimmed yours just a bit, and some of what I saw there was just dealing with things like that
<zyga> plars, can you please push a few changes to lp:lava to remove my code
<zyga> plars, and start clean for the simple branch work
<zyga> plars, so that everyone knows what to merge and where
<plars> zyga: yes, that's what I was just saying I was going to do
<mirsad> plars, that would be perfect!
<plars> [ACTION] plars to merge new dispatcher branch
plars to merge new dispatcher branch
<plars> will do that today
<plars> merge proposals should typically be against trunk
<springz> plars: you mean lp:lava?
<plars> alright then, I'll try to wrap this up quickly so that mirsad and zyga have a few min.
<plars> [TOPIC] Any other business
Any other business
<springz> there are also some enhancement to do with generating test image tarball, I have mentioned in the mail
<robtaylor> So, I have a few things, if we have time.
<plars> robtaylor: please
<robtaylor> plars: ok, so first off, i'd like to introduce paulm_. He's been tasked on COdethink's side to come up with small, well-defined chunks of work we can deploy engineers on
<paulm_> I have tried to get myself an end to end view of Lava
<zyga> paulm_, hi again
<springz> paulm_: hello
<paulm_> So I have had some fun trying to reverse engineer the blueprints into some system diagrams
<paulm_> I have posted my scheduler diagram to Http://tinypic.com/r/9r4p5s/7
<paulm_> Is there something out there like this?
<plars> so the simplest approach to this, would be to look at the work items on the blueprint whiteboards, and then talk to the assignee for that blueprint to get details on where you can help
mirsad cannot access this due to STE proxy
<plars> Since they are likely to be the ones who wrote the work items, they can answer any questions you have about what needs to happen for that work item, and also alert you if you are about to take something that they are already in the middle of
<robtaylor> plars: the current issue we see is that we need work to be well-scoped, and at the moment it's very hard to pull that information out
<paulm_> creating the diagram raised many higher level questions
<paulm_> For example
<paulm_> The normal user. Who is this? Are these defined working groups, Soc landing teams, or even upstream groups?
<robtaylor> mirsad: ah, damn. hangon, i'll try and put it somewhere httpsable
<zyga> paulm_, there are a lot of good questions there
<zyga> paulm_, but we need to structure this to answer them properly
<JamieBennett> paulm_: plars: The best forum for this is probably to gather Pauls questions together and arrange a call ?
<springz> paulm_: also can be some routine action, when a release comes
<plars> and we already have a call arranged
<paulm_> sounds good , I do have a rather a list
<plars> paulm_ and I have talked some about this already
<plars> and we have some time set aside to talk more
<plars> paulm_: some key things to remember
<JamieBennett> paulm_: can you gather your list of questions and send them to plars and myself
<JamieBennett> plars: I'd like to sit on the next call if thats OK
<plars> 1. this team didn't get kicked off until mid-cycle *after* the developer summit happened where we normally do planning
<plars> so we are sort of planning as we go on this
<paulm_> plars: are talking about the call next weds
<JamieBennett> plars: right, I'd like to help you there
<plars> we have the overall architecture of where we'd like to go
<plars> but there will be some interim steps
<paulm_> My initial questions are around who the system users are and what they are trying to achieve
<zyga> paulm_, for the moment that's just "us" all internal lava consumers
<paulm_> Then to reflect on the design meeting these goals
<plars> paulm_: that group will hopefully expand over time, initially it will mostly be platform team people, then expand to working groups
<JamieBennett> plars: can you give paulm_ an [ACTION] paulm_ to email his outstanding questions to plars and JamieBennett before the next phone call
<plars> paulm_: but I think this is probably a much larger discussion than we have time for here
<plars> [ACTION] paulm_ to email his outstanding questions to plars and JamieBennett before the next phone call
paulm_ to email his outstanding questions to plars and JamieBennett before the next phone call
<plars> anything else?
<paulm_> Have I got the right phone call? which one are you talking about
<plars> paulm_: I believe joey set one up?
<paulm_> OK, next weds. Understood
<zyga> plars, which one is that, I did not get any information?
<JamieBennett> paulm_: anything else you need atm?
<plars> paulm_: yep, that's the one, I was just looking through my calendar
<springz> zyga: maybe the sent mail before
<paulm_> I will post to the lava group and earlier feedback would be great
<springz> zyga: I remember there is a phone list mail
<zyga> I'll grep my mail then
<plars> alright then
<plars> thanks everyone
Meeting closed at 14:46
internal/archive/Platform/LAVA/Meetings/2011-02-24 (last modified 2013-08-23 13:19:27)