From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR
Date: Thu, 20 Oct 2011 13:38:59 +0100 [thread overview]
Message-ID: <1319114339.2410.5.camel@ted> (raw)
In-Reply-To: <46567209-1B97-42F5-B5DF-E34B823F6BF7@dominion.thruhere.net>
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?
Cheers,
Richard
next prev parent reply other threads:[~2011-10-20 12:45 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-17 22:18 [PATCH 1/5] kernel.bbclass: blacklist 'perf-dbg' as well for the modules metapackage Dmitry Eremin-Solenikov
2011-09-17 22:18 ` [PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR Dmitry Eremin-Solenikov
2011-09-17 22:24 ` Otavio Salvador
2011-09-27 13:52 ` Bruce Ashfield
2011-09-27 23:40 ` Koen Kooi
2011-09-28 14:54 ` Richard Purdie
2011-09-28 18:42 ` Koen Kooi
2011-09-28 18:50 ` Dmitry Eremin-Solenikov
2011-09-28 19:50 ` Richard Purdie
2011-09-28 20:04 ` Otavio Salvador
2011-10-20 6:23 ` Koen Kooi
2011-10-20 11:21 ` Richard Purdie
2011-10-20 11:29 ` Koen Kooi
2011-10-20 11:35 ` Otavio Salvador
2011-10-20 11:53 ` Frans Meulenbroeks
2011-10-20 12:38 ` Richard Purdie [this message]
2011-10-20 12:54 ` Koen Kooi
2011-10-20 13:02 ` Otavio Salvador
2011-10-21 12:05 ` Koen Kooi
2011-10-20 13:56 ` Richard Purdie
2011-09-17 22:18 ` [PATCH 3/5] kernel.bbclass: move uImage handling to separate task Dmitry Eremin-Solenikov
2011-09-17 22:25 ` Otavio Salvador
2011-09-21 13:09 ` Dmitry Eremin-Solenikov
2011-09-27 13:39 ` Bruce Ashfield
2011-09-17 22:18 ` [PATCH 4/5] kernel.bbclass: handle .cis firmware Dmitry Eremin-Solenikov
2011-09-27 13:40 ` Bruce Ashfield
2011-09-28 14:50 ` Richard Purdie
2011-09-17 22:18 ` [PATCH 5/5] kernel.bbclass: remove unshipped files in do_install Dmitry Eremin-Solenikov
2011-09-27 13:41 ` Bruce Ashfield
2011-09-28 14:50 ` Richard Purdie
2011-09-17 22:23 ` [PATCH 1/5] kernel.bbclass: blacklist 'perf-dbg' as well for the modules metapackage Otavio Salvador
2011-09-22 12:25 ` Dmitry Eremin-Solenikov
2011-09-22 12:35 ` Koen Kooi
2011-09-22 13:00 ` Dmitry Eremin-Solenikov
2011-09-22 13:17 ` Koen Kooi
2011-09-22 13:28 ` Bruce Ashfield
2011-09-22 13:56 ` Koen Kooi
2011-09-22 14:04 ` Bruce Ashfield
2011-09-28 8:47 ` Dmitry Eremin-Solenikov
2011-09-28 14:52 ` Richard Purdie
2011-09-28 14:50 ` Richard Purdie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1319114339.2410.5.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.