[oe] Kernel recipes with broken PRs now

[Phil Blundell]

On Sun, 2009-05-24 at 13:37 +0200, Koen Kooi wrote:
> On 24-05-09 11:23, Phil Blundell wrote:
> >  This seems
> > particularly pertinent for the stable branch where, as I understood it,
> > intrusive changes were supposed to be avoided.
> 
> Wrong, the stable branch can get intrusive changes as well, the only 
> prereq is review and testing, which most changes in .dev never get.

Fair enough.  "Stable" seems like a bit of a misnomer in that case, but
if this genuinely is the policy for the branch then so be it.

> That's nice and all, but I see no actual patch that implements that, or 
> even a proposal with pseudocode. I'm sure there are better ways, but 
> till someone actually takes the time to cook up a patch instead of 
> handwaving, the situation won't change.

I did already propose one specific better way (i.e. extending the
kernel-abiversion mechanism) in which you could have implemented the
original feature.  I see that Richard Purdie also made some different
suggestions in response to your original RFC.  If these suggestions
don't work for you, please explain why not and perhaps we can come up
with something different.

I have also suggested one way in which, if you aren't prepared to solve
the underlying problem in a better way, you could at least mitigate the
effect of the collateral damage (i.e. making your change be DISTRO
opt-in rather than globally applied).

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.
Simply checking in something that breaks the versioning for all kernels
apart from your own and then expecting other people to run around after
you cleaning up the mess that you've created is, at the very least,
inconsiderate.

p.