Please make sure that active@ is somehow looking at this list too - I'm not subscribed there and hence can't mail there.
2012/5/31 martin brook <martin.brook...@googlemail.com>: > 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 <ase...@kde.org> > Date: Thu, May 31, 2012 at 10:42 AM > Subject: Re: List of problems with Plasma Active on Mer > To: act...@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". Okay, let me start out with some reasoning on how things are the way they are and why they're likely to stay that way. The problems you state are true, but they need solving in different ways than you envision. First off, as you know, Mer is formed around the concept of a Core with a user community of vendors and not end-users and we're very picky about this fact. The idea here is that Mer's customers are the vendors - vendors include everything from UI projects, device makers, the lone hacker at home making an aftermarket adaptation, hardware adaptation projects, component developers, etc. The idea is that vendors will pick and choose between eachothers deliverables and use them to make devices. There's commercial deliverables, there's open source deliverables and there's semi-open source deliverables from these vendors. Nemo's a vendor, Plasma Active's a vendor, vgrade's a vendor. The Mer Project's duty is to deliver the Core, systems to support it and tools to make it easier to use, simple as that. We also see it as a value to grow a community and provide incubation places (wiki, irc, maybe OS), but we can't host all Mer-using projects as we simply can't afford it. The Mer Project strives to stay alive - it's intentionally very hard to kill and shut down - it's something we have to be able to rely on for our projects. Structurally, vendors are external to the project, but can impact the direction of the project through contribution and participation in the project. Vendors can register as interest groups / contributors can gain maintainership or technical leadership and steer their part of the project or the whole through the participation in the Advisory Board (http://wiki.merproject.org/wiki/Governance). We operate a bug category specifically for the interface we present from Mer to vendors and any of these problems are more than welcome there. Now, let's quickly run through why we don't have hardware adaptations hosted in Mer and why they're external projects to us - these things are based on many years of experiences doing hardware adaptations myself: 1) Given certain complexity, we'll have bits and pieces of any hardware adaptation that are closed source, non-redistributable or of otherwise problematic licensing that we cannot include in Mer. Can we all agree that it's significantly easier to deal with Mer when we don't have to step in a potential minefield of license problems when you copy a Mer release - and instead stick to delivering a open source Core? 2) Hardware adaptations typically follow totally different timelines and deadlines than Core releases. 3) We've learnt it the really hard way that Core and hardware adaptation does not mix from MeeGo - an example was that IVI hardware adaptation for Intel totally capsized the work to do a proper IVI UI and middleware, as it was constantly out of sync with MeeGo releases. 4) There will be hardware adaptations that are commercial and sold between vendors which cannot be part of Mer. 5) If we had HW adaptations in Mer, given sufficient hardware adaptations, there will not be a balanced enough capability and stability of these and the quality of them would reflect badly on the Core itself - that on other devices it would work fine on. This happened for example with the N900 adaptation work in MeeGo. MeeGo Core was fine - the hardware adaptation wasn't always stable. 6) Device user communities has a tendency to go towards entitlement syndromes, which wears out project developers that are working on often unrelated parts to the devices. 7) Hardware adaptations within the core has a tendency to clutter up the core itself - it was a total mess to unwind this within the MeeGo core and often a source of bugs. Any common hardware adaptation project will have some of these problems too. Now, historically, the reason we have X86 adaptation in the Nemo project is simply to place it in somewhere outside the Mer project - ignore the 'Nemo' part of it, which contains an Handset UI in it too (but seperate from hardware adaptation and building against Mer Core) - it's a grouping of people. If you'd like to take over X86 adaptation you're more than welcome, too :) Right now the plan is to align as much as we can with Intel's adaptation in Tizen and share packages directly - there's no need for NIH. Nemo hosts some hardware adaptations that proved useful to Nemo and has infrastructure to support accepting contributions for it - bugtracker, OBS projects. But not all adaptations are hosted there or should be. What the core of the problem you describe really is this: 1. There's no good way to share hardware adaptations between Mer-based projects. 2. There's no good way of identifying other vendors (incl. hw adaptation projects) utilizing and providing deliverables for the Mer 'ecosystem' 3. Hardware adaptations surrounding Mer are not 'released' currently, ie, they're always matching latest Mer Core which isn't suitable for device making So what I would like to drive from Mer side, is simple: 1. I'd like to provide a uniform way that projects can include a release from a hardware adaptation, or a UI, or whatever. Including a puzzle piece, you might say. This work is partially in progress with the kickstarter work, where the idea is that you can include modular descriptions and generate a .ks file for making images 2. I'd like to provide a way for hardware adaptation vendors and UIs to 'release' in this manner - This work is also partially in progress - David is doing release scripts all of you can use. 3. I'd like to provide a way for vendors to list themselves on the Mer homepage and their deliverables/releases - We lack hands for this currently. These would solve the problem you identify. In the end though: Mer is a co-operative. We share the load of having a common mobile core to build our devices and projects on top of. We contribute with the expectation that we lessen our load and 'cost' (time, money, sanity) by others pitching in to divide the heavy load between us. We need help to accomplish these things in better ways and some of the contributions needed is sometimes just as simple as contributing web design work. So to make Mer better, contribute - submit bugs, fix some glitch in our vendor-core interface, submit a patch, etc. Or start a thread like this on mer-general mailing list :) BR Carsten Munk > > 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 > act...@kde.org > https://mail.kde.org/mailman/listinfo/active > >
