Re: [PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Thu, 2011-10-20 at 14:54 +0200, Koen Kooi wrote:
> Op 20 okt. 2011, om 14:38 heeft Richard Purdie het volgende geschreven:
> 
> > 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@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?
> 
> That's what stable releases are for, but I don't see a release for
> OE-core, do you? I see a poky release, but not an OE-core release.

As you are no doubt aware, that got discussed at the last TSC meeting.
Khem did volunteer to help with that, there is a branch there ready to
be tagged too and I was planning to raise progress with this at
tonight's TSC meeting.

Cheers,

Richard