From: Phil Blundell <philb@gnu.org>
To: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: Replacing Web in Sato with Midori
Date: Wed, 08 Aug 2012 11:39:47 +0100 [thread overview]
Message-ID: <1344422390.23275.233.camel@phil-desktop> (raw)
In-Reply-To: <CAJTo0LZn3md_x3a9-+LV67FYopkXaPgFv8-+U4JEj7UzwSYd9Q@mail.gmail.com>
On Wed, 2012-08-08 at 09:41 +0100, Burton, Ross wrote:
> As everyone who's used it can attest, Web (the optional browser in
> Sato) is pretty rough. Part of my plans about replacing Sato with a
> leaner environment involves replacing it with Midori, and if there
> isn't any disagreements I'll work on a submission to merge Midori into
> Sato now for everyone who expects the Sato web browser to be useful.
Replacing Web with Midori in Sato probably is a fine idea from the point
of view of those folks who want to use Sato per se. As far as oe-core
is concerned, the point of having Sato included is apparently for
testability and it's not entirely obvious that much extra test coverage
would be gained by merging Midori.
Indeed, it's not totally clear that having WebKit in meta-sato is really
justified by the test coverage it brings. I think WebKit itself might
be a reasonable candidate for inclusion in oe-core proper, but the
current situation of having a slightly half-baked recipe in meta-sato is
not very satisfactory.
However...
>This will involve pulling a few projects from meta-oe to oe-core:
>ca-certificates, python-docutils and vala specifically (although its
>possible that we can drop the vala dependency).
... all three of those seem like reasonable enough things to have in
oe-core. Personally I would quite like to see Vala in there. So, from
that point of view, I don't have any objection to your proposal.
But, that said, I do still think that there is going to be some
inevitable tension between the desire to make Sato useful in itself and
the desire to have a test environment for oe-core which doesn't add too
many extra dependencies. So in the longer term I continue to feel that
Sato should probably go away into its own layer (or, at least, a layer
that isn't oe-core) and oe-core itself should gain a dedicated test
suite. Anybody who wanted to go on using Sato to exercise oe-core would
obviously be free to do so even if it was in some other layer.
p.
next prev parent reply other threads:[~2012-08-08 10:51 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-08 8:41 Replacing Web in Sato with Midori Burton, Ross
2012-08-08 10:01 ` Koen Kooi
2012-08-08 12:23 ` Richard Purdie
2012-08-08 12:36 ` Martin Jansa
2012-08-08 12:48 ` Richard Purdie
2012-08-09 15:18 ` Martin Jansa
2012-08-08 13:56 ` Koen Kooi
2012-08-08 14:03 ` Paul Eggleton
2012-08-08 14:47 ` Koen Kooi
2012-08-08 15:00 ` Paul Eggleton
2012-08-08 15:04 ` Samuel Stirtzel
2012-08-08 15:07 ` Paul Eggleton
2012-08-08 10:39 ` Phil Blundell [this message]
2012-08-08 12:07 ` Burton, Ross
2012-08-08 12:26 ` Phil Blundell
2012-08-08 12:31 ` Burton, Ross
2012-08-08 12:28 ` Richard Purdie
2012-08-08 16:39 ` Mark Hatle
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=1344422390.23275.233.camel@phil-desktop \
--to=philb@gnu.org \
--cc=openembedded-core@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox