On 08/28/2011 05:20 AM, Somebody in the thread at some point said:
On Sat, 2011-08-27 at 21:29 +0800, Andy Green wrote:
On 08/27/2011 02:15 AM, Somebody in the thread at some point said:
Gerrit is that it doesn't care if the tree has been rebased. It will
just try and merge the changeset on top
On Sat, 2011-08-27 at 21:29 +0800, Andy Green wrote:
> On 08/27/2011 02:15 AM, Somebody in the thread at some point said:
> > Gerrit is that it doesn't care if the tree has been rebased. It will
> > just try and merge the changeset on top of the current tree, whatever
> > the history so in that cas
Hi,
> OK, here's one preliminary theory after I dragged Jason to a conversation
> from his weekend in a vacation.
Thanks! Could have waited until Monday of course, but it's great to
have another starting point to work on over the weekend.
> There could be mis-use of the framebuffer's FBIOPUT_VSC
On 08/27/2011 02:15 AM, Somebody in the thread at some point said:
How well what are basically externally generated and managed kernels will
fit into Gerrit flow is something I don't really understand. But I don't
think it will be as simple as the case where the kernel is a history tree
managed
Hello Zach,
On Thu, 25 Aug 2011 18:12:01 -0500
Zach Pfeffer wrote:
[]
> > I also updated Linaro Gerrit howto:
> > https://wiki.linaro.org/Platform/Android/Gerrit , which now should
> > have all info to have one started quickly with Gerrit, and cover
> > all aspects of Gerrit setup (like upstream
>> The framebuffer is working all right under Ubuntu, so I assume there could
>> be some mis-use, esp. the omapfb extends some of the framebuffer API
>> and we have no idea what impact that will have on top of i.MX5' fb. And
>> FYI - the framebuffer works all right as well with Adeneo's rootfs (a 3