[OE-core] [PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR
richard.purdie at linuxfoundation.org
Thu Oct 20 14:38:59 CEST 2011
On Thu, 2011-10-20 at 13:29 +0200, Koen Kooi wrote:
> Op 20 okt. 2011, om 13:21 heeft Richard Purdie het volgende geschreven:
> > On Thu, 2011-10-20 at 08:23 +0200, Koen Kooi wrote:
> >> Op 28 sep. 2011, om 22:04 heeft Otavio Salvador het volgende geschreven:
> >>> On Wed, Sep 28, 2011 at 16:50, Richard Purdie
> >>> <richard.purdie at linuxfoundation.org> wrote:
> >>>>> This patch improves the current situation and I don't foresee the
> >>>>> autoPR code working soon
> >>>> Which is why we need to switch to that model and shake out the issues
> >>>> sooner than later. Enough is enough with the PR madness and we need to
> >>>> get to grips and fix it.
> >>> I fully agree this is the way to go but this doesn't mean we ought to
> >>> hold this patch until all this happens. This patch allows the removal
> >>> of the kernel.bbclass from meta-oe so reducing the delta between
> >>> oe-core and meta-oe.
> >> So a month later and no sign of the mythical working
> >> auto-PR-incrementer or work on it.
> > A month where we were stabilising for a release. Its on the 1.2 feature
> > list and as it happens I've been hearing questions about what is needed
> > here.
> >> So can this patch go in? It would mean we can drop kernel.bbclass
> >> from meta-oe.
> > I *HATE* this PR bumping stuff. I've just been told we likely need to
> > bump the PR for anything using libGL which once again shows that build
> > system basically failing to automate building things.
> > So I'm drawing a line here and no, we can't take this. If its fine to
> > expect people to bump PR values manually for lib* changes, its fine for
> > kernels too. I'd suggest you do drop this from meta-oe and we start
> > building up pressure for the problem to get fixed properly rather than
> > letting people wallpaper over the cracks.
> I have products to ship, so treating meta-oe as a plaything and break
> this for the sake of breaking it is unacceptable. I'll let oe-core
> have the monopoly on high-qualitily, but broken metadata.
Its not as if there isn't another way to handle this, it is a little
harder work I agree. This isn't breaking for the sake of breaking
either, its applying a bit of pressure to ensure we fix an underlying
problem we've had for a long time. I don't think fixing it will be easy,
I do think we need to though.
Also, the idea never was to have everyone using bleeding edge for
shipping products. This is what stable releases are for?
More information about the Openembedded-core