Guys Hi,<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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 <a href="http://wiki.merproject.org/wiki/Community_Workspace">http://wiki.merproject.org/wiki/Community_Workspace</a>  on other adaptations including Raspberry Pi and Vivaldi.</div>
<div><br></div><div>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.  </div><div><br></div><div>BR</div>
<div><br></div><div>vgrade</div><div><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Aaron J. Seigo</b> <span dir="ltr"><<a href="mailto:aseigo@kde.org">aseigo@kde.org</a>></span><br>
Date: Thu, May 31, 2012 at 10:42 AM<br>Subject: Re: List of problems with Plasma Active on Mer<br>To: <a href="mailto:active@kde.org">active@kde.org</a><br><br><br><div class="im">On Thursday, May 31, 2012 10:13:30 martin brook wrote:<br>

> Just a reminder that Mer does not include hardware adaptations, so kernel<br>
> and graphics drivers are out of scope of that project.<br>
><br>
> Nemo does aim to support an x86 adaptation.<br>
<br>
</div>imho, this highlights a scoping error for mer. here's why:<br>
<br>
* mer doesn't do hardware adaptation.<br>
* projects on top of mer do<br>
* there are multiple projects on top of mer, all of which need adaptations<br>
* there is a finite number of common hardware targets<br>
<br>
this leads to multiple projects working on the same hardware adaptations<br>
without a good place to collaborate.<br>
<br>
this conflicts with the idea that mer is a place to collaborate on the OS<br>
layer.<br>
<br>
this feels a lot like "we're doing it wrong".<br>
<br>
possible solutions, of varying benefit, that occur to me:<br>
<br>
* mer based projects (e.g. nemo, PA, etc.) pay attention to what each other is<br>
doing for hardware adaptation and collaborate when possible.<br>
<br>
this does not scale well and ad-hoc cooperations are messy and error prone.<br>
<br>
* mer provides a place for hosting hardware adaptations. this can be adjunct<br>
to the share core that is mer, but kept within the same workflow and<br>
collaboration tools that already exist<br>
<br>
this would scale well and give a natural place to collaborate. apparently mer<br>
does not see the need for this or has concerns (legal?) about $SOMETHING<br>
<br>
* mer based projects create a place to collaborate on hardware adaptations<br>
outside of mer.<br>
<br>
this will make mer a hell of a lot less influential and useful. which is the<br>
opposite of what mer should be trying to do. i understand avoiding UI stack<br>
involvement, if only because it is obvious and evident that there are not only<br>
multiple divergent UI pathways which are equally valid and unlikely to be<br>
shared via mer core, but mer core itself does not imply a UI layer at all.<br>
<br>
mer core DOES imply hardware adaptation, however. without that it is not<br>
useful.<br>
<br>
<br>
so if someone can explain to me why mer is not ammenable to providing places<br>
for projects to work on these hardware enablement projects in a central place,<br>
that'd be appreciated.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Aaron J. Seigo</font></span><br>_______________________________________________<br>
Active mailing list<br>
<a href="mailto:Active@kde.org">Active@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/active" target="_blank">https://mail.kde.org/mailman/listinfo/active</a><br>
<br></div><br></div>