Warning, /sysadmin/repo-metadata/README.md is written in an unsupported language. File is not indexed.

0001 This repository holds metadata about KDE's projects and their organisation.
0002 
0003 # Managing Projects
0004 
0005 All projects live as individual directories inside the `projects-invent/` directory. Inside `projects/` are the top-level groups, matching those you'll find on Gitlab.
0006 Under each group (such as `projects-invent/frameworks/`) are the projects themselves that form part of that group.
0007 
0008 ## File Structures
0009 
0010 The first file you'll deal with in each project is the `metadata.yaml` file. Here's a sample `metadata.yaml`:
0011 
0012 
0013     bugzilla:
0014       product: spectacle
0015       __do_not_use-legacy-product: ksnapshot
0016     description: The new screenshot capture utility, replaces KSnapshot
0017     hasrepo: true
0018     name: Screenshot Capture Utility
0019     projectpath: kde/kdegraphics/spectacle
0020     repoactive: true
0021     repopath: graphics/spectacle
0022     identifer: spectacle
0023 
0024 First, the mandatory fields. The fields `name` and `description` are to provide a name and description for the project. `projectpath` contains the logical path (in KDE's organisation structure) to the project. Currently, multiple scripts use this information and we don't generate it from the actual on disk path, so this field is mandatory. `identifier` is the unique name used to identify the project across all the groups (as the same repository name could be used in multiple groups).
0025 
0026 If your project has a repo, you'll need to set `hasrepo` to `true`. If `hasrepo` is `true`, then you'll have to define two more fields - `repopath`, a path to the repository on disk, and `repoactive`, stating if the repo is active.
0027 
0028 The `bugzilla` dictonary tells what is the corrent `product`/`component` for bugzilla. `__do_not_use-legacy-product` points to obsolute product, that was used in past.
0029 
0030 The next file you'll deal with is `i18n.json`. This file is much simpler to interpret. Here's an example:
0031 
0032     {
0033         "trunk": "none",
0034         "stable": "none",
0035         "stable_kf5": "Applications/15.12",
0036         "trunk_kf5": "master"
0037     }
0038 
0039 This file contains a single JSON object, where the key is the i18n branch and the value is the corresponding branch in your Git repository. It couldn't be any simpler.