[meta-freescale] GPU 2d/3d acceleration not working in yocto qte-in-use-image

[Otavio Salvador]

On Thu, Jul 18, 2013 at 4:16 AM, Eric Bénard <eric at eukrea.com> wrote:
> Le Wed, 17 Jul 2013 18:02:27 -0300,
> Otavio Salvador <otavio at ossystems.com.br> a écrit :
>
>> On Wed, Jul 17, 2013 at 5:43 PM, Daiane Angolini
>> <daiane.angolini at freescale.com> wrote:
>> > On 07/17/2013 10:14 AM, Otavio Salvador wrote:
>
>> >> Yes and if you check those they're build failure fixes (except the
>> >> duplicated assignment in mx28evk) so I could keep autobuilder and
>> >> users being able to build. So this is the exception :-)
>> >
>> > I don't agree it should exists any exception for this.
>>
>> For everything there're an exception. However those patches were
>> failures which NO ONE fixed and I use daily build for checking the
>> quality of the BSP so it being broken is a problem for me.
>>
>> It is clear that *most* people do not run updated master branches (or
>> they'd have got those failures and send a patch).
>>
> some peoples are not only trying to get a successful build on a daily
> basis but are designing products (sometimes based on master when the
> product's release is due for the next Yocto's release) and so can't
> update the master branch every day when they are working on their
> board's BSP.
> Being aware patches are applied on master to improve it (or fix it when
> necessary) is a good information for them.

I agree and I also have products being done.

Another thing it seems it would be bad if you update to today's master
and it is broken, no? So I think  I end helping your product
development.

>> > I really think any merged patch MUST be sent to ML previously.
>>
>> Most are send. Except the exceptions as said above.
>>
>> > I've been "accepting" your master-next approach only because I don't think
>> > it matter for anyone. However, we must be sure what have in master.
>>
>> There's GIT for it. If people matter GIT log have all the information
>> and I try to keep informative logs.
>>
> You're right, we always can find a technical solution. A more community
> friendly solution would be to use the mailing list as done in most
> other layers/projects but that's your layer so that's your policy and
> now we know it. There is not cost for you (only a git send-email before
> doing the git push - or even just after if you prefer).

This is to make your life easier. As I said the patches pushed
directly were to fix build-failures or critical issues.

Now with this on mind I am curious ... do you review all patches I
send? In case you do I am doing a good job as you comment very rarely
on them ;)

It is very good when someone review my patches and find a issue I
missed so, in case you're not following the mailing list close, please
do.

>> > Is there any restriction from Yoctoproject daily build server that it must
>> > build every single time, with no failure?
>>
>> No; this is my restriction. The more time it is failing to build more
>> failure accumulate and I keep it working all the time to avoid having
>> hidden issues there.
>>
> the important thing is to be aware of your policies (and their
> evolutions).

Regards,

--
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750