Aaron - I really value the time you've taken to highlight these issues: thanks.
My reply was going to be tl;dr; so I deleted it. Instead: "That's what the Mer Community OBS is for" "That's what the Mer Advisory Board is for" "That's what the Mer Release Management team is for" In general, Mer is open : if you want something done, participate. Having said that, one issue that I have with Mer is that Mer currently *is* seen as just a Core ... but it has the potential to be much more. I've always said that Mer is actually an incubator - and Nemo (with HA) lives on Mer-managed infra, including bugzilla, as an example of that - our organisational and infrastructural setup supports the kinds of projects you describe... but who do you propose does this stuff? We simply don't have the human resource to do more : biting off too much results in less, not more. And frankly, speaking of resources and at the risk of going OT, after I've invested 9 months of upaid full time contribution to Mer I can't keep this up much longer unless some organisations see enough value in my contributions to support my work - maybe each hiring me for just one day a week? The on-topic part of this 'complaining' is just highlighting a real risk to the project. David On 31/05/12 12:50, Aaron J. Seigo wrote: > 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). > -- "Don't worry, you'll be fine; I saw it work in a cartoon once..."
