Unser 14-tägiges Kernteamtreffen letzte Nacht war erneut ausschließlich bestimmt durch die geplanten strukturellen Änderungen zur Verbesserung unserer Arbeitsabläufe und Vereinfachungen, die es unseren Benutzern leichter machen, sich zu beteiligen.
Wie in meinem letzten Blogpost erwähnt, wollten wir die Paketlisten in unser Buildsystem pyfll vereinfachen. Es brauchte ein paar Wochen der Diskussion um hier einen Kompromiss zu finden. Leute, die dies interessiert oder die unser Buildsystem privat nutzen, können den anstehenden Veränderungen im Log ab [21:08:57] folgen.
Das zweite Thema gestern Abend betraf die Repository Struktur und neue Repository Namen. Dies sollte alle Benutzer interessieren, denn es betrifft ihre sources.list.d/siduction.list.
Zunächst einmal: Keine Panik!
Wir haben bereits einige Tests durchgeführt, um auszuprobieren ob alte und neue Bezeichnungen gleichzeitig funktionieren. Das tun sie, so daß wir jetzt Links bereitstellen können von alt nach neu. Ihr als User braucht erst mal gar nichts zu tun, es wird einfach funktionieren. Aber natürlich könnt ihr, wenn ihr wollt, um auch in Zukunft auf der sicheren Seite zu sein. Neue Installationen werden natürlich die neuen Bezeichnungen benutzen.
Hier ist die überarbeitete Struktur:
- base war bisher siduction benannt. Es enthält alle offiziellen siduction Pakete
- community gibts nicht mehr, es wurde nie verwendet. (Bitte entfernt es aus eurer Liste, wenn ihr es drin habt)
- extra ist neu und enthält alle Pakete, die nicht nach base oder user gehören. (Pakete, die wir für die Verbesserung von siduction bauen, Pakete welche (noch) nicht in Debian und nicht essentieller Bestandteil von siduction sind)
- user ist für Pakete von erfahrenen Benutzern / Team-Mitgliedern, die ihre Pakete verteilen möchten (wie z. B. towos inkscape- und gimp- Pakete)
- fixes enthält zeitweise Pakete, die in Debian kaputt sind, wenn wir einen schnellen Fix dafür haben. Unser zukünftiges Ziel ist, diese Patches upstream zu übergeben.
- razor-qt wird in base aufgehen, sobald wir Razor-Qt zu unserem offiziellen Releasezyklus hinzugefügt haben.
- experimental ist wohl selbsterklärend
- experimental-snapshots ist nur ein Puffer für unseren Teamgebrauch (Benutzer sollten dies nicht in ihre Liste aufnehmen).
Die Repository Webseite enthält die richtigen Zeilen für eure Änderungen.
Das nächste Thema handelte ebenfalls von Repositories und dem Versuch zu definieren, wo die Paketquellen am sinnvollsten vorzuhalten sind. Für die base und extra Repositories ist dies klar unsere eigenen Infrastruktur (chili/git). Die Quellen unseres user Repositories sollten von unserer Infrastruktur getrennt gehalten werden. Der Grund ist, daß jeder in der Lage sein sollte, diese auf einfache Weise zu forken, zu paketieren und in anderen Projekten zu verteilen. Github scheint hier der benutzbare Weg zu sein. Es ist dafür ausgelegt, geforkt(abgespalten) zu werden. Alle Änderungen an geforkten Paketen sind nur einen merge weit weg, um zur originalen Quelle zurück portiert zu werden.
Das letzte Thema letzte Nacht war Jenkins. Es braucht mehr Zeit und Tests. Wir stimmen alle überein, daß es nicht dringend ist und die Letzte in der Linie unserer Verbesserungen sein muß. Wenn wir es aufgesetzt haben und voll verstehen, wie es arbeitet, wird es uns eine Menge Zeit sparen, indem es Dinge automatisiert, die wir im Moment per Hand erledigen.
Und noch ein anderes Thema: Die Zeit ist gekommen, um über einen Namen für unser nächstes Release nachzudenken, denn das Art-Team braucht Zeit, um die Release-art dafür zu entwickeln. Der Prozess, mit dem wir im Moment arbeiten (User übermitteln ihre Favoriten, das Team wählt den Gewinner durch Abstimmung), ist nicht wirklich flüssig und befriedigend, soweit es mich betrifft. Wenn jemand eine bessere Idee für diese wiederkehrende Routine hat, wären wir glücklich, davon zu hören. Auf der anderen Seite, wenn nichts großartiges kommt, werden wir die alte Methode noch einmal anwenden. Also seid auf die Ankündigung einer Wikiseite zu diesem Zweck gespannt.