Mastodon IzzyOnDroid


Say thanks!
Privacy Links
↓ Your product here? ↓
Das Inoffizielle Android-HandbuchAndroid kennenlernen, Tipps & TricksDas Inoffizielle Android-Handbuch
Android kennenlernen, Tipps & Tricks
Für EUR 16,99 bei Amazon kaufen
Das Inoffizielle Android SystemhandbuchTiefer ins System einsteigenDas Inoffizielle Android Systemhandbuch
Tiefer ins System einsteigen
Für EUR 7,00 bei Amazon kaufen
Die besten Android-AppsDen Androiden austattenDie besten Android-Apps
Den Androiden austatten
Für EUR 5,00 bei Amazon kaufen
 
enhelp

Werde Teil des F-Droid Teams: Aufgaben eines Reviewers

check list
Working on my check list…

Du hast den Satz von der "permanenten Unterbesetzung" des F-Droid-Teams mindestens einmal pro Woche gelesen - und bist ihn genauso leid wie diejenigen, die ihn wiederholen, es bereits sind? Nun: willkommen im ... Team. Ja, Du. Wenn Du ein aktiver F-Droid-Nutzer bist, der die F/LOSS-Idee liebt und lebt, hast Du bereits das nötige Rüstzeug dafür. Zugegeben, es gibt komplizierte Dinge bei F-Droid, die ich selbst nicht verstehe - aber am anderen Ende der Skala gibt es auch einfache Aufgaben, die nicht viel "technisches Wissen" erfordern und leicht erlernt werden können.

Dieser Artikel soll Dir den Einstieg erleichtern und Dich mit den Aufgaben vertraut machen, die während der „App-Überprüfung“ bei RFP und bei fdroiddata Merge Requests durchgeführt werden. Er wird Dir hoffentlich auch als Referenz bei Deinen eigenen Reviews dienen. Aufzeichnungen von entsprechenden Workshops findest Du in meinem Peertube-Kanal.

Ich möchte Dich durch den "Lebenszyklus" einer Überprüfung führen, wie ich sie täglich durchführe – um Dir zu zeigen, welche Aufgaben damit verbunden sind. Als ich vor einigen Jahren anfing, war es ein kleiner Teil der einfachen Schritte, die ich abdecken konnte. Ich war kein Android-Entwickler (und bin es immer noch nicht), und ich war auch kein Paketierer (ähm, dieser Teil trifft immer noch größtenteils zu - obwohl ich inzwischen bei einigen neuen Apps und Updates selbst auf die Schaltfläche „Merge“ drücke). Ich wurde erfahrener, indem ich „einsprang“, versuchte zu helfen und diejenigen fragte, die schon da waren, wenn ich etwas nicht verstand. Heute bin ich einer der Maintainer und kann Dir eine grobe Anleitung geben, mir auf diesem Weg zu folgen.

Hier sind also die Schritte, die ich normalerweise durchführe, wenn eine neue App bei F-Droid gelistet werden soll. Dies beginnt in der Regel bei RFP als „Issue“ und geht dann weiter zu fdroiddata - aber manchmal beginnt es auch direkt als Merge Request (MR) in letzterem. Ich versuche, an beiden Stellen Licht ins Dunkel zu bringen. Das sind jetzt nur Aufzählungen, aber diesen sollte leicht zu folgen sein:

RFP/MR pre-check

RFP: IssueBot-Ergebnisse

Am Ende dieses Prozesses werden die Metadaten vorbereitet (es sei denn, es gibt bereits einen zugehörige MR, der sie enthält; in diesem Fall werden sie auf Korrektheit/Vollständigkeit geprüft). Du findest eine Beispiel-Metadaten-Datei weiter unten.

MR: IssueBot-Ergebnisse, weitere CI-Pipelines

Die Ergebnisse unserer CI finden sich direkt unter dem „Eröffnungs-Kommentar“, eingeleitet von einem Text wie „pipeline #128817296 passed for e5a357b5 on johndoe:master“. Ein „grünes Häkchen“ zeigt an, dass alles glatt gelaufen ist – ein „rotes x“ hingegen, dass es Probleme gab. Tippt man das Symbol auf der rechten Seite des Textes an erhält man ein Popup, in dem alle Pipelines gelistet sind. Jetzt diejenige antippen, an der man interessiert ist – und man gelangt zu den Logs. Nicht erschrecken, wenn diese zunächst wie Kauderwelsch aussehen – mit der Zeit gewöhnt man sich daran… irgendwie. Und lernt, die passenden Stellen zu finden.

MR: APK-Test

Nach einem erfolgreichen Build kann eine APK-Datei heruntergeladen werden. Der IssueBot gibt den direkten Download-Link am Ende seines Reports an. Bei der CI muss man das entsprechende Log öffnen (siehe oben) und dort den mit „Browse“ beschrifteten Button am rechten Rand betätigen; die APK-Datei findet sich dann im Verzeichnis unsigned.

Zusammenfassung

Egal, ob Du ein Geek, ein Nerd oder einfach nur ein Enthusiast bist – Du bist herzlich eingeladen, bei uns mitzumachen und uns dabei zu helfen, die (Antwortzeiten bei) F-Droid zu verbessern. Danke, dass Du darüber nachdenkst!


Anhang

Ich habe in den letzten Jahren einige Details gesammelt. Einige dieser Links sind bereits oben integriert worden, aber ich möchte sie hier noch einmal zusammenfassen:

Beispiel Metadaten-Datei

So würde eine vollständige Metadaten-Datei aussehen; wofür jedes Feld steht und was es enthalten sollte, wird auf der Seite Metadata in der F-Droid-Dokumentation erklärt. Nehmen wir an, wir haben eine App mit dem Namen „My Example App“, die den Paketnamen com.example.app trägt - unsere Datei heißt also com.example.app.yml:

AntiFeatures:
  - NonFreeNet
Categories:
  - Theming
License: Apache-2.0
AuthorName: John Doe
AuthorEmail: johndoe@example.com
AuthorWebSite: https://www.example.com/
WebSite: https://www.example.com/myApp
SourceCode: https://github.com/johndoe/my_example_app
IssueTracker: https://github.com/johndoe/my_example_app/issues
Translation: https://github.com/johndoe/my_example_app/wiki/Translation
Changelog: https://github.com/johndoe/my_example_app/releases
Donate: https://github.com/johndoe/my_example_app/wiki/Donate
Liberapay: johndoe
Bitcoin: <BitcoinAddressHere>

RepoType: git
Repo: https://github.com/johndoe/my_example_app.git

Builds:
  - versionName: 1.0.1
    versionCode: 2
    commit: v1.0.1
    subdir: app
    gradle:
      - yes

AutoUpdateMode: Version v%v
UpdateCheckMode: Tags
CurrentVersion: 1.0.1
CurrentVersionCode: 2

Beachte, dass nicht alle Felder obligatorisch sind - wenn es keine AntiFeatures gibt, würde der gesamte AntiFeature-Block einfach weggelassen werden. Obligatorisch sind jedoch: mindestens eine Kategorie, die Lizenz, SourceCode Link, RepoType & Repo. Zusammenfassung & Beschreibung sollen über Fastlane kommen, daher fehlen sie hier. Vom Builds-Block müssen VersionName und VersionCode mit CurrentVersion bzw. CurrentVersionCode am Ende übereinstimmen, commit sollte der Tag-Name sein. In diesem Beispiel ist der Tagname der Versionsname mit einem vorangestellten v, so dass AutoUpdateMode zu v%v wird (wobei %v für Versionsname steht).

Es gibt komplexere Definitionen (z.B. bei Flutter-Projekten) – aber diese können getrost „fortgeschrittenen Mitwirkenden“ überlassen werden. Denke daran, dass die Paketierer Deine vorbereiteten Metadaten gegenprüfen werden, also mach Dir keine Sorgen, wenn sie „nicht perfekt“ sind. Und obwohl der Builds-Block sowie die letzten 4 Zeilen ebenfalls erforderlich sind, können sie mit dem MR eingerichtet werden – da oftmals bereits neue Versionen erstellt wurden, bevor der MR abgeschlossen werden kann, müssen sie dann normalerweise sowieso aktualisiert werden.

fdroidhowto

2021-12-19