[MeeGo-dev] MeeGo OBS shutdown - huge thanks and moving on

[David Greaves]

Hi everyone

As we knew the MeeGo infrastructure is closing down.

The MeeGo OBS is scheduled for shutdown at the end of next week ~ 29 May.

I should have announced this earlier but I've been busy; sorry.

Please ensure you've taken backups of anything you need - once it's gone it
really will be gone!

I'd like to take this opportunity to thank everyone at Intel for continuing to
support the MeeGo community for this long with a HUGE special mention to Adam
Gretzinger who has helped look after the infrastructure in an efficient and
reliable way - if you ever have him as a sysadmin for your project then I'm 
jealous!

Thanks also go of course, to Neils Breet and Islam Amer who have worn MeeGo
sysadmin hats and continue to do so in our new home at the Mer Project.

So with that segue we can look forward to where we've built on the open elements
of MeeGo - and hopefully improved them - in the Mer Project.

See https://wiki.merproject.org/ and http://www.merproject.org/ for more info

If you do (or would like to) build opensource projects against Mer, Nemo or
PlasmaActive - or plan to build for Jolla's SailfishOS
(https://www.sailfishos.org/) - and want to use the Mer Community OBS at
https://build.merproject.org/ you're welcome. Register on our bugzilla
https://bugs.merproject.org/ for an account and talk to us on irc in #mer on
freenode or on the mailing lists.

Due to resource limitations we will only be able to support builds against Mer
based distros (with some special cases for our infrastructure tools like OBS,
BOSS, IMG etc) - but do talk to us if you have any questions.

I'll continue to act as a volunteer sysadmin until the lights go out; it's been
an experience and a pleasure working with the MeeGo community.

David Greaves / lbt

Soon to be ex-MeeGo.com sysadmin but now Mer Co-Founder and Vendor-relations Guy

-- 
"Don't worry, you'll be fine; I saw it work in a cartoon once..."
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

[MeeGo-dev] [Meego-SDK]https relevant

[温腊]

HI:
    I am a student of Software Institute of Chinese Academy. Now I program in 
MeeGo System. I have some questions:
The same Code when running in
(1)device: QWebView can not load "https" page but the browser contained in 
MeeGo System can load https pages.
(2)QtCreator-Simulator: QWebView can not load https pages;
(3)QtCreator-Emulator:QWebView can load https pages successfully;
I know that it is about openssl, but i don know how to configure it!
Can anyone help about this problem? Thank you very
 much.

   wenla___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

[MeeGo-dev] MeeGo Gitorious Service after March 21, 2013 and git.meego.com setup

[adam.gretzin...@linux.intel.com]

Hi folks:


The contract the MeeGo project has with Gitorious ends on March 21,
2013. Gitorious provided source coding hosting services for MeeGo.

While its not expected that they will remove existing git repos it is
expected there will be changes in the meego.gitorious.org website which
may make it hard to find the repos for some who relied on the web interface.


To keep the code available https://git.meego.com has been setup. It has
a copy of the official git repos, anyone can substitute a Gitorious URL
for a git.meego.com URL (again for official repos) if necessary.


This is a precaution to preserve an official copy of the GIT repos and
the list of all repos where a gitweb instance is provided on git.meego.com.


Adam Gretzinger
Intel Open Source Technology Center








-MeeGo Gitorious Contract Ending Announcement Email 3/18/2013
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] [MeeGo-announce] MeeGo mailing list shutdown

[George Ingram]

Thanks for all your work, Best George


George Ingram
http://www.georgeingram.com/

815 1st Avenue, Ste 156
Seattle, Washington 98104
Direct Line 804-464-7267
Fax Line 804-414-7746

-Original Message-
From: meego-announce-boun...@meego.com
[mailto:meego-announce-boun...@meego.com] On Behalf Of Thiago Macieira
Sent: Friday, January 25, 2013 3:17 PM
To: meego-annou...@lists.meego.com
Subject: [MeeGo-announce] MeeGo mailing list shutdown

Dear participants

As part of the MeeGo infrastructure ramp down, we will begin to shut down
most mailing lists. In the coming days, all mailing lists at lists.meego.com
will be shut down, except for the following:

NameReason
meego-dev   general discussions
meego-commits   automated emails from builds still being sent there
meego-security  security concerns

The mailing list archives will be frozen too, but not deleted until the main
infrastructure shuts down completely. Some mailing lists have been archived
publicly by other services, such as:

http://gmane.org/find.php?list=meego
http://www.mail-archive.com/find.php?q=meego

In addition, we'd like to ask everyone still using MeeGo services, like OBS,
to begin finding other solutions. We will shut down all but essential
services in May 2013.

If you have questions about this, please contact me or
adam.r.gretzin...@intel.com.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
___
MeeGo-announce mailing list
meego-annou...@meego.com
http://lists.meego.com/listinfo/meego-announce

___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

[MeeGo-dev] MeeGo mailing list shutdown

[Thiago Macieira]

Dear participants

As part of the MeeGo infrastructure ramp down, we will begin to shut down most 
mailing lists. In the coming days, all mailing lists at lists.meego.com will 
be shut down, except for the following:

NameReason
meego-dev   general discussions
meego-commits   automated emails from builds still being sent there
meego-security  security concerns

The mailing list archives will be frozen too, but not deleted until the main 
infrastructure shuts down completely. Some mailing lists have been archived 
publicly by other services, such as:

http://gmane.org/find.php?list=meego
http://www.mail-archive.com/find.php?q=meego

In addition, we'd like to ask everyone still using MeeGo services, like OBS, 
to begin finding other solutions. We will shut down all but essential services 
in May 2013.

If you have questions about this, please contact me or 
adam.r.gretzin...@intel.com.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] Meego-tv-irinterface

[Brendan Le Foll]

On 19 September 2012 09:52, MacBook Pro  wrote:
> Hello
> I work on Cocom Tatcher 4200 and the board can't recognize the Ir-receiver
>
> i launch the command
> ir-interface /usr/share/ir_interface/cocom_nec.map &
> Got the SoC information
> Waiting for the PIC events…
> when i list the input device at /proc/bus/input/devices i have the receiver 
> but no Physique adress like for a keyboard or a mouse
>
> I: Bus=0006 Vendor=8765 Product=4321 Version=0001
> N: Name="meego-tv-ir"
> P: Phys=
> S: Sysfs=/devices/virtual/input/input5
> U: Uniq=
> H: Handlers=kbd event3
> B: PROP=0
> B: EV=13
> B: KEY=40 0 0 0 0 18000 4180 4801 1e1680 0 0 1ffe
> B: MSC=10
>
>
> When i list the input device by id (/dev/input/by-id/), the ir receiver isn't 
> recognized
>
> lrwxrwxrwx 1 root root   9 Jan  1 00:00 
> usb-0461_USB_Optical_Mouse-event-mouse -> ../event2
> lrwxrwxrwx 1 root root   9 Jan  1 00:00 usb-0461_USB_Optical_Mouse-mouse -> 
> ../mouse0
> lrwxrwxrwx 1 root root   9 Jan  1 00:00 usb-_USB_Keyboard-event-if01 -> 
> ../event1
> lrwxrwxrwx 1 root root   9 Jan  1 00:00 usb-_USB_Keyboard-event-kbd -> 
> ../event0
>
> please, i wish know what is the problem and how to resolve it.  =)
>
> thx
> ___
> MeeGo-dev mailing list
> MeeGo-dev@meego.com
> http://lists.meego.com/listinfo/meego-dev
> http://wiki.meego.com/Mailing_list_guidelines

Hi,

Meego-tv-ir uses uinput have a look in /dev/input/uinput. Have a look
at the code if you want to understand in detail how to handle the
ir-remote. https://github.com/arfoll/meego-tv-IRinterface

Cheers,
Brendan

-- 
Brendan Le Foll
http://www.madeo.co.uk
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

[MeeGo-dev] Meego-tv-irinterface

[MacBook Pro]

Hello
I work on Cocom Tatcher 4200 and the board can't recognize the Ir-receiver

i launch the command 
ir-interface /usr/share/ir_interface/cocom_nec.map &
Got the SoC information
Waiting for the PIC events…
when i list the input device at /proc/bus/input/devices i have the receiver but 
no Physique adress like for a keyboard or a mouse

I: Bus=0006 Vendor=8765 Product=4321 Version=0001
N: Name="meego-tv-ir"
P: Phys=
S: Sysfs=/devices/virtual/input/input5
U: Uniq=
H: Handlers=kbd event3 
B: PROP=0
B: EV=13
B: KEY=40 0 0 0 0 18000 4180 4801 1e1680 0 0 1ffe
B: MSC=10


When i list the input device by id (/dev/input/by-id/), the ir receiver isn't 
recognized

lrwxrwxrwx 1 root root   9 Jan  1 00:00 usb-0461_USB_Optical_Mouse-event-mouse 
-> ../event2
lrwxrwxrwx 1 root root   9 Jan  1 00:00 usb-0461_USB_Optical_Mouse-mouse -> 
../mouse0
lrwxrwxrwx 1 root root   9 Jan  1 00:00 usb-_USB_Keyboard-event-if01 -> 
../event1
lrwxrwxrwx 1 root root   9 Jan  1 00:00 usb-_USB_Keyboard-event-kbd -> ../event0

please, i wish know what is the problem and how to resolve it.  =)

thx
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

[MeeGo-dev] MeeGo Maintenance Outages Dec 24, Dec 25, 2011

[adam.gretzin...@linux.intel.com]

We have some outages for MeeGo's infrastructure planned to get some updates 
completed during low expected usage times.



1) Impacted: MeeGo Core OBS, download and repo
December 24, 2011 19:00 GMT (11:00 Pacific)
-- Until --
December 25, 2011 03:00 GMT (19:00 Pacific)

May end early if things go faster then expected.



2) Impacted: Community OBS, MeeGo Websites (most of them), Other MeeGo
public Infrastructure
December 25, 2011 18:00 GMT (10:00 Pacific)
-- Until --
December 26, 2011 01:00 GMT (17:00 Pacific)

May end early if things go faster then expected.




Adam Gretzinger
Intel Open Source technology Center

___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

[MeeGo-dev] MeeGo Outages for Patching 10/29/2011, 10/30/2011

[adam.gretzin...@linux.intel.com]

The MeeGo IT team has a number of items to take care of as part of 
regular maintenance, we'll be having 3 separate change windows this 
coming weekend as listed below.



1) October 29, 2011 03:00 GMT - 05:00 GMT
Outage Reason: OS Patching, Firmware Upgrades
Impacted: Core OBS, download and repo



2) October 29, 2011 18:00 GMT - 22:00 GMT
Outage Reason: OBS Updates
Impacted: Community OBS



2) October 30, 2011 03:00 GMT - 06:00 GMT
Outage Reason: OS Patching, Firmware Upgrades
Impacted: Community OBS, MeeGo websites (almost all of them), MeeGo 
public infrastructure.



Thanks for your patience.

Adam Gretzinger
Intel Open Source Technology Center
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo-dev Digest, Vol 21, Issue 14

[chen walle]

I downloaded a mx-1.3-1-4.2.src.rpm  file from http://repo.meego.com and I
installed it. Then I got a repo file.
Is the rpm mean the kernel source for freescale IMX architecture?  I am
going to use the following instructions to downlown the source:
repo init -u git://gitorious.org/repo-for-meego/meego_manifest.git
repo sync
what kind of source I will get? The kernel source for freescale IMX
architecture? Or ...


2011/10/16 

> Send MeeGo-dev mailing list submissions to
>meego-dev@meego.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
>http://lists.meego.com/listinfo/meego-dev
> or, via email, send a message with subject or body 'help' to
>meego-dev-requ...@meego.com
>
> You can reach the person managing the list at
>meego-dev-ow...@meego.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of MeeGo-dev digest..."
>
>
> Today's Topics:
>
>   1. how to be a meego developer (superccxin)
>   2. Re: how to be a meego developer (Thiago Macieira)
>   3. Re: how to be a meego developer (ju...@jukka.com)
>
>
> --
>
> Message: 1
> Date: Sun, 16 Oct 2011 10:25:40 +0800
> From: "superccxin" 
> To: 
> Subject: [MeeGo-dev] how to be a meego developer
> Message-ID: 
> Content-Type: text/plain; charset="gb2312"
>
> Hi all! As I know, people always divide their system into 3 portions:
> bootloader, kernel, UI platform(eg. Android). Is meego like that too? If so,
> how and where i can get these 3 partions?
>
>
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://lists.meego.com/pipermail/meego-dev/attachments/20111016/dee7e69f/attachment-0001.html
> >
>
> --
>
> Message: 2
> Date: Sun, 16 Oct 2011 10:16:32 +0200
> From: Thiago Macieira 
> To: meego-dev@meego.com
> Subject: Re: [MeeGo-dev] how to be a meego developer
> Message-ID: <3930175.5tpBmmtICd@doriath>
> Content-Type: text/plain; charset="us-ascii"
>
> On Sunday, 16 de October de 2011 10:25:40 superccxin wrote:
> > Hi all! As I know, people always divide their system into 3 portions:
> > bootloader, kernel, UI platform(eg. Android). Is meego like that too? If
> > so, how and where i can get these 3 partions?
>
> The bootloader part you'll get from your hardware vendor. MeeGo doesn't
> provide that.
>
> The kernel and middleware is what we call MeeGo Core. You can download it
> from
> http://repo.meego.com.
>
> As for the UI, it depends on the type of vertical we're addressing. Some of
> the UIs are more advanced stage than others. All of them, depending on
> whether
> they built successfully or not, can be downloaded from the same place.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>   Software Architect - Intel Open Source Technology Center
>  PGP/GPG: 0x6EF45358; fingerprint:
>  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
> -- next part --
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 190 bytes
> Desc: This is a digitally signed message part.
> URL: <
> http://lists.meego.com/pipermail/meego-dev/attachments/20111016/0f4cbb31/attachment-0001.pgp
> >
>
> --
>
> Message: 3
> Date: Sun, 16 Oct 2011 11:48:09 +0300
> From: "ju...@jukka.com" 
> To: meego-dev@meego.com
> Subject: Re: [MeeGo-dev] how to be a meego developer
> Message-ID:
> >
> Content-Type: text/plain; charset=ISO-8859-1
>
> > The kernel and middleware is what we call MeeGo Core. You can download it
> from
> > http://repo.meego.com.
>
> Though you might want to check out Mer also: http://mer-project.org/
>
> Jukka
>
>
> --
>
> ___
> MeeGo-dev mailing list
> MeeGo-dev@meego.com
> http://lists.meego.com/listinfo/meego-dev
>
>
> End of MeeGo-dev Digest, Vol 21, Issue 14
> *
>
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Eero Tamminen]

Hi,

On 10/04/2011 12:06 PM, ext Jon Nordby wrote:

Yes, one would want Scratchbox or similar in addition to what OBS
provides. However, there is nothing that prevents Scratchbox from being
used together with RPM and an RPM based distro is there?


You need some support for RPM tools in SB and OBS would need to prefix
commands with sbox or sb2 depending on which SB version is used.



Don't go around trying to changing everything if what you're missing is
just Scratchbox.


I wouldn't say "just", distro cross-building is surprisingly hairy
problem, it can sprout warts years after you thought it was nailed
down.  Anyway, SB is package build system agnostic.

I would recommend using SB v2.  With that you just need to select
suitable packages from the distro to accelerate and adding path
mapping rules for binaries in them, whereas with SB v1 you need
to support SB specific host tools distro in addition to package
management devkit.


- Eero
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Eero Tamminen]

Hi,

On 10/04/2011 03:08 PM, ext Tom Swindell wrote:

OBS is built with packaging in mind, so it builds packages locally and
on servers in a sanitized environment. Scratchbox may be polluted by
whatever packages a developer has installed and makes dependency
tracking a bit harder IMO.


OBS and Scratchbox aren't competitors or replacements for each other.
OBS is a package building tool, Scratchbox is a cross-building tool
for distros.  I.e. their main focus is completely different.

As to cross-building in OBS, I would recommend it to adopt SB2 as
what I've understood of its current cross-compilation solution looks
like an incomplete re-implementation of SB1 i.e. either much slower
or causing much more issues with builds.


Btw. Despite name, scratchbox v1 and v2 don't have about anything
else in common except the problem they solve, distro cross-building.

SB1 problem is that its host tools are basically a hard to maintain
distro in itself and therefore typically out of sync with the target
packages, which sometimes cases issues.

Whereas SB2 is designed just to use x86 version of the packages
to speed up build of non-x86 packages, and have fine-grained
control on how all this works.


- Eero

Here's some more info on SB2:
https://maemo.gitorious.org/scratchbox2
http://packages.debian.org/wheezy/scratchbox2
http://lists.scratchbox.org/pipermail/scratchbox-users/
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[nic...@nicoladefilippo.it]

Hi,
2 weeks after the announcement of tizen Meego is unclear what kind of death he 
will die?  N.
  
> >
> > Probably.
> >
> >> Probably, an error of Nokia with the N900 is trying to mix both developers
> >> and users. This is an error.
> >
> > Can you explain this a bit more? Do you mean Nokia N900 as a product, or 
> > what we are doing with MeeGo Community edition? If you mean latter, I 
> > probably understand what you mean.
> >
> 
> When the N900 was launched, it seemed to a lot of "normal" end users as 
> an incomplete product. For developers, it was an incredible product with 
> lots of posibilities and future, so there was different perceptions.
> 
> At Maemo, there was lots of complains about its behaviour because some 
> users expected a kind of replacement for Android or iOS.
> 
> The Meego CE should be considered as a "proof-of-concept" of a wider 
> technology, better than Android and iOS, and I think it is important to 
> separate users and developers at this point (simply separated communities).
> 
> Meego CE is an incredible and amazing project and, in the long term, it 
> should be focused as a replacement of Maemo 5 on real devices: N900 ... 
> and others.
> 
> Regards,
> Àngel
> 
> 
> 
> 
> 
> ___
> MeeGo-dev mailing list
> MeeGo-dev@meego.com
> http://lists.meego.com/listinfo/meego-dev
> http://wiki.meego.com/Mailing_list_guidelines
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Angel Perles]

Probably.


Probably, an error of Nokia with the N900 is trying to mix both developers
and users. This is an error.


Can you explain this a bit more? Do you mean Nokia N900 as a product, or what 
we are doing with MeeGo Community edition? If you mean latter, I probably 
understand what you mean.



When the N900 was launched, it seemed to a lot of "normal" end users as 
an incomplete product. For developers, it was an incredible product with 
lots of posibilities and future, so there was different perceptions.


At Maemo, there was lots of complains about its behaviour because some 
users expected a kind of replacement for Android or iOS.


The Meego CE should be considered as a "proof-of-concept" of a wider 
technology, better than Android and iOS, and I think it is important to 
separate users and developers at this point (simply separated communities).


Meego CE is an incredible and amazing project and, in the long term, it 
should be focused as a replacement of Maemo 5 on real devices: N900 ... 
and others.


Regards,
Àngel





___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[jukka.eklund]

> > My personal view (which is partly based on my marketing job) is that
> > you have to start off focused on a very visible end user experience in
> > order to get the project the necessary publicity.  For your own
> > governance reasons you will probably want to make sure the split
> > between core and "vendor" is clear, but from the outside world they have
> to look like one to start with.
> >
> 
> Probably this is the correct way to maintain this project alive.

Probably.
 
> Probably, an error of Nokia with the N900 is trying to mix both developers
> and users. This is an error.

Can you explain this a bit more? Do you mean Nokia N900 as a product, or what 
we are doing with MeeGo Community edition? If you mean latter, I probably 
understand what you mean.

Jukka
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Angel Perles]

My personal view (which is partly based on my marketing job) is that you have
to start off focused on a very visible end user experience in order to get the
project the necessary publicity.  For your own governance reasons you will
probably want to make sure the split between core and "vendor" is clear, but
from the outside world they have to look like one to start with.



Probably this is the correct way to maintain this project alive.

But also it is clear that it is necessary to separate each part/community.

Kernel.org is like Mer
KDE is like the UI experience
and Ubuntu is like the integration of all pieces

Most users of Ubuntu do not know that there is a kernel.org. But Ubuntu 
is a key factor for Linux beeing succesfull. The same can be applied to 
"Mer".


Seeing Mer+KDE+... running on Bleagleboard, Rasberry pi, N900 will make 
it succesfull. Only Mer has no future, because I will opt for somethink 
like Linaro.


An Mer alone running on an AR-Drone will be more great. Imagine 
preempt-RT + core Qt here. Easy and powerfull.


Probably, an error of Nokia with the N900 is trying to mix both 
developers and users. This is an error.


I like this post al Maemo.

http://blogs.gnome.org/bolsh/2011/10/06/what-community/

Probably the same error with Tizen ... and Angstrom and others.

Regards,
Àngel

___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[t . swindell]

Some of us already have companies which can do that :) doing it on a global mer 
scale may lead to politics again...On 06/10/2011 17:03 Jeremiah Foster wrote:
If you guys are serious about this, create a company. Then you can
sign NDA's which you'll need when you approach the commercial hardware
developers.

On Thu, Oct 6, 2011 at 5:01 PM, Peter Jespersen  wrote:
> Den 06-10-2011 07:11, Carsten Munk skrev:
>>
>> Den her kan jeg vidst godt svare på dansk :)
>>
>
> :-)
>>
>> Jeg tror at for at få bedst success, så er det bedst at have noget
>> ordentligt at vise før vi virkelig rækker ud til firmaer. Vi skal også
>> have vendor-historien på plads, inkl. dokumentation hvordan man selv
>> sætter en lokal build server op, ved hjælp af Mer kildekoden.
>>
>
> Jeg tænkte mere en prøveballon "Vi har tænkt os at gøre dette her, kunne i
> være interesseret i fremtiden?" og evt få stampet en kontaktperson op af
> jorden, inden at de beslutter sig for at lukke udviklingen af deres MeeGo
> produkter ned, jeg har en fonemmelse af at det ikke er alle der er lige
> begejstret for Tizan.
>
> I was thinking of a simple probe (first contact) : "We where thinking about
> doing this - what are your initial feelings about this?" - get a contect,
> before they decide to put down their MeeGo products. Time is of the essence.
>
>> Vi har faktisk lavet en port allerede til i486 af Mer - mangler lige
>> at acceptere nogle patches men den virker vidst fint nok. nVidia
>> Tegra2 har haft gode nok drivere til softfp ARMv7 i et stykke tid i
>> deres Linux4Tegra - dem kan vi vidst nok bruge i vores ARMv7 softfp.
>>
>
> Cool :-)
>
> /Peter
>
>> 2011/10/5 Peter Jespersen:
>>
>>>
>>> Den 03-10-2011 08:01, Carsten Munk skrev:
>>>
>>> Actually I really like this idea
>>>
>>> How about sending a probe to specific vendors like ASUS, that just
>>> recently
>>> declaired that they'll stay with MeeGo, Acer and perhaps the WeTab guys -
>>> just to take the temperature.
>>>
>>> Kill of the Intel/SSE3 requirement (keep it as an option), let in AMD and
>>> VIA/Centaur (i486/i686/AMD64).
>>>
>>> Then there is the nVidia Tegra2 MeeGo drivers - hopefully they're
>>> available.
>>>
>>>

 Hi all,

 MeeGo is dead ... long live Tizen !! - Haven't we heard that before? -
 Maemo, Moblin?

 We need a community that transcends the mere branding of MeeGo, Maemo,
 Moblin - and now Tizen.

 A lot of proposals have been put forward:
 * Move to Tizen and trust that "They'll get it right this time"
 * Merge or join some existing projects (like the Qt Project, Debian,
 openSUSE, etc)
 * Keep MeeGo alive by approaching the Linux Foundation

 The goal is to find a truly sustainable way for MeeGo and other
 interested communities to work with Tizen.

 Our solution is the Mer Project:

 How does the concept of a truly open and inclusive integration
 community for devices sound? After all if "upstream is king" - then
 contributions will end up the same place, no matter if it's Tizen,
 Maemo, MeeGo or openSUSE.

 Some history - many of us in MeeGo originated from a project called
 Mer, short for Maemo Reconstructed - where we approached doing a open
 mobile platform through reconstruction of the Maemo platform into a
 open platform. We were big on open governance, open development and
 open source.

 For a few months a group of us have been working on various scenarios
 of change in MeeGo [1] and now that the Tizen news is out in the open,
 it's time to talk about what we as a community can make happen next.
 To make it clear: this is not in any way an anti-Tizen or anti-Intel
 project, but a direction we can and will go in - we strongly want to
 collaborate with Tizen and Intel.

 We will continue to welcome contribution and participation from the
 hacker community - in fact we aim to make it so easy to port to a new
 vendor device that a single hacker could do it for their device.

 We decided to approach the problems and potential scenarios of change
 in MeeGo in the light of the reallocation of resources caused by what
 is now known as the Tizen work. There have not been any Trunk/1.3
 releases since August and Tablet UX has totally stalled. What really
 works (and works quite well) is the Core. It's time to take the pieces
 and use them for reconstruction.

 We have some clear goals:

 * To be openly developed and openly governed as a meritocracy
 * That primary customers of the platform are device vendors - not
 end-users.
 * To provide a device manufacturer oriented structure, processes and
 tools: make life easy for them
 * To have a device oriented architecture
 * To be inclusive of technologies (such as MeeGo/Tizen/Qt/EFL/HTML5)
 * To innovate in the mobile OS space

 Now we'd like to talk a bit about what specific initiatives

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Jeremiah Foster]

If you guys are serious about this, create a company. Then you can
sign NDA's which you'll need when you approach the commercial hardware
developers.

On Thu, Oct 6, 2011 at 5:01 PM, Peter Jespersen  wrote:
> Den 06-10-2011 07:11, Carsten Munk skrev:
>>
>> Den her kan jeg vidst godt svare på dansk :)
>>
>
> :-)
>>
>> Jeg tror at for at få bedst success, så er det bedst at have noget
>> ordentligt at vise før vi virkelig rækker ud til firmaer. Vi skal også
>> have vendor-historien på plads, inkl. dokumentation hvordan man selv
>> sætter en lokal build server op, ved hjælp af Mer kildekoden.
>>
>
> Jeg tænkte mere en prøveballon "Vi har tænkt os at gøre dette her, kunne i
> være interesseret i fremtiden?" og evt få stampet en kontaktperson op af
> jorden, inden at de beslutter sig for at lukke udviklingen af deres MeeGo
> produkter ned, jeg har en fonemmelse af at det ikke er alle der er lige
> begejstret for Tizan.
>
> I was thinking of a simple probe (first contact) : "We where thinking about
> doing this - what are your initial feelings about this?" - get a contect,
> before they decide to put down their MeeGo products. Time is of the essence.
>
>> Vi har faktisk lavet en port allerede til i486 af Mer - mangler lige
>> at acceptere nogle patches men den virker vidst fint nok. nVidia
>> Tegra2 har haft gode nok drivere til softfp ARMv7 i et stykke tid i
>> deres Linux4Tegra - dem kan vi vidst nok bruge i vores ARMv7 softfp.
>>
>
> Cool :-)
>
> /Peter
>
>> 2011/10/5 Peter Jespersen:
>>
>>>
>>> Den 03-10-2011 08:01, Carsten Munk skrev:
>>>
>>> Actually I really like this idea
>>>
>>> How about sending a probe to specific vendors like ASUS, that just
>>> recently
>>> declaired that they'll stay with MeeGo, Acer and perhaps the WeTab guys -
>>> just to take the temperature.
>>>
>>> Kill of the Intel/SSE3 requirement (keep it as an option), let in AMD and
>>> VIA/Centaur (i486/i686/AMD64).
>>>
>>> Then there is the nVidia Tegra2 MeeGo drivers - hopefully they're
>>> available.
>>>
>>>

 Hi all,

 MeeGo is dead ... long live Tizen !! - Haven't we heard that before? -
 Maemo, Moblin?

 We need a community that transcends the mere branding of MeeGo, Maemo,
 Moblin - and now Tizen.

 A lot of proposals have been put forward:
 * Move to Tizen and trust that "They'll get it right this time"
 * Merge or join some existing projects (like the Qt Project, Debian,
 openSUSE, etc)
 * Keep MeeGo alive by approaching the Linux Foundation

 The goal is to find a truly sustainable way for MeeGo and other
 interested communities to work with Tizen.

 Our solution is the Mer Project:

 How does the concept of a truly open and inclusive integration
 community for devices sound? After all if "upstream is king" - then
 contributions will end up the same place, no matter if it's Tizen,
 Maemo, MeeGo or openSUSE.

 Some history - many of us in MeeGo originated from a project called
 Mer, short for Maemo Reconstructed - where we approached doing a open
 mobile platform through reconstruction of the Maemo platform into a
 open platform. We were big on open governance, open development and
 open source.

 For a few months a group of us have been working on various scenarios
 of change in MeeGo [1] and now that the Tizen news is out in the open,
 it's time to talk about what we as a community can make happen next.
 To make it clear: this is not in any way an anti-Tizen or anti-Intel
 project, but a direction we can and will go in - we strongly want to
 collaborate with Tizen and Intel.

 We will continue to welcome contribution and participation from the
 hacker community - in fact we aim to make it so easy to port to a new
 vendor device that a single hacker could do it for their device.

 We decided to approach the problems and potential scenarios of change
 in MeeGo in the light of the reallocation of resources caused by what
 is now known as the Tizen work. There have not been any Trunk/1.3
 releases since August and Tablet UX has totally stalled. What really
 works (and works quite well) is the Core. It's time to take the pieces
 and use them for reconstruction.

 We have some clear goals:

 * To be openly developed and openly governed as a meritocracy
 * That primary customers of the platform are device vendors - not
 end-users.
 * To provide a device manufacturer oriented structure, processes and
 tools: make life easy for them
 * To have a device oriented architecture
 * To be inclusive of technologies (such as MeeGo/Tizen/Qt/EFL/HTML5)
 * To innovate in the mobile OS space

 Now we'd like to talk a bit about what specific initiatives we propose
 to
 take:

 0) Becoming MeeGo 2.0

 Our work has the intended goal of being MeeGo 2.0 - and we hope that
 the Linux Fo

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Peter Jespersen]

Den 06-10-2011 07:11, Carsten Munk skrev:

Den her kan jeg vidst godt svare på dansk :)
   

:-)

Jeg tror at for at få bedst success, så er det bedst at have noget
ordentligt at vise før vi virkelig rækker ud til firmaer. Vi skal også
have vendor-historien på plads, inkl. dokumentation hvordan man selv
sætter en lokal build server op, ved hjælp af Mer kildekoden.
   
Jeg tænkte mere en prøveballon "Vi har tænkt os at gøre dette her, kunne 
i være interesseret i fremtiden?" og evt få stampet en kontaktperson op 
af jorden, inden at de beslutter sig for at lukke udviklingen af deres 
MeeGo produkter ned, jeg har en fonemmelse af at det ikke er alle der er 
lige begejstret for Tizan.


I was thinking of a simple probe (first contact) : "We where thinking 
about doing this - what are your initial feelings about this?" - get a 
contect, before they decide to put down their MeeGo products. Time is of 
the essence.



Vi har faktisk lavet en port allerede til i486 af Mer - mangler lige
at acceptere nogle patches men den virker vidst fint nok. nVidia
Tegra2 har haft gode nok drivere til softfp ARMv7 i et stykke tid i
deres Linux4Tegra - dem kan vi vidst nok bruge i vores ARMv7 softfp.
   


Cool :-)

/Peter


2011/10/5 Peter Jespersen:
   

Den 03-10-2011 08:01, Carsten Munk skrev:

Actually I really like this idea

How about sending a probe to specific vendors like ASUS, that just recently
declaired that they'll stay with MeeGo, Acer and perhaps the WeTab guys -
just to take the temperature.

Kill of the Intel/SSE3 requirement (keep it as an option), let in AMD and
VIA/Centaur (i486/i686/AMD64).

Then there is the nVidia Tegra2 MeeGo drivers - hopefully they're available.

 

Hi all,

MeeGo is dead ... long live Tizen !! - Haven't we heard that before? -
Maemo, Moblin?

We need a community that transcends the mere branding of MeeGo, Maemo,
Moblin - and now Tizen.

A lot of proposals have been put forward:
* Move to Tizen and trust that "They'll get it right this time"
* Merge or join some existing projects (like the Qt Project, Debian,
openSUSE, etc)
* Keep MeeGo alive by approaching the Linux Foundation

The goal is to find a truly sustainable way for MeeGo and other
interested communities to work with Tizen.

Our solution is the Mer Project:

How does the concept of a truly open and inclusive integration
community for devices sound? After all if "upstream is king" - then
contributions will end up the same place, no matter if it's Tizen,
Maemo, MeeGo or openSUSE.

Some history - many of us in MeeGo originated from a project called
Mer, short for Maemo Reconstructed - where we approached doing a open
mobile platform through reconstruction of the Maemo platform into a
open platform. We were big on open governance, open development and
open source.

For a few months a group of us have been working on various scenarios
of change in MeeGo [1] and now that the Tizen news is out in the open,
it's time to talk about what we as a community can make happen next.
To make it clear: this is not in any way an anti-Tizen or anti-Intel
project, but a direction we can and will go in - we strongly want to
collaborate with Tizen and Intel.

We will continue to welcome contribution and participation from the
hacker community - in fact we aim to make it so easy to port to a new
vendor device that a single hacker could do it for their device.

We decided to approach the problems and potential scenarios of change
in MeeGo in the light of the reallocation of resources caused by what
is now known as the Tizen work. There have not been any Trunk/1.3
releases since August and Tablet UX has totally stalled. What really
works (and works quite well) is the Core. It's time to take the pieces
and use them for reconstruction.

We have some clear goals:

* To be openly developed and openly governed as a meritocracy
* That primary customers of the platform are device vendors - not
end-users.
* To provide a device manufacturer oriented structure, processes and
tools: make life easy for them
* To have a device oriented architecture
* To be inclusive of technologies (such as MeeGo/Tizen/Qt/EFL/HTML5)
* To innovate in the mobile OS space

Now we'd like to talk a bit about what specific initiatives we propose to
take:

0) Becoming MeeGo 2.0

Our work has the intended goal of being MeeGo 2.0 - and we hope that
the Linux Foundation will see our work as a worthy succesor within the
MeeGo spirit. We'd like to provide ability to be Tizen compliant, i.e.
supporting HTML5/WAC and the application story there and feed back to
that ecosystem.

1) Modularity. A set of architectural components for making devices.

Rather than dictate the architecture we will support collaboration and
the flexibility to easily access off-the-shelf components for device
projects. Component independence permits focused feature and delivery
management too.

Initially the project will be developing a Core for basing products on
and will split UX and hardware adaptations out into

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Timo Härkönen]

o/

2011/10/6 Ville M. Vainio 

> On Thu, Oct 6, 2011 at 12:40 PM, Graham Cobb  wrote:
>
> > My personal view (which is partly based on my marketing job) is that you
> have
> > to start off focused on a very visible end user experience in order to
> get the
> > project the necessary publicity.  For your own governance reasons you
> will
>
> Yeah, people need something cool on their devices to bother trying Mer
> in the first place, provide feedback and maybe even join the project.
>
> I'm sort of hoping Plasma Active could play a big part in this.
>
>
Yep. me too but for Mer to be future proof, agile, stable, managable, easy
to build things on, etc. so it makes sense to keep it as it was announced
(core to build stuff on). Having said that, it needs things happening around
it that has flashy slick things (the community edition, plasma, etc.).

For me the separation of having Mer the core project and things building on
top of it makes very much sense. It's just like making an application, it's
good to separate your engine from the UI.

The MeeGo community obs seems to have some Mer stuff in it already so the
building blocks are starting to be there. we just need to start making
things happen. So if there's going to be a Mer+plasma thing the first thing
IMO would be to start communicating and collaborating with the people
working on the community edtion.

-Timo
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Ville M. Vainio]

On Thu, Oct 6, 2011 at 12:40 PM, Graham Cobb  wrote:

> My personal view (which is partly based on my marketing job) is that you have
> to start off focused on a very visible end user experience in order to get the
> project the necessary publicity.  For your own governance reasons you will

Yeah, people need something cool on their devices to bother trying Mer
in the first place, provide feedback and maybe even join the project.

I'm sort of hoping Plasma Active could play a big part in this.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Graham Cobb]

On Thursday 06 October 2011 07:33:24 Carsten Munk wrote:
> We have chosen to move out the hardware adaptations and UX'es out of
> the core, into the community surrounding it, to get rid of a lot of
> politics - to concentrate on what's technically good and benefits us
> all - not having to maintain our own mobile distribution ourselves.

I think I understand your point but there is a big danger there.  My day job 
is marketing.  And there is a lot of marketing involved in building an open-
source community.  In order to get contributors, or to get vendors to use you, 
you need to be seen as viable and successful.

And a lot of that is tied up with end-users: the blogs and web sites will be 
talking about you if users are talking about you.  Your strategy is going to 
require that you have a successful and visible "vendor" project and, even 
then, you need to make sure that people are mentioning your core when talking 
about the associated project.

My personal view (which is partly based on my marketing job) is that you have 
to start off focused on a very visible end user experience in order to get the 
project the necessary publicity.  For your own governance reasons you will 
probably want to make sure the split between core and "vendor" is clear, but 
from the outside world they have to look like one to start with.

The bottom line is that many potential community members will be doubtful that 
your project can be successful, unless you can show them a working (preferably 
great) end user experience (including hardware).  Many projects have been and 
gone, either sponsored by big companies (we are all familiar with those!) or 
purely hobbyist (e.g. Cordia now that the Cordia Tab seems dead).  If the 
Cordia Tab was going to happen then Cordia might have been the viable end user 
project to get you the publicity but without hardware it seems to be going 
nowhere as well.

Graham
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Carsten Munk]

2011/10/6 d4lamar :
>> * That primary customers of the platform are device vendors - not end-users.
>
> I think that this point in Mer Project or in any other branch/fork of
> Meego is to be corrected.
>
> Vendors come and vendors go, they don't care about Community as long
> as they can use it for their purposes and for me this was the main
> problem with Maemo, Moblin, Meego and if their strategies change they
> drop their products and their Communities.

So, let me describe a bit what I mean with vendor. What we're trying
to establish is a common, streamlined Linux/Qt core for others to
build on top of. For end users, this is horribly boring - the code on
it's own would just show a blinking cursor/a xterm/a qml demo

A vendor, in our view, is someone who takes the core, mixes it with
their own bits, makes it into some kind of a product. As an example,
this could be Plasma Active user experience, taking the core, some
hardware adaptations and their own UX. It could be a small business
that makes bus displays. It could be a hobbyist at home who doesn't
want to bother making his own distribution and just want to show a
clock on his LCD. But we're not the people who deliver the final
experience.

In their work, they'll come up with improvements to the core and
proposed requirements for the core.

With a proper, openly governed and discussed requirements/roadmap
process, we move ahead while maintaining quality and focus. I'll
expect those handling the requirements management to be objective in
their work.

My primary motivation about the "not end users" is the fact that this
practically ruined MeeGo, the personality split between "just a core"
and "look, shiny netbook ui" - the core was actually fantastic for
building things with, but the reference UX'es and end user's reviews
caused it to be perceived badly.

Instead, I'd like to see the amazing things people can build on top.
So many possibilities, really (just go look at the videos of what
people did with the MeeGo + Nokia N900 hardware adaptations)

We have chosen to move out the hardware adaptations and UX'es out of
the core, into the community surrounding it, to get rid of a lot of
politics - to concentrate on what's technically good and benefits us
all - not having to maintain our own mobile distribution ourselves.

> These are my 2 cents, sorry for bothering.

An opinion isn't bothering :)

BR
Carsten Munk
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[d4lamar]

Hi to all,
I'm only a lurker of Meego mailing lists and I have never contributed
to the project, but this time I would like to write some words about.

> * That primary customers of the platform are device vendors - not end-users.

I think that this point in Mer Project or in any other branch/fork of
Meego is to be corrected.

Vendors come and vendors go, they don't care about Community as long
as they can use it for their purposes and for me this was the main
problem with Maemo, Moblin, Meego and if their strategies change they
drop their products and their Communities.

This approach didn't work. We have to reach a critical mass of users
as soon as we can, then vendors will return to Community using
Community work for their projects.

I think we have to focus on end-users, we have to get users as fast as
we can, and then they will be new testers and other developers come to
help these users, Community is not a vendor that fears to burn its new
brand with an early release.

We have to learn from other successful opensource projects. Firstly we
have to hack the most common devices on the market, users unsatisfied
with their platform would like to try a different one without buying a
new device. Then we have to get their feedbacks and trying to improve.

We have to define specific requirements an user would search on this
new platform, we have to define our target users and build a solution
for the most of them.

When we will have users, vendors will come to produce using our work
for their new devices.

These are my 2 cents, sorry for bothering.

Best Regards,
d4lamar
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Timo Jyrinki]

2011/10/5 Jeremiah Foster :
>> Distrowatch are server and dektop disties. The special thing in MeeGo was
>> that
>> the focus was on emerging devices.
>
> And how exactly did it do that? By using Connman? By using an "embedded"
> Linux kernel? Btrfs? By being "small"? What exactly makes MeeGo different
> from other "desktop" distros? Or was it just a little bit of marketing?

I agree with Jeremiah here. MeeGo really was a lot more pain to get
slimmed down with its actually desktop distro legacy and for example
package dependencies than with Debian. Maemo was the actual embedded
OS, but MeeGo never got to reach it.

That said, I do believe there is a lot of room and need for Mer, and
potentially Tizen (hopefully fully usable by Mer and others) when it
actually materializes, simply because it tries to continue MeeGo as is
but fixing the problems mostly everyone agrees with - MeeGo was not
lean core at any point, and the community, decision and communication
aspects sucked in many ways. Doing so gets the existing MeeGo
community people to continue, while any other one choice like Debian
(advertised by me among else), openSUSE (advertised by Jon among
else), Yocto or other would not get all the same people on-board. With
individuals it can be about simple things like familiriaty with tools,
and OBS does rock. The important thing is to do something that matters
(to you), and if possible do it in a way that everyone can benefit.

The lesson with MeeGo here should be not to put all eggs into one
basket. I'm a multi-distro person myself, and see strong value in
distro-previously-called-MeeGo, Ubuntu, Yocto etc. in addition to
Debian which I think rules the most broadly in its operation and
scope.

-Timo
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Si Howard]

Again, I agree with the project, if Mer can resurrect Maemo/MeeGo then I 
am all for it!


On 04/10/2011 08:57, Timo Jyrinki wrote:

ma, 2011-10-03 kello 19:09 +0100, Si Howard kirjoitti:

I'm for that! Wasn't the Mer project part of the Maemo 5.0 porting to
the Nokia N8X0 platform?

That's one way of putting it, but it was indeed about reconstructing
Maemo so that it worked as a whole distribution. That then made possible
to try to get newer Maemo components working on older tablets purely as
a community effort.

So more like Maemo 5.0 porting to the Nokia N8X0 platform was a part of
the Mer project, not the other way around :)

-Timo



___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Jeremiah Foster]

On Wed, Oct 5, 2011 at 9:39 AM, Samuel Stirtzel
 wrote:
>
> 2011/10/4 Jeremiah Foster :

> >> Can a mobile
> >> segment distro like MeeGo be really compared with a desktop segment
> >> distro like e.g. embedded Ubuntu? (This is not relative to your
> >> message but a general rhetorical question.)
> >
> > I don't understand what you mean by "segment" here. And I also don't
> > understand what you're referring to with "embedded Ubuntu."
>
> What I meant is that a embedded desktop OS targets another audience
> than the embedded mobile OS (or in other terms a different market
> segment).
>
> Well I'm sorry for using the term embedded Ubuntu, I've assumed that
> others refer to projects like Linaro-Ubuntu [1], the TI-OMAP Ubuntu
> [2] and in general ARM Ubuntu as "embedded Ubuntu" too.

No reason to apologize! I was just not certain what you were referring to. :)

> >>
> >> > Before it was just big companies that could create their own Linux
> >> > distros
> >> > (before that everyone had their bespoke UNIX distro) nowadays
> >> > fragmentation
> >> > is brought to you by every Tom, Dick and Harry with an OBS login.
> >> > I've been down the fragmentation road before. It always ends with
> >> > retracing
> >> > your path back to the main highway.
> >>
> >> There seems to be much standardization work going on in the Yocto
> >> Project / OpenEmbedded Core (see [3], also Carsten already mentioned
> >> the Yocto Project in context of governance), anyone evaluated it?
> >
> > Yocto is very interesting indeed, as is OpenEmbedded, though the claim is
> > that Yocto is "open embedded done right." But for the purposes of a distro I
> > don't think Yocto is the silver bullet people are looking for. Firstly, it
> > seems focused on Intel Atom BSPs and overall seems designed to help in board
> > bring-up. Yes you can create a complete distro, but like a misused OBS
> > repository, creating your own complete distro is not a good idea. Unless of
> > course yours is THE ONE.
>
> Your statement about Yocto is right, but OpenEmbedded isn't
> OpenEmbedded anymore, alot has changed since this statement was true.
>
> OpenEmbedded Core (the new OpenEmbedded) and the Yocto Project merged
> their efforts and created an unified code base

I tried to point that out by saying "Yocto is 'open embedded done
right.'" But I guess I was unclear. From what I understand bitbake is
still at the heart of both these projects and that is a pretty
interesting piece of technology.

>
> (see [3] and [4]), also
> OpenEmbedded Core + Yocto supports a larger audience (see [5] for the
> approved list of BSP layers).
>
> In OSS systems there should not be a THE ONE distribution, for end
> users this is out of the question, they might not want to create their
> own distro, but (IMHO) developers should not be restricted in this
> direction.

But that is precisely the point. To serve end users you need a
consistent, easy to use platform, with a large ecosystem of developers
to create new applications. This is one of the reasons why Debian is
useful: its foundation is that it puts users first. From the Debian
Social Contract; "We will be guided by the needs of our users and the
free software community."

Yocto puts developers first which is great - but it doesn't make for a
consistent, easy to use platform, with a large ecosystem. It creates
different chunks which are little Linux stacks which one places over
the "layers" which seem to be like Linaro Hardware Packs, i.e. BSPs
and drivers. These chunks function as a Linux distro, you can add
packages and UIs and all kinds of amazing stuff, but you have no
community. You have no ecosystem, you don't scale.

> >>
> >> The Yocto Project / OpenEmbedded was discussed before in the IVI
> >> mailing list (see [4]), but it lacks any technical explanations and
> >> arguments why it cannot be used / or get adapted, also OpenEmbedded
> >> progressed into the new OpenEmbedded Core Project (the next release is
> >> just one step away).
> >
> > https://wiki.yoctoproject.org/wiki/FAQ
> > OpenEmbedded is widely used in commercial embedded systems. Those systems
> > tend to not be open source systems and end up costing lots of money.
> > Regards,
> > Jeremiah
>
> Sorry I don't get your point here, no offense but if I would say:
> "Debian is widely used in commercial desktop systems." Would your
> statement be the same?

No offense taken. I was purposely vague because I don't want to
publicly deride commercial Linux companies and other hardware
companies that use OE and Yocto.

The difference for me is that commercial Linux companies see Linux as
a technology. In my mind, that is a misunderstanding. Linux is a
kernel, combined with a userland (Android, GNU, etc.) and a license
group. This combination is where the magic occurs because it enforces
useful changes back into GNU/Linux distros and encourages a thriving
ecosystem. This thriving ecosystem is what makes Linux run on
everything from MIPS, to Xeon, to ARM M5, to A11, from

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Jeremiah Foster]

On Wed, Oct 5, 2011 at 10:09 AM, Stefan Werden wrote:

> Jeremiah Foster  hat am 4. Oktober 2011 um
> 20:42
> geschrieben:
>
> > On Tue, Oct 4, 2011 at 6:48 PM, Stefan Werden
> > wrote:
> >
> > > Hi,
> > >
> > > switching to debian would mean making a complete new projekt.
> >
> >
> > Nope, it would merely mean adding software to the Debian project, it
> > wouldn't require a new project at all. Debian would host the
> infrastructure
> > (it has its own IRC, build farm, hosting, project software, email lists,
> > funding, non-profit status, social contract, shell accounts, git server,
> svn
> > server, well, you get the picture.) You could turn Mer into a Debian
> blend
> > for example: http://wiki.debian.org/DebianPureBlends or you could become
> a
> > Debian derivative: http://wiki.debian.org/Derivatives/Census
> >
> > Debian derivatives currently dominate the Linux landscape. Of the top
> four
> > distros on Distro Watch, three of them are deb based. This means you get
> a
> > huge development ecosystem when you use debs, as well as a lot of users.
>


> Distrowatch are server and dektop disties. The special thing in MeeGo was
> that
> the focus was on emerging devices.


And how exactly did it do that? By using Connman? By using an "embedded"
Linux kernel? Btrfs? By being "small"? What exactly makes MeeGo different
from other "desktop" distros? Or was it just a little bit of marketing?


> So this makes it special, because it does not
> need to care about the old stuff. So bcoming a debian flavour feels not
> really
> like an option to me.
>

That's fine. It doesn't have to be an option for you. It should be described
as a potential option for others on this list however since they may not
have made up their minds yet and the FUD that is being thrown about here is
misleading.

Regards,

Jeremiah
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Samuel Stirtzel]

Hi,
sorry for re-sending this Jeremiah, but I've missed that this mail was
not sent to the list, my bad.

2011/10/4 Jeremiah Foster :
...

>
>>
>> Can a mobile
>> segment distro like MeeGo be really compared with a desktop segment
>> distro like e.g. embedded Ubuntu? (This is not relative to your
>> message but a general rhetorical question.)
>
> I don't understand what you mean by "segment" here. And I also don't
> understand what you're referring to with "embedded Ubuntu."

What I meant is that a embedded desktop OS targets another audience
than the embedded mobile OS (or in other terms a different market
segment).

Well I'm sorry for using the term embedded Ubuntu, I've assumed that
others refer to projects like Linaro-Ubuntu [1], the TI-OMAP Ubuntu
[2] and in general ARM Ubuntu as "embedded Ubuntu" too.

>
>>
>> Well I didn't use embedded Debian as example because Emdebian mailing
>> lilsts seem to be pretty dead [2].
>
> Embedian is very much alive. More
> here: http://www.debian.org/News/weekly/2011/12/#emdebian

Oh I see, I just wondered because the mailing lists seems to endure a recession.

>>
>> > Before it was just big companies that could create their own Linux
>> > distros
>> > (before that everyone had their bespoke UNIX distro) nowadays
>> > fragmentation
>> > is brought to you by every Tom, Dick and Harry with an OBS login.
>> > I've been down the fragmentation road before. It always ends with
>> > retracing
>> > your path back to the main highway.
>>
>> There seems to be much standardization work going on in the Yocto
>> Project / OpenEmbedded Core (see [3], also Carsten already mentioned
>> the Yocto Project in context of governance), anyone evaluated it?
>
> Yocto is very interesting indeed, as is OpenEmbedded, though the claim is
> that Yocto is "open embedded done right." But for the purposes of a distro I
> don't think Yocto is the silver bullet people are looking for. Firstly, it
> seems focused on Intel Atom BSPs and overall seems designed to help in board
> bring-up. Yes you can create a complete distro, but like a misused OBS
> repository, creating your own complete distro is not a good idea. Unless of
> course yours is THE ONE.

Your statement about Yocto is right, but OpenEmbedded isn't
OpenEmbedded anymore, alot has changed since this statement was true.
OpenEmbedded Core (the new OpenEmbedded) and the Yocto Project merged
their efforts and created an unified code base (see [3] and [4]), also
OpenEmbedded Core + Yocto supports a larger audience (see [5] for the
approved list of BSP layers).

In OSS systems there should not be a THE ONE distribution, for end
users this is out of the question, they might not want to create their
own distro, but (IMHO) developers should not be restricted in this
direction.

>
>>
>> The Yocto Project / OpenEmbedded was discussed before in the IVI
>> mailing list (see [4]), but it lacks any technical explanations and
>> arguments why it cannot be used / or get adapted, also OpenEmbedded
>> progressed into the new OpenEmbedded Core Project (the next release is
>> just one step away).
>
> https://wiki.yoctoproject.org/wiki/FAQ
> OpenEmbedded is widely used in commercial embedded systems. Those systems
> tend to not be open source systems and end up costing lots of money.
> Regards,
> Jeremiah

Sorry I don't get your point here, no offense but if I would say:
"Debian is widely used in commercial desktop systems." Would your
statement be the same?
If you care about the patches, i see quite an amount of users sending
patches back to OpenEmbedded Core and Yocto.


[1] https://launchpad.net/linaro-ubuntu/+milestone/11.09
[2] https://launchpad.net/ubuntu/+source/linux-ti-omap
[3] 
http://www.linuxfoundation.org/news-media/announcements/2011/03/yocto-project-aligns-technology-openembedded-and-gains-corporate-co
[4] http://www.yoctoproject.org/projects/openembedded-core
[5] http://www.openembedded.org/wiki/LayerIndex

--
Regards
Samuel
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Jeremiah Foster]

On Tue, Oct 4, 2011 at 6:48 PM, Stefan Werden wrote:

> Hi,
>
> switching to debian would mean making a complete new projekt.


Nope, it would merely mean adding software to the Debian project, it
wouldn't require a new project at all. Debian would host the infrastructure
(it has its own IRC, build farm, hosting, project software, email lists,
funding, non-profit status, social contract, shell accounts, git server, svn
server, well, you get the picture.) You could turn Mer into a Debian blend
for example: http://wiki.debian.org/DebianPureBlends or you could become a
Debian derivative: http://wiki.debian.org/Derivatives/Census

Debian derivatives currently dominate the Linux landscape. Of the top four
distros on Distro Watch, three of them are deb based. This means you get a
huge development ecosystem when you use debs, as well as a lot of users.


> I would prefer to
> just continure the current running stack.

It saves time and people know how to handle it.
>

*sigh*


>
> regards,
>
> Stefan
>
>
> Jeremiah Foster  hat am 4. Oktober 2011 um
> 14:03
> geschrieben:
>
> > On Tue, Oct 4, 2011 at 10:53 AM, karoliina.t.salmi...@gmail.com <
> > karoliina.t.salmi...@gmail.com> wrote:
> >
> > > Hello,
> > >
> > > This is just my 0.02 cents. I would think it should be done like this:
> > >
> > > - Take the debian based distro and development environment (that works)
> as
> > > a basis. It works. Look at Harmattan and all previous Nokia Maemo
> devices.
> > >
> >
> > This makes way too much sense to be adopted. :-)
> >
> > "Don't start your own project, join someone else's."
> > - Dan Frye:
> >
> > Regards,
> >
> > Jeremiah
> --
> Dr. Stefan Werden
> Managing Director
> open-slx gmbh, HRB 25876,
> Einsteinring 7, 90453 Nürnberg, Germany
>
>


-- 
=
Jeremiah C. Foster
Open Source Technologist
Pelagicore AB
Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden
Mobile: +46 (0)730 93 0506
E-Mail: jeremiah.fos...@pelagicore.com
=

=== NOTE ===
The information contained in this E-mail message is
intended only for use of the individual or entity
named above. If the reader of this message  is not
the intended recipient, or the employee or agent
responsible to deliver it to the intended recipient,
you are hereby notified that any dissemination,
distribution or copying of this communication is
strictly prohibited.
=
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Jeremiah Foster]

On Tue, Oct 4, 2011 at 4:19 PM, Samuel Stirtzel
wrote:

[snip]

>
> 2011/10/4 Jeremiah Foster :
> >> OBS is built with packaging in mind, so it builds packages locally and
> >> on servers in a sanitized environment. Scratchbox may be polluted by
> >> whatever packages a developer has installed and makes dependency
> >> tracking a bit harder IMO.
> >
> > I agree that working in a dirty chroot is problematic. That is why there
> is
> > pbuilder and cowdancer.
> >
>
> Wouldn't it be better to use a decentral build system?


Sometimes embedded developers only have the target and their laptop. So
often having your complete toolchain on your laptop while you work on site
at a customer for example can be part of a developer's work flow. This means
a decentralized system can be a necessity. But you have to make sure you
send back your patches.


> Can a mobile
> segment distro like MeeGo be really compared with a desktop segment
> distro like e.g. embedded Ubuntu? (This is not relative to your
> message but a general rhetorical question.)
>

I don't understand what you mean by "segment" here. And I also don't
understand what you're referring to with "embedded Ubuntu."


> Well I didn't use embedded Debian as example because Emdebian mailing
> lilsts seem to be pretty dead [2].
>

Embedian is very much alive. More here:
http://www.debian.org/News/weekly/2011/12/#emdebian


> > Before it was just big companies that could create their own Linux
> distros
> > (before that everyone had their bespoke UNIX distro) nowadays
> fragmentation
> > is brought to you by every Tom, Dick and Harry with an OBS login.
> > I've been down the fragmentation road before. It always ends with
> retracing
> > your path back to the main highway.
>
> There seems to be much standardization work going on in the Yocto
> Project / OpenEmbedded Core (see [3], also Carsten already mentioned
> the Yocto Project in context of governance), anyone evaluated it?
>

Yocto is very interesting indeed, as is OpenEmbedded, though the claim is
that Yocto is "open embedded done right." But for the purposes of a distro I
don't think Yocto is the silver bullet people are looking for. Firstly, it
seems focused on Intel Atom BSPs and overall seems designed to help in board
bring-up. Yes you can create a complete distro, but like a misused OBS
repository, creating your own complete distro is not a good idea. Unless of
course yours is THE ONE.


> The Yocto Project / OpenEmbedded was discussed before in the IVI
> mailing list (see [4]), but it lacks any technical explanations and
> arguments why it cannot be used / or get adapted, also OpenEmbedded
> progressed into the new OpenEmbedded Core Project (the next release is
> just one step away).
>

https://wiki.yoctoproject.org/wiki/FAQ

OpenEmbedded is widely used in commercial embedded systems. Those systems
tend to not be open source systems and end up costing lots of money.

Regards,

Jeremiah


> On a technical point of view it is possible to port over to Yocto
> Project, and it would make sence to concentrate the development of
> embedded linux distributions to unify them into a single development
> base instead of fragmenting the communities.
>
> Well I just stated my opinion here.
>
> [1] http://lists.scratchbox.org/pipermail/scratchbox-devel/
> [2] http://lists.debian.org/debian-embedded/2011/09/threads.html
> [3] http://www.yoctoproject.org/projects/openembedded-core
> [4] http://lists.meego.com/pipermail/meego-ivi/2011-February/000198.html
>
> > Regards,
> > Jeremiah
> >
> >
> > ___
> > MeeGo-dev mailing list
> > MeeGo-dev@meego.com
> > http://lists.meego.com/listinfo/meego-dev
> > http://wiki.meego.com/Mailing_list_guidelines
> >
>
> --
> Regards
> Samuel
> ___
> MeeGo-dev mailing list
> MeeGo-dev@meego.com
> http://lists.meego.com/listinfo/meego-dev
> http://wiki.meego.com/Mailing_list_guidelines
>



-- 
=
Jeremiah C. Foster
Open Source Technologist
Pelagicore AB
Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden
Mobile: +46 (0)730 93 0506
E-Mail: jeremiah.fos...@pelagicore.com
=

=== NOTE ===
The information contained in this E-mail message is
intended only for use of the individual or entity
named above. If the reader of this message  is not
the intended recipient, or the employee or agent
responsible to deliver it to the intended recipient,
you are hereby notified that any dissemination,
distribution or copying of this communication is
strictly prohibited.
=
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Arnaud Delcasse]

2011/10/4 Samuel Stirtzel :
>> Before it was just big companies that could create their own Linux distros
>> (before that everyone had their bespoke UNIX distro) nowadays fragmentation
>> is brought to you by every Tom, Dick and Harry with an OBS login.
>> I've been down the fragmentation road before. It always ends with retracing
>> your path back to the main highway.
>
> There seems to be much standardization work going on in the Yocto
> Project / OpenEmbedded Core (see [3], also Carsten already mentioned
> the Yocto Project in context of governance), anyone evaluated it?
> The Yocto Project / OpenEmbedded was discussed before in the IVI
> mailing list (see [4]), but it lacks any technical explanations and
> arguments why it cannot be used / or get adapted, also OpenEmbedded
> progressed into the new OpenEmbedded Core Project (the next release is
> just one step away).
> On a technical point of view it is possible to port over to Yocto
> Project, and it would make sence to concentrate the development of
> embedded linux distributions to unify them into a single development
> base instead of fragmenting the communities.

Well, I think that would make sense if the Mer project didn't want to
stay close to Tizen if possible, integrating Tizen features. Mer as a
standalone project can take these directions unilaterally, where it
would be more difficult to make it happen in another project. That
doesn't mean that efforts on some parts cannot be shared (the same way
like with Tizen), but IMO, the direction, philosophy and basis of Mer
as I undestand it justify that it stays independent.

Regards,

Arnaud
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Samuel Stirtzel]

Hi,
maybe I'm wrong but the Scratchbox mailing lists looks pretty dead
right now (see [1]). Is there any community alive behind it, or should
the "new MeeGo project" reanimate Scratchbox if it would be used?

2011/10/4 Jeremiah Foster :
>> OBS is built with packaging in mind, so it builds packages locally and
>> on servers in a sanitized environment. Scratchbox may be polluted by
>> whatever packages a developer has installed and makes dependency
>> tracking a bit harder IMO.
>
> I agree that working in a dirty chroot is problematic. That is why there is
> pbuilder and cowdancer.
>

Wouldn't it be better to use a decentral build system? Can a mobile
segment distro like MeeGo be really compared with a desktop segment
distro like e.g. embedded Ubuntu? (This is not relative to your
message but a general rhetorical question.)
Well I didn't use embedded Debian as example because Emdebian mailing
lilsts seem to be pretty dead [2].


> Before it was just big companies that could create their own Linux distros
> (before that everyone had their bespoke UNIX distro) nowadays fragmentation
> is brought to you by every Tom, Dick and Harry with an OBS login.
> I've been down the fragmentation road before. It always ends with retracing
> your path back to the main highway.

There seems to be much standardization work going on in the Yocto
Project / OpenEmbedded Core (see [3], also Carsten already mentioned
the Yocto Project in context of governance), anyone evaluated it?
The Yocto Project / OpenEmbedded was discussed before in the IVI
mailing list (see [4]), but it lacks any technical explanations and
arguments why it cannot be used / or get adapted, also OpenEmbedded
progressed into the new OpenEmbedded Core Project (the next release is
just one step away).
On a technical point of view it is possible to port over to Yocto
Project, and it would make sence to concentrate the development of
embedded linux distributions to unify them into a single development
base instead of fragmenting the communities.

Well I just stated my opinion here.

[1] http://lists.scratchbox.org/pipermail/scratchbox-devel/
[2] http://lists.debian.org/debian-embedded/2011/09/threads.html
[3] http://www.yoctoproject.org/projects/openembedded-core
[4] http://lists.meego.com/pipermail/meego-ivi/2011-February/000198.html

> Regards,
> Jeremiah
>
>
> ___
> MeeGo-dev mailing list
> MeeGo-dev@meego.com
> http://lists.meego.com/listinfo/meego-dev
> http://wiki.meego.com/Mailing_list_guidelines
>

-- 
Regards
Samuel
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Sivan Greenberg]

On Tue, Oct 4, 2011 at 2:19 PM, Jeremiah Foster
 wrote:
>>
>> I think what Carsten means by "growing an organisation organically" is
>> that OBS allows multiple users to create their own repositories, it
>> allows us to separate different projects into different repositories for
>> staging or logical separation and it's easy and intuitive to do all of
>> this from the web interface and to tools provided.
>
> This is likely what he's referring to. But as someone who is concerned with
> integration, this is bordering on a misfeature. What is happening is that
> each repository is a separate Linux distro. This makes integration a
> complete nightmare and unlikely to occur. Look a the ABI break that occurred
> in MeeGo for ARM. That effectively killed any release of that distro.
> Just because you can build your own Linux distro doesn't mean you should.


Also, does not Launchpad support PPA at this point, as well as on the
fly test builds out of version control? I know Linaro people are using
it and are quite happy about it or perhaps I'm misinformed ? It might
be ahead of time to be concerned by this, but the concern Quim Gill
expressed about the ability of the community to fund the
infrastructure might be realized if Mer is to be adopted on a large
scale...

My personal experience with Launchpad is that the sysadmin personnel
is *VERY* responsive and cater for rapid and fruitful distro work.
Again, those concerns are only for when Mer is in massive adoption
which is where we want to reach anyway? How do we pitch prospective
sponsors when they ask us about Harmattan and speak about Debian in
the mobile field, I think it has some success compared to others.
Linaro seems to be doing well and they so far manage to gather vendors
interested.


Again, no trolling, just asking questions :)

-Sivan
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Mika Laitio]

OBS is a very useful tool, just not for the purposes you were
apparently forced to use it for. I've used it for the commit, push
package, wait for build failure type development cycle as well, and I
agree, it's far from optimal - but for easily making heavily


There are couple of ways to speed up the development also when working 
in the OBS environment, especially when really trying to solve real 
development problems. Here couple of tips.


1) offline option "-o" when doing osc build will speed up things a 
little when trying to do a multiple local builds in a row, as then the

obs does not try to get the latest dependency list from the server.
"osc build -o armv8el" as an example...

2)When doing a development, you can first create the chroot env with
  "osc build" command and then after the first build have started switch
  to chroot environment

a) osc co Project:DE:Trunk/ohm
b) cd Project:DE:Trunk/ohm
c) osc build armv8el
   ... wait the build to complete or fail and then switch to chroot env
d) cd /var/tmp/osc-build-root/
e) sudo su
f) chroot .
g) cd home/abuild/rpmbuild/BUILD/ohm-1.1.14
h) run commands like "make/make install" on chrooted bash shell
i) edit the files by using your favourite editor from another shell
   from dir "/var/tmp/osc-build-root/home/abuild/rpmbuild/BUILD/ohm-1.1.14"

3) you can have multiple chrooted environments by editing "build-root"
   variable from the ~/.oscrc file. I for example prefer of having 
something like: build-root = /obs/buildroots/%(repo)s-%(arch)s


4) You can force that "osc build" command will always put certain 
packages to chroot env in addition of the direct dependencies of certain 
app by listing these extra packages is ~/.oscrc file.

For example: extra-pkgs = gdb strace

What I am also missing would be an easy way to configure the QT creator 
easily to use the qt, qml and gcc from the chrooted env.

(So I could just do the qml editing with the qt-creator by using those
components that happens to be installed in the chroot env that the osc 
build command has created.) So if somebody knows ways to do that, I 
would be very interested.


Mika

customised distributions, OBS is great.


e.g. seeing our duicontrolpanel on MeeGo-MeeGo installation instead of
Harmattan is a whole different experience than seeing it on Harmattan
device),





But good news, there is a easy technology to make a superb UI framework 
rapidly, QML.
It needs some work,  needs to be consistent UI concept, excellent graphics 
(which have a meaning,


The technology is, at the end of the day, not that important (though I
agree that QML makes life a lot easier) - at the end of the day, you
can have the best written UI in the world, and it will still look like
complete and utter crap without decent theming.

Hopefully we can poke some of the awesome graphical people around like
wazd to give us a hand with some of this.


- Many of the lower layers have been already open sourced by companies and
it is just about utilizing them and doing the top of the cake right. There
are some missing pieces, but filling the gaps should not be impossible.


One of the missing gaps, at least on Handset CE, is the settings
application. As you point out, it is not visually pleasing, it has
flickering text ("!! Wifi" before changing to the actual text), and
other issues which make it a bit pailful to use.

Given your experience with it, would you like to dedicate some time to
making it more usable, perhaps even doing some thinking on how to
approach it from the QML world?

BR,

Robin
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines


___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Tom Swindell]

  Other reasons for keeping OBS include trying to change as little as
possible from what MeeGo has done. So those vendors that are possibly
already accustomed and are currently using MeeGo facilities, like OBS.
Can easily migrate to Mer. There really isn't much point in debating
this, Carsten has made his decision ...

Thanks, Tom.

On Tue, 2011-10-04 at 14:19 +0200, Jeremiah Foster wrote:
> On Tue, Oct 4, 2011 at 2:08 PM, Tom Swindell 
> wrote:
> On Tue, 2011-10-04 at 13:58 +0200, Jeremiah Foster wrote:
> > On Tue, Oct 4, 2011 at 11:35 AM, Sivan Greenberg
> 
> > wrote:
> > On Tue, Oct 4, 2011 at 11:28 AM, Carsten Munk
> >  wrote:
> > > Long story short: buildd and launchpad is very
> useful but
> > only when
> > > you're doing Debian and Debian only.
> >
> >
> > Except it was built by Canonical for Ubuntu and is used by
> Linaro. But
> > perhaps those two things are "Debian" too?
> >
> > OBS is different in many
> > > different ways and allows a proper productization
> > environment as well
> > > as growing an organisation organically.
> >
> >
> >
> > What does that even mean?
> 
> 
> OBS is built with packaging in mind, so it builds packages
> locally and
> on servers in a sanitized environment. Scratchbox may be
> polluted by
> whatever packages a developer has installed and makes
> dependency
> tracking a bit harder IMO.
> 
> 
> I agree that working in a dirty chroot is problematic. That is why
> there is pbuilder and cowdancer.
>  
> 
> I think what Carsten means by "growing an organisation
> organically" is
> that OBS allows multiple users to create their own
> repositories, it
> allows us to separate different projects into different
> repositories for
> staging or logical separation and it's easy and intuitive to
> do all of
> this from the web interface and to tools provided.
> 
> 
> This is likely what he's referring to. But as someone who is concerned
> with integration, this is bordering on a misfeature. What is happening
> is that each repository is a separate Linux distro. This makes
> integration a complete nightmare and unlikely to occur. Look a the ABI
> break that occurred in MeeGo for ARM. That effectively killed any
> release of that distro. 
> 
> 
> Just because you can build your own Linux distro doesn't mean you
> should. 
> 
> OBS may not offer anything more or less than Launchpad or
> buildd, but it
> is completely open source and it targets many more
> distributions than
> Launchpad or buildd do.
> 
> 
> And more package formats, processor virtualization, per-package
> compiler flags, and a mock version control tool, etc. But all these
> things can mean that your package will not work with other distros and
> then we are back to everyone doing their own thing. How does that help
> move free software forward? It doesn't, it only encourages the silo
> effect and Not Invented Here. 
> 
> 
> Before it was just big companies that could create their own Linux
> distros (before that everyone had their bespoke UNIX distro) nowadays
> fragmentation is brought to you by every Tom, Dick and Harry with an
> OBS login. 
> 
> 
> I've been down the fragmentation road before. It always ends with
> retracing your path back to the main highway.
> 
> 
> Regards,
> 
> 
> Jeremiah
> 
> 
> 
> 


___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Carsten Munk]

2011/10/4 karoliina.t.salmi...@gmail.com :
> Hello,
> I think one of the things with the MeeGo was that it was a downgrade in
> development environment, CI systems and everything from our
> Maemo.
So, for good measure - those CI systems were never open source or
published outside the Maemo organisation. And couldn't be reused
properly for non-Debian based targets. New ones had to be developed.

> All that has been made for debian based distro and the change to the
> rpm does not make slightest sense. The debian based distro and everything
> that surrounds it has much longer history on this context and it is that
> simple. I joined the team that became later Maemo already in 2004. Back then
> scratchbox was new invention, but still today it has no replacement which
> would be better or equal. Before scratchbox we were compiling with ext hard
> drive connected to Nokia 770 proto (and ran the gcc on the arm). After
> scratchbox came, there was a great convenience improvement. Killing
> scratchbox without a replacement (OBS is not a replacement!) is not very
> good choice.

I will agree that there was a gap in development tools. It's easy to
start pointing fingers at where things went wrong and who was
responsible, but I won't. But the sad truth is that even with Maemo,
the full stack was uncompliable without internal access to Maemo
sources - it wasn't something to build a platform from.

As Kulve suggested, it is actually pretty easy to get a scratchbox
like chroot. One of the mistakes that MeeGo had was that, well, it
required Atom processors/SSSE3 to run simple development emulation
environments - which honestly, in big organisations was difficult to
find. This meant that practically, people couldn't run MeeGo in a VM
and develop straight on their typical development machine.

I stated my thoughts on build vs emulation in an old blog post of
mine: 
http://mer-project.blogspot.com/2009/08/debconf-thoughts-part-two-on-cross.html

In our original Mer project, it was possible to simply install the
entire development chain within a Mer for X86 virtual machine - and
develop directly on your PC for a system that works exactly as on
device and well-performing too. That was the piece of the puzzle that
didn't work with MeeGo.

Deep down, the packaging format doesn't matter. What matters is what
perspective things has been built with - a traditional desktop will
try to enable the kitchen sink of features. A mobile one enables those
it needs. Think of the Maemo process as cleaning out weeds in the
garden to make it fit in mobile settings.  Moblin and MeeGo was built
from scratch up for a specific mobile purpose - and even then they
managed to get crazy dependancies into the system.  And that's why I
like Moblin/MeeGo and their way of doing things - it's a lean and mean
Qt core.

> This is just my 0.02 cents. I would think it should be done like this:
> - Take the debian based distro and development environment (that works) as a
> basis. It works. Look at Harmattan and all previous Nokia Maemo devices.
I know it works and I also know how much difficulty (and years upon
years of manhours) people have gone through to mangle and modify the
Debian stack to the point it is in those mobile OS'es. I've even tried
to build things myself and realized pretty quickly why Maemo is
patched in head and tail where it is. But the fact is - that system
does not exist in open source. When inside a product organisation you
tend to loose perspective of what's open and what's not.

> - Number 2 key to the success is a blazingly superb UI.  I think QML is 
> a key to developing
> any UI concept fast whatever the Mer wants to be.
> - Number 3: Thou shalt not restrict it to one single technology. I think
> restricting to HTML5 only or QML only would be a bad idea. Instead a support
> of choices which work for different purposes is a key to success. Things
> which do not need to be replaced should not be replaced, they can be
> substituted, but not replaced.
And that's why it's a Core that seeks to perform well with
HTML5/QML/JS - anyone can do brilliant things with it. Want to run a
great UI on top? Be my guest!

BR
Carsten Munk

>
> On Mon, Oct 3, 2011 at 9:01 AM, Carsten Munk  wrote:
>>
>> Hi all,
>>
>> MeeGo is dead ... long live Tizen !! - Haven't we heard that before? -
>> Maemo, Moblin?
>>
>> We need a community that transcends the mere branding of MeeGo, Maemo,
>> Moblin - and now Tizen.
>>
>> A lot of proposals have been put forward:
>> * Move to Tizen and trust that "They'll get it right this time"
>> * Merge or join some existing projects (like the Qt Project, Debian,
>> openSUSE, etc)
>> * Keep MeeGo alive by approaching the Linux Foundation
>>
>> The goal is to find a truly sustainable way for MeeGo and other
>> interested communities to work with Tizen.
>>
>> Our solution is the Mer Project:
>>
>> How does the concept of a truly open and inclusive integration
>> community for devices sound? After all if "upstream is king" - then

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Jeremiah Foster]

On Tue, Oct 4, 2011 at 2:08 PM, Tom Swindell  wrote:

> On Tue, 2011-10-04 at 13:58 +0200, Jeremiah Foster wrote:
> > On Tue, Oct 4, 2011 at 11:35 AM, Sivan Greenberg 
> > wrote:
> > On Tue, Oct 4, 2011 at 11:28 AM, Carsten Munk
> >  wrote:
> > > Long story short: buildd and launchpad is very useful but
> > only when
> > > you're doing Debian and Debian only.
> >
> >
> > Except it was built by Canonical for Ubuntu and is used by Linaro. But
> > perhaps those two things are "Debian" too?
> >
> > OBS is different in many
> > > different ways and allows a proper productization
> > environment as well
> > > as growing an organisation organically.
> >
> >
> >
> > What does that even mean?
>
> OBS is built with packaging in mind, so it builds packages locally and
> on servers in a sanitized environment. Scratchbox may be polluted by
> whatever packages a developer has installed and makes dependency
> tracking a bit harder IMO.
>

I agree that working in a dirty chroot is problematic. That is why there is
pbuilder and cowdancer.


>
> I think what Carsten means by "growing an organisation organically" is
> that OBS allows multiple users to create their own repositories, it
> allows us to separate different projects into different repositories for
> staging or logical separation and it's easy and intuitive to do all of
> this from the web interface and to tools provided.
>

This is likely what he's referring to. But as someone who is concerned with
integration, this is bordering on a misfeature. What is happening is that
each repository is a separate Linux distro. This makes integration a
complete nightmare and unlikely to occur. Look a the ABI break that occurred
in MeeGo for ARM. That effectively killed any release of that distro.

Just because you can build your own Linux distro doesn't mean you should.

>
> OBS may not offer anything more or less than Launchpad or buildd, but it
> is completely open source and it targets many more distributions than
> Launchpad or buildd do.
>

And more package formats, processor virtualization, per-package compiler
flags, and a mock version control tool, etc. But all these things can mean
that your package will not work with other distros and then we are back to
everyone doing their own thing. How does that help move free software
forward? It doesn't, it only encourages the silo effect and Not Invented
Here.

Before it was just big companies that could create their own Linux distros
(before that everyone had their bespoke UNIX distro) nowadays fragmentation
is brought to you by every Tom, Dick and Harry with an OBS login.

I've been down the fragmentation road before. It always ends with retracing
your path back to the main highway.

Regards,

Jeremiah
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Tom Swindell]

On Tue, 2011-10-04 at 13:58 +0200, Jeremiah Foster wrote:
> On Tue, Oct 4, 2011 at 11:35 AM, Sivan Greenberg 
> wrote:
> On Tue, Oct 4, 2011 at 11:28 AM, Carsten Munk
>  wrote:
> > Long story short: buildd and launchpad is very useful but
> only when
> > you're doing Debian and Debian only. 
> 
> 
> Except it was built by Canonical for Ubuntu and is used by Linaro. But
> perhaps those two things are "Debian" too? 
>  
> OBS is different in many
> > different ways and allows a proper productization
> environment as well
> > as growing an organisation organically.
> 
> 
> 
> What does that even mean?

OBS is built with packaging in mind, so it builds packages locally and
on servers in a sanitized environment. Scratchbox may be polluted by
whatever packages a developer has installed and makes dependency
tracking a bit harder IMO.

I think what Carsten means by "growing an organisation organically" is
that OBS allows multiple users to create their own repositories, it
allows us to separate different projects into different repositories for
staging or logical separation and it's easy and intuitive to do all of
this from the web interface and to tools provided.

OBS may not offer anything more or less than Launchpad or buildd, but it
is completely open source and it targets many more distributions than
Launchpad or buildd do.

>  
> 
> 
> I see, thanks for enlightening me. 
> 
> 
> You're not enlightened, you've just gotten a perspective from one
> developer on why they like what they like.
>  
> We should then look to add the
> missing features like Feature Planning (blueprint) and others
> from
> Launchpad, although we could just use the wiki for everything
> not
> build / commit stuff.
> 
> 
> NB - Not all of Launchpad is open source.
> 
> >
> > The choice has been made to go for OBS and RPM in Mer -
> we'll be in a
> > even longer cycle if we were to revert to Debian based
> things and it's
> > not obvious there'll be any benefit - I personally got
> bitten badly by
> > basing on Debian/Ubuntu in the first iteration of Mer. We're
> here now
> > and we have something that works and expertise in these
> areas. That's
> > the direction we're going in.
> >
> > (I swear, if we are going to have the RPM vs DEB talk, I'll
> propose we
> > switch to rot13 encrypted zip files and actually go ahead
> with it!)
> 
> 
> 
> Ignorance is bliss.
> 
> 
> Regards,
> 
> 
> Jeremiah 
> ___
> MeeGo-dev mailing list
> MeeGo-dev@meego.com
> http://lists.meego.com/listinfo/meego-dev
> http://wiki.meego.com/Mailing_list_guidelines


___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Sivan Greenberg]

On Tue, Oct 4, 2011 at 1:58 PM, Jeremiah Foster
 wrote:
> On Tue, Oct 4, 2011 at 11:35 AM, Sivan Greenberg 
> wrote:
>>
>> On Tue, Oct 4, 2011 at 11:28 AM, Carsten Munk  wrote:
>> > Long story short: buildd and launchpad is very useful but only when
>> > you're doing Debian and Debian only.
>
> Except it was built by Canonical for Ubuntu and is used by Linaro. But
> perhaps those two things are "Debian" too?
>
>>
>> OBS is different in many
>> > different ways and allows a proper productization environment as well
>> > as growing an organisation organically.
>
> What does that even mean?
>
I would also like to understand that, perhaps through the use of that
layer on top of OBS which I had forgotten its name? Is there somewhere
documentation to read about this?

>>
>> I see, thanks for enlightening me.
>
> You're not enlightened, you've just gotten a perspective from one developer
> on why they like what they like.

To be frank, I just did not want to make Carsten angry and go with
rot13 encrypted zip files so we actually have to use it ;-)

>
>>
>> We should then look to add the
>> missing features like Feature Planning (blueprint) and others from
>> Launchpad, although we could just use the wiki for everything not
>> build / commit stuff.
>
> NB - Not all of Launchpad is open source.

I stand corrected.

>>
>> >
>> > The choice has been made to go for OBS and RPM in Mer - we'll be in a
>> > even longer cycle if we were to revert to Debian based things and it's
>> > not obvious there'll be any benefit - I personally got bitten badly by
>> > basing on Debian/Ubuntu in the first iteration of Mer. We're here now
>> > and we have something that works and expertise in these areas. That's
>> > the direction we're going in.
>> >
>> > (I swear, if we are going to have the RPM vs DEB talk, I'll propose we
>> > switch to rot13 encrypted zip files and actually go ahead with it!)
>
> Ignorance is bliss.


Well, deb lovers could always try and have their own deb'd meego as
Robin noted. But if Qt Creator does take care of all the packaging for
RPM and the upload to OBS, then I should not care about the underlying
packaging system.

-Sivan
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Jeremiah Foster]

On Tue, Oct 4, 2011 at 10:53 AM, karoliina.t.salmi...@gmail.com <
karoliina.t.salmi...@gmail.com> wrote:

> Hello,
>
> This is just my 0.02 cents. I would think it should be done like this:
>
> - Take the debian based distro and development environment (that works) as
> a basis. It works. Look at Harmattan and all previous Nokia Maemo devices.
>

This makes way too much sense to be adopted. :-)

"Don't start your own project, join someone else's."
- Dan Frye:

Regards,

Jeremiah
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Jeremiah Foster]

On Tue, Oct 4, 2011 at 11:35 AM, Sivan Greenberg wrote:

> On Tue, Oct 4, 2011 at 11:28 AM, Carsten Munk  wrote:
> > Long story short: buildd and launchpad is very useful but only when
> > you're doing Debian and Debian only.
>

Except it was built by Canonical for Ubuntu and is used by Linaro. But
perhaps those two things are "Debian" too?


> OBS is different in many
> > different ways and allows a proper productization environment as well
> > as growing an organisation organically.
>

What does that even mean?


>
> I see, thanks for enlightening me.


You're not enlightened, you've just gotten a perspective from one developer
on why they like what they like.


> We should then look to add the
> missing features like Feature Planning (blueprint) and others from
> Launchpad, although we could just use the wiki for everything not
> build / commit stuff.
>

NB - Not all of Launchpad is open source.

>
> >
> > The choice has been made to go for OBS and RPM in Mer - we'll be in a
> > even longer cycle if we were to revert to Debian based things and it's
> > not obvious there'll be any benefit - I personally got bitten badly by
> > basing on Debian/Ubuntu in the first iteration of Mer. We're here now
> > and we have something that works and expertise in these areas. That's
> > the direction we're going in.
> >
> > (I swear, if we are going to have the RPM vs DEB talk, I'll propose we
> > switch to rot13 encrypted zip files and actually go ahead with it!)
>

Ignorance is bliss.

Regards,

Jeremiah
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Sivan Greenberg]

On Tue, Oct 4, 2011 at 11:28 AM, Carsten Munk  wrote:
> Long story short: buildd and launchpad is very useful but only when
> you're doing Debian and Debian only. OBS is different in many
> different ways and allows a proper productization environment as well
> as growing an organisation organically.

I see, thanks for enlightening me. We should then look to add the
missing features like Feature Planning (blueprint) and others from
Launchpad, although we could just use the wiki for everything not
build / commit stuff.

>
> The choice has been made to go for OBS and RPM in Mer - we'll be in a
> even longer cycle if we were to revert to Debian based things and it's
> not obvious there'll be any benefit - I personally got bitten badly by
> basing on Debian/Ubuntu in the first iteration of Mer. We're here now
> and we have something that works and expertise in these areas. That's
> the direction we're going in.
>
> (I swear, if we are going to have the RPM vs DEB talk, I'll propose we
> switch to rot13 encrypted zip files and actually go ahead with it!)
>

I've stopped it, I hope Qt Creator will learn to create RPM packages
by when Mer is reading for playing with :-D

-Sivan
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Tuomas Kulve]

On 10/04/2011 12:06 PM, Jon Nordby wrote:

Don't go around trying to changing everything if what you're missing is
just Scratchbox.


I also liked the Scratchbox, despite the problems.

For MeeGo stuff I use this (ARM chroot created from the osc local build):

http://tuomas.kulve.fi/blog/2011/07/09/meego-1-2-armv7-chroot-beta/

The usage is similar to Scratchbox, chroot in and run make.

I feel that the OBS is a bit overkill (i.e. slow) for a single component 
developer but maintaining a distro with it seemed convenient. It was 
especially nice to notice that a company's private OBS was able to link 
to the upstream OBS and only build the differencies. The rest (both 
source and binary) came from the upstream automatically.


--
Tuomas
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Sivan Greenberg]

On Tue, Oct 4, 2011 at 11:20 AM, Robin Burchell
 wrote:
> it can be looked at. We've chosen the approach of minimal change
> because it means we have a working system with less effort.
>

I realize this, does this mean that once we find someone to sponsor
the servers we just deploy OBS on it and we are done? (trying ot
understand where this saves effort)

Again - I hope that's okay I'm asking all of this, and this does not
look like being ungrateful for the proposal :-) (With how MeeGo
mailing lists looked the last couple of months, one be better sure
than sorry ;))

-Sivan
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Carsten Munk]

2011/10/4 Sivan Greenberg :
> On Tue, Oct 4, 2011 at 11:14 AM, Robin Burchell
>  wrote:
>>
>> OBS is a very useful tool, just not for the purposes you were
>> apparently forced to use it for. I've used it for the commit, push
>> package, wait for build failure type development cycle as well, and I
>> agree, it's far from optimal - but for easily making heavily
>> customised distributions, OBS is great.
>>
>
> Robin, why is OBS different and better than the original buildd's we
> used for Maemo and/or nowdays open sourced Launchpad ? I was one of
> those who felt the whole lot of changes we've been going through to
> adopt to Moblin were time consuming and just presented yet another
> hurdle to the community that was already experienced in Debian
> packaging and the debian build servers.
>
> I think, if we're reconstructing we should perhaps re think the
> decisions that were laid upon us by the corporate governance before we
> repeat them.
>
> Important note: this is not trolling, I'm sincerely trying to
> understand where and how we are going to from now on.

Long story short: buildd and launchpad is very useful but only when
you're doing Debian and Debian only. OBS is different in many
different ways and allows a proper productization environment as well
as growing an organisation organically.

The choice has been made to go for OBS and RPM in Mer - we'll be in a
even longer cycle if we were to revert to Debian based things and it's
not obvious there'll be any benefit - I personally got bitten badly by
basing on Debian/Ubuntu in the first iteration of Mer. We're here now
and we have something that works and expertise in these areas. That's
the direction we're going in.

(I swear, if we are going to have the RPM vs DEB talk, I'll propose we
switch to rot13 encrypted zip files and actually go ahead with it!)

BR
Carsten Munk
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Sivan Greenberg]

On Tue, Oct 4, 2011 at 11:14 AM, Robin Burchell
 wrote:
>
> OBS is a very useful tool, just not for the purposes you were
> apparently forced to use it for. I've used it for the commit, push
> package, wait for build failure type development cycle as well, and I
> agree, it's far from optimal - but for easily making heavily
> customised distributions, OBS is great.
>

Robin, why is OBS different and better than the original buildd's we
used for Maemo and/or nowdays open sourced Launchpad ? I was one of
those who felt the whole lot of changes we've been going through to
adopt to Moblin were time consuming and just presented yet another
hurdle to the community that was already experienced in Debian
packaging and the debian build servers.

I think, if we're reconstructing we should perhaps re think the
decisions that were laid upon us by the corporate governance before we
repeat them.

Important note: this is not trolling, I'm sincerely trying to
understand where and how we are going to from now on.

-Sivan
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Robin Burchell]

Hi Sivan (& others),

On Tue, Oct 4, 2011 at 11:13 AM, Sivan Greenberg  wrote:
> Again, why don't we forget reinventing the infrastructure in the price
> of using debs (which is a known a loved format for embedded computing
> everywhere, and since RPM and DEBs are just a way of packaging and not
> really an issue if we chose one or another, just use Launchpad like
> Linaro does?)

Talk is cheap; actions talk much more loudly.

If you (or others) think this is a good approach, then by all means,
go for it, do some work and get a proof of concept showing how (& why)
it is better without losing the ability to easily seperate
core/UI/hardware adaptations and other key parts of the proposal, and
it can be looked at. We've chosen the approach of minimal change
because it means we have a working system with less effort.

BR,

Robin
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Jon Nordby]

On 10/04/11 11:07, Sivan Greenberg wrote:

I just think it would have been better if we (The Nokia linux
organization and the fans) did not have to go through the MeeGo
hurdle, and as you say in detail, look at harmattan and how slick and
beautiful is as a product. (I use it in N950 as my everyday phone and
no *other* OS/ device even comes close to the experience I get.

The slick parts are sadly not very open.


However, I understand from Carsten that all of our code is already in
RPM and hence this is why Mer is going to use it, I am wondering what
would it take to just use Harmattan as the basis for Mer now and keep
the tradition and the rocking dev tools (Scratchbox is indeed, a cross
compilation environment OOTB that as an embedded OS maker, I've yet
come to see in its simplicity and support to the developer from any
other platform / distro and/or vendor).
Yes, one would want Scratchbox or similar in addition to what OBS 
provides. However, there is nothing that prevents Scratchbox from being 
used together with RPM and an RPM based distro is there?


Don't go around trying to changing everything if what you're missing is 
just Scratchbox.


--
Jon Nordby - www.jonnor.com
Software Developer, Openismus GmbH - www.openismus.com
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Robin Burchell]

Hi Karoliina,

On Tue, Oct 4, 2011 at 10:53 AM, karoliina.t.salmi...@gmail.com
 wrote:
> Killing scratchbox without a replacement (OBS is not a replacement!) is not 
> very
> good choice.

MeeGo was theoretically usable in qemu, unfortunately, I don't think a
lot of effort was put into that direction. There is also MADDE,
although as you probably know, that isn't very useful unless you're a
simple application developer - a more complex beast like the settings
application wouldn't really be easy to use there unless you did some
hacking around in the rootfs, injecting your own needed libs, etc.

This is definitely something that I imagine will be looked into around
the context of Mer - Mer of old had images that could easily be shoved
into virtualbox, etc, and they made life a lot easier.

OBS is a very useful tool, just not for the purposes you were
apparently forced to use it for. I've used it for the commit, push
package, wait for build failure type development cycle as well, and I
agree, it's far from optimal - but for easily making heavily
customised distributions, OBS is great.

> e.g. seeing our duicontrolpanel on MeeGo-MeeGo installation instead of
> Harmattan is a whole different experience than seeing it on Harmattan
> device),



> But good news, there is a easy technology to make a superb UI framework 
> rapidly, QML.
> It needs some work,  needs to be consistent UI concept, excellent graphics 
> (which have a meaning,

The technology is, at the end of the day, not that important (though I
agree that QML makes life a lot easier) - at the end of the day, you
can have the best written UI in the world, and it will still look like
complete and utter crap without decent theming.

Hopefully we can poke some of the awesome graphical people around like
wazd to give us a hand with some of this.

> - Many of the lower layers have been already open sourced by companies and
> it is just about utilizing them and doing the top of the cake right. There
> are some missing pieces, but filling the gaps should not be impossible.

One of the missing gaps, at least on Handset CE, is the settings
application. As you point out, it is not visually pleasing, it has
flickering text ("!! Wifi" before changing to the actual text), and
other issues which make it a bit pailful to use.

Given your experience with it, would you like to dedicate some time to
making it more usable, perhaps even doing some thinking on how to
approach it from the QML world?

BR,

Robin
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Sivan Greenberg]

On Mon, Oct 3, 2011 at 8:01 AM, Carsten Munk  wrote:
> 4) Work towards better vendor relations and software to support these
> as well as easier contribution methods.
>
> As part of our "customer oriented" goal we're improving delivery
> methods from Mer. We are designing simpler and more resilient update
> mechanisms to support smaller and more distributed organisations
> (think outsourcing too!). We want to encourage easy upstream
> contribution and easy following and  patching of the MeeGo source tree
> - even with local vendor patches.

There are numerous system that already allow this, specifically in the
Debian world. Linaro are using Launchpad to do just this. Isn't this
an attempt to reinvent some wheels? If we did align with the debian
packaging format we could have used this infrastructure which is ready
made, and can even be deployed by us if we would not want to ask
Canonical for it. Although I'm sure they'd be keen and happy to help
without any charge and even support any community infrastructure we
would require for free.

My 0.003 EU cents on this particular point.

-Sivan

>
> 5) Initial reference vendor - the Community Edition
>
> To make our work focused, the Community Edition handset work[4] will
> continue based on the Mer Core. It will act as a model of a reference
> vendor [5] and will provide feedback into the project about delivery
> methods and problems caused by changes.
>
> We recognise that much needs to be done:
> * Hosting and build systems

Again, why don't we forget reinventing the infrastructure in the price
of using debs (which is a known a loved format for embedded computing
everywhere, and since RPM and DEBs are just a way of packaging and not
really an issue if we chose one or another, just use Launchpad like
Linaro does?)


Thanks for the proposal!

-Sivan
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Sivan Greenberg]

I just think it would have been better if we (The Nokia linux
organization and the fans) did not have to go through the MeeGo
hurdle, and as you say in detail, look at harmattan and how slick and
beautiful is as a product. (I use it in N950 as my everyday phone and
no *other* OS/ device even comes close to the experience I get.

However, I understand from Carsten that all of our code is already in
RPM and hence this is why Mer is going to use it, I am wondering what
would it take to just use Harmattan as the basis for Mer now and keep
the tradition and the rocking dev tools (Scratchbox is indeed, a cross
compilation environment OOTB that as an embedded OS maker, I've yet
come to see in its simplicity and support to the developer from any
other platform / distro and/or vendor).

If you ask me, Harmattan is the way to go , asking to yet open closed
parts or replace them with open parts , put a UX on top following the
Swipe style if we have a UX team (because Mer is supposed to be a thin
base layer nothing more). And just do it. Then Nokia (In my deepest
hopes) could re-use it when perhaps Linux will find its way back there
as a smartphone platform.


On Tue, Oct 4, 2011 at 10:53 AM, karoliina.t.salmi...@gmail.com
 wrote:
> would be better or equal. Before scratchbox we were compiling with ext hard
> drive connected to Nokia 770 proto (and ran the gcc on the arm). After
> scratchbox came, there was a great convenience improvement. Killing
> scratchbox without a replacement (OBS is not a replacement!) is not very
> good choice.

+1 .

> on your machine, not needing some OBS build service to build your package
> when you can compile on your computer. So forget RPM, is number 1 key to the
> success. And even if the intended hardware would be something else than ARM,
> it does not matter. This is my recommendation. Do whatever you want, but I
> think this would be the right thing to do at this point.

+1

> - Number 2 key to the success is a blazingly superb UI. And this is not even
> very hard one but takes some work. Community MeeGo has not had a meaningful
> UI, has always had poor graphics (or missing graphics on Nokia's code drops,
> are different from app to app because the apps are "color coded" - this kind
> of attention does matter). But QML is really awesome for creating things
> fast and the QML based swipe tutorial on Harmattan (when you boot your N9
> first time) shows that it can be done with QML (as the swipe tutorial
> simulates the Harmattan UI framework). I think QML is a key to developing
> any UI concept fast whatever the Mer wants to be.

++1

> - Number 3: Thou shalt not restrict it to one single technology. I think
> restricting to HTML5 only or QML only would be a bad idea. Instead a support
> of choices which work for different purposes is a key to success. Things
> which do not need to be replaced should not be replaced, they can be
> substituted, but not replaced.

+++1 .

Problem is that how do you make all of the technologies appear
integrative to the platform, as Rich Green once noted about apps and
WP7 that an app there does not feel different to the core OS UX. I
could argue that we should support GTK , Vala, Mono stuff and the list
goes on...but how to make it look organic?

> - Many of the lower layers have been already open sourced by companies and
> it is just about utilizing them and doing the top of the cake right. There
> are some missing pieces, but filling the gaps should not be impossible. It
> is some work to do, but it may not be overwhelmingly big work.

I have no idea about this - can anybody really estimate the amount of
work needed?

-Sivan
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[karoliina.t.salmi...@gmail.com]

Hello,

I think one of the things with the MeeGo was that it was a downgrade in
development environment, CI systems and everything from our
Maemo. All that has been made for debian based distro and the change to the
rpm does not make slightest sense. The debian based distro and everything
that surrounds it has much longer history on this context and it is that
simple. I joined the team that became later Maemo already in 2004. Back then
scratchbox was new invention, but still today it has no replacement which
would be better or equal. Before scratchbox we were compiling with ext hard
drive connected to Nokia 770 proto (and ran the gcc on the arm). After
scratchbox came, there was a great convenience improvement. Killing
scratchbox without a replacement (OBS is not a replacement!) is not very
good choice.

This is just my 0.02 cents. I would think it should be done like this:

- Take the debian based distro and development environment (that works) as a
basis. It works. Look at Harmattan and all previous Nokia Maemo devices. And
there is scratchbox, which is open source, and even if it would not be
perfect, it works and is great for developing and cross compiling anything
on your machine, not needing some OBS build service to build your package
when you can compile on your computer. So forget RPM, is number 1 key to the
success. And even if the intended hardware would be something else than ARM,
it does not matter. This is my recommendation. Do whatever you want, but I
think this would be the right thing to do at this point.

- Number 2 key to the success is a blazingly superb UI. And this is not even
very hard one but takes some work. Community MeeGo has not had a meaningful
UI, has always had poor graphics (or missing graphics on Nokia's code drops,
e.g. seeing our duicontrolpanel on MeeGo-MeeGo installation instead of
Harmattan is a whole different experience than seeing it on Harmattan
device), poor or missing icons and does not really shine in any way when
compared to iOS, Android or Harmattan. But good news, there is a easy
technology to make a superb UI framework rapidly, QML. It needs some work,
needs to be consistent UI concept, excellent graphics (which have a meaning,
if you look closely icons on Harmattan and the colors of applications, they
are different from app to app because the apps are "color coded" - this kind
of attention does matter). But QML is really awesome for creating things
fast and the QML based swipe tutorial on Harmattan (when you boot your N9
first time) shows that it can be done with QML (as the swipe tutorial
simulates the Harmattan UI framework). I think QML is a key to developing
any UI concept fast whatever the Mer wants to be.

- Number 3: Thou shalt not restrict it to one single technology. I think
restricting to HTML5 only or QML only would be a bad idea. Instead a support
of choices which work for different purposes is a key to success. Things
which do not need to be replaced should not be replaced, they can be
substituted, but not replaced.

- Many of the lower layers have been already open sourced by companies and
it is just about utilizing them and doing the top of the cake right. There
are some missing pieces, but filling the gaps should not be impossible. It
is some work to do, but it may not be overwhelmingly big work.

With some gaps filled on UI, and then lower layers, this distro could be
easily superior to e.g. Android. It is another question if someone wants to
use it, but at least would be a fun thing.

Best Regards,
Karoliina


On Mon, Oct 3, 2011 at 9:01 AM, Carsten Munk  wrote:

> Hi all,
>
> MeeGo is dead ... long live Tizen !! - Haven't we heard that before? -
> Maemo, Moblin?
>
> We need a community that transcends the mere branding of MeeGo, Maemo,
> Moblin - and now Tizen.
>
> A lot of proposals have been put forward:
> * Move to Tizen and trust that "They'll get it right this time"
> * Merge or join some existing projects (like the Qt Project, Debian,
> openSUSE, etc)
> * Keep MeeGo alive by approaching the Linux Foundation
>
> The goal is to find a truly sustainable way for MeeGo and other
> interested communities to work with Tizen.
>
> Our solution is the Mer Project:
>
> How does the concept of a truly open and inclusive integration
> community for devices sound? After all if "upstream is king" - then
> contributions will end up the same place, no matter if it's Tizen,
> Maemo, MeeGo or openSUSE.
>
> Some history - many of us in MeeGo originated from a project called
> Mer, short for Maemo Reconstructed - where we approached doing a open
> mobile platform through reconstruction of the Maemo platform into a
> open platform. We were big on open governance, open development and
> open source.
>
> For a few months a group of us have been working on various scenarios
> of change in MeeGo [1] and now that the Tizen news is out in the open,
> it's time to talk about what we as a community can make happen next.
> To make it clear: this is not in any way

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Timo Jyrinki]

ma, 2011-10-03 kello 19:09 +0100, Si Howard kirjoitti:
> I'm for that! Wasn't the Mer project part of the Maemo 5.0 porting to
> the Nokia N8X0 platform?

That's one way of putting it, but it was indeed about reconstructing
Maemo so that it worked as a whole distribution. That then made possible
to try to get newer Maemo components working on older tablets purely as
a community effort.

So more like Maemo 5.0 porting to the Nokia N8X0 platform was a part of
the Mer project, not the other way around :)

-Timo


___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[harri.hakulinen]

Carsten, David and Robin,

Thank you very much for this proposal and work already done and started. This 
single post alone convinces me that we have not wasted any work on MeeGo (ce), 
and that it in fact will have bright future ahead, no matter of the name of the 
project , the products based on it or possible companies involved in it.

This very clearly is the best part of OSS promise, when one (business) model 
changes, the projects and the best people continue with the code and  their 
learning of the old model.

I sincerely hope that people understand that your Mer project is not against 
anything or anyone. If companies don't understand the value of your proposal in 
this "round", for sure they will in next one. 
 
Have a happy hacking, and see you around.

Br,
//Harri

-Original Message-
From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On 
Behalf Of ext Carsten Munk
Sent: 3. lokakuuta 2011 9:01
To: meego-dev; meego-comm...@meego.com
Subject: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for 
MeeGo

Hi all,

MeeGo is dead ... long live Tizen !! - Haven't we heard that before? - Maemo, 
Moblin?

We need a community that transcends the mere branding of MeeGo, Maemo, Moblin - 
and now Tizen.

A lot of proposals have been put forward:
* Move to Tizen and trust that "They'll get it right this time"
* Merge or join some existing projects (like the Qt Project, Debian, openSUSE, 
etc)
* Keep MeeGo alive by approaching the Linux Foundation

The goal is to find a truly sustainable way for MeeGo and other interested 
communities to work with Tizen.

Our solution is the Mer Project:

How does the concept of a truly open and inclusive integration community for 
devices sound? After all if "upstream is king" - then contributions will end up 
the same place, no matter if it's Tizen, Maemo, MeeGo or openSUSE.

Some history - many of us in MeeGo originated from a project called Mer, short 
for Maemo Reconstructed - where we approached doing a open mobile platform 
through reconstruction of the Maemo platform into a open platform. We were big 
on open governance, open development and open source.

For a few months a group of us have been working on various scenarios of change 
in MeeGo [1] and now that the Tizen news is out in the open, it's time to talk 
about what we as a community can make happen next.
To make it clear: this is not in any way an anti-Tizen or anti-Intel project, 
but a direction we can and will go in - we strongly want to collaborate with 
Tizen and Intel.

We will continue to welcome contribution and participation from the hacker 
community - in fact we aim to make it so easy to port to a new vendor device 
that a single hacker could do it for their device.

We decided to approach the problems and potential scenarios of change in MeeGo 
in the light of the reallocation of resources caused by what is now known as 
the Tizen work. There have not been any Trunk/1.3 releases since August and 
Tablet UX has totally stalled. What really works (and works quite well) is the 
Core. It's time to take the pieces and use them for reconstruction.

We have some clear goals:

* To be openly developed and openly governed as a meritocracy
* That primary customers of the platform are device vendors - not end-users.
* To provide a device manufacturer oriented structure, processes and
tools: make life easy for them
* To have a device oriented architecture
* To be inclusive of technologies (such as MeeGo/Tizen/Qt/EFL/HTML5)
* To innovate in the mobile OS space

Now we'd like to talk a bit about what specific initiatives we propose to take:

0) Becoming MeeGo 2.0

Our work has the intended goal of being MeeGo 2.0 - and we hope that the Linux 
Foundation will see our work as a worthy succesor within the MeeGo spirit. We'd 
like to provide ability to be Tizen compliant, i.e.
supporting HTML5/WAC and the application story there and feed back to that 
ecosystem.

1) Modularity. A set of architectural components for making devices.

Rather than dictate the architecture we will support collaboration and the 
flexibility to easily access off-the-shelf components for device projects. 
Component independence permits focused feature and delivery management too.

Initially the project will be developing a Core for basing products on and will 
split UX and hardware adaptations out into seperate projects within the 
community surrounding the Core.

2) Working towards an ultra-portable Linux + HTML5/QML/JS Core for building 
products with.

We have already taken MeeGo and cut it into a set of 302 source packages that 
can boot into a Qt UI along with standard MeeGo stack pieces. This work can be 
seen already at [2] and we've made our first release and have had it booting on 
devices already[6].

To ease maintenance, we would like to encourage people to participate in the 
Core work of the Tizen project, uti

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Si Howard]

I'm for that! Wasn't the Mer project part of the Maemo 5.0 porting to 
the Nokia N8X0 platform?


On 03/10/2011 07:01, Carsten Munk wrote:

Hi all,

MeeGo is dead ... long live Tizen !! - Haven't we heard that before? -
Maemo, Moblin?

We need a community that transcends the mere branding of MeeGo, Maemo,
Moblin - and now Tizen.

A lot of proposals have been put forward:
* Move to Tizen and trust that "They'll get it right this time"
* Merge or join some existing projects (like the Qt Project, Debian,
openSUSE, etc)
* Keep MeeGo alive by approaching the Linux Foundation

The goal is to find a truly sustainable way for MeeGo and other
interested communities to work with Tizen.

Our solution is the Mer Project:

How does the concept of a truly open and inclusive integration
community for devices sound? After all if "upstream is king" - then
contributions will end up the same place, no matter if it's Tizen,
Maemo, MeeGo or openSUSE.

Some history - many of us in MeeGo originated from a project called
Mer, short for Maemo Reconstructed - where we approached doing a open
mobile platform through reconstruction of the Maemo platform into a
open platform. We were big on open governance, open development and
open source.

For a few months a group of us have been working on various scenarios
of change in MeeGo [1] and now that the Tizen news is out in the open,
it's time to talk about what we as a community can make happen next.
To make it clear: this is not in any way an anti-Tizen or anti-Intel
project, but a direction we can and will go in - we strongly want to
collaborate with Tizen and Intel.

We will continue to welcome contribution and participation from the
hacker community - in fact we aim to make it so easy to port to a new
vendor device that a single hacker could do it for their device.

We decided to approach the problems and potential scenarios of change
in MeeGo in the light of the reallocation of resources caused by what
is now known as the Tizen work. There have not been any Trunk/1.3
releases since August and Tablet UX has totally stalled. What really
works (and works quite well) is the Core. It's time to take the pieces
and use them for reconstruction.

We have some clear goals:

* To be openly developed and openly governed as a meritocracy
* That primary customers of the platform are device vendors - not end-users.
* To provide a device manufacturer oriented structure, processes and
tools: make life easy for them
* To have a device oriented architecture
* To be inclusive of technologies (such as MeeGo/Tizen/Qt/EFL/HTML5)
* To innovate in the mobile OS space

Now we'd like to talk a bit about what specific initiatives we propose to take:

0) Becoming MeeGo 2.0

Our work has the intended goal of being MeeGo 2.0 - and we hope that
the Linux Foundation will see our work as a worthy succesor within the
MeeGo spirit. We'd like to provide ability to be Tizen compliant, i.e.
supporting HTML5/WAC and the application story there and feed back to
that ecosystem.

1) Modularity. A set of architectural components for making devices.

Rather than dictate the architecture we will support collaboration and
the flexibility to easily access off-the-shelf components for device
projects. Component independence permits focused feature and delivery
management too.

Initially the project will be developing a Core for basing products on
and will split UX and hardware adaptations out into seperate projects
within the community surrounding the Core.

2) Working towards an ultra-portable Linux + HTML5/QML/JS Core for
building products with.

We have already taken MeeGo and cut it into a set of 302 source
packages that can boot into a Qt UI along with standard MeeGo stack
pieces. This work can be seen already at [2] and we've made our first
release and have had it booting on devices already[6].

To ease maintenance, we would like to encourage people to participate
in the Core work of the Tizen project, utilizing their work where we
can in Mer: why do the same work twice? Even if Tizen turns out to be
dramatically different, the maintenance load of 302 source packages -
much of it typical Linux software, is significantly lower than that of
the 1400 packages found in MeeGo today.

Using another lesson learned from MeeGo, we also want to port this
work to everywhere, ARMv6/7 - hardfp, softfp, i486, Atom, MIPS, etc -
allowing much more freedom for porting to new devices.

3) Change governance towards a more technically oriented one, similar
to the Yocto Project

We'd like to propose a revamp of governance based upon the Yocto
Project governance - which is much more geared towards open technical
work - encouraging collaboration and discussion. You can look at a
description of this at [3].

4) Work towards better vendor relations and software to support these
as well as easier contribution methods.

As part of our "customer oriented" goal we're improving delivery
methods from Mer. We are designing simpler and more resilient update

Re: [MeeGo-dev] [MeeGo-community] MeeGo as a vehicle for Qt-based products?

[Foster, Dawn M]

On Oct 1, 2011, at 11:28 AM, Kok, Auke-jan H wrote:


> 
> I've been asking the same questions as everyone else. If I get answers
> back that I can share, I most certainly will. For now, I'd like to ask
> everyone to submit questions to Dawn Foster, and keep asking. Answers
> will come - be patient.

Please no :)

I really do read all of the mailing list posts here, so continue to use
this is as the place for questions and discussion. Sending it to me
individually makes it less likely that you will get an answer, not more
likely.

Right now, there are still many unanswered questions because we just 
don't have answers to many of the technical questions yet. People
are very focused on getting the code out into the repos so that we
can start having productive discussions about the project based on
the code. Right now, we'd be guessing along with everyone else on
many of the questions.

Dawn
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Manoj Kumar]

On 3 October 2011 11:31, Carsten Munk  wrote:

> We have some clear goals:
>
> * To be openly developed and openly governed as a meritocracy
> * That primary customers of the platform are device vendors - not
> end-users.
> * To provide a device manufacturer oriented structure, processes and
> tools: make life easy for them
> * To have a device oriented architecture
> * To be inclusive of technologies (such as MeeGo/Tizen/Qt/EFL/HTML5)
> * To innovate in the mobile OS space
>


Hi Devs,

Left me in dark the past week, and this thread brought me back to earth.

Who am I? Just a Hard-core fan of Maemo, thus a fan of Meego-CE.

Developer? Not yet, but I'd love to be one, and I'm starting it off with
this MeeGo 2.0 hoping this is the new Mer now.

This thread looks like the real vision that was seen missing these days in
the past.

"That primary customers of the platform are device vendors - not end-users"
this makes me realize how good we are going to be in the near future.

Thanks,
Sorry, if I have posted in the wrong thread,
Manoj
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] [MeeGo-community] invitation... and a second one

[Timo Jyrinki]

(cc:ing to meego-dev as well since Jos originally wanted to post there,
too)

to, 2011-09-29 kello 21:40 +0200, Jos Poortvliet kirjoitti:
> Dear MeeGo friends!
> 
> Many people in your community wonder where to go since the Tizen 
> announcement. At a MeeGo meet in Tampere, many expressed concerns: can 
> we contribute to Tizen? How long will it last *this time*? How will 
> Samsung behave? I know many of you are concerned about loosing the great 
> community you've build.

Thanks Jos for the invitation!

I have now written another "invitation" from Debian perspective and an
overview of the situation from my point of view at:

http://losca.blogspot.com/2011/10/from-meego-to-tizen-debian.html

In brief: do not fall in agony, there is a wide range of communities out
there. Just answer the Aaron Seigo's question about thinking about
evaluating own motives in contributing to for example MeeGo. Then choose
the communities (plural) you want to work in! Obviously it could be the
future Tizen community as well. But it could be openSUSE, Debian, Qt
project, KDE project, Mer, or any number of other possibilities. All of
them have some similarities with what MeeGo was.

-Timo


___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[nic...@nicoladefilippo.it]

Hi,
+1 Nicola 
Da: meego-dev-boun...@meego.com
A: "meego-dev" meego-dev@meego.com, meego-comm...@meego.com
Cc: 
Data: Mon, 3 Oct 2011 08:01:17 +0200
Oggetto: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for 
MeeGo

> Hi all,
> 
> MeeGo is dead ... long live Tizen !! - Haven't we heard that before? -
> Maemo, Moblin?
> 
> We need a community that transcends the mere branding of MeeGo, Maemo,
> Moblin - and now Tizen.
> 
> A lot of proposals have been put forward:
> * Move to Tizen and trust that "They'll get it right this time"
> * Merge or join some existing projects (like the Qt Project, Debian,
> openSUSE, etc)
> * Keep MeeGo alive by approaching the Linux Foundation
> 
> The goal is to find a truly sustainable way for MeeGo and other
> interested communities to work with Tizen.
> 
> Our solution is the Mer Project:
> 
> How does the concept of a truly open and inclusive integration
> community for devices sound? After all if "upstream is king" - then
> contributions will end up the same place, no matter if it's Tizen,
> Maemo, MeeGo or openSUSE.
> 
> Some history - many of us in MeeGo originated from a project called
> Mer, short for Maemo Reconstructed - where we approached doing a open
> mobile platform through reconstruction of the Maemo platform into a
> open platform. We were big on open governance, open development and
> open source.
> 
> For a few months a group of us have been working on various scenarios
> of change in MeeGo [1] and now that the Tizen news is out in the open,
> it's time to talk about what we as a community can make happen next.
> To make it clear: this is not in any way an anti-Tizen or anti-Intel
> project, but a direction we can and will go in - we strongly want to
> collaborate with Tizen and Intel.
> 
> We will continue to welcome contribution and participation from the
> hacker community - in fact we aim to make it so easy to port to a new
> vendor device that a single hacker could do it for their device.
> 
> We decided to approach the problems and potential scenarios of change
> in MeeGo in the light of the reallocation of resources caused by what
> is now known as the Tizen work. There have not been any Trunk/1.3
> releases since August and Tablet UX has totally stalled. What really
> works (and works quite well) is the Core. It's time to take the pieces
> and use them for reconstruction.
> 
> We have some clear goals:
> 
> * To be openly developed and openly governed as a meritocracy
> * That primary customers of the platform are device vendors - not end-users.
> * To provide a device manufacturer oriented structure, processes and
> tools: make life easy for them
> * To have a device oriented architecture
> * To be inclusive of technologies (such as MeeGo/Tizen/Qt/EFL/HTML5)
> * To innovate in the mobile OS space
> 
> Now we'd like to talk a bit about what specific initiatives we propose to 
> take:
> 
> 0) Becoming MeeGo 2.0
> 
> Our work has the intended goal of being MeeGo 2.0 - and we hope that
> the Linux Foundation will see our work as a worthy succesor within the
> MeeGo spirit. We'd like to provide ability to be Tizen compliant, i.e.
> supporting HTML5/WAC and the application story there and feed back to
> that ecosystem.
> 
> 1) Modularity. A set of architectural components for making devices.
> 
> Rather than dictate the architecture we will support collaboration and
> the flexibility to easily access off-the-shelf components for device
> projects. Component independence permits focused feature and delivery
> management too.
> 
> Initially the project will be developing a Core for basing products on
> and will split UX and hardware adaptations out into seperate projects
> within the community surrounding the Core.
> 
> 2) Working towards an ultra-portable Linux + HTML5/QML/JS Core for
> building products with.
> 
> We have already taken MeeGo and cut it into a set of 302 source
> packages that can boot into a Qt UI along with standard MeeGo stack
> pieces. This work can be seen already at [2] and we've made our first
> release and have had it booting on devices already[6].
> 
> To ease maintenance, we would like to encourage people to participate
> in the Core work of the Tizen project, utilizing their work where we
> can in Mer: why do the same work twice? Even if Tizen turns out to be
> dramatically different, the maintenance load of 302 source packages -
> much of it typical Linux software, is significantly lower than that of
> the 1400 packages found in MeeGo today.
> 
> Using another lesson learned from MeeGo, we also want to port this
> work to everywhere, ARMv6/

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Alberto Mardegan]

Il 10/03/2011 09:01 AM, Carsten Munk ha scritto:

The goal is to find a truly sustainable way for MeeGo and other
interested communities to work with Tizen.

Our solution is the Mer Project:

[...]

That's fantastic! I can't make any promises, as "free time" is an 
obsolete concept for me, but I'll support the project as much as I can.


Thanks guys for driving this!

Ciao,
  Alberto
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[ext-iekku.pylkka]

Hi,

Sounds great! Count me in.

--
Iekku

>-Original Message-
>From: meego-dev-boun...@meego.com [mailto:meego-dev-
>boun...@meego.com] On Behalf Of ext Carsten Munk
>Sent: 03 October, 2011 09:01
>To: meego-dev; meego-comm...@meego.com
>Subject: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction
>for MeeGo
>
>Hi all,
>
>MeeGo is dead ... long live Tizen !! - Haven't we heard that before? - Maemo,
>Moblin?
>
>We need a community that transcends the mere branding of MeeGo,
>Maemo, Moblin - and now Tizen.
>
>A lot of proposals have been put forward:
>* Move to Tizen and trust that "They'll get it right this time"
>* Merge or join some existing projects (like the Qt Project, Debian, openSUSE,
>etc)
>* Keep MeeGo alive by approaching the Linux Foundation
>
>The goal is to find a truly sustainable way for MeeGo and other interested
>communities to work with Tizen.
>
>Our solution is the Mer Project:
>
>How does the concept of a truly open and inclusive integration community for
>devices sound? After all if "upstream is king" - then contributions will end up
>the same place, no matter if it's Tizen, Maemo, MeeGo or openSUSE.
>
>Some history - many of us in MeeGo originated from a project called Mer,
>short for Maemo Reconstructed - where we approached doing a open mobile
>platform through reconstruction of the Maemo platform into a open platform.
>We were big on open governance, open development and open source.
>
>For a few months a group of us have been working on various scenarios of
>change in MeeGo [1] and now that the Tizen news is out in the open, it's time
>to talk about what we as a community can make happen next.
>To make it clear: this is not in any way an anti-Tizen or anti-Intel project, 
>but a
>direction we can and will go in - we strongly want to collaborate with Tizen 
>and
>Intel.
>
>We will continue to welcome contribution and participation from the hacker
>community - in fact we aim to make it so easy to port to a new vendor device
>that a single hacker could do it for their device.
>
>We decided to approach the problems and potential scenarios of change in
>MeeGo in the light of the reallocation of resources caused by what is now
>known as the Tizen work. There have not been any Trunk/1.3 releases since
>August and Tablet UX has totally stalled. What really works (and works quite
>well) is the Core. It's time to take the pieces and use them for 
>reconstruction.
>
>We have some clear goals:
>
>* To be openly developed and openly governed as a meritocracy
>* That primary customers of the platform are device vendors - not end-users.
>* To provide a device manufacturer oriented structure, processes and
>tools: make life easy for them
>* To have a device oriented architecture
>* To be inclusive of technologies (such as MeeGo/Tizen/Qt/EFL/HTML5)
>* To innovate in the mobile OS space
>
>Now we'd like to talk a bit about what specific initiatives we propose to take:
>
>0) Becoming MeeGo 2.0
>
>Our work has the intended goal of being MeeGo 2.0 - and we hope that the
>Linux Foundation will see our work as a worthy succesor within the MeeGo
>spirit. We'd like to provide ability to be Tizen compliant, i.e.
>supporting HTML5/WAC and the application story there and feed back to that
>ecosystem.
>
>1) Modularity. A set of architectural components for making devices.
>
>Rather than dictate the architecture we will support collaboration and the
>flexibility to easily access off-the-shelf components for device projects.
>Component independence permits focused feature and delivery
>management too.
>
>Initially the project will be developing a Core for basing products on and will
>split UX and hardware adaptations out into seperate projects within the
>community surrounding the Core.
>
>2) Working towards an ultra-portable Linux + HTML5/QML/JS Core for building
>products with.
>
>We have already taken MeeGo and cut it into a set of 302 source packages
>that can boot into a Qt UI along with standard MeeGo stack pieces. This work
>can be seen already at [2] and we've made our first release and have had it
>booting on devices already[6].
>
>To ease maintenance, we would like to encourage people to participate in the
>Core work of the Tizen project, utilizing their work where we can in Mer: why
>do the same work twice? Even if Tizen turns out to be dramatically different,
>the maintenance load of 302 source packages - much of it typical Linux
>software, is significantly lower than that of the 1400 packages found in MeeGo
>today.
>
>Using another lesson learned from MeeGo, we also want to port this work to
>everywhere, ARMv6

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Thomas.Rucker]

Hi,

>-Original Message-
>From: Randall Arnold
>
>>From: Carsten Munk 
>>To: meego-dev ; meego-comm...@meego.com
>>Sent: Monday, October 3, 2011 1:01 AM
>>Subject: [MeeGo-dev] MeeGo Reconstructed - a plan of action and
>direction for MeeGo
>>
>>Hi all,
>>
>>MeeGo is dead ... long live Tizen !! - Haven't we heard that before? -
>>Maemo, Moblin?
>>
>>We need a community that transcends the mere branding of MeeGo, Maemo,
>>Moblin - and now Tizen.
>>
>...
>
>>Our solution is the Mer Project:
>>
>
>
>Count me in, Carsten, David and Robin, even if I get involved with other
>projects.

+1 from me

I didn't manage for openMind, but I promise to look into Mer on Archos 
gen6/7/8/9, BeagleBoard, PandaBoard and SnowBall as soon as I recover from this 
head cold and find some spare time. (help welcome!)

Cheers

Thomas
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Randall Arnold]

>

>From: Carsten Munk 
>To: meego-dev ; meego-comm...@meego.com
>Sent: Monday, October 3, 2011 1:01 AM
>Subject: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for 
>MeeGo
>
>Hi all,
>
>MeeGo is dead ... long live Tizen !! - Haven't we heard that before? -
>Maemo, Moblin?
>
>We need a community that transcends the mere branding of MeeGo, Maemo,
>Moblin - and now Tizen.
>
...

>Our solution is the Mer Project:
>


Count me in, Carsten, David and Robin, even if I get involved with other 
projects.

Randall (Randy) Arnold
http://texrat.net
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[martin brook]

Carsten Hi,

Your aims are why I was draw to MeeGo in the first place and its good to see
you aiming even higher.

'We will continue to welcome contribution and participation from the
hacker community - in fact we aim to make it so easy to port to a new
vendor device that a single hacker could do it for their device.'

That's me so count me in.

vgrade

PS thanks for adding the Pi video link

On Mon, Oct 3, 2011 at 7:01 AM, Carsten Munk  wrote:

> Hi all,
>
> MeeGo is dead ... long live Tizen !! - Haven't we heard that before? -
> Maemo, Moblin?
>
> We need a community that transcends the mere branding of MeeGo, Maemo,
> Moblin - and now Tizen.
>
> A lot of proposals have been put forward:
> * Move to Tizen and trust that "They'll get it right this time"
> * Merge or join some existing projects (like the Qt Project, Debian,
> openSUSE, etc)
> * Keep MeeGo alive by approaching the Linux Foundation
>
> The goal is to find a truly sustainable way for MeeGo and other
> interested communities to work with Tizen.
>
> Our solution is the Mer Project:
>
> How does the concept of a truly open and inclusive integration
> community for devices sound? After all if "upstream is king" - then
> contributions will end up the same place, no matter if it's Tizen,
> Maemo, MeeGo or openSUSE.
>
> Some history - many of us in MeeGo originated from a project called
> Mer, short for Maemo Reconstructed - where we approached doing a open
> mobile platform through reconstruction of the Maemo platform into a
> open platform. We were big on open governance, open development and
> open source.
>
> For a few months a group of us have been working on various scenarios
> of change in MeeGo [1] and now that the Tizen news is out in the open,
> it's time to talk about what we as a community can make happen next.
> To make it clear: this is not in any way an anti-Tizen or anti-Intel
> project, but a direction we can and will go in - we strongly want to
> collaborate with Tizen and Intel.
>
> We will continue to welcome contribution and participation from the
> hacker community - in fact we aim to make it so easy to port to a new
> vendor device that a single hacker could do it for their device.
>
> We decided to approach the problems and potential scenarios of change
> in MeeGo in the light of the reallocation of resources caused by what
> is now known as the Tizen work. There have not been any Trunk/1.3
> releases since August and Tablet UX has totally stalled. What really
> works (and works quite well) is the Core. It's time to take the pieces
> and use them for reconstruction.
>
> We have some clear goals:
>
> * To be openly developed and openly governed as a meritocracy
> * That primary customers of the platform are device vendors - not
> end-users.
> * To provide a device manufacturer oriented structure, processes and
> tools: make life easy for them
> * To have a device oriented architecture
> * To be inclusive of technologies (such as MeeGo/Tizen/Qt/EFL/HTML5)
> * To innovate in the mobile OS space
>
> Now we'd like to talk a bit about what specific initiatives we propose to
> take:
>
> 0) Becoming MeeGo 2.0
>
> Our work has the intended goal of being MeeGo 2.0 - and we hope that
> the Linux Foundation will see our work as a worthy succesor within the
> MeeGo spirit. We'd like to provide ability to be Tizen compliant, i.e.
> supporting HTML5/WAC and the application story there and feed back to
> that ecosystem.
>
> 1) Modularity. A set of architectural components for making devices.
>
> Rather than dictate the architecture we will support collaboration and
> the flexibility to easily access off-the-shelf components for device
> projects. Component independence permits focused feature and delivery
> management too.
>
> Initially the project will be developing a Core for basing products on
> and will split UX and hardware adaptations out into seperate projects
> within the community surrounding the Core.
>
> 2) Working towards an ultra-portable Linux + HTML5/QML/JS Core for
> building products with.
>
> We have already taken MeeGo and cut it into a set of 302 source
> packages that can boot into a Qt UI along with standard MeeGo stack
> pieces. This work can be seen already at [2] and we've made our first
> release and have had it booting on devices already[6].
>
> To ease maintenance, we would like to encourage people to participate
> in the Core work of the Tizen project, utilizing their work where we
> can in Mer: why do the same work twice? Even if Tizen turns out to be
> dramatically different, the maintenance load of 302 source packages -
> much of it typical Linux software, is significantly lower than that of
> the 1400 packages found in MeeGo today.
>
> Using another lesson learned from MeeGo, we also want to port this
> work to everywhere, ARMv6/7 - hardfp, softfp, i486, Atom, MIPS, etc -
> allowing much more freedom for porting to new devices.
>
> 3) Change governance towards a more technically oriented one, similar
> to the

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Carsten Munk]

2011/10/3 Timo Härkönen :
>
>
> 2011/10/3 Carsten Munk 
>>
>> Hi all,
>>
>> Our solution is the Mer Project:
>>
>
> Excellent! count me in.
>
> A few questions about the project's communication channels? Do we use these
> MeeGo mailing list, the meego-* IRC channels or are we moving somewhere?
> (IMO moving to mer-specific channels would make sense)

I think for now, we use mer specific channels. Ideally we'd like to
stay within MeeGo community, but for reasons such as trademark usage
and uncertain future, we'd like to earn ability to use MeeGo as a name
through actual effort and merit.

Also, I seem to have learnt that cross posting is bad, seems like I
posted to meego-commits@ as well instead of meego-community.

BR
Carsten Munk
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Timo Härkönen]

2011/10/3 Carsten Munk 

> Hi all,
>
> Our solution is the Mer Project:
>
>
Excellent! count me in.

A few questions about the project's communication channels? Do we use these
MeeGo mailing list, the meego-* IRC channels or are we moving somewhere?
(IMO moving to mer-specific channels would make sense)

-Timo
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

[MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo

[Carsten Munk]

Hi all,

MeeGo is dead ... long live Tizen !! - Haven't we heard that before? -
Maemo, Moblin?

We need a community that transcends the mere branding of MeeGo, Maemo,
Moblin - and now Tizen.

A lot of proposals have been put forward:
* Move to Tizen and trust that "They'll get it right this time"
* Merge or join some existing projects (like the Qt Project, Debian,
openSUSE, etc)
* Keep MeeGo alive by approaching the Linux Foundation

The goal is to find a truly sustainable way for MeeGo and other
interested communities to work with Tizen.

Our solution is the Mer Project:

How does the concept of a truly open and inclusive integration
community for devices sound? After all if "upstream is king" - then
contributions will end up the same place, no matter if it's Tizen,
Maemo, MeeGo or openSUSE.

Some history - many of us in MeeGo originated from a project called
Mer, short for Maemo Reconstructed - where we approached doing a open
mobile platform through reconstruction of the Maemo platform into a
open platform. We were big on open governance, open development and
open source.

For a few months a group of us have been working on various scenarios
of change in MeeGo [1] and now that the Tizen news is out in the open,
it's time to talk about what we as a community can make happen next.
To make it clear: this is not in any way an anti-Tizen or anti-Intel
project, but a direction we can and will go in - we strongly want to
collaborate with Tizen and Intel.

We will continue to welcome contribution and participation from the
hacker community - in fact we aim to make it so easy to port to a new
vendor device that a single hacker could do it for their device.

We decided to approach the problems and potential scenarios of change
in MeeGo in the light of the reallocation of resources caused by what
is now known as the Tizen work. There have not been any Trunk/1.3
releases since August and Tablet UX has totally stalled. What really
works (and works quite well) is the Core. It's time to take the pieces
and use them for reconstruction.

We have some clear goals:

* To be openly developed and openly governed as a meritocracy
* That primary customers of the platform are device vendors - not end-users.
* To provide a device manufacturer oriented structure, processes and
tools: make life easy for them
* To have a device oriented architecture
* To be inclusive of technologies (such as MeeGo/Tizen/Qt/EFL/HTML5)
* To innovate in the mobile OS space

Now we'd like to talk a bit about what specific initiatives we propose to take:

0) Becoming MeeGo 2.0

Our work has the intended goal of being MeeGo 2.0 - and we hope that
the Linux Foundation will see our work as a worthy succesor within the
MeeGo spirit. We'd like to provide ability to be Tizen compliant, i.e.
supporting HTML5/WAC and the application story there and feed back to
that ecosystem.

1) Modularity. A set of architectural components for making devices.

Rather than dictate the architecture we will support collaboration and
the flexibility to easily access off-the-shelf components for device
projects. Component independence permits focused feature and delivery
management too.

Initially the project will be developing a Core for basing products on
and will split UX and hardware adaptations out into seperate projects
within the community surrounding the Core.

2) Working towards an ultra-portable Linux + HTML5/QML/JS Core for
building products with.

We have already taken MeeGo and cut it into a set of 302 source
packages that can boot into a Qt UI along with standard MeeGo stack
pieces. This work can be seen already at [2] and we've made our first
release and have had it booting on devices already[6].

To ease maintenance, we would like to encourage people to participate
in the Core work of the Tizen project, utilizing their work where we
can in Mer: why do the same work twice? Even if Tizen turns out to be
dramatically different, the maintenance load of 302 source packages -
much of it typical Linux software, is significantly lower than that of
the 1400 packages found in MeeGo today.

Using another lesson learned from MeeGo, we also want to port this
work to everywhere, ARMv6/7 - hardfp, softfp, i486, Atom, MIPS, etc -
allowing much more freedom for porting to new devices.

3) Change governance towards a more technically oriented one, similar
to the Yocto Project

We'd like to propose a revamp of governance based upon the Yocto
Project governance - which is much more geared towards open technical
work - encouraging collaboration and discussion. You can look at a
description of this at [3].

4) Work towards better vendor relations and software to support these
as well as easier contribution methods.

As part of our "customer oriented" goal we're improving delivery
methods from Mer. We are designing simpler and more resilient update
mechanisms to support smaller and more distributed organisations
(think outsourcing too!). We want to encourage easy upstream
contribution 

Re: [MeeGo-dev] [MeeGo-community] MeeGo as a vehicle for Qt-based products?

[Michael Hasselmann]

On Sat, 2011-10-01 at 21:29 +, Jarmo Kuronen wrote:
> > I feel as if you over-estimate Intel's software development efforts for
> > MeeGo.
> 
> Lets be realistic, what there is left, really, after N+I has left the 
> building?

Freedom.

___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] [MeeGo-community] MeeGo as a vehicle for Qt-based products?

[Dayo]

On 10/01/2011 10:29 PM, Jarmo Kuronen wrote:

I feel as if you over-estimate Intel's software development efforts for
MeeGo.

Lets be realistic, what there is left, really, after N+I has left the building?

- Jarmo
___

How about the MeeGo community?
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] [MeeGo-community] MeeGo as a vehicle for Qt-based products?

[Jarmo Kuronen]

> I feel as if you over-estimate Intel's software development efforts for
> MeeGo.

Lets be realistic, what there is left, really, after N+I has left the building?

- Jarmo
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] [MeeGo-community] MeeGo as a vehicle for Qt-based products?

[Kok, Auke-jan H]

On Sat, Oct 1, 2011 at 8:49 AM, Gabriel Beddingfield  wrote:
> On Sat, Oct 1, 2011 at 10:20 AM, Michael Hasselmann
>  wrote:
>> On Sat, 2011-10-01 at 10:13 -0500, Gabriel Beddingfield wrote:
>>> With Intel removing the lion's share of those developer resources...
>>> it would be foolish to continue that failed approach.  It sets
>>> everyone up for failure.
>>
>> I feel as if you over-estimate Intel's software development efforts for
>> MeeGo.
>
> Well... MeeGo loses Auke... and that's pretty darn big IMHO.  :-)
>
> I'm not going to bicker over head count or even quality.  You wanna
> support 5 verticals, go ahead.  Make us all proud.  I think it's a
> plan for failure.
>
> 
> I'm all talk.  At this moment, and for the past few months, I can't
> commit any time to MeeGo (or even Tizen).  But I really dig MeeGo for
> several reasons... mostly the native/Qt API's... so I hope(d) to see
> it succeed as a main-stream mobile OS.
> 

Heh, I'm honored to be missed already, but, I'm not exactly gone just yet.

Personally, I have about as many unanswered questions as anyone out
there, which is partially why I haven't chimed in to any of the
discussions recently. The other reason is that I've been on a 2-week
vacation :-)

As what this means to MeeGo, I'm not entirely sure and I've been
asking questions. We most definitely have customers that will be
getting part of my time to support their current MeeGo products, so
meego.com isn't about to disappear. What exactly it means for the long
run, and especially for the community, unfortunately I don't know
either. See also the post from Stefano earlier.

I've been asking the same questions as everyone else. If I get answers
back that I can share, I most certainly will. For now, I'd like to ask
everyone to submit questions to Dawn Foster, and keep asking. Answers
will come - be patient.

Auke
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] [MeeGo-community] MeeGo as a vehicle for Qt-based products?

[Luis Araujo]

On 10/01/2011 11:19 AM, Gabriel Beddingfield wrote:

On Sat, Oct 1, 2011 at 10:20 AM, Michael Hasselmann
  wrote:

On Sat, 2011-10-01 at 10:13 -0500, Gabriel Beddingfield wrote:

With Intel removing the lion's share of those developer resources...
it would be foolish to continue that failed approach.  It sets
everyone up for failure.

I feel as if you over-estimate Intel's software development efforts for
MeeGo.

Well... MeeGo loses Auke... and that's pretty darn big IMHO.  :-)

I'm not going to bicker over head count or even quality.  You wanna
support 5 verticals, go ahead.  Make us all proud.  I think it's a
plan for failure.

Why so much fuss about the different verticals?

This is up to the interest of the different volunteers, if someone wants 
to work in a specific area, let it be; as long as there exist certain 
coordination and a modular way of communication between the groups (as I 
earlier proposed), everything should be fine, there is no need to set in 
stone the exclusion of any of the verticals, or exclusively narrow down 
MeeGo to a single one.



   --- Luis

___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] [MeeGo-community] MeeGo as a vehicle for Qt-based products?

[George Ingram]

All your missing is the free food and conferences, and the advocates that
did very little anyway other than make interesting comments anyway...

George Ingram Computer Scientist
Winner Intel Coders Challenge 2010
http://www.linkedin.com/in/georgeingramcom/

503 East Nifong Blvd I Suite 167
Columbia Missouri 65201-3792

Voice 804-464-7257


-Original Message-
From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On
Behalf Of Gabriel Beddingfield
Sent: Saturday, October 01, 2011 10:13 AM
To: Dayo
Cc: meego-dev@meego.com
Subject: Re: [MeeGo-dev] [MeeGo-community] MeeGo as a vehicle for Qt-based
products?

On Sat, Oct 1, 2011 at 7:56 AM, Dayo  wrote:
>>>
>>> Fine... pick IVI.  Pick *something*.
>>>
>>> MeeGo's complexity ({Netbook,Handset,IVI,Tablet} x {i586,armv7} x
>>> {MeeGoCompliance,PlatformCompliance,DeviceCompliance}) was 
>>> apparently too much to bear even with corporate sponsorship.  If you 
>>> continue as a community project, it's important to narrow this down 
>>> in order to succeed.
>>
>> ++1 That is why I said so the first place. Trying to do everything 
>> ++and
>> in the same time proved us very wrong.
>>
> I don't see a problem with keeping the various implementations of 
> MeeGo alive, if there are people interested in contributing to them. 
> Naturally, if a project receives no active contributions it goes stale 
> and dies, but why kill it preemptively?

Many of us believe that supporting all the verticals and profiles failed
because it fragmented developers... and there were not enough developers to
support it all.  I honestly believe that it is a large reason why MeeGo has
been more or less floundering.


With Intel removing the lion's share of those developer resources...
it would be foolish to continue that failed approach.  It sets everyone up
for failure.

By re-focusing the goals to ONE THING... the hard-to-rely-on community
development model (*cough*Debian*cough*) has a reasonable chance of
accomplishing those goals.  Once achieved, you may find room to re-add those
other verticals on top of a stable foundation.

-gabriel
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines


___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] [MeeGo-community] MeeGo as a vehicle for Qt-based products?

[George Ingram]

Code is Code is code, move your repos into a different eco-system that runs on 
top of the open linix kernel, and beam yourself up dude & dudettes, Best George

George Ingram Computer Scientist
Winner Intel Coders Challenge 2010
http://www.linkedin.com/in/georgeingramcom/

503 East Nifong Blvd I Suite 167
Columbia Missouri 65201-3792

Voice 804-464-7257

-Original Message-
From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On 
Behalf Of Angel Perles
Sent: Saturday, October 01, 2011 10:15 AM
To: meego-dev@meego.com
Subject: Re: [MeeGo-dev] [MeeGo-community] MeeGo as a vehicle for Qt-based 
products?


I consider that a kind of reference UI experience and "demo" is fundamental for 
Meego. Probably a good starting point could be the incorporation of KDE + 
Wayland in this area.

Also, it could be interesting to talk to guys at projects like Openmoko, GPE, 
etc to join efforts and to avoid fragmentation of efforts.


An important issue is the lack of drivers from modern pieces of 
hardware, for example TIs OMAP 3xxx has not public drivers (open or 
closed) for hardfp's ARM Meego 1.2.

Hardware manufactures (TI, Qualcom, Samsung, ...) must deal with the 
requisites of its customers (Nokia, Microsoft, Google, Samsung-2, ...) 
and not provide drivers for this kind of projects.

As we all assume, Microsoft has blocked Meego project with its alliance 
with Nokia. Well done, Microsoft.

Its is not necesary to continue with the name of Meego, it could be
something similar to OpenOffice->FreeOffice. If "trademark" problems.


Regards,
Àngel




El 29/09/11 17:37, Robin Burchell escribió:
> Hi,
>
> On Thu, Sep 29, 2011 at 5:20 PM, Nasa  wrote:
>>> So I'll shed some light on how I see this and how we should proceed:
>>>
>>> 1) Concentrate on the handset and *ONLY* on it from now onward. "Do
>>> one thing and do it best (tm)".
>>>
>>
>> Why would you exclude 4/5 of the people involved in the meego project?
>> Handsets weren't even the largest part of the project...
>
> Personal area of interest, perhaps. Anyway, we don't need to exclude
> anyone here - anyone can come and play ball. In my view of the ideal
> MeeGo universe, UX is entirely seperate projects from MeeGo itself -
> MeeGo Core is just the basics needed to boot and get to a display,
> hardware adaptations and user interfaces are outside of scope there.
>
> All the best,
>
> Robin
> ___
> MeeGo-dev mailing list
> MeeGo-dev@meego.com
> http://lists.meego.com/listinfo/meego-dev
> http://wiki.meego.com/Mailing_list_guidelines
>

-- 

*
Angel F. Perles Ivars

Departament d'Informàtica de Sistemes i Computadors - DISCA
Universitat Politècnica de València - E.U.Informàtica
Cami de Vera s/n. 46022-Valencia
Edifici 1G Despatx 2S-13
e-mail: aper...@disca.upv.es
Telf.+34 963877007 Ext. 75775 Fax.+34 963877579
http://www.disca.upv.es/aperles
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines


___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] [MeeGo-community] MeeGo as a vehicle for Qt-based products?

[Gabriel Beddingfield]

On Sat, Oct 1, 2011 at 10:20 AM, Michael Hasselmann
 wrote:
> On Sat, 2011-10-01 at 10:13 -0500, Gabriel Beddingfield wrote:
>> With Intel removing the lion's share of those developer resources...
>> it would be foolish to continue that failed approach.  It sets
>> everyone up for failure.
>
> I feel as if you over-estimate Intel's software development efforts for
> MeeGo.

Well... MeeGo loses Auke... and that's pretty darn big IMHO.  :-)

I'm not going to bicker over head count or even quality.  You wanna
support 5 verticals, go ahead.  Make us all proud.  I think it's a
plan for failure.


I'm all talk.  At this moment, and for the past few months, I can't
commit any time to MeeGo (or even Tizen).  But I really dig MeeGo for
several reasons... mostly the native/Qt API's... so I hope(d) to see
it succeed as a main-stream mobile OS.


-gabriel
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] [MeeGo-community] MeeGo as a vehicle for Qt-based products?

[Dayo]

On 10/01/2011 04:13 PM, Gabriel Beddingfield wrote:

On Sat, Oct 1, 2011 at 7:56 AM, Dayo  wrote:

Fine... pick IVI.  Pick *something*.

MeeGo's complexity ({Netbook,Handset,IVI,Tablet} x {i586,armv7} x
{MeeGoCompliance,PlatformCompliance,DeviceCompliance}) was apparently too
much to bear even with corporate sponsorship.  If you continue as a
community project, it's important to narrow this down in order to
succeed.

++1 That is why I said so the first place. Trying to do everything and
in the same time proved us very wrong.


I don't see a problem with keeping the various implementations of MeeGo
alive, if there are people interested in contributing to them. Naturally, if
a project receives no active contributions it goes stale and dies, but why
kill it preemptively?

Many of us believe that supporting all the verticals and profiles
failed because it fragmented developers... and there were not enough
developers to support it all.  I honestly believe that it is a large
reason why MeeGo has been more or less floundering.

With Intel removing the lion's share of those developer resources...
it would be foolish to continue that failed approach.  It sets
everyone up for failure.

By re-focusing the goals to ONE THING... the hard-to-rely-on community
development model (*cough*Debian*cough*) has a reasonable chance of
accomplishing those goals.  Once achieved, you may find room to re-add
those other verticals on top of a stable foundation.

-gabriel

I don't understand what you mean by fragmented developers. There are 
developers working on various MeeGo implementations, due to their 
interests in the respective implementations. I don't see how that can be 
called fragmentation. Fragmentation would be, e.g. if you had several 
developers working on different variations of the same GSM modules.


If there are developers currently working on handset, and they wish to 
continue this work, then let them. If there are developers currently 
working on tablet or IVI, and they want to keep developing for these, 
then why stop them? Closing off access to various portions of what is 
supposed to be an open-source project is counterintuitive, especially at 
a time when MeeGo has been abandonned by Nokia/Intel.


What we need now more than ever is to *attract* active development, not 
stifle it.


Dayo
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] [MeeGo-community] MeeGo as a vehicle for Qt-based products?

[Michael Hasselmann]

On Sat, 2011-10-01 at 10:13 -0500, Gabriel Beddingfield wrote:
> With Intel removing the lion's share of those developer resources...
> it would be foolish to continue that failed approach.  It sets
> everyone up for failure.

I feel as if you over-estimate Intel's software development efforts for
MeeGo.

regards,
Michael

___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] [MeeGo-community] MeeGo as a vehicle for Qt-based products?

[Angel Perles]

I consider that a kind of reference UI experience and "demo" is 
fundamental for Meego. Probably a good starting point could be the 
incorporation of KDE + Wayland in this area.


Also, it could be interesting to talk to guys at projects like Openmoko, 
GPE, etc to join efforts and to avoid fragmentation of efforts.



An important issue is the lack of drivers from modern pieces of 
hardware, for example TIs OMAP 3xxx has not public drivers (open or 
closed) for hardfp's ARM Meego 1.2.


Hardware manufactures (TI, Qualcom, Samsung, ...) must deal with the 
requisites of its customers (Nokia, Microsoft, Google, Samsung-2, ...) 
and not provide drivers for this kind of projects.


As we all assume, Microsoft has blocked Meego project with its alliance 
with Nokia. Well done, Microsoft.


Its is not necesary to continue with the name of Meego, it could be
something similar to OpenOffice->FreeOffice. If "trademark" problems.


Regards,
Àngel




El 29/09/11 17:37, Robin Burchell escribió:

Hi,

On Thu, Sep 29, 2011 at 5:20 PM, Nasa  wrote:

So I'll shed some light on how I see this and how we should proceed:

1) Concentrate on the handset and *ONLY* on it from now onward. "Do
one thing and do it best (tm)".



Why would you exclude 4/5 of the people involved in the meego project?
Handsets weren't even the largest part of the project...


Personal area of interest, perhaps. Anyway, we don't need to exclude
anyone here - anyone can come and play ball. In my view of the ideal
MeeGo universe, UX is entirely seperate projects from MeeGo itself -
MeeGo Core is just the basics needed to boot and get to a display,
hardware adaptations and user interfaces are outside of scope there.

All the best,

Robin
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines



--

*
Angel F. Perles Ivars

Departament d'Informàtica de Sistemes i Computadors - DISCA
Universitat Politècnica de València - E.U.Informàtica
Cami de Vera s/n. 46022-Valencia
Edifici 1G Despatx 2S-13
e-mail: aper...@disca.upv.es
Telf.+34 963877007 Ext. 75775 Fax.+34 963877579
http://www.disca.upv.es/aperles
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] [MeeGo-community] MeeGo as a vehicle for Qt-based products?

[Gabriel Beddingfield]

On Sat, Oct 1, 2011 at 7:56 AM, Dayo  wrote:
>>>
>>> Fine... pick IVI.  Pick *something*.
>>>
>>> MeeGo's complexity ({Netbook,Handset,IVI,Tablet} x {i586,armv7} x
>>> {MeeGoCompliance,PlatformCompliance,DeviceCompliance}) was apparently too
>>> much to bear even with corporate sponsorship.  If you continue as a
>>> community project, it's important to narrow this down in order to
>>> succeed.
>>
>> ++1 That is why I said so the first place. Trying to do everything and
>> in the same time proved us very wrong.
>>
> I don't see a problem with keeping the various implementations of MeeGo
> alive, if there are people interested in contributing to them. Naturally, if
> a project receives no active contributions it goes stale and dies, but why
> kill it preemptively?

Many of us believe that supporting all the verticals and profiles
failed because it fragmented developers... and there were not enough
developers to support it all.  I honestly believe that it is a large
reason why MeeGo has been more or less floundering.

With Intel removing the lion's share of those developer resources...
it would be foolish to continue that failed approach.  It sets
everyone up for failure.

By re-focusing the goals to ONE THING... the hard-to-rely-on community
development model (*cough*Debian*cough*) has a reasonable chance of
accomplishing those goals.  Once achieved, you may find room to re-add
those other verticals on top of a stable foundation.

-gabriel
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo...

[Angel Perles]

El 29/09/11 02:39, Leonardo Luiz Padovani da Mata escribió:

"Burned me once, that's ok, burned me twice, fine, but the third time
(after speaking about Meego in some other engagements)?  You've got to
have a pretty good reason why I'm gonna trust this new development."

+one with the same feeling.




Oh my God! Also the same feeling!.

But I'm sure I will continue with Qt.

(A developer encouraged to swicth to Android, but happy using Maemo's 5 
N900).




___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] [MeeGo-community] MeeGo as a vehicle for Qt-based products?

[Dayo]

On 10/01/2011 12:53 PM, Sivan Greenberg wrote:

On Sat, Oct 1, 2011 at 2:28 PM, Gabriel Beddingfield  wrote:

On 09/29/2011 10:20 AM, Nasa wrote:



1) Concentrate on the handset and *ONLY* on it from now onward. "Do
one thing and do it best (tm)".


Why would you exclude 4/5 of the people involved in the meego project?
Handsets weren't even the largest part of the project...

Fine... pick IVI.  Pick *something*.

MeeGo's complexity ({Netbook,Handset,IVI,Tablet} x {i586,armv7} x
{MeeGoCompliance,PlatformCompliance,DeviceCompliance}) was apparently too
much to bear even with corporate sponsorship.  If you continue as a
community project, it's important to narrow this down in order to succeed.

++1 That is why I said so the first place. Trying to do everything and
in the same time proved us very wrong.

-Sivan
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

I don't see a problem with keeping the various implementations of MeeGo 
alive, if there are people interested in contributing to them. 
Naturally, if a project receives no active contributions it goes stale 
and dies, but why kill it preemptively?


Dayo
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] [MeeGo-community] MeeGo as a vehicle for Qt-based products?

[kate.alhola]

On Oct 1, 2011, at 2:28 PM, ext Gabriel Beddingfield wrote:

> On 09/29/2011 10:20 AM, Nasa wrote:
>> 
>> 
>>> 1) Concentrate on the handset and *ONLY* on it from now onward. "Do
>>> one thing and do it best (tm)".
>>> 
>> 
>> Why would you exclude 4/5 of the people involved in the meego project?
>> Handsets weren't even the largest part of the project...
> 
> Fine... pick IVI.  Pick *something*.
> 
> MeeGo's complexity ({Netbook,Handset,IVI,Tablet} x {i586,armv7} x 
> {MeeGoCompliance,PlatformCompliance,DeviceCompliance}) was apparently too 
> much to bear even with corporate sponsorship.  If you continue as a community 
> project, it's important to narrow this down in order to succeed.


Just as my personal opinion as OSS hacker that has nothing to do with my 
employer.

Let's first divide MeeGo as horizontal layers.
1- Mobile Qt / QtQuick /QtQuick based applications
2- Mobile UX
3- Foundation layers ( Linux kernel and most of middleware)

1, Mobile Qt apps, there will be big future and Intel decision did not change 
anything, there is community that would like to develop these apps and there 
are many platforms able to run them,MeeGo from MeeGo project , MeeGo 
Harmattan/N9, Symbian, Android, Tizen and Nokia's "Next Billion" project. 
having community for mobile Qt development together is good reason to be 
existing. 

2. MeeGo offers only full Open Source Mobile UX. Tizen don't need it but 
OpenSuse proposal was interesting.  using MeeGo UX, we could make mobile 
distros based on OpenSuse, Ubuntu and others. I don't see any reason continue 
Netbook, there are already Ubuntu etc and MeeGo has very little to offer. IVI 
is car manufacturer driven, if they are interested and continues sponsor MeeGo, 
it is OK.  Handsets, full open handsets that allow installing your own OS are 
rare, so it is relatively small field. Tablets I see best target for MeeGo. 
Intel abandoned MeeGo and they were driving tablet, we can make better tablet 
UX based on MeeGo handset UX. Combining forces with other Linux distros we can 
make competitive alternative distro for tablets. 

3- In this area, I don't see any reason duplicate work that ids already done 
with other distros.

We can think that 1, Mobile Qt apps will be there and there will be lot of 
developers doing it. MeeGo and Maemo were already Mobile app developers 
community so that we can still be. Good question is even closer relation with 
KDE community.

As my personal opinion we should have OSS distro for tablets as alternative. In 
case I would have x86 tablet, I won't even consider Windows7 or even Windows8. 
In this area we have clear common interest with desktop linux distros. They 
have everything else but they are lacking mobile UX and MeeGo is only one that 
can offer it. When MeeGo was corporate driven and building full distro, it did 
not need them but as OSS project there are common interests.


Kate 


___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] [MeeGo-community] MeeGo as a vehicle for Qt-based products?

[Sivan Greenberg]

On Sat, Oct 1, 2011 at 2:28 PM, Gabriel Beddingfield  wrote:
> On 09/29/2011 10:20 AM, Nasa wrote:
>>
>>
>>> 1) Concentrate on the handset and *ONLY* on it from now onward. "Do
>>> one thing and do it best (tm)".
>>>
>>
>> Why would you exclude 4/5 of the people involved in the meego project?
>> Handsets weren't even the largest part of the project...
>
> Fine... pick IVI.  Pick *something*.
>
> MeeGo's complexity ({Netbook,Handset,IVI,Tablet} x {i586,armv7} x
> {MeeGoCompliance,PlatformCompliance,DeviceCompliance}) was apparently too
> much to bear even with corporate sponsorship.  If you continue as a
> community project, it's important to narrow this down in order to succeed.

++1 That is why I said so the first place. Trying to do everything and
in the same time proved us very wrong.

-Sivan
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] [MeeGo-community] MeeGo as a vehicle for Qt-based products?

[Luis Araujo]

On 10/01/2011 06:58 AM, Gabriel Beddingfield wrote:

On 09/29/2011 10:20 AM, Nasa wrote:




1) Concentrate on the handset and *ONLY* on it from now onward. "Do
one thing and do it best (tm)".



Why would you exclude 4/5 of the people involved in the meego project?
Handsets weren't even the largest part of the project...


Fine... pick IVI.  Pick *something*.

MeeGo's complexity ({Netbook,Handset,IVI,Tablet} x {i586,armv7} x 
{MeeGoCompliance,PlatformCompliance,DeviceCompliance}) was apparently 
too much to bear even with corporate sponsorship.  If you continue as 
a community project, it's important to narrow this down in order to 
succeed.


-gabriel


I think this is pretty much up to the people/groups interested in the 
different verticals.


Now, I think most of the current volunteers interests are focused on 
handsets and some part in tablets too, but that is different and there 
is no need to set in stone a decision about excluding anything; let 
people volunteering for what they want.


What could be a change and improvement, in my opinion, is to find a 
better way of communication through the different verticals, probably in 
a more modular way.



   --- Luis
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] [MeeGo-community] MeeGo as a vehicle for Qt-based products?

[Gabriel Beddingfield]

On 09/29/2011 10:20 AM, Nasa wrote:




1) Concentrate on the handset and *ONLY* on it from now onward. "Do
one thing and do it best (tm)".



Why would you exclude 4/5 of the people involved in the meego project?
Handsets weren't even the largest part of the project...


Fine... pick IVI.  Pick *something*.

MeeGo's complexity ({Netbook,Handset,IVI,Tablet} x {i586,armv7} x 
{MeeGoCompliance,PlatformCompliance,DeviceCompliance}) was apparently 
too much to bear even with corporate sponsorship.  If you continue as a 
community project, it's important to narrow this down in order to succeed.


-gabriel
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo as a vehicle for Qt-based products?

[Luis Araujo]

On 09/29/2011 09:33 AM, Robin Burchell wrote:

So Intel has upped and gone Tizen. What I wonder is: does this have to
actually spell the end of MeeGo?

Definitely not.

MeeGo has been intended as an open source project since the very 
beginning, and that means: let's keep the ball rolling.



In the past few days, we have seen that there is definitely a
community of individuals wanting to continue building products using
Qt (or simply writing apps using Qt on mobile), and MeeGo Core was a
good vehicle to enable making that happen. I wonder what the wider
community thinks about continuing work on MeeGo, if necessary, without
Intel - perhaps theoretically aligning with Tizen to minimise workload
(&  share apps) if possible.

I think the community is really interested on continuing this work, and 
as we most of all clearly know, MeeGo being an open source platform, 
then why not? ... this shouldn't stop _anyone_ interested on MeeGo to 
continue its development, deployment or even evangelization ;)


In this thread, we have already seen how some users have pointed out 
interest for that to happen, and also the interest that certain 
companies and even external projects have towards MeeGo, so my opinion 
is just welcome all that support and invitations, and let the symbiosis 
begin.


About Tizen, well, I guess we need to wait until they release further 
information about it (according to its website front page, within the 
upcoming weeks), and that way we can know better how MeeGo could 
cooperate and benefit from Tizen, we then would define the kind of 
symbiosis we want with such a project. they also "promise" an easy 
transition for MeeGo developers and users, so this is a very good sign, 
if it is like it sounds , I think both projects could really gain a lot.



Obviously, we'd probably need to rethink some things like project
governance, infrastructure, etc - but provided these can be solved,
what do you all think? Can it be business as usual?

Of course, the current situation does change the scenario, we would need 
to re-think many things now, but hey, this isn't necessarily a bad 
thing, this could even be a great and good thing to do, in my opinion, 
this is the time to discuss more openly the road the community wants 
MeeGo to take  this might also be the perfect time to address any 
issue we have wanted to change or improve for some time .. This is 
the Time  :)


One thing I really would like to see it is some kind of announcement 
about the current project in the general technical level,  code, 
packages, OBS, infra, docs, translations, wiki pages  what will 
happen with all this?, for how long the infra machines will be 
available?, how about OBS access to Core repos?, Do we still need it or 
we can do fine mirroring everything in a community server and working 
from there?, what about the web pages? ... and so on and so on ... , 
MeeGo lifespan has been small, compared with other open source community 
projects, but in my opinion its contribution has been really big for the 
community itself in many aspects, and we should try to include all we 
can during this transition (if possible, and as long as someone is 
interested to do that work).




   --- Luis
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo as a vehicle for Qt-based products?

[quim.gil]

About the original point in the subject of this thread: a Tizen architecture 
draft would be useful in order to know what to do. Even a markitecture diagram 
would help. Without that it's difficult to discuss the best approach for Qt in 
relation to Tizen releases and/or future MeeGo.

Apart from the scarce  official information, the only interesting Qt related 
detail is Nomovok saying that they can offer Qt integrated to Tizen. From there 
I understand that there is somewhere enough technical information available to 
make such a decision. That is exactly the same information Robin and other 
developers and stakeholders would need in order to make the right decisions.

Qt is cutting edge technology and for the Qt Project mobile Linux is an 
essential platform. If Tizen becomes a cutting edge mobile Linux platform and 
if Qt can technically run there, then it makes sense to think that someone will 
work on Qt support for Tizen releases. However, I enjoy speculation as little 
as you do and with the current lack of information this assumption is probably 
as far as we can go.

--
Quim 
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] [MeeGo-community] MeeGo as a vehicle for Qt-based products?

[Sivan Greenberg]

On Thu, Sep 29, 2011 at 6:37 PM, Robin Burchell
 wrote:
> Hi,
>
> On Thu, Sep 29, 2011 at 5:20 PM, Nasa  wrote:
>>> So I'll shed some light on how I see this and how we should proceed:
>>>
>>> 1) Concentrate on the handset and *ONLY* on it from now onward. "Do
>>> one thing and do it best (tm)".
>>>
>>
>> Why would you exclude 4/5 of the people involved in the meego project?
>> Handsets weren't even the largest part of the project...
>
> Personal area of interest, perhaps. Anyway, we don't need to exclude
> anyone here - anyone can come and play ball. In my view of the ideal
> MeeGo universe, UX is entirely seperate projects from MeeGo itself -
> MeeGo Core is just the basics needed to boot and get to a display,
> hardware adaptations and user interfaces are outside of scope there.

Personal area of interest, nobody should be excluded but I think we
should consider managing the verticals team in a way that would enable
each of them to progress without being delayed for parts they don't
really need to use on the core, so for instance, tablet should not be
delayed for GSM modem code and vice versa for handset if they do not
need it for operation.

-- 
-Sivan
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] [MeeGo-community] MeeGo as a vehicle for Qt-based products?

[Andrew Flegg]

On Thu, Sep 29, 2011 at 16:37, Robin Burchell  wrote:
>
> Personal area of interest, perhaps. Anyway, we don't need to exclude
> anyone here - anyone can come and play ball. In my view of the ideal
> MeeGo universe, UX is entirely seperate projects from MeeGo itself -
> MeeGo Core is just the basics needed to boot and get to a display,
> hardware adaptations and user interfaces are outside of scope there.

Agreed entirely; and this is why "Blueprint" wasn't a blog post - but
instead the foundation of a living document.

IMHO, one of the problems MeeGo suffered from was a lack of clarity on
team responsibilities. Address that, the Governance and the direction,
and we should be able to make something attractive to vendors (and
contributors).

Cheers,

Andrew

-- 
Andrew Flegg -- mailto:and...@bleb.org  |  http://www.bleb.org/
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] [MeeGo-community] MeeGo as a vehicle for Qt-based products?

[Robin Burchell]

Hi,

On Thu, Sep 29, 2011 at 5:20 PM, Nasa  wrote:
>> So I'll shed some light on how I see this and how we should proceed:
>>
>> 1) Concentrate on the handset and *ONLY* on it from now onward. "Do
>> one thing and do it best (tm)".
>>
>
> Why would you exclude 4/5 of the people involved in the meego project?
> Handsets weren't even the largest part of the project...

Personal area of interest, perhaps. Anyway, we don't need to exclude
anyone here - anyone can come and play ball. In my view of the ideal
MeeGo universe, UX is entirely seperate projects from MeeGo itself -
MeeGo Core is just the basics needed to boot and get to a display,
hardware adaptations and user interfaces are outside of scope there.

All the best,

Robin
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] [MeeGo-community] MeeGo as a vehicle for Qt-based products?

[Nasa]

- Original Message -
> On Thu, Sep 29, 2011 at 5:03 PM, Robin Burchell
>  wrote:
> > Obviously, we'd probably need to rethink some things like project
> > governance, infrastructure, etc - but provided these can be solved,
> > what do you all think? Can it be business as usual?
> >
> I believe so. In fact I think this could actually enable us to create
> a true open base truly governed by community perhaps similar to the Qt
> Open Governance project. I think we should align with Qt releases as
> much as we can as our *core* app dev technology. Through concentrating
> on rocking Qt support, we earn a lot of great technologies (including
> HTML5 if I read right the Qt5 direction) not to mention great SDK and
> documentation to engage and attract veteran and new developers. (I get
> people asking me all the time how to use Qt on Android, as the native
> tools for them more often then not do not provide the experience they
> know or heard of about Qt)
> 
> So I'll shed some light on how I see this and how we should proceed:
> 
> 1) Concentrate on the handset and *ONLY* on it from now onward. "Do
> one thing and do it best (tm)".
> 

Why would you exclude 4/5 of the people involved in the meego project?
Handsets weren't even the largest part of the project...

Because Meego netbooks are "fairly well-established," Intel will add APIs 
(application programming interfaces) to ensure applications written for them 
will work in Tizen, said Imad Sousou, director of the Intel Open Source 
Technology Center. Asus, Dell, Acer, Lenovo, HP and Toshiba have made Meego 
devices, but they have only a minimal presence in the market.

"On mobile, obviously, the situation is different in terms of deployment," 
Sousou said. Since there are few Meego phones in use, Intel has decided not to 
encumber Tizen with legacy APIs, he said.

Nasa

> 2) Invite contacts from any handset mfct. interested to tell us their
> requirements and what would make it attractive for them to use as a
> base and try to respond to these. Nokia seems the first natural
> company I would like to talk to. (Admittedly as a passionate Nokia
> fan, I would love to try and do something that would help Nokia to
> produce the next Linux phone if they ever want to do this again.
> People who are fans of other vendors could do the same)
> 
> 3) Vendor involvement is only through having contacts but they do not
> steer the project, unless getting into steering based by merit and
> proving skills. Community steers it. They can make suggestion and help
> in implementation but through the normal community channels, as a
> community contributor. No precedence or short-lanes to vendors and
> participation rights are based *only* on merit.
> 
> 
> Related to (2) I talked with Qualcomm people back then before SF2011
> (we were supposed to meet in SF) about MeeGo but there was some
> concerns back then due to the heavy vendor steering, perhaps now we
> could invite them aboard, presenting a pure community project.
> 
> These are some steps I think we could take, I would propose to see how
> we can align as best with Qt Open Gov now and follow their governance
> structure.
> 
> -Sivan
> ___
> MeeGo-dev mailing list
> MeeGo-dev@meego.com
> http://lists.meego.com/listinfo/meego-dev
> http://wiki.meego.com/Mailing_list_guidelines
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] [MeeGo-community] MeeGo as a vehicle for Qt-based products?

[Sivan Greenberg]

On Thu, Sep 29, 2011 at 5:03 PM, Robin Burchell
 wrote:
> Obviously, we'd probably need to rethink some things like project
> governance, infrastructure, etc - but provided these can be solved,
> what do you all think? Can it be business as usual?
>
I believe so. In fact I think this could actually enable us to create
a true open base truly governed by community perhaps similar to the Qt
Open Governance project. I think we should align with Qt releases as
much as we can as our *core* app dev technology. Through concentrating
on rocking Qt support, we earn a lot of great technologies (including
HTML5 if I read right the Qt5 direction) not to mention great SDK and
documentation to engage and attract veteran and new developers. (I get
people asking me all the time how to use Qt on Android, as the native
tools for them more often then not do not provide the experience they
know or heard of about Qt)

So I'll shed some light on how I see this and how we should proceed:

1) Concentrate on the handset and *ONLY* on it from now onward. "Do
one thing and do it best (tm)".

2) Invite contacts from any handset mfct. interested to tell us their
requirements and what would make it attractive for them to use as  a
base and try to respond to these. Nokia seems the first natural
company I would like to talk to. (Admittedly  as a passionate Nokia
fan, I would love to try and do something that would help Nokia to
produce the next Linux phone if they ever want to do this again.
People who are fans of other vendors could do the same)

3) Vendor involvement is only through having contacts but they do not
steer the project, unless getting into steering based by merit and
proving skills. Community steers it. They can make suggestion and help
in implementation but through the normal community channels, as a
community contributor. No precedence or short-lanes to vendors and
participation rights are based *only* on  merit.


Related to (2) I talked with Qualcomm people back then before SF2011
(we were supposed to meet in SF) about MeeGo but there was some
concerns back then due to the heavy vendor steering, perhaps now we
could invite them aboard, presenting a pure community project.

These are some steps I think we could take, I would propose to see how
we can align as best with Qt Open Gov now and follow their governance
structure.

-Sivan
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] [MeeGo-community] MeeGo as a vehicle for Qt-based products?

[Andrew Flegg]

On Thu, Sep 29, 2011 at 15:03, Robin Burchell  wrote:
> So Intel has upped and gone Tizen. What I wonder is: does this have to
> actually spell the end of MeeGo?

No, but as you address - infrastructure is one of the biggest things.
How long until LF/Intel turn off *.meego.com?

> Obviously, we'd probably need to rethink some things like project
> governance, infrastructure, etc - but provided these can be solved,
> what do you all think? Can it be business as usual?

My governance proposal:

http://wiki.meego.com/Blueprint

Of course, that assumed that there were developers working on Core
outside of this governance proposal. We'd also want something around
trademarks...

Comments welcome.

Cheers,

Andrew

-- 
Andrew Flegg -- mailto:and...@bleb.org  |  http://www.bleb.org/
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

[MeeGo-dev] MeeGo as a vehicle for Qt-based products?

[Robin Burchell]

So Intel has upped and gone Tizen. What I wonder is: does this have to
actually spell the end of MeeGo?

In the past few days, we have seen that there is definitely a
community of individuals wanting to continue building products using
Qt (or simply writing apps using Qt on mobile), and MeeGo Core was a
good vehicle to enable making that happen. I wonder what the wider
community thinks about continuing work on MeeGo, if necessary, without
Intel - perhaps theoretically aligning with Tizen to minimise workload
(& share apps) if possible.

Obviously, we'd probably need to rethink some things like project
governance, infrastructure, etc - but provided these can be solved,
what do you all think? Can it be business as usual?

(I'm cross-posting to make sure the best audience sees this, but
please, let's keep discussion on meego-community@)

Best regards,

Robin
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo...

[Jeremiah Foster]

On Thu, Sep 29, 2011 at 7:07 AM, Peter Jespersen wrote:

> Den 29-09-2011 00:46, Clint Christopher Cañada skrev:
>
>  It's kinda disappointing though with what's happening.  Burned me once,
>> that's ok, burned me twice, fine, but the third time (after speaking about
>> Meego in some other engagements)?  You've got to have a pretty good reason
>> why I'm gonna trust this new development.
>>
>
> Got the same feeling here
>
> In short why ?
>
> Is this a way to make further distance from Nokia (Qt) via a rebranding ?
>
> Is it because you feel that MeeGo is getting nowehere (even though real
> units has seen the light of day) and that LiMo has a better chance (better
> support from hardware manufacturers) ?
>
> Is it Intel ?
>
> What does the Genivi Alliance have to say ?
>

I don't speak for the GENIVI Alliance. But from where I sit I see GENIVI is
a set of automotive middleware that runs on a number of operating systems in
a number of configurations. MeeGo is only one of those operating systems,
there are a number of others. A quick search for GENIVI compliance will
likely turn up some press releases about who else has a GENIVI compliant
distro.

Regards,

Jeremiah


> And why this secrecy ?
>
> Also it does sound a bit like Tizen will be LiMo-based
>
>
> Live long and prosper...
>
>
> __**_
> MeeGo-dev mailing list
> MeeGo-dev@meego.com
> http://lists.meego.com/**listinfo/meego-dev
> http://wiki.meego.com/Mailing_**list_guidelines
>



-- 
=
Jeremiah C. Foster
Open Source Technologist
Pelagicore AB
Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden
Mobile: +46 (0)730 93 0506
E-Mail: jeremiah.fos...@pelagicore.com
=

=== NOTE ===
The information contained in this E-mail message is
intended only for use of the individual or entity
named above. If the reader of this message  is not
the intended recipient, or the employee or agent
responsible to deliver it to the intended recipient,
you are hereby notified that any dissemination,
distribution or copying of this communication is
strictly prohibited.
=
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo...

[Peter Jespersen]

Den 29-09-2011 00:46, Clint Christopher Cañada skrev:
It's kinda disappointing though with what's happening.  Burned me 
once, that's ok, burned me twice, fine, but the third time (after 
speaking about Meego in some other engagements)?  You've got to have a 
pretty good reason why I'm gonna trust this new development.


Got the same feeling here

In short why ?

Is this a way to make further distance from Nokia (Qt) via a rebranding ?

Is it because you feel that MeeGo is getting nowehere (even though real 
units has seen the light of day) and that LiMo has a better chance 
(better support from hardware manufacturers) ?


Is it Intel ?

What does the Genivi Alliance have to say ?

And why this secrecy ?

Also it does sound a bit like Tizen will be LiMo-based


Live long and prosper...

___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo...

[Steven]

On 09/28/2011 08:14 PM, Ian Lawrence wrote:

Hi,


I disagree. The need of native apps will never go away. Tell me how an
HTML5 app will interface to a camera or gps device, for instance.

This can also be done using something like PhoneGap
(http://docs.phonegap.com/) which exposes native mobile device apis
and data to JavaScript. It builds for Android, iOS, Blackberry,
Symbian, WebOS and Bada through an automated build system
(https://build.phonegap.com/) which is currently in Beta but which
seems to be stable enough to at least get get you started on building
cross platform mobile apps

Regards

why we using something like this, for example,  phonegap in bada system, 
just start a new bada app which then running HTML app on this, we still 
using this tech?

I am sad about this approach.

Thanks

Steven Liu
---
Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) 
is intended only for the use of the intended recipient and may be confidential and/or privileged of 
Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is 
not the intended recipient, unauthorized use, forwarding, printing,  storing, disclosure or copying 
is strictly prohibited, and may be unlawful.If you have received this communication in error,please 
immediately notify the sender by return e-mail, and delete the original message and all copies from 
your system. Thank you. 
---


___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo...

[Leonardo Luiz Padovani da Mata]

"Burned me once, that's ok, burned me twice, fine, but the third time
(after speaking about Meego in some other engagements)?  You've got to
have a pretty good reason why I'm gonna trust this new development."

+one with the same feeling.


2011/9/28 Clint Christopher Cañada :
> I do agree with the sentiment though.  I've personally done some programming
> apps in android using an open framework that uses html and javascript but,
> although it does provide access to hardware, like gps, the camera and media,
> for more advanced functionality, you'd have to go back to adding that
> functionality through java.  HTML/js is good for rapid deployment, however,
> nothing beats C and other compiled languages.
>
> It's kinda disappointing though with what's happening.  Burned me once,
> that's ok, burned me twice, fine, but the third time (after speaking about
> Meego in some other engagements)?  You've got to have a pretty good reason
> why I'm gonna trust this new development.
>
> Cheers,
> Clint
>
> On 9/29/2011 6:30 AM, Si Howard wrote:
>
> My bad, I meant C/C++.
>
> Cheers,
>
> Si.
>
> On 28/09/2011 22:11, Jeremiah Foster wrote:
>
> On Wed, Sep 28, 2011 at 10:42 PM, S. Howard  wrote:
>
> The APIs only show media streams being parsed through HTML. Interpreted
> languages are still developing and can sill be surpassed by compiled
> languages such as C/Python.
>
> Eh? Python is not compiled, it is interpreted.
>
> Regards,
>
> Jeremiah
>
>
> ___
> MeeGo-dev mailing list
> MeeGo-dev@meego.com
> http://lists.meego.com/listinfo/meego-dev
> http://wiki.meego.com/Mailing_list_guidelines
>
> ___
> MeeGo-dev mailing list
> MeeGo-dev@meego.com
> http://lists.meego.com/listinfo/meego-dev
> http://wiki.meego.com/Mailing_list_guidelines
>



-- 
Leonardo Luiz Padovani da Mata

International Syst S/A
Metasys Tecnologia
Software Engineer Metasys MeeGo Team

leonar...@metasys.com.br
+55-31-3503-9040

"May the force be with you, always"
"Nerd Pride... eu tenho. Voce tem?"
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] MeeGo...

[Clint Christopher Cañada]

I do agree with the sentiment though.  I've personally done some 
programming apps in android using an open framework that uses html and 
javascript but, although it does provide access to hardware, like gps, 
the camera and media, for more advanced functionality, you'd have to go 
back to adding that functionality through java.  HTML/js is good for 
rapid deployment, however, nothing beats C and other compiled languages.


It's kinda disappointing though with what's happening.  Burned me once, 
that's ok, burned me twice, fine, but the third time (after speaking 
about Meego in some other engagements)?  You've got to have a pretty 
good reason why I'm gonna trust this new development.


Cheers,
Clint

On 9/29/2011 6:30 AM, Si Howard wrote:

My bad, I meant C/C++.

Cheers,

Si.

On 28/09/2011 22:11, Jeremiah Foster wrote:

On Wed, Sep 28, 2011 at 10:42 PM, S. Howard  wrote:

The APIs only show media streams being parsed through HTML. Interpreted
languages are still developing and can sill be surpassed by compiled
languages such as C/Python.

Eh? Python is not compiled, it is interpreted.

Regards,

Jeremiah



___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines


___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines