QGIS-Entwicklung

Willkommen auf den QGIS-Entwicklungsseiten

Fehler, Funktionen und Probleme

Wenn Sie einen Fehler finden, melden Sie ihn bitte!

Sie brauchen ein OSGeo-Konto und Anmeldung um Fehler zu melden. Um zu beginnen, erstellen Sie sich einen OSGeo-Zugang.

Sobald Sie ein Konto haben, melden Sie sich unter QGIS Fehlerverfolgung an und überprüfen Sie, ob der Fehler eventuell bereits gemeldet ist.

Berichte

Berichte dienen zum Melden von Fehler, Vorschlagen von Verbesserungen und zum Einreichen von Patches. Redmine ist mehr als ein Fehlerberichtssystems. Berichte können QGIS-Meilensteinen zugeordnet werden und der Fortschritt zu deren Erreichen sichtbar machen. Deren Erreichen erfordert nicht nur das Beheben von Fehlern, sondern auch anderer mit der Freigabe verbundenen Aufgaben, wie Dokumentation, Websiteupdates, Paketerstellung und Bekanntmachungen.

Einen Bericht erstellen

Vor der Meldung eines Fehlers

Vor der Meldung eines Fehler sehen Sie bitte die offenen Fehler durch, um ein doppeltes Melden zu vermeiden. Wenn Sie weitere Informationen zu einem Fehler haben, können Sie das Ticket ergänzen. Erweiterung Dritter können auch Probleme verursachen. Wenn Sie solche installiert haben, prüfen Sie bitte ob das Problem auch ohne sie reproduzierbar ist. Bitte berichten Sie nicht mehrere unzusammenhängende Fehler in einem Fehlerbericht.

Erweiterungsfehler

Erweiterungsfehler müssen in dem dazugehörigen Fehlerverfolgungssystem eröffnet werden. Prüfen Sie zuerst, ob die Erweiterung unter Erweiterungsübersicht aufgeführt ist. In diesem Fall klicken Sie auf den Erweiterungsnamen und dann “New issue”. Sonst sehen Sie in der Dokumentation der Erweiterung, um das zugehörige Fehlerverfolgungssystem bzw. eine Entwickerkontakt zu finden.

Schritte

Um einen Fehler zu melden wählen sie “Neues Ticket” aus der Menüleiste. Hinweis: Sie können mit dem Ticketsystem auch Erweiterungswünsche und Patches einreichen.

Wichtig zum Eröffnen eines Berichte notwendige Informationen:

  • Tracker - wählen Sie den Tickettyp aus der Dropdownliste: Bug report oder Feature request.

  • Thema - eine Kurzbeschreibung des Problems.

  • Beschreibung - liefern Sie eine vollständige Beschreibung des Problems mit Schritte im es zu reproduzieren; Wenn sie denken, dass der Fehler auf ein bestimmte Plattform oder -version oder abhängige Bibliotheken (GDAL/OGR, GEOS etc.) betroffen sind, geben Sie auch dies an. Wenn QGIS abstürzt kann es nützlich sein eine Backtrace beizulegen (siehe unten). Ein sehr wichtiger Punkt in einem Fehlerbericht ist es ein Minimalbeispiel zu bestimmen mit dem sich der Fehler reproduzieren läßt. Wie groß die Chance das ein Fehler schnell behoben wird, hängt direkt mit der Geschwindigkeit zusammen wie schnell ein Entwicker das Problem nachvollziehen kann. Wenn Sie es dem Entwickler schwer machen, kann es sein, dass der Entwickler ihn für ein Weile ignoriert oder gar aufgibt.

  • Priorität - schätzen Sie die Schweregrad des Problems ein. Low (ein Problem, dass die Benutzbarkeit von QGIS nicht beeinflußt), Normal (der Vorgabewert, gültig für die meisten Fehler und fast alle Funktionswünsche), High (ein Fehler starke Auswirkungen auf die Benutzbarkeit hat) oder Blocker (ein Fehler der QGIS komplett unbenutzbar macht, schwerwiegende Datenverluste oder Regressionen von vorherigen QGIS-Versionen)

  • Kategorie - wählen Sie einen Bereich der Anwendung an mit dem das Problem am meisten zu tun hat.

  • Affected version - geben Sie an mit welche QGIS-Version das Problem hat.

  • Affected version - geben Sie an mit welche QGIS-Version das Problem hat.

  • Platform - Plattform, die Sie benutzen

Bevor Sie den Fehler abschicken, prüfen Sie die Formatierung Ihres Berichts mit “Vorschau”. Bitte vermeiden Sie vorhandene Berichte zu bearbeiten, wenn es nicht um Tippfehler geht. Geben Sie lieber Kommentare ab.

Einen Stacktrace erzeugen

If you have a crash it might be useful to include a backtrace as the bug might be not reproducible on an other machine.

On Linux QGIS automatically tries to use gdb to connect to the crashing process to produce a backtrace. But some distributions disable the possiblity to connect debuggers to a running processes. In that case gdb only produces a rather useless message like:

QGIS died on signal 11Could not attach to process.  If your uid matches the uid of the target
process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
again as the root user.  For more details, see /etc/sysctl.d/10-ptrace.conf
ptrace: Operation not permitted.
No thread selected
No stack.
gdb returned 0
Aborted (core dumped)

In that case you should reenable that option by setting kernel.yama.ptrace_scope to 0 in /etc/sysctl.d/10-ptrace.conf (or /etc/sysctl.conf or some other file in /etc/sysctl.d/) and run sysctl -p as root. When you reproduce the crash after that, a backtrace will be printed instead.

If you cannot reproduce the crash, there should still be a core dump in the current directory, that can be analysed after the process has already terminated. It’s called core (on some systems a dot and the process id is append to the filename).

On some distributions the creation of core dumps is also disabled. In the event that you just get Aborted instead of Aborted (core dumped) when the crash occurs. Then you need to run ulimit -c unlimited before starting QGIS. You can also include that in your .profile, so that it’s always enabled when you login.

To produce a backtrace from the core file it you start gdb /path/to/the/qgis/binary core. The binary is usually /usr/bin/qgis or /usr/bin/qgis.bin on Debian with the GRASS plugin installed. In gdb you run bt which will produce the backtrace.

Protokollausgabe unter Windows

Das nächtliche Kompilat in OSGeo4W (Paket qgis-dev) wird mit Debugausgaben erzeugt, die sie mit DebugView ansehen können. Wenn das Problem nicht leicht nachzuvollziehen ist kann diese Ausgabe Licht auf die Stelle, an der QGIS abstürzt, werfen.

Einen Patch erstellen

Zu erledigen

Planung

Seit QGIS 2.0 wird die Weiterentwicklung einem Zeitplan folgen.

Ungerade Versionnummern (2.1, 2.3 usw) sind Entwicklungsversionen.

Gerade Versionsnummern (2.2, 2.4, usw) sind freigegebene Versionen.

Alle vier Monate wird eine neue Version veröffentlicht. In den ersten drei Monaten findet neue Entwicklung statt. Danach wird eine Feature Freeze ausgelöst, in dem keine neuen Funktionen mehr hinzugefügt werden. Der letzte Monat für Tests, Fehlerbehebung, Übersetzung und Releasevorbereitung verwendet. Wenn das Release stattfindet wird eine Zweig mit einer geraden Zahl erstellt und der Master-Zweig erhält die nächste ungerade Zahl. Nach dem Release wird zur Erstellung von Paketen aufgerufen.

Jedes dritte Release (beginnend mit 2.8) ist ein langfristiges Release (LTR) das bis zum nächsten langfristigen Release gepflegt wird.

Entwicklungsphase

In der Entwicklungsphade arbeiten die Entwickler an neuen Funktionen für das nächste Release. Frühzeitige Anwender können sich mit den nächtlichen Kompilaten, die wir für die Hauptplattformen haben, einen Eindruck des Entwicklungsfortschritt machen, Vorabtests durchführen und Fehlermeldungen und Ihre Gedanken liefern um die Entwicklung zu unterstützen.

Feature freeze

In der Feature Freeze Phase sind keine neuen Funktionen mehr erlaubt und jedermanns Fokus wechselt vom Erweitern von QGIS zur dessen Stabilisierung. Dies macht die nächtlichen Kompilate auch effektiv zu prereleases.

Anwender sollten nun mit ausgeweitetem Testen dieser Vorabversionen in Ihrer Umgebung beginnen und überprüfen, daß es keine Dinge gibt, die sie nicht im kommenden Release antreffen wollen. Alle Schwierigkeiten sollten berichtet werden (siehe Fehler, Funktionen und Probleme). Alles was unentdeckt bleibt, wird auch ins nächste Release kommen. Nur im Falle von schwerwiegenden Probleme werden Punktversionen (z.B. 2.4.1) erfolgen. Daher ist das Testen der Vorabversionen sehr wichtig.

Im Feature Freeze beobachten Entwickler den Hub und beginnen mit der Beseitigung der berichteten Fehler.

Mit dem Beginn des Feature Freezes werden auch die Übersetzungsdateie aktualisiert, damit die Übersetzer mit ihrer Arbeit beginnen können. Beachten Sie das die eine inkrementeller Prozeß sein kann, obwohl die Funktionen feststehen. Fehlerkorrekturen könnten immer noch Änderungen an den Übersetzungstexten mit sich bringen.

Release-Zeitplan

Im folgenden der Zeitplan für 2015

Woche

Datum

Ereignis

(30 31.10

2.6 wurde freigegeben

3 23.01

2.7 Freeze beginnt

7 20.02

2.8 wird freigegeben (LTR)

20 22.05

2.9 Freeze beginnt

25 26.06

2.10 wird freigeben

38 26.09

2.11 Freeze beginnt

42 23.01

2.12 wird freigeben

Ort von Vorabversionen / nächtlichen Kompilaten

Plattform

Ort

Windows

Wöchtentlicher Release-Kandidat (eigenständige Installation)

OSGeo4W
Linux Debian
Ubuntu
MacOS Mac OS

Entwicklung

Siehe INSTALL

API-Dokumentation

API-Documentation für C++ ist vorhanden.

Erweiterungsentwicklung

QGIS hat eine Erweiterungsinfrastruktur. Sie können viel neue Funktionionalität mit eigene Erweiterungen ergänzen.

Diese Erweiterunge können entweder in C++ oder Python geschrieben werden

C++-Erweiterungsentwicklung

Wie Sie Ihre erste C++-Erweiterung schreiben, finden Sie hier: C++-Erweiterungen entwickeln

Über ein Skript wird eine Erweiterungsvorlage erzeugt, die weiter verwendet werden kann.

Python-Erweiterungsentwicklung

QGIS bietet auch eine Menge für Python-Entwickler.

QGIS hat Python-Anbindung mit der Sie QGIS-Aufgaben mit Python automatisieren können.

Bei Interesse für Python-Erweiterungenentwicklung, gehen Sie zu Python-Erweiterungen entwickeln oder gucken Sie ins PyQGIS-Developer-Cookbook.

Beispiel für Python-Erweiterungen finden Sie unter http://plugins.qgis.org

Die QGIS-Pythonschnittstelle finden Sie hier:

http://qgis.org/api/classQgisInterface.html (für QGIS-Test)

http://qgis.org/api/2.0/classQgisInterface.html (für QGIS 2.0)

http://qgis.org/api/1.8/classQgisInterface.html (für QGIS 1.8)

GRASS-Werkzeuge hinzufügen

adding-grass-tools