Package tiering
The tier idea has been abandoned: it requires deep changes in the infrastructure, and the benefit is unclear. The project is moving towards maintaining a smaller set of packages. Older packages can be accessed through older catalog releases.

Background

There are two significant problems with the OpenCSW catalog:

  1. Inconsistent quality of packages. Actively maintained, high quality packages coexist with long abandoned, unmaintained ones. It is believed that it might be a big turnoff for users who happen to first try a broken, unmaintained package and that forms their opinion about the whole catalog.
  2. Stable release testing. There is no manpower to test every package in the catalog for the purposes of the stable branch. However, it's possible to narrow down the scope of testing, by selecting a subset of packages. This has been discussed in Oslo1 and Dublin.

Overview

There are two base categories of packages: whether they are actively maintained or not, and whether they are important packages, e.g. they are part of SAMP stack, or the GNU userland. The set of important packages is determined by the community. Packages, based on their classification, are sorted into 3 tiers: core, main and unsupported.

maintained unmaintained
important core unsupported
not important main unsupported

Criteria

The packages assigned to specific tiers must match the following criteria:

core

  • assigned to an active maintainer2
  • possible to take over by another maintainer if the original maintainer is unavailable or not responding
  • the build description is submitted to the source code repository3 and verified to be working by another maintainer
  • all the dependencies of the package are also in core

main

  • assigned to an active maintainer

unsupported

  • all other packages

Caveats

Some problems are inevitable. Some packages which are a very common dependency might be orphaned. In such a case, a new maintainer must be assigned. It could be done either by recruiting a volunteer on the maintainers mailing list, or assigning the package to one of the owners of dependent packages. In other cases, the dependent package might be rebuilt without the optional dependency so it could be dropped. Alternately, The dependent package could be split into multiple packages such that the tier 1 portion has no dependency on the orphaned package and the optional portion of the package that needs the dependency would become a tier 2 package. For instance:

CSWfoo is a candidate for core, but it depends on orphaned CSWbar. In such case, a new package CSWfoo-bar can be created.

  • CSWfoo (core) (no dependency on CSWbar)
  • CSWfoo-bar (2) → CSWbar (t2)

This is only useful when the dependency is soft/optional.

See also

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License