Meego Wiki
Views

Talk:Quality/Compliance primer 1.0

From MeeGo wiki
< Talk:Quality(Difference between revisions)
Jump to: navigation, search
 
(2 intermediate revisions not shown)
Line 13: Line 13:
--[[User:Ali1234|Ali1234]] 01:18, 15 February 2011 (UTC)
--[[User:Ali1234|Ali1234]] 01:18, 15 February 2011 (UTC)
 +
 +
@[[User:Dm8tbr]]:  There are 2 levels of compliance:
 +
 +
* Device & stack compliance ("I can put a MeeGo sticker on my device", or "I have respun the MeeGo stack to include some extra stuff, to cater to a new UX, etc, and I want to call it MeeGo School Edition" (or whatever)) - this is roughly equivalent to Android platform compliance. This is where Suse MeeGo would fit in, and potentially (when they conform to the compliance requirements) Linpus. This is also where Smeagol and Debian MeeGo port have trouble.
 +
* Application compliance ("My app is a MeeGo application") - this is an application bundle that is certified for a given version of MeeGo, and installs stand-alone, like a Mac app or an Android package. And this is where community apps that want to pull in upstream dependencies have trouble.
 +
 +
So a community hardware adaptation should install a MeeGo compliant stack to be able to call itself a MeeGo device. If there are any compliance rules preventing me from (say) installing the MeeGo stack on an N900 or an O2 Joggler and having that be called the MeeGo Joggler edition or whatever, then I would say that that's a bug in the compliance rules & needs to be fixed.
 +
 +
Can you give an example of a situation where the current compliance rules would prevent a community hardware adaption from using the MeeGo name?
 +
 +
--[[User:Dneary|Dneary]] 13:44, 15 February 2011 (UTC)
 +
 +
Example: When a community hardware adaptation has just begun, and has not yet achieved compliance, it cannot use the MeeGo trademark on development versions of it's software, because they are not compliant. Therefore it won't be able to distribute testing versions to developers and beta testers, or possibly even tell anyone about the goals of the project. This will make it impossible for a community project to attract any developers and so compliance is unlikely to ever be achieved. The only legal and realistic option is to strip all references to MeeGo from the code - essentially creating an unencumbered fork (like CentOS) - before beginning any adaption work.
 +
 +
--[[User:Ali1234|Ali1234]] 20:28, 17 February 2011 (UTC)
 +
 +
see also: https://bugs.meego.com/show_bug.cgi?id=13516
 +
 +
--[[User:Ali1234|Ali1234]] 20:06, 20 February 2011 (UTC)

Latest revision as of 20:06, 20 February 2011

Community hardware adaptations are not mentioned here at all. It is all "products, products, products". Although I do not argue with the fact that products and their compliance should be a primary concern for MeeGo, community hardware adaptations and the community in general should not be ignored. It just leads to problems, frustration, misunderstandings or in the worst case lawsuits and I hope we all can agree that this is not a desireable outcome.

There has to be a common roof under which community work can happen and that does address the specific needs of community work.

--Dm8tbr 10:59, 12 February 2011 (UTC)

Response: Dm8tbr, can you please define what you mean by hardware adaptation? Can you provide some concrete examples?

--Bdub 21:22, 14 February 2011 (UTC)

Bdub, see http://wiki.meego.com/ARM/MSMQSD and http://codex.xiaoka.com/wiki/meego:archos

--Ali1234 01:18, 15 February 2011 (UTC)

@User:Dm8tbr: There are 2 levels of compliance:

  • Device & stack compliance ("I can put a MeeGo sticker on my device", or "I have respun the MeeGo stack to include some extra stuff, to cater to a new UX, etc, and I want to call it MeeGo School Edition" (or whatever)) - this is roughly equivalent to Android platform compliance. This is where Suse MeeGo would fit in, and potentially (when they conform to the compliance requirements) Linpus. This is also where Smeagol and Debian MeeGo port have trouble.
  • Application compliance ("My app is a MeeGo application") - this is an application bundle that is certified for a given version of MeeGo, and installs stand-alone, like a Mac app or an Android package. And this is where community apps that want to pull in upstream dependencies have trouble.

So a community hardware adaptation should install a MeeGo compliant stack to be able to call itself a MeeGo device. If there are any compliance rules preventing me from (say) installing the MeeGo stack on an N900 or an O2 Joggler and having that be called the MeeGo Joggler edition or whatever, then I would say that that's a bug in the compliance rules & needs to be fixed.

Can you give an example of a situation where the current compliance rules would prevent a community hardware adaption from using the MeeGo name?

--Dneary 13:44, 15 February 2011 (UTC)

Example: When a community hardware adaptation has just begun, and has not yet achieved compliance, it cannot use the MeeGo trademark on development versions of it's software, because they are not compliant. Therefore it won't be able to distribute testing versions to developers and beta testers, or possibly even tell anyone about the goals of the project. This will make it impossible for a community project to attract any developers and so compliance is unlikely to ever be achieved. The only legal and realistic option is to strip all references to MeeGo from the code - essentially creating an unencumbered fork (like CentOS) - before beginning any adaption work.

--Ali1234 20:28, 17 February 2011 (UTC)

see also: https://bugs.meego.com/show_bug.cgi?id=13516

--Ali1234 20:06, 20 February 2011 (UTC)

Personal tools