Ressourcen für die Entwicklung

Diese Seite beschreibt viele der auf Rechnern des GNU-Projekts für die Entwicklung zur Verfügung stehenden Ressourcen für GNU-Entwickler. Weitere Informationen über Privilegien und Verantwortlichkeiten der GNU-Projektbetreuer sind unter Information für GNU-Projektbetreuer und GNU-Programmierstil zu finden. Ebenfalls interessant können die Tipps für GNU-Betreuer und Überblick über die Bedeutung eines GNU-Pakets sein.

Mit dem sowohl Überfluss an preiswerten Rechnern, die GNU/Linux ausführen können, als auch der besseren Verfügbarkeit des Internetzugangs stehen heute vielen GNU-Freiwilligen alle benötigten Rechnerausstattungen zur Verfügung. Es gibt aber nach wie vor Vorzüge zentrale Rechner zu haben, auf denen GNU-Freiwillige zusammenarbeiten können, ohne den eigenen Rechner anderen zugänglich machen zu müssen.

Die Free Software Foundation hält GNU-Softwareprojekte deshalb nachdrücklich dazu an, die Rechner unter GNU.org als Startseite ihrer Webpräsenz zu benutzen. Durch die höhere Sensibilisierung der Öffentlichkeit für GNU und der Verbreitung der Idee der Zusammenarbeit profitiert damit indirekt auch das GNU-Projekt zu Gunsten aller.

Savannah und Versionskontrolle

Wenn Sie ein offizielles GNU-Paket entwickeln, wird dringend empfohlen ein öffentliches Projektarchiv zur Quellcodeverwaltung auf Savannah, dem GNU-Hosting-Server, zu nutzen. Zunächst Erstellen Sie ein eigenes Benutzerkonto und anschließend Registrieren Sie Ihr GNU-Paket. Danach wählen Sie ein System zur Versionskontrolle, erstellen Webseiten für Ihr Paket, verwalten die Berechtigungen der Projektmitglieder auf den Seiten und vieles mehr.

Mailinglisten

Mailinglisten werden für GNU-Softwarepakete je nach Bedarf sowohl manuell als auch automatisch gepflegt.

Wenn ein GNU-Paket auf Savannah registriert ist, ermöglicht eine Weboberfläche Entwicklern, Mailinglisten zu Ihrem Paket zu erstellen und zu pflegen.

Jedes GNU-Paketname sollte mindestens eine Mailingliste für Fehlerberichte mit dem entsprechenden Namen bug-name@gnu.org sowie alle Aliasnamen haben, die hilfreich sein können. Mit Savannah können Sie Mailinglisten für Ihr Paket nach diesem Muster erstellen. Einige Pakete teilen sich die Mailingliste [email protected], aber wir ermutigen, eigene einzurichten.

Pakete können weitere Mailinglisten für Ankündigungen, Hilfe, Quellcodeeinsendungen für Diskussion unter Projektmitgliedern oder was auch immer PaketbetreuerInnen nützlich finden.

Mailinglistenarchive für automatisch betreute Mailinglisten sind sowohl unter lists.gnu.org (Mbox-Archive über Rsync und ftp) als auch durch den Betreuer der Mailingliste abrufbar. Archive für manuell betreute Mailinglisten werden in der Regel auf den GNU-Rechnern unter /com/archive betreut.

Wird eine Mailingliste zu umfangreich und rechtfertigt dies, können wir eine -gnu.* -Newsgroup mit einem zwei-Wege-Verweis auf die Mailingliste einrichten.

Webseiten

Der GNU-Master-Webserver ist http://www.gnu.org/. Wir empfehlen dringend, dass GNU-Pakete als primäre Startseite http://www.gnu.org/software/PAKET-ID verwenden.

Mit Savannah können Entwickler ihre eigenen Webseiten unter dieser Internetadresse über ein CVS Web-Projektarchiv erstellen und pflegen, getrennt vom Quellcode-Projektarchiv des Pakets (welches alle Systeme zur Versionskontrolle unterstützt). Weitere Informationen über die Betreuung von GNU-Webseiten.

FTP

Die primäre FTP-Seite für GNU-Software befindet sich auf http://ftp.gnu.org/, die weltweit gespiegelt wird. Wir empfehlen nachdrücklich, alle GNU-Pakete hier hochzuladen (zusätzlich zu einem beliebigen, für Sie bequemeren weiteren Speicherort).

Wir verwenden einen anderen Server für Testversionen, damit Menschen sie nicht mit dem Gedanken installieren, sie wären zur Hauptsendezeit fertig. Dieser Server lautet ftp://alpha.gnu.org/.

Unter Informationen für GNU-Projektbetreuer finden Sie alle Details über den FTP-Upload-Vorgang, welcher der gleiche für beide Server ist.

Anmeldekonten

Wir bieten Shell-Anmeldezugang auf GNU-Rechner für Menschen, die diesen für die Arbeit an GNU-Software benötigen. Ein Anmeldekonto ist sowohl ein Privileg und eine Verantwortung und sollte nur für die Arbeit an GNU verwendet werden. Instructions for Obtaining an Account Machines sind separat beschrieben.

Auf dem allgemeinen Anmelderechner betreuen die GNU SRC-Paketentwickler eine Hierarchie aktueller GNU-Paket-Freigaben (/gd/gnu/gnusys/live), kompiliert aus den Originalquellen. Siehe auch /gd/gnu/gnusys/live/setup.

Sie können auch ein GNU-Benutzerkonto für E-Mail nutzen.

Hydra: Kontinuierliche Builds- und Portabilitätstests

Kontinuierliche Build-Dienstprogramme (oft als Kontinuierliche Integration bezeichnet) ermöglichen Programmierfehler frühzeitig zu entdecken, kurz nachdem sie in einem Softwareprojekt eingecheckt wurden, das besonders nützlich für gemeinsam entwickelte Software ist.

Hydra ist ein freies auf der Nix-Paketverwaltung basierendes Build-Dienstprogram. Administratoren der Hydra Instance (Delft University of Technology) haben großzügigerweise Slots für das GNU-Projekt angeboten. Projekte auf Hydra werden mit jedem Commit oder jeder Änderung ihrer Abhängigkeiten neu aufgebaut, was auch immer zuerst kommt (Abhängigkeiten umfassen die standardmäßige Build-Umgebung, die selbst die bisherigen freigegebenen Versionen von GCC, GNU Make usw. enthält).

Derzeit können Software-Builds auf GNU/Linux (i686 und x86_64) als auch FreeBSD, Darwin, Solaris, Cygwin, Cross-Builds für GNU/Hurd und GNU/Linux auf andere Architekturen und MinGW erstellt werden. Es kann mit LCOV erzeugte Kontrollflussorientierte Testverfahren-Berichte erstellen. Neben Quellcode-Tarballs und Nix-Paketen können Pakete für .deb- und .RPM-basierte Distributionen erstellt werden. Pakete können gegen die neuesten Versionen ihrer Abhängigkeiten erstellt werden. Beispielsweise wird die GNU Transport Layer Security-Bibliotek (GnuTLS) mittels der ASN.1-Bibliothek GNU Libtasn1 und der Kryptografie-Bibliothek GNU Libgcrypt entsprechend ihrer neuesten Revisionen erstellt.

Neben der Weboberfläche kann Hydra Benachrichtigungen per E-Mail senden, wenn sich der Build-Status eines Projekts ändert ‑ z. B. von ERFOLGREICH auf FEHLGESCHLAGEN. Wenn ein Build fehlschlägt, wird dieser protokolliert und der Build-Tree über die Weboberfläche zugänglich gemacht und ermöglicht, generierte Dateien (z. B. config.log oder testsuite.log) zu untersuchen, was Hinweise zur Fehlerbeseitigung liefert.

Jedes GNU-Softwarepaket kann einen Slot auf Hydra anfordern. Jedes Paket muss sein eigenes Build-Rezept, geschrieben in der Programmiersprache Nix, bereitstellen (im Nix-Sprachgebrauch ein Nix-Ausdruck). Nix-Ausdrücke für GNU-Projekte sind via Git verfügbar. Das Rezept ist für einfache Projekte mit Standard-Build-Dienstprogrammen von GNU wie Automake und Autoconf in der Regel recht einfach. Siehe beispielsweise das Rezept für GNU Patch. Gerne können Sie unter [email protected] nachfragen.

Senden Sie nach Erstellung des Build-Rezepts eine Nachricht an [email protected] und bitten in Hydra aufgenommen zu werden. Stellen Sie außerdem sicher, Mitglied des Hydra-Rezepte-Projekts auf Savannah zu sein. Dies ermöglicht Ihren, die Build-Aufgabe des Projekts direkt anzupassen.

Technische Informationen sind über die Handbuch-Seiten von Hydra (als HTML, PDF und Quelltext) abrufbar, weitere Einzelheiten über die Handbuch-Seiten von Nix (als HTML, PDF und Quelltext).

Plattform-Tester: Manuelle Portabilitätstests

Eine weitere nützliche Option für Tests von Vorabversion ist die Mailingliste der Plattform-Tester. Zeit vorausgesetzt, erstellen die Mitwirkenden auf dieser Mailingliste auf Anfrage Vorabversionen für eine Vielzahl von Plattformen (es sind Freiwillige erforderlich, die sich um Testanfragen kümmern; einfach die Mailingliste abonnieren und anfangen mitzuwirken!).

Im Gegensatz zum oben beschriebenen Hydra-Dienstprogramm arbeiten die Plattform-Tester im wesentlichen per Hand, jede Methode hat also ihre Vor- und Nachteile. Außerdem hat das Plattform-Tester-Team Zugang zu einer breiteren Auswahl an Plattformen und Compilern als das Hydra-Setup.

Wenn Sie also eine Vorabversion haben, können Sie an die Mailingliste schreiben: (1.) die URL zum Tarball bereitstellen, (2.) das geplante Datum der Veröffentlichung und (3.) die E-Mail-Adresse, an die die Build-Berichte gesendet werden sollen. Builds und Berichte erfolgen manuell von den Freiwilligen der Mailingliste.