All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Jansa <martin.jansa@gmail.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: BBVERSIONS
Date: Tue, 23 Mar 2010 10:47:57 +0100	[thread overview]
Message-ID: <20100323094757.GE21210@jama> (raw)
In-Reply-To: <b6ebd0a51003221526y7c47c57esd7bc14cc5e85f893@mail.gmail.com>

On Mon, Mar 22, 2010 at 03:26:53PM -0700, Chris Larson wrote:
> Greetings all,
> 
> Thoughts? Questions? Concerns?  I've been wondering if this is really
> worthwhile, but I think it is.  I think there is value in keeping old
> versions around, but this allows us to avoid cluttering up the repository as
> much, and makes it so that one change to a recipe can affect all the
> versions in that range by default, or all versions, rather than just the one
> version you tested.  Of course, ideally you'd test all versions, but that's
> the case today too, its just that now our recipes get bitrotted instead.
>  Personally, I'd rather see the old version content continue to be brought
> forward by default, and if it fails to build with that, we fix it, but it's
> easier to fix a build than to unclutter the repository.
> 
> I'm hoping to get some input on this :)

For me it seems easier to read shared stuff in .inc and then multiple
files with just include on .inc and checksums. Sometimes with additional
patch or some fix only for particular version, instead of one a bit
longer file with OVERRIDES.

But maybe it's just lack of imagination on my side.

Also as I stated in some other thread, I think it's usefull to have one version
of each major version which was in OE (probably latest from each range
you have in nano.bb example), because to test 5 version at least if
patches apply cleanly and it builds ok, is much faster than 42 version
from example.

Regards,

-- 
uin:136542059                jid:Martin.Jansa@gmail.com
Jansa Martin                 sip:jamasip@voip.wengo.fr 
JaMa                         



  parent reply	other threads:[~2010-03-23  9:51 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 ` Martin Jansa [this message]
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         ` BBVERSIONS Martin Jansa
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=20100323094757.GE21210@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.