All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Larson <clarson@kergoth.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: BBVERSIONS
Date: Tue, 23 Mar 2010 15:19:19 -0700	[thread overview]
Message-ID: <b6ebd0a51003231519v7818d8bjdf749c712f58f0ae@mail.gmail.com> (raw)
In-Reply-To: <20100323204511.GA12446@gmail.com>

On Tue, Mar 23, 2010 at 1:45 PM, Khem Raj <raj.khem@gmail.com> wrote:

> On (23/03/10 10:47), Martin Jansa wrote:
> > 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 :)
>
> I think it could be an useful experiment as an option for packages which
> dont change so much as the releases progress. However adding stuff to build
> for multiple version in same recipe can be error prone. I have seen this
> happening with changes made to .inc files when other recipes break
> silently.
>
> Currently we have per version recipes (roughly) which gives a playground
> for a given version one can do customization fairly easily and they are
> contained.
>
> If I make change to a given version the recipe will also affect other
> versions even if nothing of interest was done for those versions due to say
> PR bump isnt it ?
>
> I think moving bitrotted recipes to different location is probably also a
> good
> way to speed up parsing time for general users without changing the bb
> files too much.
>
> Recently asking new users about bitbake they were pretty much confused with
> syntax I think this will add to it.


Well, as I said previously in the thread, I personally think it's a better
idea to have the old recipes brought forward with current developments, even
if it breaks other versions, than let the other recipes rot and never pick
up those fixes.  This is the dev branch, shit breaks, it happens.  That
said, you can still constrain a change to a single version with this feature
used, by using the version override.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics


  reply	other threads:[~2010-03-23 22:22 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         ` BBVERSIONS Martin Jansa
2010-03-23 20:45   ` BBVERSIONS Khem Raj
2010-03-23 22:19     ` Chris Larson [this message]
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=b6ebd0a51003231519v7818d8bjdf749c712f58f0ae@mail.gmail.com \
    --to=clarson@kergoth.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.