FreeBSD unterstützen

---

1.1. Aufgaben für Nicht-Programmierer

Viele Menschen, die an FreeBSD beteiligt sind, sind keine Programmierer. Es sind Leute, die an der Dokumentation arbeiten, Internetseiten erstellen oder einfach Hilfe anbieten. Alles, was diese Leute mitbringen müssen, sind Zeit und die Bereitschaft, etwas zu lernen.

1. Lesen Sie die häufig gestellten Fragen (FAQ) und das Handbuch gelegentlich. Wenn etwas schlecht erklärt wird, veraltet oder einfach falsch ist, teilen Sie es uns mit. Oder noch besser, korrigieren Sie es (SGML ist nicht schwer zu erlernen, wir akzeptieren aber auch Vorschläge im ASCII-Format.).

2. Helfen Sie dabei, die Dokumentation in Ihre Muttersprache zu übersetzen. Wenn an der Übersetzung in Ihre Sprache bereits gearbeitet wird, helfen Sie, indem Sie weitere Dokumente übersetzen, oder sorgen Sie dafür, dass die Übersetzungen aktuell sind. Lesen Sie zuerst die Übersetzungs-FAQ der Fibel für neue Mitarbeiter des FreeBSD-Dokumentations-Projekts. Sie verpflichten sich dabei nicht dazu, jede einzelne Seite zu übersetzen — als Freiwilliger übersetzen Sie genau so viel, wie Sie wollen. Wenn jemand mit der Übersetzung beginnt, beteiligen sich fast immer auch andere Personen daran. Wenn Sie nur Zeit und Energie für einen Teil der Dokumentation haben, dann übersetzen Sie bitte die Installationsanleitung.

3. Lesen Sie FreeBSD general questions sowie die the comp.unix.bsd.freebsd.misc newsgroup gelegentlich (oder sogar regelmäßig). Es kann sehr befriedigend sein, wenn Sie Ihr Wissen teilen und anderen Leuten dabei helfen können, deren Probleme zu lösen; vielleicht lernen Sie sogar noch etwas Neues! Diese Foren können auch eine Quelle für Ideen sein, an denen man arbeiten könnte.

---

1.2. Aufgaben für Programmierer

Die meisten der hier aufgeführten Aufgaben erfordern entweder einen bedeutenden Zeitaufwand oder eine sehr gute Kenntnis des FreeBSD-Kernels, oder beides. Es gibt jedoch genug Aufgaben, die auch für “Wochenendprogrammierer” geeignet sind.

1. Wenn Sie FreeBSD-CURRENT installiert haben und über eine schnelle Internetanbindung verfügen, können Sie von current.FreeBSD.org ein täglich neu erzeugtes Release herunterladen — versuchen Sie dann hin und wieder, das neueste Release zu installieren und melden Sie dabei eventuell auftretende Fehler.

2. Lesen Sie FreeBSD problem reports. Es könnte ein Problem geben, an dem Sie konstruktiv mitarbeiten könnten, oder für das es Patches gibt, die Sie testen könnten. Oder Sie könnten sogar versuchen, eines dieser Probleme selbst zu beheben.

3. Wenn Sie von Fehlerbehebungen wissen, die zwar erfolgreich auf -CURRENT angewendet wurden, die aber nach einem bestimmten Zeitraum nicht in -STABLE eingebracht wurden (normalerweise innerhalb einiger Wochen), erinnern Sie den Committer höflich daran.

4. Verschieben Sie beigetragene Software im Quellcodebaum nach src/contrib.

5. Stellen Sie sicher, dass der Code in src/contrib aktuell ist.

6. Bauen Sie den Quellcodebaum (oder einen Teil des Baumes) mit aktivierten Compilerwarnungen und beheben Sie auftretende Fehlermeldungen.

7. Beheben Sie Fehlermeldungen bei der Installation von Ports, die auf unsauberen Code hinweisen (etwa die Verwendung von gets() oder die Einbindung von malloc.h).

8. Wenn Sie einen Port beigetragen und dabei irgendwelche FreeBSD-spezifischen Änderungen getätigt haben, senden Sie Ihre Patches an die ursprünglichen Autoren (das wird ihr Leben einfacher machen, wenn die nächste Version des Ports erscheint).

9. Besorgen Sie sich Kopien von wichtigen Standards wie POSIX®. Als Ausgangspunkt für Ihre Suche können Sie die Seite des FreeBSD C99 & POSIX Standards Conformance Project verwenden. Vergleichen Sie das Verhalten von FreeBSD mit dem von dem jeweiligen Standard geforderten Verhalten. Verhält sich FreeBSD in einem Bereich unterschiedlich, sollten Sie einen Problembericht (PR) einsenden. Wenn Sie dazu in der Lage sind, können Sie sich auch eine Lösung des Problems überlegen und Ihrem PR einen Patch anfügen. Wenn Sie der Meinung sind, dass der Standard nicht korrekt ist, können Sie auch das jeweilige Standardgremium um weitere Informationen bitten.

10. Schlagen Sie weitere Aufgaben für diese Liste vor!

---

1.3. Die PR-Datenbank durchsehen

Die FreeBSD PR-Datenbank enthält alle derzeit offenen Problemberichte und Verbesserungswüsche, die von Anwendern eingereicht wurden. Die PR-Datenbank enthält sowohl Aufgaben für Programmierer als auch für Nichtprogrammierer. Gehen Sie die Liste der offenen PRs durch, um festzustellen, ob Sie ein Problem interessiert. Bei manchen Berichten geht es nur darum, zu überprüfen, ob der bereitgestellte Patch korrekt funktioniert. Andere Problemberichte sind hingegen komplexer, oder beinhalten überhaupt keinen Lösungsvorschlag.

Beginnen Sie mit den PRs, die niemandem zugewiesen sind. Ist ein PR, für den Sie eine Lösung hätten, bereits jemandem zugewiesen, nehmen Sie mit dem dafür Zuständigen Kontakt auf und fragen Sie ihn, ob Sie an der Lösung mitarbeiten können — es könnte etwa bereits ein Patch existieren, der nur noch getestet werden muss, oder Sie könnten weitere Ideen mit ihm diskutieren.

---

1.4. Wählen Sie einen der Einträge auf der “Ideen”-Seite aus

Die Liste von Projekten und Ideen für FreeBSD ist auch für Freiwillige interessant, die etwas zum FreeBSD Projekt beitragen möchten. Diese Liste wird regelmäßig aktualisiert und enthält Einträge für Programmierer und Nicht-Programmierer sowie Informationen zu jedem Projekt.

---

2.1. Fehlerberichte und allgemeine Vorschläge

Eine Idee oder ein Vorschlag von allgemeinem technischen Interesse sollte an FreeBSD technical discussions geschickt werden. Personen, die an solchen Fragen interessiert sind (und kein Problem mit einem hohen Mailaufkommen haben!) können die Mailingliste FreeBSD technical discussions auch abonnieren. Informationen zu dieser und anderen Mailinglisten finden Sie im FreeBSD Handbuch.

Wenn Sie einen Fehler gefunden oder eine Verbesserung entwickelt haben, vergessen Sie nicht, einen Bericht über send-pr(1) oder dessen Internetschnittstelle zu erstellen. Versuchen Sie bitte, jedes Feld auszufüllen. Ist Ihr Patch kleiner als 65 KB, sollten Sie ihn direkt in den Bericht einbauen. Kann der Patch direkt auf den Quellcodebaum angewendet werden, fügen Sie [PATCH] im Synopsis-Feld ein. Wenn Sie einen Patch einfügen, verwenden Sie bitte kein copy-and-paste, weil dadurch Tabulatoren in Leerzeichen umgewandelt werden, was den Patch unbrauchbar macht. Sind die Patches viel größer als 20 KB, sollten Sie sie komprimieren (z.B. mit gzip(1) oder bzip2(1)) und uuencode(1) verwenden, um diese in ihren Problembericht einzufügen.

Nachdem Sie einen Bericht versandt haben, erhalten Sie eine E-Mail, die eine Bestätigung sowie eine Identifikationsnummer enthält. Geben Sie diese Nummer im Betreff der Nachricht an ("Re: kern/3377"), wenn Sie neue Informationen zu diesem Problem an <[email protected]> senden. Zusätzliche Informationen zu Problemberichten sollten immer auf diese Art und Weise verschickt werden.

Sollten Sie innerhalb einer Woche keine Bestätigung erhalten, oder send-pr(1) nicht verwenden können, können Sie über FreeBSD problem reports jemanden bitten, dies für Sie zu erledigen.

Weitere Informationen zum Verfassen von guten Problemberichten finden Sie im entsprechenden Artikel.

---

2.2. Änderungen der Dokumentation

Änderungen der Dokumentation werden vom FreeBSD documentation project überwacht. Lesen Sie bitte die Fibel für neue Mitarbeiter des FreeBSD-Dokumentationsprojekts für weitere Informationen. Korrekturen und Ergänzungen (selbst kleine Änderungen sind willkommen!) werden mit send-pr(1) übermittelt. Lesen Sie dazu den Abschnitt Fehlerberichte und allgemeine Vorschläge.

---

2.3. Änderungen am vorhandenen Quellcode

Änderungen des existierenden Quellcodes sind etwas komplizierter. Entscheidend ist hier, wie vertraut Sie mit dem aktuellen Entwicklungsstand von FreeBSD sind. Es existiert eine spezielle, ständig aktualisierte Version von FreeBSD, die als “FreeBSD-CURRENT” bekannt ist. Diese ist auf verschiedenen Wegen erhältlich und stellt den aktuellen Stand der Entwicklung dar. Lesen Sie den Abschnitt FreeBSD-CURRENT vs. FreeBSD-STABLE des Handbuchs für weitere Informationen zur Installation und Verwendung von FreeBSD-CURRENT.

Arbeiten Sie mit älteren Quellcodeversionen, kann dies leider bedeuten, das Ihre Änderungen obsolet sind, oder sich nicht mehr in FreeBSD reintegrieren lassen. Dieses Risiko lässt sich verringern, wenn Sie die Mailinglisten FreeBSD announcements und FreeBSD-CURRENT abonnieren, auf denen aktuelle Systemänderungen diskutiert werden.

Wenn Ihre Änderungen auf ausreichend aktuellen Quellen beruhen, erstellen Sie als Nächstes einen Differenzensatz, den Sie an die FreeBSD-Entwickler schicken. Eine solche Differenz erstellen Sie mit diff(1).

Das bevorzugte diff(1)-Format für das Versenden von Patches ist das sogenannte unified output-Format, das Sie mit diff -u erstellen. Für größere Änderungen kann allerdings das context output-Format (erzeugt mit diff -c) die bessere Wahl sein.

Dazu ein Beispiel:

% diff -c oldfile newfile

oder

% diff -c -r olddir newdir

würde einen solchen Satz von Differenzen für die angegebene Verzeichnishierarchie erzeugen.

Genauso hätte

% diff -u oldfile newfile

oder

% diff -u -r olddir newdir

den gleichen Effekt, allerdings erfolgt die Ausgabe im unified diff-Format.

Lesen Sie dazu auch diff(1).

Nachdem Sie den Differenzensatz erstellt und mit patch(1) getestet haben, sollten Sie ihn an das FreeBSD-Projekt senden. Verwenden Sie dazu send-pr(1) (wie im Abschnitt Fehlerberichte und allgemeine Vorschläge beschrieben). Senden Sie die Differenzen nicht nur an FreeBSD technical discussions, da diese sonst verloren gehen. Wir freuen uns über Ihren Beitrag (schließlich ist FreeBSD ein Freiwilligenprojekt); wir sind aber manchmal nicht in der Lage, das Problem sofort anzugehen. Es verbleibt aber in der PR-Datenbank, bis wir dafür Zeit finden. Verwenden Sie den Begriff [PATCH] im Synopsis-Feld des Berichts.

Sie können auch ein tar-Archiv erzeugen (was vor allem dann sinnvoll ist, wenn Sie Dateien hinzugefügt, gelöscht oder umbenannt haben) und uuencode(1) auf das Archiv anwenden. Mit shar(1) erzeugte Archive sind ebenfalls willkommen.

Wenn Ihre Änderungen potentielle Probleme aufweisen, wie Unklarheiten im Hinblick auf das Copyright, oder Sie einfach eine genaue Überprüfung Ihrer Änderungen möchten, sollten Sie die Änderungen an das “FreeBSD core team” schicken, statt sie mit send-pr(1) zu versenden. Die Mailingliste “FreeBSD core team” erreicht nur eine kleine Gruppe von Leuten, die sich um die tägliche Arbeit an FreeBSD kümmern. Beachten Sie aber, dass diese Gruppe sehr beschäftigt ist. Daher sollten Sie nur dann eine E-Mail an sie schicken, wenn es absolut notwendig ist.

intro(9) und style(9) beschreiben den zu verwendenden Programmierstil. Bevor Sie also Code versenden, sollten Sie diese Informationen gelesen haben.

---

2.4. Neuer Code oder große Mehrwertpakete

Handelt es sich um einen bedeutenden Beitrag oder um das Hinzufügen von neuen wichtigen Fähigkeiten zu FreeBSD, ist es fast immer notwendig, die Änderungen als uuencoded tar-Dateien zu versenden, oder diese auf einer Internetseite oder einem FTP-Server bereitzustellen. Haben Sie keinen eigenen Speicherplatz im Internet, sollten Sie auf einer entsprechenden Mailinglisten nachfragen, ob jemand diese Aufgabe für Sie übernehmen kann.

Arbeitet man mit großen Codebeständen, kommt man unweigerlich mit den unterschiedlichen Lizenzen in Berührung. Code, der in FreeBSD enthalten ist, kann unter den folgenden Lizenzen stehen:

1. Der BSD-Lizenz. Diese Lizenz wird von uns bevorzugt, weil sie an “keine Bedingungen” geknüpft ist und daher für kommerzielle Unternehmen sehr attraktiv ist. Das FreeBSD-Projekt unterstützt diese kommerzielle Verwendung, die manchmal sogar in eine Förderung des FreeBSD-Projekts mündet.

2. Der GNU General Public License, oder “GPL”. Diese Lizenz ist nicht ganz so beliebt bei uns, da sie die kommerzielle Nutzung des Quellcodes einschränkt. In Anbetracht der schieren Menge an GPL-Quellcode, den wir derzeit benötigen (wie Compiler, Assembler oder Textformatierer) wären wir aber schlecht beraten, Beiträge, die unter dieser Lizenz stehen, abzulehnen. Code, der unter der GPL steht, befindet sich in einem gesonderten Bereich des Quellcodebaums, und zwar unter /sys/gnu oder /usr/src/gnu, und ist daher für jeden, für den die GPL ein Problem darstellt, sofort erkennbar.

Beiträge, die unter einer dieser Lizenzen stehen, müssen sorgfältig geprüft werden, bevor ihre Aufnahme in FreeBSD in Betracht gezogen wird. Beiträge, für die besonders restriktive Lizenzen gelten, werden generell abgelehnt, obwohl die Autoren ermutigt werden, ihre Veränderungen über ihre eigenen Kanäle verfügbar zu machen.

Um Ihre Arbeit unter die “BSD-Lizenz” zu stellen, fügen Sie den folgenden Text am Beginn jeder von Ihnen erstellten Quellcodedatei ein, wobei Sie den Text zwischen den %%-Zeichen durch die entsprechenden Informationen ersetzt:

Copyright (c) %%Jahr der Veröffentlichung%%
        %%Ihr Name%%, %%Ihr Land%%  %%Ihre Postleitzahl%%.
	All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
   notice, this list of conditions and the following disclaimer as
   the first lines of this file unmodified.
2. Redistributions in binary form must reproduce the above copyright
   notice, this list of conditions and the following disclaimer in the
   documentation and/or other materials provided with the distribution.

THIS SOFTWARE IS PROVIDED BY %%Ihr Name%% ``AS IS'' AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL %%Ihr Name%% BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

        $Id$

Eine Kopie dieses Textes finden Sie unter /usr/share/examples/etc/bsd-style-copyright.

---

2.5. Geld, Hardware oder Internetzugang

Wir freuen uns immer, wenn jemand das FreeBSD-Projekt durch Spenden unterstützen will. Auch kleine Spenden können eine große Wirkung haben. Hardwarespenden sind ebenfalls sehr wichtig, um die Liste der von FreeBSD unterstützten Hardware erweitern zu können, da uns die Mittel zum Erwerb dieser Hardware fehlen.