Upstream Release Monitoring

TLDR; Get Packages Monitored

Get bug reports for a project’s releases in Fedora’s Bugzilla with three steps:

  1. Add the project to Anitya.

  2. Map the project to a Fedora package in Anitya.

  3. Tweak the monitoring setting for your packages at Fedora Package Sources.

Bugzilla bugs by the-new-hotness

Details

One of the core foundation of Fedora is First which implies having the latest versions of software (in rawhide and sometimes in released branches), but as a package maintainer it can be tedious to keep up with the releases from multiple projects.

Fedora thus offers a service to help with this. This service is divided into three components:

Anitya

Available at release-monitoring.org, Anitya provides a web service where anyone can register a project. Anitya will then broadcast a fedmsg message when it finds a new release. Checks are run by cron twice a day.

Anitya is not specific to Fedora but we are using it as a way to learn about new releases. Edit entries there to your heart’s content.

Bugs, features request and patches should go to anitya/issues.

Monitoring settings at src.fedoraproject.org

Fedora package maintainers can use the bottom left column at the package’s page at src.fedoraproject.org to have it monitored by the-new-hotness (see below).

The-New-Hotness

The-new-hotness is an application that listens to the fedmsg bus and acts upon receiving messages from release-monitoring.org.

When it receives a message indicating that a project has a new release, and that project is mapped to a Fedora package, it will check in pkgdb2 if the Fedora package is marked to be monitored.

If the package is marked to be monitored, the-new-hotness will open a ticket on Bugzilla mentioning the availability of the new release. It will then clone the git repository, bump the version and reset the release, download the new sources (if it can) and attempt a scratch build in koji.

The result of the scratch build is then added to the open bugzilla ticket.

Subsequent successful koji builds are added to the ticket as well.

In some cases the scratch build will always fail (for example if the Source0 in the spec file cannot be adjusted automatically), if you wish to avoid receiving the notification that the scratch-build failed, you can set the monitoring flag in pkgdb2 to nobuild (or Bugs only). Then the bugzilla ticket will be created upon finding a new version, but no scratch build will be made.