Re: [MeeGo-dev] [MeeGo-community] MeeGo as a vehicle for Qt-based products?
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-community] MeeGo as a vehicle for Qt-based products?
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?
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?
> 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?
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?
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?
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?
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?
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?
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?
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?
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?
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-community] MeeGo as a vehicle for Qt-based products?
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?
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?
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?
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?
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-community] MeeGo as a vehicle for Qt-based products?
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?
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?
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?
- 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?
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?
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
