GNU-Betriebssystem

Dieses Werk ist eine Übersetzung aus dem Englischen.

Ressourcen für die Entwicklung

Diese Seite beschreibt die auf Rechnern mit GNU-Projekten verfügbaren Entwicklungsdienste für GNU-Entwickler. Weitere Informationen über Privilegien und Verantwortlichkeiten der GNU-Projektbetreuer finden Sie unter Information für GNU-Projektbetreuer und GNU Coding-Standards. Ebenfalls interessant zu überprüfen kann die Übersicht über die Bedeutung eines GNU-Pakets sein.

Mit dem Überfluss von preiswerten Rechnern, die GNU/Linux ausführen können, sowie durch die bessere Verfügbarkeit des Internetzugangs, stehen heute vielen GNU-Freiwilligen alle benötigten Rechnerausstattungen zur Verfügung. Allerdings gibt es weiterhin Vorteile 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 befürwortet deshalb nachdrücklich, GNU-Softwareprojekte auf Rechnern unter gnu.org als Startseite ihres Webauftritts zu nutzen. Mit diesen Rechnern profitiert indirekt auch das GNU-Projekt durch die höhere Sensibilisierung der Öffentlichkeit für GNU und die Verbreitung der Idee der Zusammenarbeit 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

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

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

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 bug-gnu-utils@gnu.org, 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 http://lists.gnu.org abrufbar als auch durch den Betreuer der Mailingliste. Archive für manuell betreute Mailinglisten werden in der Regel auf den GNU-Rechnern unter /com/archive betreut.

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

Webseiten

Der Master-Webserver von GNU ist http://www.gnu.org/. Wir empfehlen dringend, dass GNU-Pakete http://www.gnu.org/software/PAKET-ID als primäre Startseite 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-Projektverwalter 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 kontinuierliches 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 gemacht werden. Es bietet von LCOV produzierte Kontrollflussorientierte Testverfahren-Berichte. 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; zum Beispiel wird GnuTLS mittels GNU libtasn1 erstellt und GNU libgcrypt-Builds entsprichen der neuesten Version.

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 hydra-users@gnu.org nachfragen.

Senden Sie nach Erstellung des Build-Rezepts eine Nachricht an hydra-users@gnu.org 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 über Hydra finden Sie unter Hydra User’s Guide (als PDF abrufbar). Weitere Einzelheiten finden Sie in den Bedienungsanleitungen von Nix und Nixpkgs.

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.