All of lore.kernel.org
 help / color / mirror / Atom feed
From: Koen Kooi <k.kooi@student.utwente.nl>
To: openembedded-devel@lists.openembedded.org
Subject: Re: OE recipe tree quality
Date: Fri, 30 Jul 2010 10:41:01 +0200	[thread overview]
Message-ID: <i2u36t$cl1$1@dough.gmane.org> (raw)
In-Reply-To: <AANLkTimUYuJBUa5Hz=N_dM-DOe6qPoCDbqCEs2LHTpab@mail.gmail.com>

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

On 30-07-10 10:34, Frans Meulenbroeks wrote:
> 2010/7/30 Koen Kooi <k.kooi@student.utwente.nl>
> 
> On 30-07-10 09:21, Esben Haabendal wrote:
>>>> On Thu, Jul 29, 2010 at 2:07 PM, Philip Balister <philip@balister.org>
> wrote:
>>>>>
>>>>>
>>>>> On 07/29/2010 05:45 AM, Koen Kooi wrote:
>>>>>>
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA1
>>>>>>
>>>>>> On 29-07-10 10:50, Frans Meulenbroeks wrote:
>>>>>>>
>>>>>>> Dear all,
>>>>>>>
>>>>>>> Given the discussions on quality that sometimes pop up (and also
>>>>>>> triggered
>>>>>>> by Robert's message), I decided to kick off a bitbake -k world.
>>>>>>
>>>>>> Could you first explain to me why 'bitbake world' is a good way to
>>>>>> measure quality?
>>>>>>
>>>>>> I would think that building something like console-image and looking at
>>>>>> the following would be a much better metric:
>>>>>>
>>>>>> * does it build?
>>>>>> * are all the rootfs types working?
>>>>>> * does the image do what it is supposed to do?
>>>>>> * Are all the licenses of the output packages correct?
>>>>>> * Do the output packages have any spurious deps?
>>>>>> * Is the content of the output packages correct?
>>>>>> * Are there any known CVEs in the resulting packages?
>>>>>> * Did packaged-staging do its job?
>>>>>> * What kind of QA errors and warnings were raised?
>>>>>> * Did all recipes pass recipe_sanity?
>>>>>> * Did all recipes conform to oe-stylize.py?
>>>>>>
>>>>>> etc
>>>>>>
>>>>>> I would actually advocate removing the 'world' feature from bitbake/OE
>>>>>> to stop people from wasting time on looking at bitbake world and have
>>>>>> them fix actual problems.
>>>>>
>>>>> bitbake world seems to be the source of pointless listserv discussions.
> Does
>>>>> it serve any purpose?
>>>>
>>>> Pointless or not really depends on how you look at quality.
>>>>
>>>> If you look at it as you, Koen and other OE long-timers, yes, it looks
>>>> rather pointless to have bitbake world.
>>>> But for those of us who have a different view on what quality is, then
>>>> bitbake world serves a purpose.
> 
> As Thomas points out, as soon as you start blacklisting things (which
> actually increases quality), bitbake world doesn't work anymore.
> 
> 
>> Blacklisting does *NOT* increase quality. It just hides the problem and as
>> such it is ostrich behaviour.

You're saying that making a choice to only support bluez4 and disallow
linking to random bluez versions does not increase quality? The bluez
people are quite clear on this, pick a version and stick with it.
So please explain to me why following upstream advice and making things
deterministic doesn't increase quality?
You seem to be implying that the bluez developers are a bunch of
ostriches for keeping the API compatible, no?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFMUpAcMkyGM64RGpERAjsTAJ4mtLOVTbW/j/YvrAUfMgJbFmKPDQCfTz9b
D9h1U+Cqg3L9yC3CheQSYr8=
=Nj6f
-----END PGP SIGNATURE-----




  reply	other threads:[~2010-07-30  8:41 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-29  8:50 OE recipe tree quality Frans Meulenbroeks
2010-07-29  9:42 ` Thomas Zimmermann
2010-07-29  9:45 ` Koen Kooi
2010-07-29 10:32   ` Frans Meulenbroeks
2010-07-29 12:07   ` Philip Balister
2010-07-29 12:15     ` Frans Meulenbroeks
2010-07-30  7:21     ` Esben Haabendal
2010-07-30  8:22       ` Koen Kooi
2010-07-30  8:31         ` Graeme Gregory
2010-07-30  8:48           ` Frans Meulenbroeks
2010-07-30  8:56             ` Graeme Gregory
2010-07-30  9:07               ` Frans Meulenbroeks
2010-07-30  9:09                 ` Graeme Gregory
2010-07-30  9:36                 ` Marcin Juszkiewicz
2010-07-30  8:54           ` Esben Haabendal
2010-07-30  8:34         ` Frans Meulenbroeks
2010-07-30  8:41           ` Koen Kooi [this message]
2010-07-30  9:01             ` Frans Meulenbroeks
2010-07-30 15:39               ` Dr. Michael Lauer
2010-07-31 23:12           ` Richard Purdie
2010-08-01  5:10             ` Frans Meulenbroeks
2010-08-01 14:05             ` Philip Balister
2010-08-01 18:48               ` Richard Purdie

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='i2u36t$cl1$1@dough.gmane.org' \
    --to=k.kooi@student.utwente.nl \
    --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.