In the meanwhile, a few smaller comments to 1.0.99.3:
- Lines 121, 122: "...but changes MUST NOT affect API, ABI, or behavior."
- Should this say something like "in incompatible manner". Meaning,
can someone e.g. add a function to some API for their own use?
- 2.5: Do we need some EGL version?
- 2.5: This talks about OpenGL ES 2.0 but 3.4 about OpenGL ES 2.1 - is that OK?
- Line 279: "...public interfaces from all libraries"
- Does Platform API include any D-Bus interfaces? If yes, how should
those be covered?
- In addition to public library interfaces, are there also private
ones?
How are these differentiated?
- Appendix A:
- hwdata: is this applicable in all environments (Intel, ARM)?
- mesa: is this applicable like this in all environments (Intel, ARM)?
- Do these packages contain device/HW-specific plugins (binary modules):
DSME, gst-plugins-*, kernel, ohm-plugins-misc, pulseaudio, qt-mobility,
sensorfw, xorg-x11-server? If they do, should something be said about
their "special nature".
Regards, Jari
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of Palojarvi Jari (Nokia-MS/Tampere)
> Sent: 04. marraskuuta 2010 10:16
> To: [email protected]; [email protected]
> Subject: Re: [MeeGo-dev] Compliance spec updated 1.0.99.2
>
> Still waiting for other comments concerning whether some packages now
> in the MeeGo Core Packages list contain components that are not
> applicable in all MeeGo HW/device environments...
>
> Anyway, I agree with point (2) below. Generally, if the compliance
> requirements are expressed as they now are, we need to make sure that
> the required packages only contain components that are
> sensible/needed/functional everywhere (not device/HW specific).
>
>
> Regards, Jari
>
> > -----Original Message-----
> > From: ext Wichmann, Mats D [mailto:[email protected]]
> > Sent: 03. marraskuuta 2010 16:53
> > To: Palojarvi Jari (Nokia-MS/Tampere); [email protected]
> > Subject: RE: Compliance spec updated 1.0.99.2
> >
> > [email protected] wrote:
> > > Hi,
> > >
> > > Just took a look at 1.0.99.3. I'd like to point out one
> > > potential issue related to System Implementation / Platform
> > > Compliance and the MeeGo Core Packages list.
> > >
> > > If all compliant platforms must include the binary packages
> > > listed in the MeeGo Core Packages list, I suppose that all SW
> > > components in those packages are also expected to be present
> > > and work in all compliant platforms (%files in spec files not
> > > allowed to be changed)? However, as we all know, compliant
> > > platforms can differ from each other when it comes to
> > > device/HW adaptation. Device/HW adaptation typically consists
> > > of plugins to some user space frameworks (GStreamer,
> > > PulseAudio, Resource Policy, Sensor Framework, oFono, X, Qt
> > > Mobility APIs etc.) and device drivers ("plugins" to Linux
> > > kernel). And different platforms can have a different set of
> > > HW adaptation related plugins.
> > >
> > > Do the packages now listed in MeeGo Core Packages include
> > > device/HW adaptation related SW components that are specific
> > > to some HW environment? E.g. do the oFono, Sensor Framework
> > > and PulseAudio packages contain SW components that are not
> > > applicable/sensible in all environments? If they do, isn't
> > > that a bit problematic (components required to be present but
> > > not used/functional)? Or have I misunderstood something?
> >
> > I don't think there's adaptation stuff in there - but I haven't
> > worked on the package list, just been handed it, so we'll need
> > to wait for others to comment.
> >
> > > How should we handle/mention this aspect in the compliance
> > specification?
> >
> > There's two parts to it:
> >
> > (1) bits which are unique to a whole platform family should be
> > in the profile
> >
> > (2) bits which aren't even that common, such as down to a specific
> > device, need to be "fuzzed" in a way that make it clear it's a
> > behavior and not a specific package that is required. An example
> > of this style (the only case at the moment) is saying GLES is
> > needed but not mandating that it come from Mesa.
> >
> > This kind of stuff needs to be called out to avoid the issues
> > you mention (e.g., requiring non-functional or not-needed bits),
> > and to do that, someone has to identify those piece so they
> > can be covered - I don't have any of that information!
>
> _______________________________________________
> MeeGo-dev mailing list
> [email protected]
> http://lists.meego.com/listinfo/meego-dev
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
