All of lore.kernel.org
 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 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.