Develop tooling to handle kde_projects.xml
Closed, ResolvedPublic

Description

With the demise of projects.kde.org in the move to Phabricator, we'll lose our current source of information (as well as the generation infrastructure) for kde_projects.xml

We therefore need to come up with alternative tooling for that. To maximise flexibility, i'd rather not tie it into Phabricator in any fashion, but have it completely decoupled. This will also allow us to shutdown projects.kde.org (a resource hog) before we move to Phabricator for repo hosting and reviews.

The kde_projects.xml file contains the following:

  1. The "tree" which puts repositories in given positions within the tree. 'amarok' goes at 'extragear/multimedia' for instance.
  2. The i18n metadata.

It has been a prior request from the Translations Co-Ordinator that regexes be used for determining the i18n metadata to save time and make updates easier. This would be the most ideal time to implement this.

In terms of the tree, I think we can implement a data source for that quite simply: A JSON file, which declares a branch (say extragear/multimedia) and the repositories that go within that. A script should then be able to split the branch names by the slashes and reconstruct that into a tree.

Project Maintainers can be dropped from the file - I see no need to maintain that information at this time, as we're going to be changing how repositories will be managed in the Phabricator world anyway.

bcooksley updated the task description. (Show Details)
bcooksley raised the priority of this task from to Normal.
bcooksley added a project: Phabricator.
bcooksley added a subscriber: bcooksley.
bgupta added a subscriber: bgupta.Mar 12 2016, 9:09 AM
bgupta claimed this task.Mar 12 2016, 5:53 PM

This is done on my local machine.

I've currently written two scripts - one which takes an existing kde_projects.xml from ChiliProject and creates a filesystem tree from it, and another which turns this tree back into a XML file. The filesystem tree contains metadata (name, description, maintainers etc) in one yaml file, and repository data in another yaml file

Support for patterned i18n branch settings are implemented via fnmatch style expressions which are matched against the project path ("frameworks/*" would match "frameworks/baloo", for example). Extending this to support full PCRE expressions won't be difficult, but is it necessary?

Any branches set by the global i18n pattern-based settings can be overriden per project using a i18n.json file in the project directory.