[ipv6-tf] Projekt DHCPv6

[Tomasz Mrugalski]

Witam

W końcu znalazłem chwilkę, aby napisać kilka słów odnośnie naszego 
spotkania. Przede wszystkich chciałbym podziękować Bartkowi Gajdzie za 
zorganizowanie i pierwszorzędne poprowadzenie spotkania. Dobra robota.

O DHCPv6 opowiadałem na naszym spotkaniu, więc wstęp nie jest chyba 
konieczny. Mogę od razu przejść do rzeczy. W trakcie dyskusji, która 
wywiązała się po prezentacji wyłoniło się kilka spraw, którymi warto się 
zająć. W nawiasach numery bugów w bugzilli (http://klub.com.pl/bugzilla/).

  DHCPv6 TODO
-------------

1. Instalator (#59, #60) - Wypadałoby przygotować instalkę pod windowsy.
    Michał Balcerkiewicz zaproponował, żeby użyć mechanizmu dostępnego w MS
    VC++. Nie podoba mi się to rozwiązanie, bo wg słów Michała konieczna
    jest jakaś rejestracja. Dodatkowo coraz bardziej uzależniamy się od
    jednego komercyjnego producenta, co nigdy nie jest fajną sprawą. Od
    siebie dodam, że słyszałem sporo niepochlebnych opinii na temat tego
    install wizarda - głównie chodzi o przygotowywanie kolejnych instalek
    (ponoć mnóstwo roboty za każdym razem). W przeciwieństwie do programu
    Inno Setup, który ma być rewelacyjny. Niestety, nie miałem czasu tego
    sprawdzić.
2. Przygotowanie RPMów (#63,#64). Nie jestem pewien, czy dobrze kojarzę
    nazwisko z osobą, ale chyba Marcin Kamiński zaproponował, żeby
    przygotować paczki z RPMami. Ułatwi to instalację w systemach
    wykorzystujących ten format pakietów (RedHat/Fedora, PLD, Mandrake).
    Są też szanse na włączenie do dystrybucji PLD. Uważam, że zanim się
    z tym uporamy, konieczne jest wykonanie zadania nr 3.
3. (#61, #62) - brakuje manuala. Zanim zaczniemy na poważnie myśleć o
    przygotowaniu prmów/debów itp. konieczny jest manual. Musi zawierać
    krótkie informacje nt. używalności i konfiguracji.
4. Przygotowanie DEBów (#65, #66). Podobnie, jak task 2. Tym razem chodzi
    o Debiana i pochodne.
5. Zmiana parsera z klasycznego na XML. To propozycja (znów nie jestem
    pewien nazwiska) Bartka Beltera. Uważam, że pomysł jest ciekawy, jednak
    jego realizacja (miesiąc pisania, miesiąc usuwania bugów) jest zbyt
    czasochłonna. Dużo pracy, a zysk w funkcjonalności zerowy. Oprócz tego
    niewiele aplikacji korzysta z plików konfiguracyjnych zapisanych w
    XMLu (np. sendmail, apache, proftpd, exim, samba itd. wszystkie mają
    klasyczne konfigi), więc jest to pomysł nieco kontrowersyjny. Jego
    istotną zaletą byłaby możliwość napisania zautomatyzowanego (klikanego?)
    generatora konfigów. Pojawia się jednak pytanie, komu miałby on służyć?
    Administratorzy i tak nie mają nic przeciwko edycji konfigów. Natomiast
    użytkownicy końcowi... hmmm, nie jestem pewien, czy to do nich jest
    adresowane DHCPv6.
6. WIN32: Rezygnacja z wykorzystania netsh.exe na rzecz wykorzystania
    funckji systemowych. Jestem jak najbardziej za. Jedyny powód, dla
    którego netsh.exe jest jeszcze wywoływane w kodzie to taki, że nie
    udało mi się znaleźć sposobu na realizację pewnych rzeczy, np.
    dodanie/zdjęcie adresu z interfejsu, ustawienie serwerów DNS itd.
    Jeżeli Michał byłby w stanie to zrobić, to ja z radością czekam na
    patche.
7. Testy. Ekipa PCSS obiecała przeprowadzić testy. Czekam z
    niecierpliwością na ich wyniki. W razie problemów nie wahajcie się ze
    zgłaszaniem błędów. Jeżeli uważacie, że coś działa nie tak, jak powinno
    (nie tylko w samej aplikacji, ale również systemie budowania, patrz
    task 8.) śmiało wbijajcie opis w bugzilli. Jeżeli okaże się, że jednak
    wszystko jest ok - nie ma problemu. Zamykamy buga ze statusem
    fixed_nobug i po kłopocie.
8. Raportowanie błędów. Jeżeli użytkownicy/testerzy natrafią na jakieś
    nieprawidłowości w działaniu, proszę umieścić buga w bugzilli lub
    podesłać mi mailem opis problemu. Prosiłbym o nieco bardziej
    szczegółowy opis, niż "mamy problemy z kompilacją" :) Zrzut ostatnich
    kilku linijek działania polecenia make all jest niezłym pomysłem.
    Do tego wyniki:
    uname -a
    gcc --version
    g++ --version
    bison --version
    flex --version
    przekierowane do pliku też na pewno nie zaszkodzą.
9. Flex/Bison: Zarówno flex, jak i bison++ NIE są potrzebne do kompilacji
    źródeł. Kod wygenerowany z tych programów jest już w tar.gz i CVSie.
    Oba te szatańskie narzędzia są potrzebne jedynie w przypadku, kiedy
    ktoś pragnie podjąć desperacką próbę modyfikacji parserów.
A. Patche. Z niecierpliwością oczekuję na wszelkiego rodzaju patche. Po
    podesłaniu kilku (2-3) patchy, chętnemu mogę dać dostęp do CVSa.
    Niestety, na razie w ciągu roku istnienia projektu łączną ilość patchy
    można policzyć na palcach jednej ręki pracownika tartaku. :) Mam
    nadzieję, że ten stan wkrótce ulegnie zmianie.

Ja ze swojej strony w pierwszej kolejności zajmę się przygotowaniem 
manuala (task 3). Przygotuję też developer's guide, czyli 
dokumencik/przewodnik po źródłach ułatwiający orientację.

Uff, to by było na tyle. Jeżeli macie jakieś sugestie odnośnie 
funkcjonalności, którą wartoby dodać, czekam na sugestię.

Pozdrawiam z Gdańska i życzę udanych testów.

-- 
Tomasz Mrugalski,              | "We all know Linux is great...it does    |
thomson(at)klub(dot)com(dot)pl |  infinite loops in 5 seconds."           |
                                |                           Linus Torvalds |