Build Service/Concepts/Factory
From openSUSE
Contents |
Factory Open Development
| This text is just a DRAFT or a braindump. Please get into the discussion! Do not consider this as a final complete concept. |
The openSUSE project plans to create the distribution as projects in the buildservice. That opens up the development of the distribution to the community and enables people to work directly on packages in the distribution.
However there are some issues with it. The openSUSE distribution is the base for the Novell Enterprise products which are going to be released on base of distributions that are successors of certain openSUSE releases. As a result it is crucial for the SUSE team to be able to monitor all changes that go into the Factory distribution very tightly. There has to be a reviewer process that checks all submissions to Factory and a team of responsible people such as project- and product managers, distro experts and build masters need to take decision on every change going into Factory.
This step should hinder creative work of all package maintainers as little as possible.
Upstream Packages
Therefore we introduce the concept of Upstream-Packages which every package in Distributions like Factory can have.
| Warning ! | The name Upstream Package is probably a bit confusing because it can be mixed up with upstream development. We're open for suggestions. |
An Upstream-Package is a package in any kind of project that acts as a test bed for the package before it goes to Factory. The Upstream-Package is usually maintained by a group of experts for the distinct package. They work on the package regularly and intensive and probably know best when it's time to switch the version for Factory. The Upstream-Maintainers often propose the switch which still needs to be approved by the product responsibility team.
For packages in Factory which have an Upstream-Package the source in the Factory package is replaced by a source link to a certain version of the Upstream-Package. Even if the upstream maintainer continue to work on the linked package, their work does not go into Factory immediately because of the link to a certain version.
If somebody wants to change a package in Factory which has an Upstream package the API automatically delivers the package with the sources of the version the Factory package links to. There might be the case that the Upstream Package already has a newer version than the one that is referenced by Factory, but that is not considered.
The Upstream Request
If a package wants to act as an Upstream Package of another package that is usually part of a project like Factory, an Upstream Request needs to be filed proposing the Upstream Package. The request has to be approved by the owner of the Factory project. There can only be one Upstream Package per Package. Cascaded Upstream Packages are not allowed at the moment to avoid brain burn.
The Merge Request
If an Upstream Package wants Factory to update to a later version of the Update Package a normal Merge Request needs to be filed which has to be approved.
Removal of Upstream Package
If the relationship is not longer wanted, the currently linked source version needs to be copied from the upstream package before the link is removed.

