Notes and actions from MM WG call on 5th April

Hi All, Please find enclosed link to minutes and actions for multimedia wg meeting on 5th April 2011. https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Notes/2011-04-05

Re: git merge question

On Fri, 2011-04-08 at 18:57 +0100, Jesse Barker wrote: > All these git related puns are killing me :-) Ha, it's nice to make people laugh but I find that if I hit the stage I don't feel as committed to it anymore. Ok, you might find that one a bit far-fetched but I beg to differ :) Will __

[NOTES] Minutes & Actions: Toolchain Working Group meetings of Apr 04 & 07, 2011

Enclosed you'll find a link to the agenda, minutes and actions from the Linaro Toolchain working group weekly meetings of April 04 & 07, 2011. https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2011-04-04 https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2011-04-07 == Summary ==

Re: [RFF] Patch tracking/metrics

On Fri, 8 Apr 2011 18:24:03 +0100, Peter Maydell wrote: > Sure. It does mean that fixing deficiencies in the system is more > important than if it's just collecting patches and only needs to > be interacted with by a few people. Agreed. > It's a feature I'd really like to see, and upstream soun

Re: git merge question

All these git related puns are killing me :-) On Fri, Apr 8, 2011 at 8:46 AM, Will Deacon wrote: > > On Fri, Apr 8, 2011 at 3:45 PM, Tixy wrote: > > > On Fri, 2011-04-08 at 10:16 +0100, Dave Martin wrote: > > >> one reason why my understanding of the actual problem here was a bit > > >> patchy.

[PATCH android/system/core] libpixelflinger: Add ARM NEON optimized scanline_t32cb16

Reference benchmark results on Beagleboard (TI OMAP353x) at 500 MHz: scanline_t32cb16_c memory bandwidth: 31.63 MB/s scanline_t32cb16_neon memory bandwidth: 147.69 MB/s It can dramatically improve the performance of boot animation. Code Review: https://review.source.android.com//#change,16358

Re: [RFF] Patch tracking/metrics

On 8 April 2011 17:15, James Westby wrote: > On Fri, 8 Apr 2011 16:41:26 +0100, Peter Maydell > wrote: >> On 8 April 2011 15:14, James Westby wrote: >> > This service is going to be used by management to get an idea of the >> > number of patches going to each project over time, the number of pa

Re: [PATCH v2 00/12] mmc: use nonblock mmc requests to minimize latency

On Wed, Apr 6, 2011 at 9:07 PM, Per Forlin wrote: > The intention for introducing none blocking mmc requests is to minimize the > time between a mmc request ends and another mmc request starts. Acked-by: Linus Walleij FWIW, I've looked at the patches so many times I'm already blind for any rema

Re: [RFF] Patch tracking/metrics

On Fri, 8 Apr 2011 16:41:26 +0100, Peter Maydell wrote: > On 8 April 2011 15:14, James Westby wrote: > > This service is going to be used by management to get an idea of the > > number of patches going to each project over time, the number of patches > > submitted upstream by each team over time

Re: git merge question

git rebase -i is a god send if you find yourself needing to rebase often and it get even better when you learn about git rerere (google it) On Fri, Apr 8, 2011 at 9:01 AM, Dave Martin wrote: > On Fri, Apr 8, 2011 at 3:45 PM, Tixy wrote: >> On Fri, 2011-04-08 at 10:16 +0100, Dave Martin wrote: >

RE: git merge question

> On Fri, Apr 8, 2011 at 3:45 PM, Tixy wrote: > > On Fri, 2011-04-08 at 10:16 +0100, Dave Martin wrote: > >> one reason why my understanding of the actual problem here was a bit > >> patchy. > > > > :-) > > _not_ intentional! (if you believe me) I don't believe you; I think you should consider

Re: [RFF] Patch tracking/metrics

On 8 April 2011 15:14, James Westby wrote: > This service is going to be used by management to get an idea of the > number of patches going to each project over time, the number of patches > submitted upstream by each team over time, the % of patches accepted > upstream, the average time from subm

Re: git merge question

On Fri, Apr 8, 2011 at 3:45 PM, Tixy wrote: > On Fri, 2011-04-08 at 10:16 +0100, Dave Martin wrote: >> one reason why my understanding of the actual problem here was a bit >> patchy. > > :-) _not_ intentional! (if you believe me) Anyway ... interactive rebase solved my problem relatively painle

Re: git merge question

On Fri, 2011-04-08 at 10:16 +0100, Dave Martin wrote: > one reason why my understanding of the actual problem here was a bit > patchy. :-) -- Tixy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linar

Re: [RFF] Patch tracking/metrics

On Fri, Apr 8, 2011 at 4:14 PM, James Westby wrote: > Hi, > > This service is going to be used by management to get an idea of the > number of patches going to each project over time, the number of patches > submitted upstream by each team over time, the % of patches accepted > upstream, the avera

Re: [RFF] Patch tracking/metrics

Hi, This service is going to be used by management to get an idea of the number of patches going to each project over time, the number of patches submitted upstream by each team over time, the % of patches accepted upstream, the average time from submission to acceptance for each project, and othe

Re: [gw...@debian.org: Registration now open for DebConf11]

+++ Steve McIntyre [2011-04-08 13:02 +0100]: > FYI: Which grade is ARM paying for? Commercial or corporate? Have you found out what the expenses contribution for driving there is, or were you just ignoring all that? Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http:/

[gw...@debian.org: Registration now open for DebConf11]

FYI: - Forwarded message from Gunnar Wolf - Date: Thu, 7 Apr 2011 14:16:33 -0500 From: Gunnar Wolf To: debian-devel-annou...@lists.debian.org Subject: Registration now open for DebConf11 User-Agent: Mutt/1.5.20 (2009-06-14) Registration is now open for DebConf11. For registration instr

Re: git merge question

On Thu, Apr 7, 2011 at 9:53 PM, Nicolas Pitre wrote: > On Thu, 7 Apr 2011, Dave Martin wrote: > >> The problem seems to be that when a merge is committed, git references >> the merged commits in their original context: no information is >> recorded about how the merge was resolved.  The result jus