Fwd: List of problems with Plasma Active on Mer

[martin brook]

Guys Hi,

The Plasma Active project has identified a number of issues with their Mer
based build which means they are still developing the MeeGo based build.
 This is not what the guys want to do ideally so I volunteered to get a
list of the blocking issues and try and get some resources working on them.

It became apparent from the list that a number of them were related to the
x86 hardware adaptation (kernel and graphics drivers) issues.  Just to
remind people of the scope of Mer I posted the following reminder to the
active list and the reply from Aaron.

>From my view there is a place for the x86 adaptations and this is in the
Nemo project and Mer people contribute there.  Work goes on in COBS and in
the http://wiki.merproject.org/wiki/Community_Workspace  on other
adaptations including Raspberry Pi and Vivaldi.

In my view its the number of resources available to work these adaptations
which is the problem just as in all software development projects I've been
involved in.

BR

vgrade

---------- Forwarded message ----------
From: Aaron J. Seigo <aseigo at kde.org>
Date: Thu, May 31, 2012 at 10:42 AM
Subject: Re: List of problems with Plasma Active on Mer
To: active at kde.org


On Thursday, May 31, 2012 10:13:30 martin brook wrote:
> Just a reminder that Mer does not include hardware adaptations, so kernel
> and graphics drivers are out of scope of that project.
>
> Nemo does aim to support an x86 adaptation.

imho, this highlights a scoping error for mer. here's why:

* mer doesn't do hardware adaptation.
* projects on top of mer do
* there are multiple projects on top of mer, all of which need adaptations
* there is a finite number of common hardware targets

this leads to multiple projects working on the same hardware adaptations
without a good place to collaborate.

this conflicts with the idea that mer is a place to collaborate on the OS
layer.

this feels a lot like "we're doing it wrong".

possible solutions, of varying benefit, that occur to me:

* mer based projects (e.g. nemo, PA, etc.) pay attention to what each other
is
doing for hardware adaptation and collaborate when possible.

this does not scale well and ad-hoc cooperations are messy and error prone.

* mer provides a place for hosting hardware adaptations. this can be adjunct
to the share core that is mer, but kept within the same workflow and
collaboration tools that already exist

this would scale well and give a natural place to collaborate. apparently
mer
does not see the need for this or has concerns (legal?) about $SOMETHING

* mer based projects create a place to collaborate on hardware adaptations
outside of mer.

this will make mer a hell of a lot less influential and useful. which is the
opposite of what mer should be trying to do. i understand avoiding UI stack
involvement, if only because it is obvious and evident that there are not
only
multiple divergent UI pathways which are equally valid and unlikely to be
shared via mer core, but mer core itself does not imply a UI layer at all.

mer core DOES imply hardware adaptation, however. without that it is not
useful.


so if someone can explain to me why mer is not ammenable to providing places
for projects to work on these hardware enablement projects in a central
place,
that'd be appreciated.

--
Aaron J. Seigo
_______________________________________________
Active mailing list
Active at kde.org
https://mail.kde.org/mailman/listinfo/active
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/active/attachments/20120531/50179579/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 205 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/active/attachments/20120531/50179579/attachment.sig>