2010/9/9 Phil Blundell <[email protected]>: > On Thu, 2010-09-09 at 09:11 +0200, Frans Meulenbroeks wrote: >> 2010/9/2 Frans Meulenbroeks <[email protected]>: >> > - if this_soc_family and not re.match(need_machine, >> > this_soc_family): >> > + if (this_soc_family and not re.match(need_machine, >> > this_soc_family)) or not this_soc_family: >> > raise bb.parse.SkipPackage("incompatible with machine >> > %s" % this_machine) > > I am still far from convinced that this hunk of SOC_FAMILY code is > desirable to have in the first place but, if it's going to stay there, > clearly it should be fixed so that it doesn't cause problems for > non-users. > > So, yes, your patch looks fine to me. > > p. > Phil, thanks for the feedback.
I'm not too sure on the usefulness of it either, but there is some breakage so we should either revert the patch or fix it. Actually the SOC_FAMILY got pushed before the review was concluded. Technically it got the ack's but the discussion was still ongoing when this was pushed. What also makes it fishy is that all acks are from the same company (which is the same one as the person who submitted the patch): Signed-off-by: Chase Maupin <[email protected]> Acked-by: Denys Dmytriyenko <[email protected]> Acked-by: Koen Kooi <[email protected]> Signed-off-by: Koen Kooi <[email protected]> I would suggest modifying the commit policy disallowing these kind of things, saying the two Ack's must be from two developers not affiliated with the same company. (actually we might even want to take it further and saying that global changes that affect everyone would require ACK's from developers from more than one distro). Question to the TSC: should the SOC_FAMILY patch be reverted and put on hold until there is agreement whether or not we want this? Frans _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
