< Infrastructure
Revision as of 22:07, 24 July 2013 by Mpyne (talk | contribs) (Introduce infrastructure documentation for kde-build-metadata)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

KDE Project Metadata

Metadata describing the Git repositories that make up KDE software, and the relationships between those repositories, are contained in two different sources.

  1. A KDE Projects Management website, where various data about individual repos can be altered by git repository maintainers, including which branches are considered 'stable' and 'development' branches for i18n purposes.
  2. Metadata about the relationships between individual repositories are kept in a separate git repository, kde-build-metadata.

kde-build-metadata

The kde-build-metadata repository contains several files which can be used by scripts and automated programs to properly handle the KDE git repositories. As of this writing there are several files that make up this repository:

  • build-script-ignore: This file contains a list of git repositories that should be ignored by scripts used to build the KDE source repositories. Empty lines and comments (prefixed by a #) are permitted. Each other line should be the full kde-project path of a module to ignore. Most examples are for modules that simply have nothing to build and install, but other uses include convenience modules that duplicate functionality handled in other source code modules.
  • dependency-data: This file contains a list of dependencies between KDE git repositories. It is used by the kdesrc-build build script, and the continuous integration infrastructure.

Logical module grouping

Note
This section documents a proposed addition. Nothing actually uses this at this point, although it has been reviewed by some of the sysadmins.


In order to make it easy for the various groups building KDE software to get the version they wish, there is a proposal to add the concept of logical module groups so that scripts may automatically select the most appropriate branch for a given individual git repository.

The current proposal is to use a JSON file, with the following structure:

To be fleshed out.

Content is available under Creative Commons License SA 4.0 unless otherwise noted.