openSUSE:Factory-Entwicklungsmodell
 
|
Dieser Artikel wurde aus einem fremdsprachigen Wiki importiert und muss noch übersetzt, sowie an das deutschsprachige Wiki angepasst werden. Hier ist die Originalseite zu finden: en:openSUSE:Factory development model. Anmerkungen des Übersetzers: Aus eigenem Interesse übersetzen. Zeitstempel und Signatur des Autors/Übersetzer:--Buschmann23 (Diskussion) 15:37, 31. Aug. 2015 (UTC) |
Inhaltsverzeichnis
Entwicklungsmodell
Factory wird in einem eignen Projekt namens openSUSE:Factory auf dem Referenz-Server des Open Build Service gebaut. Wie man sieht handelt es sich dabei um ein riesiges Paketdepot. Die Entwicklung findet allerdings nicht direkt in openSUSE:Factory statt, sondern in so genannten Devel Projects. Ein Devel Project (Entwicklungsprojekt) ist, wie der Name schon sagt, ein Projekt, in dem die Entwicklung einer bestimmten Gruppe von Paketen stattfindet, wie etwa Multimedia, GNOME, KDE oder Kernel. Die Verbindung zwischen Paketen im Projekt openSUSE::Factory und Paketen in Devel Projects wird in den Metadaten der Pakte in openSUSE:Factory festgelegt.
Devel-Projekte
Jedes Devel Project nutzt eigene Prozesse, Regeln und Kommunikationskanäle, die am besten zu seinen Abläufen passen. Bezugspunkt für diese Informationen ist die Projektbeschreibung des des zugehörigen Build-Service-Projekts. Devel Projects unterliegen außerdem immer wieder Änderungen, da sich die Welt der FOSS-Software ständig weiterentwickelt. Manche Software wird überflüssig, Standards und Grundeinstellungen ändern sich. Für die Devel Projects und die enthaltenen Pakete bedeutet dies, dass sich Namen ändern können, Pakete und Projekte gelöscht oder neu erstellt werden, oder das sich Inhalt und Ausrichtung ändern. Die aktuellen Devel Projects die in openSUSE einfließen können im Ausklappmenü am Anfang dieser Seite gefunden werden. Eine zusammenfassende Beschreibung des Prozesses zur Paketeinreichung finden Sie hier.
Weitere Informationen zu diesem Thema erhalten Sie hier.
Staging-Projekte
Von Zeit zu Zeit verursachen manche Pakete (bspw. neue Versionen von GCC) so viele Änderungen, dass die Factory-Betreuer ein spezielles Staging-Pojekt erstellen, in dem Factory gegen das neue Paket gebaut wird. Die Entwickler können dann dort mögliche Fehler und Inkonsistenzen beheben, bevor sie das Paket endgültig in Factory integrieren.
Staging-Projekte sind eine Art Abzweigung von Factory, in der Entwickler Änderungen/Aktualisierungen für verschiedene Pakete vorbereiten, sie dann zusammenbauen und testen und anschließend gemeinsam zur Integration in Factory einreichen können, falls alle Prüfungen erfolgreich abgeschlossen wurden.
Factory ist in drei Ringe/Schichten (0-bootstrap, 1-minimalX, 2-testDVD) aufgeteilt. Der innerste Ring (0-bootstrap) enthält Pakete, die das minimale Basissystem darstellen. Der nächste Ring enthält Ring 0 plus alles, was zur Ausführung eines minimalen X-Systems benötigt wird. Schlussendlich enthält er äußerste Ring den ganzen Rest.
Wenn ein Anfrage zur Einreichung eines Pakets gestellt wird, das zum inneren Ring gehört, dann wird diese Anfrage automatisch in eine Liste für den Staging-Verwalter zur Überprüfung und späteren Zuweisung an ein bestimmtes Staging-Projekt eingetragen. Es gibt momentan zehn Staging-Projekte die nach den Buschstaben A, B, C, D, E, F, G, H, I und J benannt sind und deren Zweck und enthaltene Pakete sich immer wieder ändern. Staging J ist dabei ein Sonderfall, da sein Zweck darin besteht, Pakete zu prüfen, die keinem Ring angehören (bspw. neue Pakete). Regelmäßig werden dabei für jedes Staging-Projekt ISO-Installationsabbilder erstellt und im openQA getestet, um auszuschließen, dass diese Pakete die aktuelle Factory unbrauchbar machen.
Es ist dabei möglich, dass auf Grund dieser Einreichungen auch der Bau anderer Pakete fehlschlägt. Diese werden dann dem selben Staging-Projekt hinzugefügt, so dass sie gegeneinander gebaut werden können.
Sobald jedes Paket in einem Staging-Projekt erfolgreich gebaut wurde und die openQA-Tests erfolgreich waren, kann der Factory-Betreuer sie an Factory übergeben und das Staging-Projekt zum Test anderen Änderungen freigeben.
osc-plugin-factory ist dabei das Werkzeug, dass alle Dinge im Zusammenhang mit mit Staging-Projekten handbabt. Dieses Staging-Plugin-Dokument erklärt den Umgang mit diesem Werkzeug.
Übersicht über den Entwicklungsprozess
Der vollständige Entwicklungsprozess wird auf dieser Seite detailliert beschrieben. Er besteht aus den folgenden Schritten:
- Roadmap und Planung von Features wird vom Release Manager verwaltet, der die initiale Roadmap erstellt. In der Zwischenzeit setzen die Entwickler technische Ziele für die Distribution basierend auf der vorgesehenen Veröffentlichung und Daten indenen ein Freeze (Einfrieren) geschieht.
- Paketentwicklung beginnt in einem OBS home Projekt [8]. Der Paketentwickler kann ohne Einfluß auf andere Dinge hier arbeiten. Sobald das Paket gut genug ist, kann eine Einreichungsanfrage (submit request) an ein devel-Projekt gestellt werden.
- Integration in Develprojekt folgt als nächstes und wird von Project Maintainers überwachst, die ein Auge auf die technische Qualität der Einreichungsanfrage sowie den ganzen Status eines Develprojekts haben. Nach erfolgreicher Integration erstellen die Project Maintainers eine Einreichungsanfrage für Factory.
- Der Review Prozess stellt sicher, dass alle Pakete auf dem Weg in Factory durch 4 (manchmal 5) Überprüfungen gehen.
- Factory-Auto: ein Skript, welches grundlegende Regeln überprüft [10]
- Legal-Auto: ein Skript, welches prüft, ob die Lizenz des Pakets in der erlaubten Lizenzdatenbank ist [10]
- Repo-Checker: ein tiefergehender (und langsamer) automatischer Check [10]
- Review Team: Menschliche Kontrolle der Anfrage.
- Optional: Manueller Security Team Check (sofern Legal-Auto dies als erforderlich benennt)
- Factory Integration wird von dem Factory Maintainer und den Release Managern überwachst, welche die Einreichungsanfragen akzeptieren, die von den verschiedenen devel-Projekten in Factory kommen [9]. Sie entscheiden größtenteils über Timing und Policy-Faktoren wie Freezes, die bereits vorhanden sind da der Reviewprozess bereits die Qualität sicherstellte. In manchen Fällen entscheiden sie, dass ein Stagingprojekt notwendig wird. Wenn ein Stagingprojekt notwendig ist, müssen die Einreichungsanfragen durch openQA gehen und ein grünes Ergebnis haben. Sobald alles einwandfrei läuft, würde der Factory Maintainer dieses Stagingprojekt akzeptieren so dass alle Einreichungsanfragen, die zum Stagingprojekt gehören in Factory eingecheckt werden.
- Qualitätssicherungsprozess (openQA) läuft die ganze Zeit. Zeitweise werden ISO-Abbilder von OBS generiert und durchliefen einen vorgefertigten Satz an Tests. Wenn Probleme gefunden werden, wird ein Bericht erstellt, der auf die Fehlschläge im ISO-Abbild verweist. Momentan testet openQA größtenteils Staging Projects and Factory-ToTest Abbilder.
- Factory-ToTest. Im aktuellen Factorymodell repräsentiert Factory-ToTest das Projekt welches mehrere Factory-Snapshots speichert. Diese wiederum sind Kandidaten, die veröffentlicht werden sollen, wenn die Qualität gut genug auf openQA ist.
- Release Prozess. Basierend auf dem Timing und den Ergebnissen des QA-Prozesses, kann ein Meilenstein oder Beta vom Release Manager veröffentlicht werden. Er/sie kümmert sich um die Releaseaufgaben: Berechnung der ISO MD%/SHA1 Hashes, Einrichten der Repositories, Vorbereiten und Verbreitung auf Spiegelservern, Bereitstellen der Produkte und Anstoßen des Marketings, die Veröffentlichung zu kommunizieren.
- Öffentliches Testen findet nach der Meilensteinveröffentlichung statt, normalerweise auf wirklicher Hardware und zu einem geringeren Teil in virtuellen Maschinen.
Nicht zu lang nach der Veröffentlichung der Beta (der letzte Meilenstein vor dem Gesamteinfrieren) zieht das Release Team die Veröffentlichung von Factory ab und verwendet den Not too long after the release of the Beta (the final milestone before total freeze), the Release Team forks off the release from Factory and uses the Maintenance update process um die Veröffentlichung zu stabilisieren.
- Hier findet man detailliertere Informationen über den openSUSE-Entwicklungsprozess.
- Findet mehr hier über den Releaseprozess heraus.
- Findet heraus, was was ist und nutzt das Glossar.
Leitung
Behebungen von Bugs und neue Merkmale müssen zuerst in ein devel-Projekt eingebracht werden und werden von dort aus in das Haupt-openSUSE Factoryprojekt weitergeleitet. Aus diesem Grund ist die Leitung des Factoryprojekts ebenfalls unterteilt.
Responsibilities
| Package | Devel Project | Factory |
|---|---|---|
| Maintainer & Bugowner | Project Maintainer & Bugowner | Release team |
Eine detailliertere Liste von Rollen und Verantwortungsbereiche findet man unter See a more detailed list of roles and responsibilities Rollen und Verantwortungsbereiche.
Eskalationen
Die meisten Entscheidungen werden vom Betreuer (Maintainer) des Pakets getroffen. Wenn der Betreuer keine Entscheidung treffen kann oder falls ein Konflikt zwischen Betreuern entsteht, entscheiden die devel-Projekt-Betreuer gemeinsam. Wenn die devel-Projekt-Maintainers auch nicht zu einer Entscheidung oder Lösung kommen oder ein Konflikt zwischen zwei devel-Projekten entsteht, fällt das openSUSE Release Team die Entscheidung. Wenn die Entscheidung nicht von dem Release Team getroffen werden kann, wenden sie sich an das openSUSE Board, welches versucht die Entscheidung mit allen beteiligten Leuten zu schlichten. Wenn dies auch nicht erfolgreich ist, erstellt das Board die Problematik auf eine öffentliche Befragung und Abstimmung der Mitglieder.
Maintainer ==> Devel project maintainers ==> openSUSE:Release team ==> openSUSE:Board ==> openSUSE:Members Abstimmung Hier kann man detailliertere Informationen über den openSUSE/Factory Entwicklungsprozess nachlesen.