2. Was Sie tun können

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 <bug-followup@FreeBSD.org> 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.