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-----
next prev parent 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