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 > >>> <[email protected]> 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? Cheers, Richard _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
