parę wymagań i wskazówek dla developerów:

1) gdy coś poprawiasz/dodajesz, zachowuj styl reszty kodu. wcięcia rób
   znakami tabulacji, a nie spacjami. stawiaj spacje po przecinkach i
   średnikach. jeśli masz inny styl, a podesłane poprawki będą dobre
   i/lub potrzebne, nie zdziw się, jeśli Twój kod zostanie przeredagowany.

2) dopisuj się do copyrightów na początku pliku. inaczej zakładam, że
   zrzekasz się praw do podesłanych kawałków kodu. oczywiście podsyłany
   kod musi być na takiej samej licencji, co reszta. w innym wypadku 
   nie trać czasu i go nie przysyłaj.

3) zachowuj przyjętą konwencję. jeśli wszystkie zmienne danej struktury
   mają nazwy typu ,,foobar_count'', nie dodawaj ,,foocount'', czy
   ,,nfoo''.

4) nie zmieniaj api bez powodu. nawet jeśli chcesz to zrobić, skonsultuj
   z resztą developerów.

5) tworząc większy kawałek/moduł/plik przeznaczony do jakiejś konkretnej
   funkcji, staraj się nazywać funkcje i zmienne tak, by było wiadomo,
   do czego służą. przykład: funkcje dotyczące list zaczynają się list_*,
   funkcje dotyczące userlisty to userlist_*, konfiguracja to config_*.

6) do alokacji pamięci używaj funkcji xmalloc(), xcalloc(), xrealloc()
   i xstrdup(). nie musisz sprawdzać zwracanej wartości. jeśli zabraknie
   pamięci, funkcje te same zajmą się grzecznym zamknięciem programu.
   dbaj o zwalnianie buforów, gdy nie są one już potrzebne.

   zamiast strncpy() oraz strncat() używaj strlcpy() i strlcat(), które
   przyjmują jako parametr całkowity rozmiar bufora. nie trzeba się martwić
   o to, ile w buforze pozostało jeszcze miejsca, czy znak zerowy się zmieści,
   etc. obie funkcje _zawsze_ zwracają ilość znaków, jaka została(by) zapisana
   do bufora.

7) jeśli nie masz pojęcia o alokacji pamięci i obsłudze stringów w C,
   najlepiej daj sobie spokój. nawet jeśli kod działa, ale nie trzyma
   się kupy, zostanie odrzucony.

8) podsyłając patche, twórz je poleceniem ,,diff -u''. diff bez parametrów
   generuje patche, które nie zawierają żadnego kontekstu i ciężko je
   dołączyć do źródła, gdy zmieniła się wcześniej chociaż jedna linijka.
   patche najlepiej generować względem najświeższej wersji, ale nie jest
   to wymagane, jeśli w międzyczasie nie było poważnych zmian w kodzie.

9) jeśli poprawka jest niewielka (jedna, dwie linijki), nie trać swojego,
   ani mojego czasu, tylko po prostu wklej oryginał i poprawioną wersję do
   treści listu.

nikt nie będzie się zachowywać tak, że będzie wrzucać do źródeł tylko
to, co mu się podoba, albo tylko patche ludzi, z którymi piwo pija. byle
tylko były zachowane pewne zasady i nie było po miesiącu bałaganu w kodzie.
oczywiście wszystkie zmiany będą przeglądane i w razie czego autor dostanie
po łapach.

$Id$