par wymaga i wskazwek dla developerw:

1) gdy co poprawiasz/dodajesz, zachowuj styl reszty kodu. wcicia rb
   znakami tabulacji, a nie spacjami. stawiaj spacje po przecinkach i
   rednikach. jeli masz inny styl, a podesane poprawki bd dobre
   i/lub potrzebne, nie zdziw si, jeli Twj kod zostanie przeredagowany.

2) dopisuj si do copyrightw na pocztku pliku. inaczej zakadam, e
   zrzekasz si praw do podesanych kawakw kodu. oczywicie podsyany
   kod musi by na takiej samej licencji, co reszta. w innym wypadku 
   nie tra czasu i go nie przysyaj.

3) zachowuj przyjt konwencj. jeli wszystkie zmienne danej struktury
   maj nazwy typu ,,foobar_count'', nie dodawaj ,,foocount'', czy
   ,,nfoo''.

4) nie zmieniaj api bez powodu. nawet jeli chcesz to zrobi, skonsultuj
   z reszt developerw.

5) tworzc wikszy kawaek/modu/plik przeznaczony do jakiej konkretnej
   funkcji, staraj si nazywa funkcje i zmienne tak, by byo wiadomo,
   do czego su. przykad: funkcje dotyczce list zaczynaj si list_*,
   funkcje dotyczce userlisty to userlist_*, konfiguracja to config_*.

6) do alokacji pamici uywaj funkcji xmalloc(), xcalloc(), xrealloc()
   i xstrdup(). nie musisz sprawdza zwracanej wartoci. jeli zabraknie
   pamici, funkcje te same zajm si grzecznym zamkniciem programu.
   dbaj o zwalnianie buforw, gdy nie s one ju potrzebne.

   zamiast strncpy() oraz strncat() uywaj strlcpy() i strlcat(), ktre
   przyjmuj jako parametr cakowity rozmiar bufora. nie trzeba si martwi
   o to, ile w buforze pozostao jeszcze miejsca, czy znak zerowy si zmieci,
   etc. obie funkcje _zawsze_ zwracaj ilo znakw, jaka zostaa(by) zapisana
   do bufora.

7) jeli nie masz pojcia o alokacji pamici i obsudze stringw w C,
   najlepiej daj sobie spokj. nawet jeli kod dziaa, ale nie trzyma
   si kupy, zostanie odrzucony.

8) podsyajc patche, twrz je poleceniem ,,diff -u''. diff bez parametrw
   generuje patche, ktre nie zawieraj adnego kontekstu i ciko je
   doczy do rda, gdy zmienia si wczeniej chocia jedna linijka.
   patche najlepiej generowa wzgldem najwieszej wersji, ale nie jest
   to wymagane, jeli w midzyczasie nie byo powanych zmian w kodzie.

9) jeli poprawka jest niewielka (jedna, dwie linijki), nie tra swojego,
   ani mojego czasu, tylko po prostu wklej orygina i poprawion wersj do
   treci listu.

nikt nie bdzie si zachowywa tak, e bdzie wrzuca do rde tylko
to, co mu si podoba, albo tylko patche ludzi, z ktrymi piwo pija. byle
tylko byy zachowane pewne zasady i nie byo po miesicu baaganu w kodzie.
oczywicie wszystkie zmiany bd przegldane i w razie czego autor dostanie
po apach.

$Id$
