OpenSuse Build Service - Revision history

timoph: /* Basics */

2012-05-02T09:03:31Z

Basics

← Older revision		Revision as of 09:03, 2 May 2012
Line 28:		Line 28:
	* [[/Autobuild\|An OBS Autobuilder queue]] - not started		* [[/Autobuild\|An OBS Autobuilder queue]] - not started
	* [[/Reporting\|Reporting]] - not started		* [[/Reporting\|Reporting]] - not started
		+	* [[Task:Maemo_OBS\|Task page for Maemo OBS]]

	[[Category:OpenSuse build service]]		[[Category:OpenSuse build service]]

amigadave: cut toplevel heading

2011-02-11T10:53:38Z

cut toplevel heading

← Older revision		Revision as of 10:53, 11 February 2011
Line 1:		Line 1:
-	~~= OBS Intro =~~
-
	== Our Goals ==		== Our Goals ==
	We want:		We want:

amigadave: Category:OpenSuse build service

2010-06-18T13:29:48Z

Category:OpenSuse build service

← Older revision		Revision as of 13:29, 18 June 2010
Line 30:		Line 30:
	* [[/Autobuild\|An OBS Autobuilder queue]] - not started		* [[/Autobuild\|An OBS Autobuilder queue]] - not started
	* [[/Reporting\|Reporting]] - not started		* [[/Reporting\|Reporting]] - not started
		+
		+	[[Category:OpenSuse build service]]

amigadave: /* Basics */ link to Chinook setup WIP

2010-06-18T09:55:34Z

Basics: link to Chinook setup WIP

← Older revision		Revision as of 09:55, 18 June 2010
Line 24:		Line 24:
	* [[/Installation\|OBS Installation]] - a detailed guide on how the system was setup.		* [[/Installation\|OBS Installation]] - a detailed guide on how the system was setup.
	* [[/Application QA Process\|Application QA Process on the OBS]] - a proposal		* [[/Application QA Process\|Application QA Process on the OBS]] - a proposal
		+	* [[/Chinook Setup\|Setting up Chinook]] - WIP
	* [[/Fremantle_Setup\|Setting up Fremantle]] - WIP.		* [[/Fremantle_Setup\|Setting up Fremantle]] - WIP.
	* [[/MeeGo_Setup\|Setting up MeeGo]] - WIP.		* [[/MeeGo_Setup\|Setting up MeeGo]] - WIP.

lbt: /* Basics */

2010-06-12T13:44:25Z

Basics

← Older revision		Revision as of 13:44, 12 June 2010
Line 25:		Line 25:
	* [[/Application QA Process\|Application QA Process on the OBS]] - a proposal		* [[/Application QA Process\|Application QA Process on the OBS]] - a proposal
	* [[/Fremantle_Setup\|Setting up Fremantle]] - WIP.		* [[/Fremantle_Setup\|Setting up Fremantle]] - WIP.
		+	* [[/MeeGo_Setup\|Setting up MeeGo]] - WIP.
	* [[/Cross_Setup\|Setting up cross-building]] - started, not imported yet		* [[/Cross_Setup\|Setting up cross-building]] - started, not imported yet
	* [[/Autobuild\|An OBS Autobuilder queue]] - not started		* [[/Autobuild\|An OBS Autobuilder queue]] - not started
	* [[/Reporting\|Reporting]] - not started		* [[/Reporting\|Reporting]] - not started

lbt: /* Basics */

2010-05-08T11:56:34Z

Basics

← Older revision		Revision as of 11:56, 8 May 2010
Line 22:		Line 22:

	Some tasks needed to get the OBS running:		Some tasks needed to get the OBS running:
-	* [[/Installation\|OBS Installation]]	+	* [[/Installation\|OBS Installation]] - a detailed guide on how the system was setup.
-	* [[/Application QA Process\|Application QA Process on the OBS]]	+	* [[/Application QA Process\|Application QA Process on the OBS]] - a proposal
-	* [[/Fremantle_Setup\|Setting up Fremantle]]	+	* [[/Fremantle_Setup\|Setting up Fremantle]] - WIP.
-	* [[/Cross_Setup\|Setting up cross-building]]	+	* [[/Cross_Setup\|Setting up cross-building]] - started, not imported yet
-	* [[/Autobuild\|An OBS Autobuilder queue]]	+	* [[/Autobuild\|An OBS Autobuilder queue]] - not started
-	* [[/Reporting\|Reporting]]	+	* [[/Reporting\|Reporting]] - not started

lbt: How do we move to an OBS

2010-05-08T11:55:16Z

How do we move to an OBS

Show changes

lbt: Undo revision 34022 by lbt (Talk)

2010-05-08T11:07:11Z

Undo revision 34022 by lbt (Talk)

← Older revision		Revision as of 11:07, 8 May 2010
Line 1:		Line 1:
	[[/Installation \| Installing OpenSuse Build Service]] is a prerequisite for setting up a specific OBS project.		[[/Installation \| Installing OpenSuse Build Service]] is a prerequisite for setting up a specific OBS project.

-
-	In a closed environment you use what's in the SDK and you get your own little space; talking to others is discouraged and sharing and re-use outside the blessed area is frowned upon. This dictatorial style has the advantage of making life easier for the vendor. In an open world we have more interactions... and as students of networks know: increased connectivity brings increased complexity as well as increased benefits. So this is an initial proposal for the organisation of OBS build projects and packages to support a QA process into an app-store / Extras or garage -like environment. I'll introduce some basic OBS concepts and then describe how this might work. I would like this to raise awareness of some potential complexities that we may face and get some thoughts on how to deal with them.
-
-
-	~~OBS Intro~~
-
-	~~Lets set out some basics about the OBS.~~
-
-	~~1. It's a build system. You put source on it and say "use this repository" and it builds a minimal SDK-like chroot using the deb/rpms it finds in that repository~~
-	~~2. It has packages - a package corresponds to a tarball and a spec/dsc~~
-	~~3. It has projects - a project is like a directory with packages~~
-	~~4. When a package is built it is 'published' from the project where it was uploaded into a corresponding repository (which can be used to build other projects)~~
-	~~5. The repositories can also be used by devices to download binary packages.~~
-
-	~~The 'trick' then, is to set up a structure of projects that we can use to support the publishing and sharing activities that we need.~~
-
-
-	~~Our Goals~~
-
-	~~We want to allow freedom for developers to develop;~~
-
-	~~We want to provide excellent quality assured applications for our "app store";~~
-
-	~~We want to extend the core distro with a community supported Surrounds area for libraries and packages that are depended upon by more than one application.~~
-
-
-	~~Individual Homes~~
-
-	You'll start by uploading and building a package in your "home" directory (which can have a structure underneath it for multiple projects). This will allow you to build against any of the main distros; any group/community projects or even any other community member home projects. Oh, and they can use your code as a baseline too. Once built your code is automatically published to a repo on the community downloads server.
-
-
-
-	~~This is a lot like the Ubuntu PPA solution.~~
-
-
-
-	At that point you can stop if you want. You have a complete set of repositories (1/subproject). No painful QA processes. No 'fragmentation'. But equally your repo(s) will needed to be manually added to a device in order for it to appear in any apt-get/zypper/yum etc.
-
-
-	~~A huge benefit here is that to get at a development version of an application you use a specific repository, not a mishmash of randomly unstable packages like Extras-devel.~~
-
-
-	~~Community Repository - Extras~~
-
-	~~If you'd like your application to appear in the Extras repo which is pre-installed on devices then you can submit to the QA process.~~
-
-
-	First you register for the package name (a thought occurs... should this namespace be the same as the distro package namespace?), then submit your code to the distro promoter; there it is QA checked, copied to Extras:Testing, built, QA'ed again and becomes available in the Testing repository.
-
-
-	~~<here be dragons>~~
-
-	~~The community testers then approve your code.~~
-
-	~~</dragons>~~
-
-
-	~~Once approved the code is built or copied to Extras:Stable a final time~~
-
-
-	~~General Building~~
-
-
-	~~First off we need to build against releases of vanilla distros; these all support both i586 & arm~~
-
-
-	~~MeeGo:name-number~~
-
-	~~Maemo:Fremantle~~
-
-	~~Maemo:Harmattan~~
-
-
-	~~I anticipate that there will be a community library around MeeGo (like MUD for Maemo or Universe for Ubuntu). These would cover that~~
-
-
-	~~MeeGo:name-number:Surrounds~~
-
-	~~Maemo:Fremantle:Surrounds~~
-
-	~~Maemo:Harmattan:Surrounds~~
-
-
-	~~Or, for more platform oriented users we may need to build against bleeding edge codesets:~~
-
-	~~MeeGo:Trunk~~
-
-	~~MeeGo:snap:latest~~
-
-	~~MeeGo:snap:w13~~
-
-	~~Maemo:Harmattan:alpha1~~
-
-	~~[[/Fremantle_Setup\|Setting up Fremantle]]~~

	= Fremantle =		= Fremantle =

lbt: /* Fremantle */

2010-05-08T11:05:23Z

Fremantle

← Older revision		Revision as of 11:05, 8 May 2010
Line 1:		Line 1:
	[[/Installation \| Installing OpenSuse Build Service]] is a prerequisite for setting up a specific OBS project.		[[/Installation \| Installing OpenSuse Build Service]] is a prerequisite for setting up a specific OBS project.

		+
		+	In a closed environment you use what's in the SDK and you get your own little space; talking to others is discouraged and sharing and re-use outside the blessed area is frowned upon. This dictatorial style has the advantage of making life easier for the vendor. In an open world we have more interactions... and as students of networks know: increased connectivity brings increased complexity as well as increased benefits. So this is an initial proposal for the organisation of OBS build projects and packages to support a QA process into an app-store / Extras or garage -like environment. I'll introduce some basic OBS concepts and then describe how this might work. I would like this to raise awareness of some potential complexities that we may face and get some thoughts on how to deal with them.
		+
		+
		+	OBS Intro
		+
		+	Lets set out some basics about the OBS.
		+
		+	1. It's a build system. You put source on it and say "use this repository" and it builds a minimal SDK-like chroot using the deb/rpms it finds in that repository
		+	2. It has packages - a package corresponds to a tarball and a spec/dsc
		+	3. It has projects - a project is like a directory with packages
		+	4. When a package is built it is 'published' from the project where it was uploaded into a corresponding repository (which can be used to build other projects)
		+	5. The repositories can also be used by devices to download binary packages.
		+
		+	The 'trick' then, is to set up a structure of projects that we can use to support the publishing and sharing activities that we need.
		+
		+
		+	Our Goals
		+
		+	We want to allow freedom for developers to develop;
		+
		+	We want to provide excellent quality assured applications for our "app store";
		+
		+	We want to extend the core distro with a community supported Surrounds area for libraries and packages that are depended upon by more than one application.
		+
		+
		+	Individual Homes
		+
		+	You'll start by uploading and building a package in your "home" directory (which can have a structure underneath it for multiple projects). This will allow you to build against any of the main distros; any group/community projects or even any other community member home projects. Oh, and they can use your code as a baseline too. Once built your code is automatically published to a repo on the community downloads server.
		+
		+
		+
		+	This is a lot like the Ubuntu PPA solution.
		+
		+
		+
		+	At that point you can stop if you want. You have a complete set of repositories (1/subproject). No painful QA processes. No 'fragmentation'. But equally your repo(s) will needed to be manually added to a device in order for it to appear in any apt-get/zypper/yum etc.
		+
		+
		+	A huge benefit here is that to get at a development version of an application you use a specific repository, not a mishmash of randomly unstable packages like Extras-devel.
		+
		+
		+	Community Repository - Extras
		+
		+	If you'd like your application to appear in the Extras repo which is pre-installed on devices then you can submit to the QA process.
		+
		+
		+	First you register for the package name (a thought occurs... should this namespace be the same as the distro package namespace?), then submit your code to the distro promoter; there it is QA checked, copied to Extras:Testing, built, QA'ed again and becomes available in the Testing repository.
		+
		+
		+	<here be dragons>
		+
		+	The community testers then approve your code.
		+
		+	</dragons>
		+
		+
		+	Once approved the code is built or copied to Extras:Stable a final time
		+
		+
		+	General Building
		+
		+
		+	First off we need to build against releases of vanilla distros; these all support both i586 & arm
		+
		+
		+	MeeGo:name-number
		+
		+	Maemo:Fremantle
		+
		+	Maemo:Harmattan
		+
		+
		+	I anticipate that there will be a community library around MeeGo (like MUD for Maemo or Universe for Ubuntu). These would cover that
		+
		+
		+	MeeGo:name-number:Surrounds
		+
		+	Maemo:Fremantle:Surrounds
		+
		+	Maemo:Harmattan:Surrounds
		+
		+
		+	Or, for more platform oriented users we may need to build against bleeding edge codesets:
		+
		+	MeeGo:Trunk
		+
		+	MeeGo:snap:latest
		+
		+	MeeGo:snap:w13
		+
		+	Maemo:Harmattan:alpha1
		+
		+	[[/Fremantle_Setup\|Setting up Fremantle]]

	= Fremantle =		= Fremantle =

dneary at 14:11, 4 May 2010

2010-05-04T14:11:19Z

← Older revision		Revision as of 14:11, 4 May 2010
Line 1:		Line 1:
-	[[/Installation \|\| Installing OpenSuse Build Service]] is a prerequisite for setting up a specific OBS project.	+	[[/Installation \| Installing OpenSuse Build Service]] is a prerequisite for setting up a specific OBS project.

← Older revision		Revision as of 09:55, 18 June 2010
Line 24:		Line 24:
	* [[/Installation\|OBS Installation]] - a detailed guide on how the system was setup.		* [[/Installation\|OBS Installation]] - a detailed guide on how the system was setup.
	* [[/Application QA Process\|Application QA Process on the OBS]] - a proposal		* [[/Application QA Process\|Application QA Process on the OBS]] - a proposal
		+	* [[/Chinook Setup\|Setting up Chinook]] - WIP
	* [[/Fremantle_Setup\|Setting up Fremantle]] - WIP.		* [[/Fremantle_Setup\|Setting up Fremantle]] - WIP.
	* [[/MeeGo_Setup\|Setting up MeeGo]] - WIP.		* [[/MeeGo_Setup\|Setting up MeeGo]] - WIP.

← Older revision		Revision as of 13:44, 12 June 2010
Line 25:		Line 25:
	* [[/Application QA Process\|Application QA Process on the OBS]] - a proposal		* [[/Application QA Process\|Application QA Process on the OBS]] - a proposal
	* [[/Fremantle_Setup\|Setting up Fremantle]] - WIP.		* [[/Fremantle_Setup\|Setting up Fremantle]] - WIP.
		+	* [[/MeeGo_Setup\|Setting up MeeGo]] - WIP.
	* [[/Cross_Setup\|Setting up cross-building]] - started, not imported yet		* [[/Cross_Setup\|Setting up cross-building]] - started, not imported yet
	* [[/Autobuild\|An OBS Autobuilder queue]] - not started		* [[/Autobuild\|An OBS Autobuilder queue]] - not started
	* [[/Reporting\|Reporting]] - not started		* [[/Reporting\|Reporting]] - not started

← Older revision		Revision as of 11:56, 8 May 2010
Line 22:		Line 22:

	Some tasks needed to get the OBS running:		Some tasks needed to get the OBS running:
-	* [[/Installation\|OBS Installation]]	+	* [[/Installation\|OBS Installation]] - a detailed guide on how the system was setup.
-	* [[/Application QA Process\|Application QA Process on the OBS]]	+	* [[/Application QA Process\|Application QA Process on the OBS]] - a proposal
-	* [[/Fremantle_Setup\|Setting up Fremantle]]	+	* [[/Fremantle_Setup\|Setting up Fremantle]] - WIP.
-	* [[/Cross_Setup\|Setting up cross-building]]	+	* [[/Cross_Setup\|Setting up cross-building]] - started, not imported yet
-	* [[/Autobuild\|An OBS Autobuilder queue]]	+	* [[/Autobuild\|An OBS Autobuilder queue]] - not started
-	* [[/Reporting\|Reporting]]	+	* [[/Reporting\|Reporting]] - not started