Hi, As vgrade said, there's a place for Hardware adaptations in the Nemo bugzilla, having x86-generic component. If there's a need to have more specific components please let me know, I try to help as much as I can.
Br, Iekku On 31 May 2012 13:04, martin brook <[email protected]> wrote: > 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 <[email protected]> > Date: Thu, May 31, 2012 at 10:42 AM > Subject: Re: List of problems with Plasma Active on Mer > To: [email protected] > > > 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 > [email protected] > https://mail.kde.org/mailman/listinfo/active > > > -- --- Iekku Pylkkä Please, notice my new e-mail address: [email protected]
