Note: The ?WannaBuildInfrastructure is undergoing a larger reshape, thats why I not working on this project for now. See Projects/DebSrc3.0 (http://wiki.debian.org/Projects/DebSrc3.0) for more information.
Feel free to correct my mistakes or -understandings, either by editing these pages or participate on the discussion page, or sending comments to <<firstname.lastname@example.org>> with the subject line: "Comments to: Debian Wanna-Build Infrastructure", unless you want to end in my spambox.
For the time being, these pages are under heavily construction. Now, you're warned.
On these wiki pages, I'll try to describe how to install, configure and administer a Wanna-Build infrastructure composed of one wanna-build database and one or more build servers, aka Debian Autobuilder Network.
Before I do that, we must first understand the Debian Release Cycle in a overly simplyfied overview. Note, that the Debian Team uses releases and distributions interchangably. However, I stick to term repository rather than release and distribution, because I consider Debian as one distribution covering many (platform) architectures, where from at some point in time they officially make releases from.
The first and forever ongoing repository is the unstable repository, aka Sid, where the active development of Debian occurs. At some point in time or when a policy fires, the Team decide that they want to release a (new version of or) package from the repository and take a copy of the repository or the package from the unstable repository to the testing repository. When the testing repository and its packages has stabilized or when a policy fires, the Team decide that they want to officially release the (testing repository or a) package to the public, and thus take a copy of the (testing repository or) package to the stable repository and thereby it is released to the public.
Generally, The testing and stable repositories can only be changed with accepted proposed update and security patches.
The unstable repository is mainly changed by new upstream functionality or platform specific patches or by moving packages from experimental. Note, that the patches to the upstream only adhere to the Debian Platform Architecture (kernel, library, cpu and platform hardware used for that architecture), not to the functionality itself of the upstream software, this is left unchanged.
The stable repositories can only be changed with accepted proposed patches.
There are additional and third party repositories.
With this scheme, of repositories and policies of releasing new versions or packages, the further away you get from the unstable repository, the more stable, but older, the packages, and thus the software, you are using become. Thus, the newer computer you have, the more close you should get to the unstable repository.
In the beginning the Debian Team downloaded the debian software packages from one of the above repositories and build them at their own computeres, and uploaded the binary packages to the repository after successfull compilation. However, when the package repositories grew larger and more architectures entered into the distribution, Debian builders entered the scene to relief the Debian Team building binary packages.
A Wanna-Build infrastructure is composed of one wanna-build database related to a repository and one or more build servers communicating with this database. The database keeps track on the status of the building of the debian software packages from the related repository. Successfully builded binary packages can be uploaded to a repository by the build server(s).