From: Martin Jansa <martin.jansa@gmail.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: BBVERSIONS
Date: Tue, 23 Mar 2010 17:20:00 +0100 [thread overview]
Message-ID: <20100323162000.GA32576@jama> (raw)
In-Reply-To: <b6ebd0a51003230907u767ef141icafb3dd88b381883@mail.gmail.com>
On Tue, Mar 23, 2010 at 09:07:01AM -0700, Chris Larson wrote:
> Fair enough, there are valid concerns here, though I think some exist with
> or without the bbversions mechanism to a certain extent. If a minor version
> is buildable that isn't patched with the security patch, remove it from the
> BBVERSIONS variable. Not that different from what you'd do today, just with
> less individual recipes. I'm not proposing that we sit down and turn every
> recipe into something like what I'm playing with with nano, where you can
> build any version that exists, this is just a proof of concept, to
> experiment with the new possibilities for structuring of recipes. I expect
> in the real world we'd start by using it to consolidate some metadata, as
> you mention, and add only versions which we already have, or have tested.
> Do you think the feature would be useful in this way?
Sure, I'm just pointing that expected use-cases where it's really
usefull are a bit limited by those concerns above. So it was more for
your question if it's worth it :).
> Of course, ideally, we'd set up more testing of things on the target with an
> automated testing system of some sort, to make it easier to confirm that we
> haven't broken things in other versions and other architectures (and this is
> a concern today too).
>
> Are there any concerns about this feature existing actually being a problem,
> in that it will encourage people to start using it, or should we get it into
> master and see how it goes? We won't be able to really utilize it in OE
> until 1.10 releases and we bump our required bitbake to 1.10 anyway, which
> is why I'm doing the testing and experimentation outside it for now.
At least I'm happy to see another dev waiting for 1.10 required by
oe.dev :).
Cheers,
--
uin:136542059 jid:Martin.Jansa@gmail.com
Jansa Martin sip:jamasip@voip.wengo.fr
JaMa
next prev parent reply other threads:[~2010-03-23 16:23 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-22 22:26 BBVERSIONS Chris Larson
2010-03-23 9:32 ` BBVERSIONS Frans Meulenbroeks
2010-03-23 9:50 ` BBVERSIONS Holger Hans Peter Freyther
2010-03-23 9:58 ` BBVERSIONS Frans Meulenbroeks
2010-03-23 15:36 ` BBVERSIONS Chris Larson
2010-03-23 12:40 ` BBVERSIONS Michael Smith
2010-03-23 14:57 ` BBVERSIONS Chris Larson
2010-03-23 9:47 ` BBVERSIONS Martin Jansa
2010-03-23 15:41 ` BBVERSIONS Chris Larson
2010-03-23 15:57 ` BBVERSIONS Martin Jansa
2010-03-23 16:07 ` BBVERSIONS Chris Larson
2010-03-23 16:20 ` Martin Jansa [this message]
2010-03-23 20:45 ` BBVERSIONS Khem Raj
2010-03-23 22:19 ` BBVERSIONS Chris Larson
2010-03-23 15:42 ` BBVERSIONS Chris Larson
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=20100323162000.GA32576@jama \
--to=martin.jansa@gmail.com \
--cc=openembedded-devel@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.