On Wed, Dec 15, 2010 at 07:02:17AM -0800, Arjan van de Ven wrote:
> On 12/14/2010 10:53 PM, Thomas B. Ruecker wrote:
>>
>>> I don't see the difference between a vendor maintaining a kernel package
>>> and a community of people maintaining a kernel package....
>> Being involved in a relatively small OSS community around Archos portable
>> media players I can tell you that it makes a huge difference for us.
>> But I'm not even sure why I'm jumping into this discussion. Most of our
>> projects are doomed to stick to whatever kernel was adapted for the given
>> hardware.
>
>
> first I'll say I am quite appreciative of people doing such things; I  
> know it's not easy for a small group of people, esp if they are not  
> hardcore kernel developers, to do creative things on devices that  
> weren't really intended to do these things.
>
> On the flip side, for an OS like MeeGo, we can't just support  
> arbitrarily old kernel versions as part of compliance etc etc.
Yes I understand that issue too. I think it's good to set a high bar for
 e.g. CPU/SoC companies so that they actually upstream 
their kernel patches.
The point I'm trying to make is that although MeeGo is still in its infancy
it has created a lot of buzz and interest also among those smaller groups.
So far it is unclear for me how a community, which is working on 
a hardware adaptation, is even able to fit into the MeeGo-verse. 
Often I bump into such issues like the kernel.

> Now at least Nokia for the N900 provides a much newer kernel for MeeGo,  
> so those of us who own N900's are in good shape, but the conflict I'm  
> trying to point out is real... and there will be a point where, even if  
> you ignore the hard compliance topic of what applications can expect,  
> the core OS just expects newer kernel functionality.
Yes, we've seen this happen with previous hardware where we are stuck
with 2.6.22 and a kernel config that clashes with newer udev.
That's the moment where we either find a way to patch in the needed
feature or say 'tough luck, no cookie for us'. It's not how it should
be, yes. Newer kernel would be lovely, but often it won't happen.

I really appreciate the stance MeeGo takes over those issues.
In the best case this will help to avoid such situations in the long run.
Still we should keep in mind that there are a lot of people who are
attracted to MeeGo and want to experiment and learn. We should find
a way how to include them and their hardware without discouraging them.
Also I've seen many people later end up working for companies
that have official (MeeGo) hardware in the pipeline.

If it turns out that for whatever reasons you can't call it MeeGo
(e.g. because it needs to pass each end every compliance test/criteria)
even if it's just a community tinkering, then we should start thinking
now if MeeGo should have a community 'label' which gives a roof
to all such projects. Other distros have this too (openSuse, Fedora, ...)
If we don't, then we'll end up with a messy uncoordinated pile 
of spawning and dieing forks and no coordinated feedback or inclusion
to the MeeGo project.

I hope it's getting clearer what point I'm trying to make.
The kernel being really just one puzzle piece that triggered me.
(c.f. recent ftp space for BB adaptation discussion)

Thomas
_______________________________________________
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Reply via email to