Entwicklung/Mitmachen
TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Spende
Entwickler und Nutzer können in der LibreOffice Entwickler auf vielerlei Art und Weise mitmachen und jeder ist dabei willkommen.
Nutzer können z. Bsp. bei der Entwicklung helfen, indem sie Beta Releases der Software testen, Bugs testen und melden, Dokumentationen schreiben, bei Vorlagen mitmachen, Thesaurus und Wörterbücher aktualisieren, in ihre Muttersprache(n) übersetzen, Diagramme erstellen, für LibreOffice werben und es verteilen.
Auf dieser Seite konzentrieren wir uns auf Entwickler. Wir sind eines der größten, ältesten und bekanntesten (als OpenOffice) freien Software Pakete. Wenn Du ein Student bist oder auf der Suche nach Entwickler-Jobs bist, ist es ein dickes Plus, "Ich habe für LibreOffice gearbeitet" in den Lebenslauf schreiben zu können. Entwickler helfen den LibreOffice Code zu überprüfen. Zunächst kann der Code ziemlich individuell verfasst sein, aber die Dokumentation klärt auf und das existierende Entwicklerteam hilft Neulingen bei der Einarbeitung. Diese Seite hilft, die ersten Schritte zu gehen. Zur Hilfe erfolgt hier ein Überblick:
- grafische Code Übersicht
- Dokumentation zu speziellen Modulen
- How to Create a Custom Widget? (engl.)
- DrawingLayer: What should you Know about it? (engl.)
- Frequently Asked Questions
Schritt-für-Schritt Handbuch für neue Entwickler
Man ist leicht überwältigt von der Größe und Komplexität von LibreOffice. Die Quellen sind in vielen verschiedenen Sprachen und Formaten geschrieben — C, C++, Java, Bash, JavaScript, Python, Perl, SQL, XML — und besteht aus grob geschätzt 102.000 Dateien (ohne alle Lokalisationen) mit 36.000.000 Textzeilen (7.000.000 Zeilen Quelltext).
Niemand kennt den gesamten Code im Einzelnen. Dafür haben wir viele Haupt-Entwickler, von denen jeder einen Teil des Codes ganz genau kennt. Dieses Schritt-für-Schritt Handbuch zeigt einen einfachen Weg vom "will helfen" zur erfolgreichen ersten Änderung im Endprodukt.
Anmeldung an unsere Kommunikationswege
Unsere Mailing List ist libreoffice@lists.freedesktop.org; wir empfehlen Dir, Dich hier anzumelden. Du kannst die Liste auch online verfolgen.
Zum Echtzeit-Chat nutzen wir IRC im Libera Chat network #libreoffice-dev IRC://
LibreOffice compilieren
Um programmieren zu können, braucht man den Quelltext. Der gesamte Code befindet sich im git. Wie man an den Quelltext kommt, wird in den Anweisungen für jedes Betriebssystem erklärt.
Windows
Windows Entwickler brauchen Cygwin und andere Werkzeuge. Der einfachste Weg dazu ist LibreOffice Development Environment (LODE) zu verwenden. Detaillierte Windows build Anweisungen sind auch erhältlich.
macOS
Wir empfehlen, den Anweisungen unter LibreOffice Development Environment (LODE) zu folgen. Weitere Informationen und Einzelheiten zum XCode stehen im Artikel zu Building LibreOffice on macOS.
Linux
Linux (die meisten Installationen) können unter Verwendung der Installationspakete installiert werden. Wir empfehlen, Building on Linux zu folgen.
Vorbereitungen, um Patches einzuspielen
Sobald LibreOffice erfolgreich compiliert wurde, können Patches auch eingespielt werden. Wir verwenden dazu gerrit, um die Änderungen zu dokumentieren. Daher benötigt jeder Entwickler dort einen Account. Befolgen Sie bitte daher dieses gerrit Handbuch
Es gibt grundsätzlich zwei Methoden, um mit Änderungen zu arbeiten. Jene, die mit Git review vertraut sind, können es gerne nutzen, aber wir empfehlen ein einfacheres Tool, genannt logerrit
.
Vorsicht ist geboten, wenn Änderungen an Untermodulen wie der Hilfe bestätigt werden (auch wenn die Hilfe nur kopiert wurde), da das logerrit script nicht verfügbar ist und stattdessen gerrit installiert ist. Zum Setup siehe Development/Submodules.
Finde den ersten Fehler zur Bereinigung
Gratulation, der interessante Teil ist erreicht.
Das Bereinigen des ersten Fehlers beinhaltet das Kennenlernen neuer Tools und Wege. Daher haben wir einige einfache Fehler, Easy_Hacks genannt, identifiziert. Wir verwenden Bugzilla, um benannte Fehler zu verfolgen und zu dokumentieren. Dort wird ein eigenes Konto benötigt.
Easy Hacks sind echte Fehler, aber die Hauptentwickler haben Hinweise auf den Quellcode und manchmal textuelle Hilfe angegeben, statt sie direkt selbst zu bereinigen. Dadurch wird es einfacher für die Newbies, den Fehler zu beseitigen. Suche einen Fehler in Deiner Programmiersprache aus (siehe oben), der Dich interessiert EasyHacks by language and skill. Es gibt viele Fehler zur Auswahl. Wir empfehlen, einen aus der Kategorie "Skill level: beginner" auszuwählen. So kannst Du Dich auf das "Wie mache ich ..." konzentrieren.
Sobald ein Fehler ausgesucht ist, bitte nicht vergessen, sich im Bugzilla dazu einzutragen. So sehen die anderen, dass sich um diesen Fehler bereits jemand kümmert. Wenn Du an einem generellen Problem arbeitest (wie z. Bsp. foo durch xyz zu ersetzen), dann den Fehler bitte nicht zuordnen. So können viele an der Sache gleichzeitig arbeiten. Die Easy Hacks werden überwacht. Daher werden sie nach einiger Zeit der Inaktivität wieder freigegeben.
Natürlich gibt es auch andere Herausforderungen für später:
Fehler bereinigen
Einige Tipps aus der Praxis:
- Niemals im Master ändern - erst einen eigenen Branch anlegen.
- Für jeden Fehler wird ein eigener Branch angelegt. Dieser wird erst gelöscht, wenn die Fehlerbereinigung im Master eingefügt ist.
- Die Programmierrichtlinien (z. Bsp. Variablenbenamsungen usw.) werden eingehalten.
- Neue Dateien werden unter der Policy for Licensing and Copyright Attribution (engl.) angelegt.
- Grössere Umformatierungen im Quelltext sind möglichst zu vermeiden (außer in den unten angeführten Fällen) - wir erwägen mittel- und langfristig automatische/magische Methoden dazu.
- Aktualisiere Deinen Master, bevor Du einen neuen Fehler bearbeitest. Lasse dabei einen make check laufen, um sicher zu sein, dass der Compile sauber durchläuft, bevor Du irgendwelche Änderungen am Master vornimmst.
- Stelle keine Änderungen ein, die voneinander abhängig sind, bevor Du nicht dazu aufgefordert wirst. Ansonsten können Deine Änderungen nicht im Master berücksichtigt werden.
- Wenn Deine Änderungen noch nicht freigegeben werden können, stelle sie auf -2. Damit können Beobachter erkennen, dass sie in Bearbeitung sind.
- Geduld ist wichtig. Wir sind alle Ehrenamtliche. Erlaube also einige Tage zur Bearbeitung.
Empfohlener Ablauf
1. Master aktualisieren
Dein Master ist aktuell und funktioniert. Wenn Dein Master zu alt ist, riskierst Du, dass Deine Änderungen nicht brauchbar sind.
Als Faustregel gilt:
- Dein Master ist nicht älter als eine Woche.
- Dein Bug-Fix betrifft die Version, die gerade bearbeitet wird.
./g pull -r
make
make check
!! make muss Version 3.8.1 oder höher haben.
Der Schalter -r wird eingesetzt. Dieser ist viel effektiver als einfaches herausziehen. Der Master bricht öfters zusammen. Aber normalerweise nur für kurze Zeit (Committer reagieren normalerweise schnell, wenn sie falsch committet haben).
Wenn der make durchläuft, ist klar, dass der Master funktioniert. Wenn also der make beim Compilieren des Patches abbricht, wissen wir, dass das Problem irgendwo im geänderten Code liegt. make check lässt alle Testfälle laufen und sichert daher eine lauffähige Version von LibreOffice. Ein reiner make vor dem make check kostet keine Compile-Zeit und Fehler im Testfall. Es stellt dagegen ein lauffähiges Build sicher.
2. Arbeiten in einem Branch
Du kannst später gebeten werden, etwas an Deinem Patch zu ändern. Wenn Du in einem seperaten Branch gearbeitet hast, ist das sehr leicht. Nutze daher bitte einen neuen Branch (vom Original/Master) für jeden Fehler, den Du bearbeitest. Wenn der Patch eingespielt ist, kannst Du den Branch wieder löschen.
git checkout -b test1 origin/master
test1 wird durch einen individuellen Namen ersetzt.
3. Der Fehler wird bereinigt
Das Problem wird identifiziert und der Code korrigiert. Dann wird eine neue Version generiert und getestet. Ein Unit-Test wird etabliert, wo dies möglich ist. Damit kann überprüft werden, ob das Problem gelöst ist.
Es gibt einige manuelle Tools, die helfen können:
- OpenGrok - Zum Suchen und Durchsuchen des Qullcodes
- Konvertiert java Unit-Tests nach Python
- cgit commit log
- Ein Überblick über gerrit für LibreOffice
git commit -a sollte regelmäßig durchgeführt werden. Dadurch können falsche Fährten relativ einfach identifiziert und entschärft werden.
4. Der Patch wird eingespielt
Commit-Meldungen sollten wie folgt aussehen:
tdf#12345 <short developer description of change, not just the bug title> <empty line> <description of what the patch does, the more words the better others understand it later>
- Wenn es einen Fehlerbericht im Zusammenhang mit dem Commit gibt, muss die erste Zeile mit einer Referenz darauf, wie z. Bsp. tdf#12345, beginnen (siehe folgende Einzelheiten).
- Der Rest der ersten Zeile wird für eine präzise Zusammenfassung der Änderungen genutzt. Die maximale Länge dieser Zeile beträgt 72 Zeichen.
- Der Text wird in der Gegenwart abgefasst und gibt auf spannende Art und Weise an, was die Änderung bewirkt. "Dekorationen" wie z. Bsp. Striche oder Klammern, die nur Platz verschwenden, werden vermieden.
- Wenn mehr Text gebraucht wird, als in der ersten Zeile Platz findet, muss die zweite Zeile leer gelassen werden.
- Ab der dritten Zeile wird erklärt, was der Patch tut. Wenn es nicht offensichtlich ist, auch warum. Diese Zeilen haben maximal 80 Zeichen; falls die Erklärung länger ist, wird sie in mehrere Zeilen aufgeteilt. Hier kann auch beschrieben werden, was vorher falsch gemacht wurde.
Wenn der Patch einen Fehler aus Bugzilla bereinigt, kann die automatische Fehler-Benachrichtigung genutzt werden. Diese wird durch den Commit ausgelöst: wenn die erste Zeile der Commit-Meldung eine Referenz auf einen Fehler in der Form tdf#12345 enthält, wird ein entsprechender Kommentar automatisch in den Fehlerbericht eingefügt, sobald die Änderung in das Repository eingespielt wird. Siehe die Ankündigung auf mail-archive.com oder i [mhttps://lists.freedesktop.org/archives/libreoffice/2012-February/026028.html fdo-listarchive] für nähere Einzelheiten.
Beachte bitte, dass Deine Änderungen keine automatisierten Tests unterbricht:
make check
Jetzt kann der Patch an gerrit übertragen werden (siehe Vorbereitungen, um Patches einzuspielen):
./logerrit submit master
Kontrolle der Fehlerbereinigung
Im Falle eines Easy Hacks wird die Person als Revisor des Patches angegeben, der die Code-Hinweise gegeben hat. Der Entweickler erhält eine eMail, wenn an dem Patch etwas geändert wurde.
Im Allgemeinen können drei Dinge in der Kontrolle passieren:
- Der Revisor kontrolliert und testet den Patch erfolgreich und fügte ihn ein (Glückwunsch)
- Der Revisor hat einige Anmerkungen, die noch abzuarbeiten sind.
- Manchmal kommt ein Patch mit anderen Funktionaltäten in Konflikt. Er wird dann als "Cannot merge" gekennzeichnet.
In den letzteren zwei Fällen muss der Patch geändert werden.
Nähere Einzelheiten für den Patch Kontroll Prozess siehe unter Development/gerrit/PatchReview.
Eine Fehlerbereinigung aktualisieren
Der Branch wird ausgecheckt,
git checkout test1
Die erforderlichen Änderungen werden eingepflegt und getestet. Es wäre höflich, die Änderungen, die nicht geändert werden sollen oder bei denen kein Konsens mit dem Revisor besteht, zu kommentieren. Diese Kommentare erfolgen direkt in gerrit.
Sobald der Patch wieder bereit zur Revision ist, ist es wichtig --amend zu verwenden.
git commit --amend -a
Wichtig Auf keinen Fall den -m Parameter verwenden, das dieser die Patch ID aus gerrit löscht. Mit dem Editor in gerrit kann die Nachricht des Revisors geändert werden (oder ungeändert bleiben). Bei Änderungen bitt auf alle Fälle die letzte Zeile mit der Patch ID unverändert lassen.
Dadurch wird der bestehende Patch aktualisiert und kein neuer (mit einer neuen Change-ID:) erzeugt.
Die neue Fehlerbereinigung wird bei gerrit hochgeladen:
./logerrit submit master
License statement
Wir wollen den Quelltext frei für den Gebrauch durch jeden halten. Daher ist es wichtig, Dass Du ein Mail (Bitte mit dem Betreff: <Dein Name> license statement) mit einem license statement an libreoffice@lists.freedesktop.org schickst mit dem Text:
All of my past & future contributions to LibreOffice may be licensed under the MPLv2/LGPLv3+ dual license.
Es ist wichtig, dass das Mail erlaubt, das Statement mit die Veröffentlichungen zu verknüpfen. Sende das Statement daher von derselben eMail-Adresse, die Du bei Deiner Arbeit an LibreOffice nutzt.
Eine leichte Anpassung an Deine persönlichen Anforderungen ist in Ordnung, solange die Intention klar bleibt. Wir unterhalten eine Liste in unserem wiki.
Das Statement sollte erst mit dem ersten Eintrag abgegeben in gerrit abgegeben werden. Bei Minderjährigen müssen die gesetzlichen Vertreter die eMail senden.
Wenn Illustrationen (wie z. Bsp Icons) zur Software veröffentlicht werden sollen, sollte folgendes dem license statement hinzugefügt werden:
Additionally, to the extent possible under law, I waive all copyright and related or neighboring rights to my past & future Artwork and Design contributions to the LibreOffice project, and similarly to The Document Foundation, placing such contributions under CC0: https://creativecommons.org/publicdomain/zero/1.0
Glückwunsch
Du hast erfolgreich dem populärsten Open-Source Projekt der Welt eine Änderung hinzugefügt.
Fahre fort, Patches zu erstellen und Du wirst bald selbst ein Revisor werden.
Fahrplan zum persönlichen Wachstum
Ein Erntwickler brsucht besondere Fähigkeiten, um am LibreOffice Code zu arbeiten. Das ist der empfohlene Weg, um an der Entwicklung von LiobreOffice mitzuarbeiten:
- Verstehe durchschnittliches C++: Der meiste Quelltext von LibreOffice ist in C++. Daher sollte fliessend C++ gesprochen werden, um am Code zu arbeiten.
- Verstehe git und gerrit: git ist die Version Controll Software für LibreOffice. Man sollte daher git und gerrit beherrschen, um mitarbeiten zu können.
- Sei in der Lage, LibreOffice zu compilieren: Um Änderungen am Quelltext vornehmen zu können, ist es unabdinglich, LibreOffice aus den Quellen erzeugen zu können.
- Bearbeite mindestens 10 Fehler-Sichtungen: Entwickler sollten Bugzilla und den Arbeitsablauf der Fehler und Eigenschaften verstehen. Das ist grundlegend, um in der Lage zu sein, erfolgreich zu sein.
- Bearbeite mindestens 5 EasyHacks für Anfänger (C++): Der erste Schritt zum Verstehen und Ändern des Codes.
- Bearbeite mindestens 5 EasyHacks mittlerer Schwierigkeit (C++): Nach einigen einfacheren Aufgaben ist es wichtig, in der Lage zu sein, etwas ernstere Arbeit zu machen.
- Bearbeite mindestens 1 EasyHack mit Schierigkeitsgrad "interessant".
- Bereinige mindetens 5 Regressionen: Regressionen sind einfach zu reproduzieren und können einfach in vernünftiger Zeit bereinigt werden. Daher sind sie ideal für Neulinge.
- Erreiche eine bestimmte Anzahl an Bestätigungen (~60)
- Bearbeite mindedstens 1 CoreHack
Anfänger Etikette
Erfahrene Mitarbeiter werden helfen, Lösungen für alle Probleme zu finden. Aber es gibt auch Erwartungen und Grenzen. Remote-Hilfe und Troubleshooting bringt mehr als physikalische Präsenz. Gute Vorbereitung motiviert die Helfer mehr als alles andere.
Allgemeine Richtlinien:
- Bei Verwendung des Chats wird am besten sofort das Problem geschildert. Bleiben Sie bitte danach für mindestens eine Stunde im Channel präsent.
- Um Texte mit mehr als einer Zeile im Chat zu schreiben, sollte ein Texteditor wie der im Channel angegebene verwendet werden.
- Wenn eine Internet-Verbindung besteht, funktioniert die Mailing-Liste besser als der Chat.
- Wenn Sie eine komplexe Aufgabe bearbeiten, ist es eine gute Idee, persönliche Notizen zu verwenden. Diese werden nützlich, wenn Sie danach gefragt werden, was Sie bisher unternommen haben.
- Sobald Sie eine Antwort erhalten, bestätigen Sie sie irgendwie. Wenn Sie ohne eine Spur verschwinden, werden sich Ihre Helfer Sorgen machen.
Wenn Sie an einer Aufgabe mit git, Patch-Übertragung oder die Enwicklungsumgebung aufsetzen arbeiten, folgen sie folgenden Schritten:
- Versuchen Sie, eine Anleitung oder die Lösung selbst zu finden. Manchmal müssen die Helfer auch suchen.
- Wenn die Suche erfolgreich war, versuchen Sie, sich an die Anleitung zu halten.
- Wenn Sie keine Lösung finden oder an der Umsetzung scheitern, fragen Sie um Hilfe.
Bei diesen Aufgabentypen versuchen die Helfer gerne, das gesamte Problem für Sie zu lösen.
Wenn Sie einen Easy Hack lösen, hilft es, folgende Fakten und Tipps im Kopf zu behalten:
- Es gibt kein einzelnes Dokument, das den Quelltext in Prosa erklärt. Schulungsmaterial findet sich in Präsentationen, Blog Einträgen und auf Wiki-Seiten.
- Die Häufigkeit von Kommentaren im Quelltext ist suboptimal (Sie können helfen!!). Daher sollten Sie damit rechnen, Code zu lesen.
- Verwenden Sie git grep, eine IDE und OpenGrok, um die Definitionen der Funktionen und Klassen, die Sie verwenden, zu finden.
- Untersuche den Änderungsverlauf, auch für ähnliche Aufgaben woanders im Quelltext. OpenGroks Annotate-Kommando kann für derartige Detektiv-Arbeit aufschlussreich sein.
- Lassen Sie LibreOffice im Debugger laufen, um herauszufinden, was unter der Decke passiert.
- Durchsuchen Sie die die readme Dateien.
Wenn Sie jemanden fragen, wie Sie etwas implementieren sollen, werden Sie mit Schweigen konfrontiert sein. EasyHacks sind dafür gedacht, dass sie einen Lerneffekt auslösen. Mentoren werden diesen nicht zerstören. Eine vorgeschlagene Implementation wird in der Rezension vermerkt werden.