Carsten Munk wrote: > > Quick run through - hope this is constructive criticism:
yes, it was good stuff, thanks. > > Line 72, we really need to spell out that it is ARMv7, EABI, softfp > (for 1.1) as there is emerging tendancies in industry to use hardfp too. I'll take any info I can get here, nobody's given me any details for this area. Do you have proposed wording? > Line 75-76, IVI is not a supported profile? > > Lines 127-129, given that GCC 4.5 in MeeGo 1.1 isn't exactly the best > when it comes to compiler bugs on ARM and some other areas, is there > an exception to compiler bug fixes as these might be needed to actually > productize? suggestions for a way to say this? I'll poke around and see if there are objections. > Line 182, MeeGo 1.1 Xorg server actually has --disable-xinerama so > we can't demand this as compliance (please verify rest on a running > implementation). Hmmm, good point. > For GLESv2 you should require that an implementation must Provide: > libGLESv2.so.2 exists (can be a symlink) and libEGL.so.1 (can be a > symlink) > > Line 187, don't we need more than 'uses 2.6.35 kernel or later'? There > should be a requirement on the minimum of options to provide on a > MeeGo install for a userland to run. I think so, but so far despite a few references about as detailed as yours (should have a list of config options), the details haven't been forthcoming. > Lines 241-242, regarding the heated issue: I agree there's no good > technical way to test for compliance with non-core-non-ux-deps right > now, but I would propose we set up a work group to work on this exact > issue to come up with a proper solution for 1.2 timeframe - you agree? > > There certainly seems to be enough people passionate about the issue > and we should be able to come up with a good solution in a proper > constructive work group. I'd like to think so. > Lines 249-250: This doesn't ring true in my ears - MeeGo compliant app > means that my app will install and run, right? > > I think this needs more work and specification before it should be > allowed - the RPM subarchitecture stuff might be a direction but (d) > must always be true or we can't rely an app being compliant meaning it > will install and work on my device. yeah, not enough detail here for it to be useful. Didn't quite know what to do with this proposal that came in privately, and didn't get any comments later to resolve it. > Lines 262: there's also a patchlevel (.35) in current MeeGo 1.1 Is it important to add this (ref: bash version, which is only listed as 4.0)? > MeeGo Core packages: most apps will base on let's say, libGLESv2.so.2 > instead of 'mesa' - is it stated anywhere that for these things, a > drop-in ABI-API compatible .so is OK too? the GL stuff is a special case, yes. The distro chapter suggests this by not calling out an implementation, but rather that GLES support is what matters. sound like there should be something in the application chapter as well. > General comment: I think it would be wise to state something about > compliant package distribution. It would be good to discourage > straight-rpm downloads and encourage repositories instead due to > making it possible to receive security updates of the application. > > And the philosophical comment: compliance document only states what > MeeGo requires, not what too much about what it promises in terms of > it's platform development. Let's say, if we do ABI/API breaks doing > major releases or not.. the hard part will be not doing them on minor releases :( what did you have in mind here? _______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
