List of problems with Plasma Active on Mer

[Aaron J. Seigo]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/active/attachments/20120531/a184fe18/attachment-0001.sig>