[OE-core] [oe-core][PATCH 1/2] site/arm-common: alignment values for guin32, guin64 and unsigned long

Martin Jansa martin.jansa at gmail.com
Thu May 3 14:41:57 UTC 2012


On Thu, May 03, 2012 at 02:46:48PM +0100, Richard Purdie wrote:
> I should also note that there is a wider problem here I'm complaining
> about. The glib issue is actually less of a concern.
> 
> People keep sending patches without sensible descriptions in the commit
> message. I think I've made some comments on list to Saul about this to
> pick on someone in particular. The last set of patches from Khem
> contains one which removed pretty much the whole qemu patch set from the
> git version with no explanation in the commit message.
> 
> No, its not going in and I find it a a bit of an insult that I'm being
> expected to read the diffs, notice these changes and spent time replying
> to the patch with a nicely worded rejection email. I might just start
> replying "no".

True I should be more precise in saying what was tested, in cover letter
I've said:
Tested on my images and fixed failing recipe, mostly it's about
including header files like:
glib-2.0/glib/gthread.h:28:2: error: #error "Only <glib.h> can be
included directly."

And by my images I mean SHR image which cover much more then just
oe-core (mostly meta-oe and meta-smartphone layers). So I had to fix
9 recipes in meta-oe layer and 3 more in meta-smartphone while testing
rebuild from scratch with gcc-4.7 which needed another 3 recipes fixed
in meta-oe, firefox in meta-mozilla and 2 more recipes in
meta-smartphone. So yes I was quite busy whole weekend just because I
wanted to provide good gcc-4.7 coverage with more layers than just
oe-core. Whole glib upgrade was just one of steps in order to be able to
upgrade failing webkit-efl... And it wasn't my decision to make gcc-4.7
default version.

And when talking with Saul on IRC I've
said that I'm not building world (because my desktop is too slow, so
your autobuilder can find broken recipes sooner then my machine even
gets to building them).

So that's why I felt a bit insulted too when it's my fault that I wasn't
testing all this also on e.g. mips.

And FWIW as soon as I've discovered there is problem with other archs
I've replied to this patch (saying that other archs need similar patch)
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-May/021774.html
and submited site changes for x86/x86-64 where I was able to test it
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-May/021779.html

So if that's not enough to report there is known problem with such patch
I cannot do more and I'll rather go out for a walk in such nice weather.

Cheers,
 
> So what I'm asking is that people think about the changes they submit
> and try and help me, not use patch submission as a sounding board and
> not to hope I don't spot something.
> 
> To scale this project we need to develop trust relationships with people
> taking ownership of areas of the codebase. I consider Mark Hatle to
> "own" most things rpm for example. To scale we need to do more of this
> but trust is important. If some people don't want to do this and just
> contribute things when they can which interest them, that is fine but we
> are going to reach a point where we have to take longer to test and take
> such changes.
> 
> Cheers,
> 
> Richard
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20120503/c6324555/attachment-0002.sig>


More information about the Openembedded-core mailing list