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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active