Extras repository process definition - Revision history

imported_>andre: Protected "Extras repository process definition" [edit=autoconfirmed:move=autoconfirmed]

2012-06-14T14:10:15Z

Protected "Extras repository process definition" [edit=autoconfirmed:move=autoconfirmed]

← Older revision	Revision as of 14:10, 14 June 2012
(No difference)

imported_>andre: Reverted edits by 94.23.1.28 (Talk); changed back to last version by Josh

2012-06-14T14:10:04Z

Reverted edits by 94.23.1.28 (Talk); changed back to last version by Josh

← Older revision		Revision as of 14:10, 14 June 2012
Line 4:		Line 4:
	The Extras repository needs to maintain a high level of quality applications.		The Extras repository needs to maintain a high level of quality applications.

	~~This~~ is ~~way better than~~ a ~~brick & mroatr establishment~~.		=== Nokia ===
			* There are many applications that would increase the value of our product(s), but we must guarantee:
			** Quality (Quality)
			** Ease of use (Simplicity)
			* We want to empower the community to push and promote the software they think is good enough for that. For this we think a centralized aproach makes sense and will make things easier", "simpler" and adds service—without compromising the open source ideal. (Simplicity, centric, scalability)
			* We must keep security in mind—nobody must be able to inject bad packages etc... (Security, Control)
			* We want to attract new developers and give them a guided testing bed. (Iterative)

	=== Developers ===		=== Developers ===

94.23.1.28: /* Nokia */

2012-06-14T03:30:13Z

Nokia

← Older revision		Revision as of 03:30, 14 June 2012
Line 4:		Line 4:
	The Extras repository needs to maintain a high level of quality applications.		The Extras repository needs to maintain a high level of quality applications.

	~~=== Nokia ===~~		This is way better than a brick & mroatr establishment.
	* There are many applications that would increase the value of our product(s), but we must guarantee:
	** Quality (Quality)
	** Ease of use (Simplicity)
	* We want to empower the community to push and promote the software they think is good enough for that. For this we think a centralized aproach makes sense and will make things easier", "simpler" and adds service—without compromising the open source ideal. (Simplicity, centric, scalability)
	* We must keep security in mind—nobody must be able to inject bad packages etc... (Security, Control)
	* We want to attract new developers and give them a ~~guided testing bed~~. ~~(Iterative)~~

	=== Developers ===		=== Developers ===

imported_>josh: /* Quality Assurance */ piuparts

2009-08-31T11:21:26Z

Quality Assurance: piuparts

← Older revision		Revision as of 11:21, 31 August 2009
Line 141:		Line 141:
	* Nokia to include extras apps in their own testing.		* Nokia to include extras apps in their own testing.
	* Specific QA routines to be defined for extras apps being promoted in maemo.nokia.com or other marketing activities.		* Specific QA routines to be defined for extras apps being promoted in maemo.nokia.com or other marketing activities.
			* Automated use of Debian tools like [http://wiki.debian.org/piuparts piuparts] would help find issues with installing, upgrading, downgrading, and removing packages.

	== Links ==		== Links ==

imported_>jeremiah: /* Analysis of current situation */

2009-05-26T12:17:51Z

Analysis of current situation

← Older revision		Revision as of 12:17, 26 May 2009
Line 2:		Line 2:

	== Analysis of current situation ==		== Analysis of current situation ==
	Extras needs to ~~satisfy the requirements and desires of~~ a ~~number~~ of ~~groups~~.		The Extras repository needs to maintain a high level of quality applications.

	=== Nokia ===		=== Nokia ===
	* There are many applications that would increase the ~~wealth~~ of our product, but we must guarantee:		* There are many applications that would increase the value of our product(s), but we must guarantee:
	** Quality (Quality)		** Quality (Quality)
	** Ease of use (Simplicity)		** Ease of use (Simplicity)
Line 14:		Line 14:
	=== Developers ===		=== Developers ===
	* We have problems promoting their software. (Promote)		* We have problems promoting their software. (Promote)
	* It is difficult to assure that the application is installing and running well on all devices. (Quality ~~assurance~~)		* It is difficult to assure that the application is installing and running well on all devices. (Quality Assurance)
	* There are multiple platforms that we need to build manually for. (Build ~~management~~)		* There are multiple platforms that we need to build manually for. (Build Management)
	* We have problems to coordinating our work with the work of other developers—especially if using common libraries. (Coordination)		* We have problems to coordinating our work with the work of other developers—especially if using common libraries. (Coordination)
	* Not every developer is ~~similar~~. The process must support:		* Not every developer is alike. The process must support:
	** Garage projects		** Garage projects
	** External projects with local packaging		** External projects with local packaging

72.19.127.9: /* Bugzilla */

2009-01-07T20:21:19Z

Bugzilla

← Older revision		Revision as of 20:21, 7 January 2009
Line 64:		Line 64:

	* Each extras package should have its own defined bug tracking system (either in garage or a component in bugs.maemo.org?).		* Each extras package should have its own defined bug tracking system (either in garage or a component in bugs.maemo.org?).
	** Ensuring that each package has ~~it's~~ own bug-tracking system isn't feasible. What about trivial make/compile ports, and packages which are adapted from debian largely unchanged. These will appropriately have essentially no maemo-specific infrastructure, and will have infrastructure upstream instead. Also consider the case of a very immature project with a single developer who hasn't created infrastructure yet.		** Ensuring that each package has its own bug-tracking system isn't feasible. What about trivial make/compile ports, and packages which are adapted from debian largely unchanged. These will appropriately have essentially no maemo-specific infrastructure, and will have infrastructure upstream instead. Also consider the case of a very immature project with a single developer who hasn't created infrastructure yet.
	** Instead, extras should have ~~it's~~ own bug-tracker which applies to extras as a whole.		** Instead, extras should have its own bug-tracker which applies to extras as a whole.
	** Each package should have an owner, who may or may not be the upstream developer. The owner must watch the extras bug-tracker for bugs submitted against their packages.		** Each package should have an owner, who may or may not be the upstream developer. The owner must watch the extras bug-tracker for bugs submitted against their packages.
	** Bugs which are appropriately resolved upstream should be resubmitted there, either by the package owner, or by closing the bug wontfix with a comment that certain types of need to be dealt with upstream and a polite message requesting that the submitter resubmit the bug there.		** Bugs which are appropriately resolved upstream should be resubmitted there, either by the package owner, or by closing the bug wontfix with a comment that certain types of need to be dealt with upstream and a polite message requesting that the submitter resubmit the bug there.

66.234.51.197: /* Bugzilla */

2008-11-21T14:39:48Z

Bugzilla

← Older revision		Revision as of 14:39, 21 November 2008
Line 64:		Line 64:

	* Each extras package should have its own defined bug tracking system (either in garage or a component in bugs.maemo.org?).		* Each extras package should have its own defined bug tracking system (either in garage or a component in bugs.maemo.org?).
			** Ensuring that each package has it's own bug-tracking system isn't feasible. What about trivial make/compile ports, and packages which are adapted from debian largely unchanged. These will appropriately have essentially no maemo-specific infrastructure, and will have infrastructure upstream instead. Also consider the case of a very immature project with a single developer who hasn't created infrastructure yet.
			** Instead, extras should have it's own bug-tracker which applies to extras as a whole.
			** Each package should have an owner, who may or may not be the upstream developer. The owner must watch the extras bug-tracker for bugs submitted against their packages.
			** Bugs which are appropriately resolved upstream should be resubmitted there, either by the package owner, or by closing the bug wontfix with a comment that certain types of need to be dealt with upstream and a polite message requesting that the submitter resubmit the bug there.
			** Extras is essentially a linux distro. The above bug handling strategies are used by every major distro on the planet, we should use them too.
	* Try to synchronize application bug tracking system with upstream bug tracking system.		* Try to synchronize application bug tracking system with upstream bug tracking system.

imported_>qgil: /* Quality Assurance */

2008-11-21T09:30:00Z

Quality Assurance

← Older revision		Revision as of 09:30, 21 November 2008
Line 134:		Line 134:
	* Objective criteria to demote a package from extras to testing/devel?		* Objective criteria to demote a package from extras to testing/devel?
	** What would happen to regular users with that package installed? They might be confused if a human-readable notification doesn't tell them what's going on.--[[User:qgil\|qgil]] 09:28, 21 November 2008 (UTC)		** What would happen to regular users with that package installed? They might be confused if a human-readable notification doesn't tell them what's going on.--[[User:qgil\|qgil]] 09:28, 21 November 2008 (UTC)
			* Nokia to include extras apps in their own testing.
			* Specific QA routines to be defined for extras apps being promoted in maemo.nokia.com or other marketing activities.

	== Links ==		== Links ==

imported_>qgil: /* Quality Assurance */

2008-11-21T09:28:13Z

Quality Assurance

← Older revision		Revision as of 09:28, 21 November 2008
Line 125:		Line 125:

	Your ideas here.		Your ideas here.

			* Visibility and promotion of [http://maemo.org/maemo_release_documentation/maemo4.1.x/node16.html Quality considerations] for application developers.
			** A checkbox requesting the developer to say 'Yes, I'm aware of the quality considerations and I have done my best implementing them in my software"? Might sound a bit stupid and totally by-passable but it might be a good promotion of these quality considerations.--[[User:qgil\|qgil]] 09:28, 21 November 2008 (UTC)
			* Perhaps a very basic and descriptive list of Very Basic Testing to do in each release?
			* Automated testing, what can be done on the server side?
			* Some days of quarantene in extras-testing when promoting a package from extras-devel, no matter what?
			** Hum, falling again in the unstable-testing-stable paradigm.--[[User:qgil\|qgil]] 09:28, 21 November 2008 (UTC)
			* Objective criteria to demote a package from extras to testing/devel?
			** What would happen to regular users with that package installed? They might be confused if a human-readable notification doesn't tell them what's going on.--[[User:qgil\|qgil]] 09:28, 21 November 2008 (UTC)

	== Links ==		== Links ==

imported_>qgil: /* Solution strategies */

2008-11-21T09:17:30Z

Solution strategies

← Older revision		Revision as of 09:17, 21 November 2008
Line 121:		Line 121:

	* [http://www.hadrons.org/~guillem/debian/docs/origin.proposal Origin field in deb]		* [http://www.hadrons.org/~guillem/debian/docs/origin.proposal Origin field in deb]

			=== Quality Assurance ===

			Your ideas here.

	== Links ==		== Links ==