On Sep 18, 2010, at 4:28 AM, David Greaves wrote: > Allow me to invert this email and suggest some prioritisation. > > On 18/09/10 01:09, Skarpness, Mark wrote: > >> What we have been discussing on this thread is the guidelines themselves... > > Good point ... and I have made one of the very few concrete proposals for > wording in this thread ... and AFAICS it hasn't been even commented upon. > Perhaps you'd care to go back to that? > > As I say... my objective is to permit (not mandate) MeeGo compliance for > applications developed using the open-source development model which tends to > favour componentised applications with cross app shared components. > > First of all, could you and Arjan (as the main objectors) clarify if this is > a > worthy objective for MeeGo? I don't agree that having MeeGo compliance support componentised applications is an objective we should take for the near term. I would rather us focus on solving the core problem (self-contained compliant app runs on any compliant device).
Before we require compliant devices to support apps with external dependencies, I think we need to demonstrate that the value of that justifies the cost and complexity. For example - show what can be done with MeeGo Extras following this model. We can add this to a future version of compliance if everyone says "wow, that's great - I really want this on my next device" > If it is an objective then I'd like to see us work to achieving it. If there > are > unsurmountable technical issues then... OK; lets back off until a solution > can > be found. It's not just about technical issues - there are also many business issues that would need to be solved. > > My compliance wording proposal is: > > Applications *MUST NOT* require (in RPM terminology) packages that are not > themselves compliant. > > Applications that require (in RPM terminology) packages that cannot be > provided > MUST NOT be installed. > > Please comment. As I said above, I don't think we are ready to make this a requirement in the compliance spec yet. We need to build a case for the value in the market. -Mark > > > Some irc conversation raised a few points: > * What does compliance promise > * Is compliance verification implicit > > I am assuming, respectively: > * If you _install_ a compliant app then it will work > * The on-device installer is not going to enforce or even verify that an > application is compliant > > The first point means that the installer tool must verify dependencies before > it > installs an app; if the dependency installation succeeds then the application > is > installed. This will only affect users and applications using external > dependencies. > > I hesitate to mention some technical thoughts as they are easy to critique > before we address the main issues above; however: > > I would anticipate that installation from an app store could streamline this > process through negotiation: > "this app needs X=<ver>,Y,Z"... "OK, can meet"..."here's the app" > > I also assume the app store will need to know the profile of the device in > order > to satisfy small issues like making sure compliant x86 packages don't go to > an > ARM device ;) > > (To paraphrase Andrew Flegg... MeeGo compliant doesn't mean you have to run > qemu!) > > This profile *could* include capabilities (enabled repos) which *could* be > used > to limit the users exposure to apps that they can run. > > Below is some further reasoning: > >> On Sep 17, 2010, at 4:43 PM, Will Marone wrote: >>> On 9/17/2010 12:02 PM, Quim Gil wrote: >>>> On Thu, 2010-09-16 at 12:13 +0200, ext Jeremiah Foster wrote: >>> Supposing I wrote software and made it available via Extras/Surrounds, why >>> is my app being there grounds to disqualify it for "compliance" even if it >>> meets the guidelines fully? Certainly that's insulting to the author and >>> implies things about their software that may be completely false. > > It's not. This has never been suggested by anyone. > >> If your app meets the guidelines fully - then it will be qualified for >> compliance. > > Will, here is where the potential discrimination against open-source arises. > > Clearly there is no discrimination against the license per se; I am well > aware > of that. > > *However* .... there *is* a discrimination against the model (well, there > will > be if the draft is modified as has been suggested). > > Open source apps *tend* to have external dependencies. > Closed source apps *tend* not to. > > If I look at a couple of apps on debian: > skype .... 19.2Mb > twinkle .. 1.7Mb > Guess which uses libspeeex and co? > > Another example: if http://zeitgeist-project.com/ gets into Surrounds (they > came > onto irc to discuss porting to meego) then that framework cannot be built > upon > by MeeGo Compliant apps. > >> You can distribute it via Extras / Surrounds or whatever other >> mechanism you choose. > > I feel a few people misinterpreted a statement I made earlier: > > I think we need to achieve 2 things: > * permit the open-source development model to work for compliant applications > ..[snip] > > I try to be careful with my words.... I *DID NOT* say > "permit open-source compliant applications" > > So I realise we can make and distribute compliant apps.... we just can't use > the > "best practice" method that OSS tends to favour and still call them compliant. > > Anyhow... that is why I feel all this is important. > >> Those building devices get to choose which sources of >> applications they make available on their device (i.e. just because you have >> a compliant app does not mean every device is required to make it available >> to the end user for installation - though if you have a good app, I would >> expect everyone to want it :-) > > YES ... every time you say something like this Mark I feel we are getting > closer > to a solution :) > > "Those building devices get to choose which sources of applications they make > available on their device" > > ie... policy can override "mere compliance" already. > A user can't expect that their "device [will have] it available [snip] for > installation" > > I see refusing to install an application that relies on Surrounds (because > it's > not "enabled") is just another policy restriction. > > David > > -- > "Don't worry, you'll be fine; I saw it work in a cartoon once..." _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
