Openembedded Devel Discussions
 help / color / mirror / Atom feed
From: Koen Kooi <koen@dominion.kabel.utwente.nl>
To: openembedded-devel@openembedded.org
Subject: Re: OE Staging ABI Change Warning
Date: Mon, 03 Mar 2008 13:46:58 +0100	[thread overview]
Message-ID: <fqgs03$f44$1@ger.gmane.org> (raw)
In-Reply-To: <200803031312.15859.zecke@selfish.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Holger Freyther schreef:
| On Monday 03 March 2008 10:37:59 Richard Purdie wrote:

|> Having looked at some old parts of the metadata when fixing up staging
|> references, we already have a ton of broken .bb files :(. I was really
|> disappointed with the quality in some areas and I honestly don't know
|> what to do about this.
|
| There is proposal to start with an empty repository and move things over,
| testing and compiling world, clean up weekends.... more review on
checking
| things in.

The previous consensus to that proposal was "we should be able to do
cleanups in-place". I still think we should start such a branch where we
can do the clean up while retaining the history. Those cleanups would
consist of:

a) basic janitorial stuff:

* running the recipe through oe-stylize.py and fix accordingly
* document patches (origin, upstream status, etc)
* restucrure FILESDIR to avoid duplicate files (e.g. files/foo.patch
bar-1.0/foo.patch, etc)

b) updating to OE standards

* Replace custom methods with standards ones where appropriate (e.g.
do_stage() -> autotools_stage_all
* document remaining custom methods (e.g. do_configure_append sed magic)
* sanitize PACKAGES and FILES
* sanitize overrides (e.g. fix all the CONFFILES_nylon stuff)

c) unit testing

* compile for different archs
* run through insane

Regardless if we create a branch for that or not, we should declare a
freeze for e.g. 3 months where only bugfixes and cleanups are allowed to
be checked in.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFHy/NCMkyGM64RGpERAkjlAJ9GgDhax6XcSE0kQja3za3fxK8e6wCZAdba
6G2Uq14grE9WgmwjTfjqGMs=
=vD/7
-----END PGP SIGNATURE-----




  reply	other threads:[~2008-03-03 12:48 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-29 16:46 OE Staging ABI Change Warning Richard Purdie
2008-02-29 17:24 ` Leon Woestenberg
2008-02-29 18:04   ` Richard Purdie
2008-02-29 18:29     ` Leon Woestenberg
2008-02-29 22:43       ` Richard Purdie
2008-03-03  1:07 ` Holger Freyther
2008-03-03  9:37   ` Richard Purdie
2008-03-03 12:12     ` Holger Freyther
2008-03-03 12:46       ` Koen Kooi [this message]
2008-03-03 14:34         ` Richard Purdie
2008-03-03 14:43           ` Koen Kooi
2008-03-03 15:46           ` Rod Whitby
2008-03-03 16:14             ` Leon Woestenberg
2008-03-03 16:39               ` Leon Woestenberg
2008-03-03 17:20 ` Mike (mwester)
2008-03-04  0:08 ` Koen Kooi
2008-03-04 16:53 ` Koen Kooi
2008-03-06 12:42   ` Richard Purdie
2008-03-06 12:58     ` Koen Kooi

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='fqgs03$f44$1@ger.gmane.org' \
    --to=koen@dominion.kabel.utwente.nl \
    --cc=openembedded-devel@lists.openembedded.org \
    --cc=openembedded-devel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox