Agenda

  • Go over actions from last meeting
  • Around the table: Accomplishments, Plans, any Issues
  • Technical discussion

Meeting Minutes

  • Assign one to record major items from this meeting

Action From Last Meeting

  • Copy actions from last meeting here

Action From This Meeting

  • Record action from this meeting

Issues

  • Record any issue raised in this meeting and communicate with TL and PM.

IRC log

 Via email 1-10-2012
Hey Anton!
       I just realized that while I intended to schedule a meeting tomorrow at
11pm your time (11am mine), I haven't actually done so.

So instead of springing a late night mumble meeting, I figured I'd try
to have the meeting over email instead.

This one is a little long, since there's more initial stuff to cover. I
suspect these will get shorter as we get going.

Just reply to the mail with inline quotes to answer any questions (lkml
style, snip what isn't relevant to your response), and feel free to ask
any questions that arise. I'll take the mails and try to assemble them
into something that can go on the wiki.


[Administrative stuff]========================
Wiki:
 * So we're trying to sort out the wiki page as a central location of
the Android subteam's info and status:
       https://wiki.linaro.org/WorkingGroups/Kernel/AndroidUpstreaming

 * Anton, please review and let me know if there is any other info that
would be useful to have on the wiki. Also keep it in mind as a good
place to store any other useful bits of team-specific information or
process documents.

Weekly Status:
 * Anton, The weekly status you sent out on the 26 was great. Keep it
up!

Blueprints:
 * In order to keep track of what got done when, please add completion
dates to the blueprint work-items when they are marked DONE using the
following format:
       [owner] work item description (Date completed): DONE

 * Also ideally work item granularity should be "a few days". So ideally
each week there should be at least one or two blueprint work-items
completed. Feel free to break up work items, or if needed, add new work
items as they are done.

 * Unfortunately the blueprint reporting format is seemingly constantly
in flux, so we may need to change our blueprint structure in the future
to better accommodate the status.linaro.org reporting. I'll try to let
you know as soon as I better understand what's needed.


[Lowmemory killer]===============================
https://blueprints.launchpad.net/linux-linaro/+spec/android-lowmem-upstreaming

* Blueprint work items are a little coarse. Anton, If you could add a
little more granularity it would be great.

* Just a minor nit, you have " Milestone 1: Send a new driver w/ a cover
letter explaining alternatives. This is mostly to start a new
discussion, we don't expect the driver to be merged as is: DONE" under
2012, but this was done back in Dec.

* The staging-next branch, including the lowmemory killer  has landed in
3.3-rc. It would probably be good to add the work items related to the
staging tree to either this blueprint (or maybe create a new blueprint
to track that work? Anton, what is your preference there?)

* I noticed in the android tree there is a patch called "staging:
android: lowmemkiller: Substantially reduce overhead during reclaim"
that isn't upstream yet in staging. You might dig it out, and if it
makes sense to, send it to Greg for inclusion, along with any other
improvements to the staging low-mem killer code you've been working on.

[ashmem]==========================================
https://blueprints.launchpad.net/linux-linaro/+spec/android-ashmem-upstreaming

* I believe the blueprint is fairly current, but let me know if anything
looks to be missing or is confusing.

* I'm considering splitting the ashmem staging work out into a separate
blueprint from the ashmem alternative work.

* Getting progress utilizing akpm's mumbletree structure has been hard.
I need some better focus days to be able to attack that one, and
recently there's been lots of distractions.

[monotonic evdev]=================================
https://blueprints.launchpad.net/linux-linaro/+spec/android-evdev-upstreaming

* Patches revised a few time and resubmitted to list

* Got buy in from both ChromeOS folks and Android folks

* Waiting for it to get pulled into Dmitry's git tree, hoping it goes in
for 3.3, but suspect it will be pushed out to 3.4

[alarmtimer mending]==============================
https://blueprints.launchpad.net/linux-linaro/+spec/android-alarmtimer-mending

* I've got a patch queue that adds a android alarmtimer driver, which is
mended to use the upstreamed alarmtimer code, to staging. Unfortunately
the android alarmtimer heavily relies on wakelocks which are not
upstream.

* Need to send the patch queue out to get some feedback on it from Arve
and Greg to see how viable it would be to include in staging with
wakelocks stubbed out.

* Sent some mail discussing plans with Rafael about how he intends to
convert the pm_stay_awake/pm_relax interfaces to be sufficient to
replace wakelocks


[Misc]===============================================

* I've been busy with a few RTC regressions that popped up over the
holidays. Also have a bunch of queued timekeeping work that I need to
get into shape for inclusion into -tip.

* Anton, how's the panda board going? Managed to boot a Linaro Android
image yet?

* Anton, have you been able to look into the cpufreq items yet? Let me
know when you start that so we can create a blueprint to track the work.

* Anton, Let me know if there is any other work you're starting on that
isn't covered in the above. Or if there is anything blocking you from
getting stuff done that we need to resolve.

* Anton, Any other questions you have?

* Deepak, Mounir: Any questions or thoughts on this format of meeting?

thanks
John Stultz john.stultz@linaro.org
        
Jan 10 (2 days ago)
                
to Anton, Deepak, me
On Tue, 2012-01-10 at 14:15 -0800, John Stultz wrote:
> [Misc]===============================================

* One quick addendum: The android team at google has gotten back to us
with a mail alias that goes to their kernel team.  So in the future,
when sending out patches that affect android code in staging or
potential alternative implementations, be sure to CC:
kernel-team@android.com


thanks
Mounir Bsaibes  Jan 10 (2 days ago)
John, The format looks great as long as it works for you guys. Just one obser...
John Stultz john.stultz@linaro.org
        
Jan 10 (2 days ago)
                
to me, Anton, Deepak
On Tue, 2012-01-10 at 17:13 -0600, Mounir Bsaibes wrote:
> John,
> The format looks great as long as it works for you guys.
> Just one observation. How are you handling priorities?

Currently the blueprints being focused on (in the wiki) are the
priorities. That said, if you have a better approach I'm willing to look
into it.

> For example:
> https://blueprints.launchpad.net/linux-linaro/+spec/android-ashmem-upstreaming
> has to be done this month and therefore has a highier priority to be
> completed first.

So I sent you some mail on this issue yesterday. ashmem upstreaming
isn't going to be done in a month.

I'm not sure where that idea got started. When I was talking with Deepak
after the last connect, my understanding is that we would have a number
of blueprints that cover the complete work required, and we'd
target/adjust them as needed. But most of them aren't short efforts
(shorter then a 6mo cycle). Even if the work required is somewhat short,
there is the split between getting some code upstream, and then also the
mending step where we convert android to use the new upstreamed
functionality. This can easily spread across cycles.

I know we need to have something that will help express what we're
hoping to have complete for each month, and right now the blueprints
don't do that very well.

I know last cycle we tried splitting up work items into monthly
blueprints, but I don't feel that worked very well. It might be that we
need more fine-grained blueprints, which I talk about a bit in the
meeting-email (ie: where best to track some of the staging work as
opposed to the alternative work), but with the kernel release cycle
being 3 months, its very unlikely that we can develop, merge and mend a
chunk of code in a single month. Its much more likley that we'll see
blueprints completed in bursts. With no blueprints completed some
months, and then a larger number of them completed in other months.

For example, the evdev work, which went from nothing to mostly complete
has all happened in the last few weeks. But it might not get merged and
then used for another 3-4 months!.

Also we need a way to handle the dynamic aspect to the work, since much
of the staging tree stuff that has happened since early December, and
has consumed much of my time with really great results,  wasn't even on
the map until a few weeks ago.


> Also for storage and future referral to the meeting, are you planning
> to add the thread of these notes/meetings (when done) to the calendar
> entry?

Yep. That's the plan.

thanks
Anton Vorontsov Jan 11 (2 days ago)
Hello John, On Tue, Jan 10, 2012 at 02:15:38PM -0800, John Stultz wrote: [...]
Mounir Bsaibes
        
Jan 11 (1 day ago)
                
to John, Anton, Deepak
On Tue, Jan 10, 2012 at 5:51 PM, John Stultz <john.stultz@linaro.org> wrote:

    On Tue, 2012-01-10 at 17:13 -0600, Mounir Bsaibes wrote:
    > John,
    > The format looks great as long as it works for you guys.
    > Just one observation. How are you handling priorities?

    Currently the blueprints being focused on (in the wiki) are the
    priorities. That said, if you have a better approach I'm willing to look
    into it.

 
John,
I meant to bring to your attention the priority of the blueprints listed in the wiki.

Specifically, the ashmem blueprint should have had a highier priority, since it had an associated roadmap card targeted for this quarter.
- just checked the card has been moved to a future quarter, so I think we are ok now -
In general, this is what I meant, based on what we have on hand to deliver, sometimes we have to juggle the priorities to meet the targeted dates.



    > For example:
    > https://blueprints.launchpad.net/linux-linaro/+spec/android-ashmem-upstreaming
    > has to be done this month and therefore has a highier priority to be
    > completed first.

    So I sent you some mail on this issue yesterday. ashmem upstreaming
    isn't going to be done in a month.

    I'm not sure where that idea got started. When I was talking with Deepak
    after the last connect, my understanding is that we would have a number
    of blueprints that cover the complete work required, and we'd
    target/adjust them as needed. But most of them aren't short efforts
    (shorter then a 6mo cycle). Even if the work required is somewhat short,
    there is the split between getting some code upstream, and then also the
    mending step where we convert android to use the new upstreamed
    functionality. This can easily spread across cycles.


If a feature spans multiple cycles (quarters) we call it an epic. An epic would have more than one roadmap cards on the roadmap.
For example if you think ashmem work may take 2 cycles, you can create 2 cards one for each cycle. in the first cycle you could do a prototype for example, in the next cycle you could do the actual work. This is what we are doing for the KVM work. Of course this has to make sense for what you are doing.


    I know we need to have something that will help express what we're
    hoping to have complete for each month, and right now the blueprints
    don't do that very well.

    I know last cycle we tried splitting up work items into monthly
    blueprints, but I don't feel that worked very well. It might be that we
    need more fine-grained blueprints, which I talk about a bit in the
    meeting-email (ie: where best to track some of the staging work as
    opposed to the alternative work), but with the kernel release cycle
    being 3 months, its very unlikely that we can develop, merge and mend a
    chunk of code in a single month. Its much more likley that we'll see
    blueprints completed in bursts. With no blueprints completed some
    months, and then a larger number of them completed in other months.


that is ok. We can go back to having blueprints with Work Items monthly blocks.
Would that help?

WorkingGroups/KernelArchived/AndroidUpstreamMeetings/2012-01-10 (last modified 2013-01-14 19:34:03)