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>
Subject: Re: Replacing Web in Sato with Midori
Date: Wed, 08 Aug 2012 13:28:27 +0100	[thread overview]
Message-ID: <1344428907.9756.338.camel@ted> (raw)
In-Reply-To: <1344422390.23275.233.camel@phil-desktop>

On Wed, 2012-08-08 at 11:39 +0100, Phil Blundell wrote:
> 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.

I think the intent which perhaps isn't being put clearly is that we're
intending to "morph" sato into a kind of test suite of OE-Core (whether
anything is still "sato" in the end remains to be seen). We appreciate
it needs to be minimal yet have good coverage of the various libs/apis.
Some things will just get moved (eds/pimlico) out, some will go into the
core (e.g. webkit) and so on.

If the webkit recipe is half baked, lets fully bake it as I believe in
doing things properly if you do them at all (which is why web-sato needs
to go).

The changes won't happen overnight but I think Ross' proposal for
sorting the browser as a first step is a good one as part of the larger
plan.

Cheers,

Richard




  parent reply	other threads:[~2012-08-08 12:40 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
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 [this message]
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=1344428907.9756.338.camel@ted \
    --to=richard.purdie@linuxfoundation.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