[oe] [PATCH] base.bbclass: fix soc-family test

[Denys Dmytriyenko]

On Thu, Sep 09, 2010 at 03:16:54PM +0200, Frans Meulenbroeks wrote:
> 2010/9/9 Maupin, Chase <chase.maupin at ti.com>:
> 
> >>
> >> 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 <chase.maupin at ti.com>
> >> Acked-by: Denys Dmytriyenko <denys at ti.com>
> >> Acked-by: Koen Kooi <k-kooi at ti.com>
> >> Signed-off-by: Koen Kooi <koen at openembedded.org>
> >>
> >> 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,
> >
> > As the person who submitted this change I'd like to ask that it not be reverted.  I am using it currently so that when defining COMPATIBLE_MACHINE for recipes targeted at OMAP3 devices I do not have to keep a rolling list of all the various OMAP3 devices.  This can quickly become:
> >
> > COMPATIBLE_MACHINE = "dm37x-evm|am37x-evm|omap3evm|am3517-evm|beagleboard|......"
> >
> > Instead by allowing SOC_FAMILY to be used as a COMPATIBLE_MACHINE this can be handled cleanly with:
> >
> > COMPATIBLE_MACHINE = "omap3"
> >
> > Please consider this use case.  I would much prefer if your fix was put into the base.bbclass than if this were removed.
> >
> 
> Chase,
> 
> I understand your use case.
> The major concern I see is the overlap with MACHINE_CLASS.
> Anyway, I have no real objections against SOC_FAMILY.
> The only observation is that it has been introduced a little bit
> hastily without the community reaching consensus.
> 
> Frans.
> 
> PS: thanks for the ack that arrived while I was typing this
> PPS: wrt COMPATIBLE_MACHINE: I think it is possible to use wildcards,
> so *if* the machines with omap3 get that as a prefix it could also be
> used
> (and yes: this is just an alternate option, and I see the con's of it)

Frans,

I'd like us to find a compromise and a solution that satisfies everybody. 

Unfortunately, the original discussion about SOC_FAMILY vs. MACHINE_CLASS 
never came to any fruition - Graeme explained his motives behind MACHINE_CLASS 
and said that it is now deprecated.

It was also mentioned, while SOC_FAMILY is slightly newer than MACHINE_CLASS, 
the feature itself is over a year old and used quite extensively, although 
limited mainly to recipes/ti location...

And if technically SOC_FAMILY may be similar to MACHINE_CLASS, logically they 
try to solve grouping problem from different direction, which was also 
explained.

After that the original discussion was stalled and there were no strong 
opinions one way or another. Based on that, Chase's change was pushed.

I see and understand Phil's position - if that's strong enough, we can 
re-consider.

BTW, I was under impression, that the issue in COMPATIBLE_MACHINE was fixed 
soon after it was discovered. Sorry for not acknowledging your fix earlier.

Anyway, just wanted to let you know that we are not trying to undermine 
anybody in the community and we, as a company, want to work close with the 
community, and be a good citizen. Hopefully, this incident will not be 
considered as an indication of otherwise. Thank you for your understanding.

-- 
Denys