On Thursday, May 31, 2012 13:23:10 Carsten Munk wrote: > Now, let's quickly run through why we don't have hardware adaptations > hosted in Mer
if that's what i was suggesting, what followed would be a very useful list of points. it isn't what i suggested, however. > Any common hardware adaptation project will have some of these problems too. and for the adaptations, such as for x86, that don't have such problems it isn't a problem. i realize that is axiomatic. providing a solution for the cases where it can work makes sense. avoiding solutions because there are cases where it won't work .. that makes less sense. i hope we can agree on that, and so leave the verbose disclaimers to the side? :) > 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) that's exactly the division i'm suggesting we create, so as to raise visibility of these efforts and get more hands working on the same required deliverables. > - it's a grouping of people. If you'd like to take over X86 adaptation > you're more than welcome, too :) i don't want to take it over, i want to contribute to it. > 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. +1 > 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. yes, the exceptions do not make the rule. so let's focus on those that do "make the rule". in this case, x86 is the posterchild. > 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' correct ... > 3. Hardware adaptations surrounding Mer are not 'released' currently, > ie, they're always matching latest Mer Core which isn't suitable for > device making i see this as a separate issue. > 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 this goes along with point #3 above. it is related to release management not to adaptation collaboration, which is what i'm initially trying to address. release and development collaboration are, ime, rarely the same thing. the get comingled because release often imposes freezes on development, depending on the development methodology being used. > 2. I'd like to provide a way for hardware adaptation vendors and UIs > to 'release' in this manner that'd be very cool. to that end, dividing out UI and adaptation layers would be extra helpful, since adaptations are more likely to be common goods. releasing an adaptation + UI is a little less useful, and that in turn will lower instances of collaboration. > 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. +1 .. this will need more than a list on a wiki; a common place for work on adaptations that can be shared is highly desirable. i don't want 5 different places to work on 5 different common adaptations. if mer doesn't provide this, the inneficiency implies that someone else will. that would result in additional organizational complexity that we don't need. but that can be avoided by working on it together and coming up with a solution together. punting it outside of the mer community and saying "someone else handle that bit" doesn't help. people outside of the mer core team may end up shouldering the work (probably should; you guys have enough to do already) but the answers ought to emerge from the common mer community. > These would solve the problem you identify. yes, i think it would be a great start, indeed ... :) > 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. couldn't agree more. i hope that my emails have been clear enough in this way. if any other impression was gained or given from them, i apologize :) > 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 :) i agree, and this is precisely what i'm asking for: a way to more efficiently contribute, starting with ways to identify where those collaboration opportunities exist (solution point #3 in your email begins to address this aspect) and a place in which to do this collaboration (which still needs definition). -- Aaron J. Seigo
signature.asc
Description: This is a digitally signed message part.
