Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Cc: Phil Blundell <philb@gnu.org>
Subject: Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes
Date: Thu, 20 Oct 2011 15:25:52 +0100	[thread overview]
Message-ID: <1319120752.2410.34.camel@ted> (raw)
In-Reply-To: <4E9F5E5A.6040002@intel.com>

On Wed, 2011-10-19 at 16:33 -0700, Saul Wold wrote:
> On 10/19/2011 12:00 PM, Otavio Salvador wrote:
> > On Wed, Oct 19, 2011 at 16:30, Khem Raj<raj.khem@gmail.com>  wrote:
> > ...
> >>>>> Many upstreams we can't track if updates are required automagically, so
> >>>>> we
> >>>>> need a place to record when the last manual check was, also possible
> >>>>> reasons
> >>>>> why we should not update to newer versions, ...
> >>
> >> hmm manual check means it has to be done manually is there any thing
> >> that needs it ?
> >>
> >> I think unless they are distro specific which seems not since they are
> >> in oe-core
> >> they could exist in recipes  thats my opinion.
> >
> > I agree that this should be put into the recipes. Besides this allows
> > for checking if it was updated when the version has been updated.
> >
> > If done right, when updating the version this data will be updated
> > together. I see no change in the amount of changes.
> >
> > A plus of this choice is it will be more difficult to forget to update
> > that info. This happened in last qt update for an example.
> >
> 
> This may need to be something that the TSC brings up, possibly we can 
> talk about it in Prague next week.

So just to give some background here, the information in those files was
added by Yocto people to give some idea of the update status of various
recipes. This included when the version was last checked/updated for
recipes which we can't automate that process for, when certain cleanup
checks were made, what the general state of the recipe was and who on
the Yocto team was specifically looking after given recipes.

When it was discussed, some of it was Yocto specific, some of it wasn't
and popular opinion was against it going into the recipes themselves. I
was ok with that given we have the pn- overrides and can handle the
problem that way just fine.

OE-Core happened and we kept the data with OE-Core at least for now. We
have several options:

a) Keep the data where it is
b) Merge the data into the recipes
c) Move the data out of OE-Core

Since a lot of that data is fairly Yocto process specific, it may make
sense to move it over to meta-yocto...

Cheers,

Richard





  reply	other threads:[~2011-10-20 14:32 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-19  8:28 [CONSOLIDATED PULL 00/16] Various Updates Saul Wold
2011-10-19  8:28 ` [CONSOLIDATED PULL 01/16] poky: fix broken ubifs link in deploy folder Saul Wold
2011-10-19  8:28 ` [CONSOLIDATED PULL 02/16] bluez4: Add glib-2.0 to DEPENDS Saul Wold
2011-10-19  8:28 ` [CONSOLIDATED PULL 03/16] gcc-4.6: Upgrade SRCREV to latest FSF 4.6 branch Saul Wold
2011-10-19  8:28 ` [CONSOLIDATED PULL 04/16] gcc-4.6: Backport PR46934 fix Saul Wold
2011-10-19  8:28 ` [CONSOLIDATED PULL 05/16] ghostscript: Disable parallel make due to install issues Saul Wold
2011-10-19  8:28 ` [CONSOLIDATED PULL 06/16] src_distribute.bbclass, src_distribute_local.bbclass: mostly rewritten Saul Wold
2011-10-19  8:28 ` [CONSOLIDATED PULL 07/16] ghostscript: renamed x86_64 to x86-64 for patch to work Saul Wold
2011-10-19  8:28 ` [CONSOLIDATED PULL 08/16] insane.bbclass: print full path on invalid LICENSE_FILES_CHKSUM Saul Wold
2011-10-19  8:28 ` [CONSOLIDATED PULL 09/16] x86 tune files: set baselib for x32 tune as libx32 Saul Wold
2011-10-19  8:28 ` [CONSOLIDATED PULL 10/16] gmp: also generate the libgmpcxx library Saul Wold
2011-10-19  8:28 ` [CONSOLIDATED PULL 11/16] python-scons: upgrade from 2.0.1 to 2.1.0 Saul Wold
2011-10-19  8:28 ` [CONSOLIDATED PULL 12/16] python-dbus: upgrade from 0.83.2 to 0.84.0 Saul Wold
2011-10-19  8:28 ` [CONSOLIDATED PULL 13/16] libxml-parser-perl: upgrade from 2.40 to 2.41 Saul Wold
2011-10-19  8:28 ` [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes Saul Wold
2011-10-19  8:30   ` Koen Kooi
2011-10-19 15:49     ` Kamble, Nitin A
2011-10-19 15:52       ` Koen Kooi
2011-10-19 16:24         ` Kamble, Nitin A
2011-10-19 16:37           ` Koen Kooi
2011-10-19 16:49             ` Phil Blundell
2011-10-19 16:57               ` Saul Wold
2011-10-19 17:00                 ` Khem Raj
2011-10-19 17:45                   ` Saul Wold
2011-10-19 18:30                     ` Khem Raj
2011-10-19 19:00                       ` Otavio Salvador
2011-10-19 23:33                         ` Saul Wold
2011-10-20 14:25                           ` Richard Purdie [this message]
2011-10-20 14:36                             ` Martin Jansa
2011-10-20 14:48                               ` Koen Kooi
2011-10-20 15:55                               ` Richard Purdie
2011-10-20 16:24                                 ` Koen Kooi
2011-10-20 17:38                                   ` Joshua Lock
2011-10-20 21:28                                 ` Saul Wold
2011-10-20 16:18                             ` Khem Raj
2011-10-20 16:02                         ` Eric Bénard
2011-10-19  8:28 ` [CONSOLIDATED PULL 15/16] gst-plugins-good: update to 0.10.30 Saul Wold
2011-10-19  8:28 ` [CONSOLIDATED PULL 16/16] tzdata: updated SRC_URI and update to 2011k Saul Wold

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=1319120752.2410.34.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=philb@gnu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox