Entwicklung/Mitmachen

This page is a translated version of the page Development/GetInvolved and the translation is 68% complete.

TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Spende

Other languages:

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:

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.

Once you are ready to commit again it is important you use --amend

git commit --amend -a

Important do not use the -m parameter as it will wipe out the gerrit patch id. Let git open an editor, allowing you to edit the commit message (or leave it unchanged). When editing be careful not to remove/modify the last line with the patch id.

This will ensure you update the patch, instead of generating a new one (with a new Change-Id:).

Die neue Fehlerbereinigung wird bei gerrit hochgeladen:

./logerrit submit master

License statement

We want to keep the source code free for use by anybody, therefore it is important that you mail (please use Subject: <your name> license statement) a license statement to libreoffice@lists.freedesktop.org with the text:

   All of my past & future contributions to LibreOffice may be
   licensed under the MPLv2/LGPLv3+ dual license.

It is important to make sure that the mail allows connecting the statement to the contributions, so send the statement from the same email that is used in your commits.

A slight variation to suit your personal taste is fine as long as the intention is clear. We keep a list of developers in our wiki.

Please only send the statement no earlier than when you post your first submission to gerrit. If you are underage, ask your parents or legal guardians to send the email (all persons having guardianship).

If you will be contributing artwork that will be included with the software (such as icons), add this to your license statement email:

   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

You have successfully made a change to one of the most popular open-source packages in the world.

Continue to make patches, and you will soon be a committer yourself.

Roadmap for personal growth

A developer needs to have specific skills/experience in order to be able to work on LibreOffice Code. This is the path suggested for anyone who wants to get involved in LibreOffice development:

Understand intermediate level C++: Most of the LibreOffice code is in C++, so one should be fluent with C++ in order to be able to work with the code.
Understand git and gerrit: git is the version control software that is used in LibreOffice. One should understand git and gerrit in order to be able to contribute
Be able to build LibreOffice: To be able to change the code, one should be able to build LibreOffice from the sources.
Do at least 10 bug triages: Developers should understand Bugzilla and the workflow associated with bugs and features. This is essential in order to be able to proceed.
Do at least 5 EasyHacks with difficulty beginner (C++): The first step towards being able to understand and change the code.
Do at least 5 EasyHacks with difficulty medium (C++): After doing some easier tasks, it is important to be able to do some more serious work.
Do at least 1 EasyHacks with difficulty interesting
Fix at least 5 regressions: Regressions are usually easy to reproduce, and can be fixed in a reasonable amount of time, so they are suitable for the newcomers
Reach certain number of commits (~60)
Do at least 1 CoreHack

Anfänger Etikette

Experienced contributors will help you find solutions to your problems, but there are expectations and limits. Remote mentoring and troubleshooting has a greater cognitive load compared to being physically present. Showing you are well-prepared makes people more motivated to help you.

Allgemiene Richtlinien:

When using the chat, immediately describe your problem and stay in the channel for at least an hour.
For sharing text with multiple lines in the chat, use a paste service such as the one mentioned in the channel topic.
If you have network connection issues, the mailing list works better than the chat.
If you are doing a complex multi-step task, it is a good idea to keep personal notes. These will come in handy when you are asked what you did so far.
After receiving a reply, acknowledge it somehow. If you disappear without a trace, your helpers will feel distressed.

If you are facing an issue with git, patch submission or setting up the development environment, it is best to follow these steps:

Try to search for the how-to or solution yourself. Sometimes your helpers have to search as well.
If your search was successful, make an attempt to follow the instructions.
If you did not find any instructions or got stuck applying them, ask for help.

With these types of issues, helpers are quite happy to try and solve your entire problem for you.

If you are solving an easy hack, it is good to keep these facts and tips in mind:

There is no single document explaining the code base in prose. Educational material is scattered across conference presentation slides, blog posts and wiki pages.
The frequency of code comments is less than ideal (you can help!), so you should be prepared to read code.
Use git grep, an IDE and OpenGrok to find the definitions of the functions and classes you run into.

Investigate the commit history, also for similar topics elsewhere in the code base. OpenGrok's Annotate command can be revealing for this type of detective work.
Run a debugger while using LibreOffice to find out what is going on under the hood.
Browse the readme files.

If you ask someone to say how to implement something, you will probably be faced with silence. Easy hacks are supposed to be a learning experience and mentors do not want to ruin it. A proposed implementation will be commented on in the review system.