Überwachung von Upstream-Veröffentlichungen

TLDR; Pakete überwachen lassen

Mit drei Schritten können Sie Fehlerberichte für die Veröffentlichungen eines Projekts in Fedoras Bugzilla abrufen:

Fügen Sie das Projekt zu Anitya hinzu.
Ordnen Sie das Projekt einem Fedora-Paket in Anitya zu.
Passen Sie die Überwachungseinstellungen für Ihre Pakete unter Fedora Package Sources an.

Bugzilla-Fehlerberichte von the-new-hotness

Details

Eine der Kerngrundlagen von Fedora ist First, was bedeutet, dass man immer die neuesten Softwareversionen hat (in Rawhide und manchmal auch in veröffentlichten Zweigen). Für einen Paketbetreuer kann es jedoch mühsam sein, mit den Veröffentlichungen mehrerer Projekte Schritt zu halten.

Fedora bietet daher einen Dienst an, der dabei hilft. Dieser Dienst ist in drei Komponenten unterteilt:

Anitya
Überwachungseinstellungen in Fedora Package Sources
The-new-hotness

Anitya

Anitya ist auf release-monitoring.org verfügbar und bietet einen Webdienst, über den jeder ein Projekt registrieren kann. Sobald eine neue Version verfügbar ist, sendet Anitya eine Nachricht an fedmsg. Die Überprüfung erfolgt zweimal täglich per Cronjob.

Anitya ist nicht spezifisch für Fedora, aber wir nutzen es, um uns über neue Versionen zu informieren. Bearbeiten Sie dort nach Herzenslust Einträge.

Fehlerberichte, Funktionsanfragen und Patches sollten an anitya/issues gesendet werden.

Überwachungseinstellungen auf src.fedoraproject.org

Fedora-Paketbetreuer können die Spalte unten links auf der Paketseite unter src.fedoraproject.org verwenden, um das Paket von the-new-hotness überwachen zu lassen (siehe unten).

The-New-Hotness

The-new-hotness ist eine Anwendung, die den fedmsg-Bus abhört und auf den Empfang von Nachrichten von release-monitoring.org reagiert.

Wenn eine Meldung eingeht, die darauf hinweist, dass ein Projekt eine neue Version hat und dieses Projekt einem Fedora-Paket zugeordnet ist, prüft das System in pkgdb2, ob das Fedora-Paket zur Überwachung markiert ist.

Wenn das Paket zur Überwachung markiert ist, erstellt „the-new-hotness“ ein Ticket auf Bugzilla, in dem die Verfügbarkeit der neuen Version vermerkt wird. Anschließend wird das Git-Repository geklont, die Versionsnummer erhöht und das Release zurückgesetzt, die neuen Quellen heruntergeladen (sofern verfügbar) und ein Scratch-Build in Koji versucht.

Das Ergebnis des Scratch-Builds wird dann zum offenen Bugzilla-Ticket hinzugefügt.

Weitere erfolgreiche Koji-Builds werden ebenfalls zum Ticket hinzugefügt.

In manchen Fällen schlägt der Scratch-Build immer fehl (z.B. wenn Source0 in der Spec-Datei nicht automatisch angepasst werden kann). Um Benachrichtigungen über fehlgeschlagene Scratch-Builds zu vermeiden, können Sie das Monitoring-Flag in pkgdb2 auf nobuild (oder Bugs only) setzen. Dann wird beim Auffinden einer neuen Version ein Bugzilla-Ticket erstellt, aber kein Scratch-Build durchgeführt.