User:Stskeeps/Harmattan collaboration proposal - Revision history

imported>lbt: Category Mer

2009-08-14T20:27:51Z

Category Mer

← Older revision		Revision as of 20:27, 14 August 2009
Line 40:		Line 40:

	Maemo gatekeeper(s) would maintain a cloned repository (possibly internal) of a Maemo Platform package with a branch for Maemo packaging, and a branch for Maemo-specific patches, if any difference exists between Maemo packaging and reference packaging.		Maemo gatekeeper(s) would maintain a cloned repository (possibly internal) of a Maemo Platform package with a branch for Maemo packaging, and a branch for Maemo-specific patches, if any difference exists between Maemo packaging and reference packaging.

			[[Category:Mer]]

imported>stskeeps at 16:43, 11 August 2009

2009-08-11T16:43:31Z

← Older revision		Revision as of 16:43, 11 August 2009
Line 21:		Line 21:
	Each piece of software would have one or more maemo.org members (Maemo Devices developers are included in this set) as gatekeepers for what contributed patches gets merged in to the software. Each team of gatekeepers determines who to add or remove as additional gatekeepers.		Each piece of software would have one or more maemo.org members (Maemo Devices developers are included in this set) as gatekeepers for what contributed patches gets merged in to the software. Each team of gatekeepers determines who to add or remove as additional gatekeepers.

	Each piece of software would be considered separately released and not focused onto specific releases of ~~neither~~ Mer or Maemo - when you have a fix and you consider the current state release-worthy, a release is tagged.		Each piece of software would be considered separately released and not focused onto specific releases of either Mer or Maemo - when you have a fix and you consider the current state release-worthy, a release is tagged.

	Each piece of software would have a public roadmap determined by the gatekeepers based on the public roadmap. Gatekeepers would generate tasks based on this roadmap which contributors can choose to take upon him/herself to do (see maemo.org sprint process, Mer sprintweb) in cooperation with gatekeepers & mentors.		Each piece of software would have a public roadmap determined by the gatekeepers based on the public roadmap. Gatekeepers would generate tasks based on this roadmap which contributors can choose to take upon him/herself to do (see maemo.org sprint process, Mer sprintweb) in cooperation with gatekeepers & mentors.

imported>stskeeps at 13:46, 11 August 2009

2009-08-11T13:46:27Z

← Older revision		Revision as of 13:46, 11 August 2009
Line 11:		Line 11:
	== Future: Maemo Platform ==		== Future: Maemo Platform ==

	Maemo Platform is defined as a set of software implementing the Maemo platform that is target-agnostic. This would be APIs, UI, reference themes, sounds, daemons, applications and data making together the basic Maemo platform that developers target. MP should be able to 'stand on it's own' on top of a reference platform and hence be complete in itself. The goal is that an application built for Maemo Platform will build for any Maemo Platform implementors.		Maemo Platform is defined as a set of software implementing the Maemo platform that is target-agnostic. This would be APIs, UI, reference themes, sounds, daemons, applications and data making together the basic Maemo platform that developers target.

	~~Software in~~ Maemo ~~platform would~~ be ~~developed~~ in ~~the public~~. ~~There would be a shared collaboration space (Gitorious,~~ for ~~instance) hosting the software, with clear directions in maemo.org web~~ on ~~where to find the DVCS repositories. The~~ Maemo ~~platform would have public roadmaps for development~~.		The Maemo Platform should be able to 'stand on it's own' on top of a reference distribution and hence be complete and usable in itself. The goal is that an application built for Maemo Platform will build on any Maemo Platform implementers.

	~~Each piece of software would have one or more maemo.org members (Maemo Devices developers are included in this set) as gatekeepers for what contributed patches gets merged in to the software.~~		=== Platform development ===

	~~Each piece of software~~ would be ~~considered seperately released and not focused onto specific releases of neither Mer or Maemo - when you have~~ a ~~fix and you consider~~ the ~~current state release-worthy~~, a ~~release is tagged~~.		Software in the Maemo platform would be developed in the public. There would be a shared collaboration space (Gitorious, for instance) hosting the software, with clear directions in maemo.org web on where to find the DVCS repositories. The Maemo platform would have a public roadmap for future development.

	Each piece of software would have a roadmap determined by the gatekeepers based on the public roadmap. Gatekeepers would generate tasks based on this roadmap which contributors can choose to take upon him/herself to do (see maemo.org sprint process, Mer sprintweb) in cooperation with gatekeepers & mentors.		Each piece of software would have one or more maemo.org members (Maemo Devices developers are included in this set) as gatekeepers for what contributed patches gets merged in to the software. Each team of gatekeepers determines who to add or remove as additional gatekeepers.

			Each piece of software would be considered separately released and not focused onto specific releases of neither Mer or Maemo - when you have a fix and you consider the current state release-worthy, a release is tagged.

			Each piece of software would have a public roadmap determined by the gatekeepers based on the public roadmap. Gatekeepers would generate tasks based on this roadmap which contributors can choose to take upon him/herself to do (see maemo.org sprint process, Mer sprintweb) in cooperation with gatekeepers & mentors.

	Each piece of software would have reference packaging (seperated in branches) to base distro-specific packaging on.		Each piece of software would have reference packaging (seperated in branches) to base distro-specific packaging on.

	All bugs related to Maemo Platform would be maintained in bugs.maemo.org.		All bugs related to Maemo Platform would be maintained in bugs.maemo.org.

	== Future: Mer ==		== Future: Mer ==
Line 34:		Line 38:

	The future Maemo Harmattan would be based on Maemo Platform. Vendor differentiation for certain devices would then be applied on top of Maemo platform and distribution of choice (Themes, applications, services, added value software, icons, firmware, device-specific APIs, etc.)		The future Maemo Harmattan would be based on Maemo Platform. Vendor differentiation for certain devices would then be applied on top of Maemo platform and distribution of choice (Themes, applications, services, added value software, icons, firmware, device-specific APIs, etc.)

			Maemo gatekeeper(s) would maintain a cloned repository (possibly internal) of a Maemo Platform package with a branch for Maemo packaging, and a branch for Maemo-specific patches, if any difference exists between Maemo packaging and reference packaging.

imported>stskeeps: /* Future: Maemo Platform */

2009-08-11T13:28:45Z

Future: Maemo Platform

← Older revision		Revision as of 13:28, 11 August 2009
Line 11:		Line 11:
	== Future: Maemo Platform ==		== Future: Maemo Platform ==

	Maemo Platform is defined as a set of software implementing the Maemo platform that is target-agnostic. This would be APIs, UI, reference themes, sounds, daemons, applications and data making together the basic Maemo platform that developers target.		Maemo Platform is defined as a set of software implementing the Maemo platform that is target-agnostic. This would be APIs, UI, reference themes, sounds, daemons, applications and data making together the basic Maemo platform that developers target. MP should be able to 'stand on it's own' on top of a reference platform and hence be complete in itself. The goal is that an application built for Maemo Platform will build for any Maemo Platform implementors.

	Software in Maemo platform would be developed in the public. There would be a shared collaboration space (Gitorious, for instance) hosting the software, with clear directions in maemo.org web on where to find the DVCS repositories. The Maemo platform would have public roadmaps for development.		Software in Maemo platform would be developed in the public. There would be a shared collaboration space (Gitorious, for instance) hosting the software, with clear directions in maemo.org web on where to find the DVCS repositories. The Maemo platform would have public roadmaps for development.

imported>stskeeps: /* Future: Mer */

2009-08-11T13:25:59Z

Future: Mer

← Older revision		Revision as of 13:25, 11 August 2009
Line 27:		Line 27:
	== Future: Mer ==		== Future: Mer ==

	The future Mer distribution (previously Mer-as-distro) would be based on Maemo Platform and be considered a mix of software with community-specific patches. It would be fully open source, usable and adaptable by any user or vendor.		The future Mer distribution (previously Mer-as-distro) would be based on Maemo Platform and be considered a mix of software with community-specific patches. It would be fully open source, usable and adaptable by any user or vendor.

			Mer gatekeeper(s) would maintain a cloned repository of a Maemo Platform package with a branch for Mer packaging, and a branch for Mer-specific patches, if any difference exists between Mer packaging and reference packaging.

	== Future: Maemo Harmattan ==		== Future: Maemo Harmattan ==

	The future Maemo Harmattan would be based on Maemo Platform. Vendor differentiation for certain devices would then be applied on top of Maemo platform and distribution of choice (Themes, applications, services, added value software, icons, firmware, device-specific APIs, etc.)		The future Maemo Harmattan would be based on Maemo Platform. Vendor differentiation for certain devices would then be applied on top of Maemo platform and distribution of choice (Themes, applications, services, added value software, icons, firmware, device-specific APIs, etc.)

imported>stskeeps: New page: '''(work in progress, a proposal/idea and not complete at all)''' == Now: Mer-as-distro and Mer-as-upstream == We operate with the terms 'Mer-as-distro' and 'Mer-as-upstream' in the Mer ...

2009-08-11T12:39:17Z

New page: '''(work in progress, a proposal/idea and not complete at all)''' == Now: Mer-as-distro and Mer-as-upstream == We operate with the terms 'Mer-as-distro' and 'Mer-as-upstream' in the Mer ...

New page

'''(work in progress, a proposal/idea and not complete at all)'''

== Now: Mer-as-distro and Mer-as-upstream ==

We operate with the terms 'Mer-as-distro' and 'Mer-as-upstream' in the Mer project.

This refers to two views on Mer. Mer-as-distro is the distribution / the mix of packages + the hardware support packages which represents the open and portable OS developed by the maemo.org community.

Mer-as-upstream represents the target-agnostic set of software. It's the current set of Maemo Fremantle packages, modified to build on top of modern distributions and not rely on being compiled in Scratchbox, or installed on a Nokia Internet Tablet.

== Future: Maemo Platform ==

Maemo Platform is defined as a set of software implementing the Maemo platform that is target-agnostic. This would be APIs, UI, reference themes, sounds, daemons, applications and data making together the basic Maemo platform that developers target.

Software in Maemo platform would be developed in the public. There would be a shared collaboration space (Gitorious, for instance) hosting the software, with clear directions in maemo.org web on where to find the DVCS repositories. The Maemo platform would have public roadmaps for development.

Each piece of software would have one or more maemo.org members (Maemo Devices developers are included in this set) as gatekeepers for what contributed patches gets merged in to the software.

Each piece of software would be considered seperately released and not focused onto specific releases of neither Mer or Maemo - when you have a fix and you consider the current state release-worthy, a release is tagged.

Each piece of software would have a roadmap determined by the gatekeepers based on the public roadmap. Gatekeepers would generate tasks based on this roadmap which contributors can choose to take upon him/herself to do (see maemo.org sprint process, Mer sprintweb) in cooperation with gatekeepers & mentors.

Each piece of software would have reference packaging (seperated in branches) to base distro-specific packaging on.

All bugs related to Maemo Platform would be maintained in bugs.maemo.org.

== Future: Mer ==

The future Mer distribution (previously Mer-as-distro) would be based on Maemo Platform and be considered a mix of software with community-specific patches. It would be fully open source, usable and adaptable by any user or vendor.

== Future: Maemo Harmattan ==

The future Maemo Harmattan would be based on Maemo Platform. Vendor differentiation for certain devices would then be applied on top of Maemo platform and distribution of choice (Themes, applications, services, added value software, icons, firmware, device-specific APIs, etc.)