pingou/releng/fedora-scm-requests

A ticket queue for Fedora SCM admin requests | https://fedoraproject.org/wiki/Changes/ArbitraryBranching

fedora-scm-requests

A ticket queue for dist-git requests and a repository for Bugzilla assignee overrides

Tickets For "dist-git" Requests

All tickets must be submitted using fedrepo-req. This allows other tooling to programmatically process tickets in a format it expects.

Repository Structure

The root of the repository contains a list of directories representing the namespaces in Pagure over dist-git (e.g. rpms). Within those directories, YAML files will be named after components. The contents of those YAML files will be in the format of a dictionary, with each key being an option for the repo.

Bugzilla Assignee Overrides

This repository is used to override the default Bugzilla ticket assignees on a component in a product (e.g "Fedora EPEL" or "Fedora"). By default, the Bugzilla ticket assignee is the main admin of the component (e.g. rpms/python-requests) in Pagure over dist-git.

To override the default assignee in Bugzilla, find/or create the YAML file that configures the repository you want to set (e.g. rpms/python-requests). The bugzilla_contact key in the YAML file is used to override this with a dictionary, where each key represents a product (e.g. "Fedora EPEL" or "Fedora"). Each value should specify the FAS username or FAS group (groups are signified by starting with a "@") of the default Bugzilla ticket assignee for the component in that product.

Anitya setting

This repository allows you to specify the level to monitoring you would like your package to have with anitya. Setting or changing this setting is easy, fork this project, clone the git repository, add or find your package (see the different under the folders corresponding to each namespace: container, modules, rpms) and add or edit to anitya setting which can be any one of:

monitoring: monitoring-with-scratch
monitoring: no-monitoring
monitoring: monitoring

the-new-hotness will then use this setting to know if new released should be monitored or not and if a scratch build should be attempted or not.