[oe] Kernel recipes with broken PRs now

[Phil Blundell]

On Sun, 2009-05-24 at 15:04 +0200, Koen Kooi wrote:
> On 24-05-09 14:27, Phil Blundell wrote:
> 
> > It seems fairly clear that, as the originator of the patch in question,
> > the onus is on you to minimise any resulting damage to other users.
> 
> I'm gradually fixing kernel as I encounter them, but since I don't have 
> access to all hardware present in OE, or computing power to test all 
> toolchain permutations needed to build all kernels (e.g. kernels 
> requiring gcc 2.93.3), I am currently limiting that effort to kernel I 
> can actually test.

In situations like this there are still steps you can reasonably take to
manage the impact on other people, even if you can't directly test all
the potentially-affected packages for yourself.  

In cases like the one at hand here, it's fairly straightforward to
consider what would happen to recipes and machines which haven't been
modified and ensure that the answer isn't anything undesirable.  If it
isn't practical to do that (because the change is more complex and the
interactions are hard to foresee), or if the answer is that something
bad will happen but you don't know how to fix it, you can arrange for
your patch to only take effect for DISTROs that have explicitly selected
it in order to limit the risk for others.

> Furthermore, only kernel actually used by machines present in OE can
> get fixed, we have a number of kernels that have recipes, but no
> machines using them.

That does seem like another indication that this enforced 1:1 mapping
between kernels and MACHINEs is not a good idea in general.  If I
remember right there are at least a few machines which have many-to-many
mappings here and it's hard to see how a MACHINE_KERNEL_PR variable can
really work in that situation.

p.