[OE-core] Replacing Web in Sato with Midori

Richard Purdie richard.purdie at linuxfoundation.org
Wed Aug 8 12:48:18 UTC 2012


On Wed, 2012-08-08 at 14:36 +0200, Martin Jansa wrote:
> On Wed, Aug 08, 2012 at 01:23:08PM +0100, Richard Purdie wrote:
> > On Wed, 2012-08-08 at 12:01 +0200, Koen Kooi wrote:
> > > Op 8 aug. 2012, om 10:41 heeft "Burton, Ross" <ross.burton at intel.com> het volgende geschreven:
> > > 
> > > > Hi,
> > > > 
> > > > 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.
> > > > 
> > > > 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).
> > > 
> > > Adding more stuff to oe-core is a bad idea. You should take this
> > > opportunity to split all the sato stuff into its own layer.
> > 
> > I feel very strongly that having a core layer with no way of
> > demonstrating and testing it is a very bad idea. I haven't changed my
> > mind about this and am very unlikely to. "How do you know it works?" is
> > the question you ask about package upgrades for example.
> 
> And does it need to be in the same layer?
> 
> Why not test webkit-gtk from oe-core with midori from meta-oe layer? 
> Or meta-browser layer if meta-oe is too big for testing webkit-gtk.

It needs to be in the same layer. The logistics of including sections of
meta-oe or meta-browser on the autobuilder whilst trying to test things
like "bitbake world" is not somewhere I want to go. The Yocto Project
does not have the manpower at this point in time to increase test
coverage to include meta-browser or meta-oe. If someone gives me access
to a large team of engineers...

Cheers,

Richard







More information about the Openembedded-core mailing list