home_etc STRIKES BACK

[Tomasz Kłoczko]

On Thu, 6 Jun 2002, Blues wrote:

> On Thu, 6 Jun 2002, Tomek Orzechowski wrote:
> > No tak, tylko zmiana nazwy pliku komplikuje parę rzeczy:
> > - trzeba koniecznie uzupełnić dokumentację, to tak to bez czytania
> >   patchy albo wyników [ls]trace nie będzie wiadomo co i jak, czyli
> >   pracochłonne
> > - kloczek w ogóle nie widzi sensu zmiany nazw, nawet usuwania kropek na
> >   początku; jestem w stanie się z tym pogodzić, ale nie znaczy to, że
> >   mi się to podoba
> 
> Mi się usuwanie kropek podoba. W osobnym katalogu nie ma wogóle 
> potrzeby, żeby te pliki/katalogi były ukrywane, bo i po co. Tak jest 
> wygodniej.

Nie potrzebnie widziesz to jako nazwy plików. Po odseparowaniu w osobne 
drzewko staje się lepiej widoczne że to przypminą nazwę klucza w bazie :)
A to że klucz m kropki w nazwaczh .. (?) no cóż  .. taka przypadłość.

Mając klucz w bazie moża zmieniać potem backend bazy z drzewa katalogów na 
coś innego ale do tego jeszcze dłuuuga droga :_)

Lekkie zamieszanie jakie powstaje obecnie przy preparowaniu poprawek
wynika z tego że nie do końca trzymamy się założeń i/lub zdarza się że
ktoś do tych założeń dokłada własną cegiełkę :)
Niby nic złego jeszcze bo z takich odprysków może dojść cos istotrnego do 
samego rozwiązania. Wszystko pzry załozęniu że same załozenai nie są 
jeszcze do końca niejako "scentowane/zamrożone"

Rozwiązanie sytuacji jest dość proste:

1) trzymamy się ściśle specyfikacji uznając że jest ona już kompletna i 
   dalej podług tego są jzui tylko ralizowane konkretne patche.

2) uznajemy że jeszcze jest tu coś do omówiemnia ale najpierw to omawiamy 
   a potem ściśle według tego co z tycjh rozmów wynika cofamy się do 
   punktu 1.

> > Na razie mam wrażenie, że home_etc w Waszym wykonaniu mnie przerasta -
> > dla mnie miało być stadko małych patchy które zrobią porządek w moim ~/
> > a tu widzę że jakaś kosmiczna hydra się z tego wykluwa... Chcę tylko
> > zaznaczyć, że jedno podejście do robienia dużych zmian było, efekt jak
> > dla mnie niezadawalający...
> 
> Zadowalający. Pojawiły się błędy, ale... zawsze są.
> Gra jest naprawdę warta świeczki - po zrobieniu jednego porządnego patcha 
> reszta naprawdę pójdzie już duuuużo łatwiej... :)

Pawałe OK ale najpierw osoby które mają próbować implemtować pewne
założenia muszą jasno sobie zdać sprawę z tego jakie są owe załozenia :)

Jeżeli coś nie jest jeszcze jasne dla kogoś kto zamierza inwestować w to
swój własny czas w ten kierunek rozwoju musi starać się upewnić, że
dokładnie to samo rozumieją założenia i inni. Zapewne część nieporozumień
wynika z konkrenej postaci dokumentu który swoją formą rodzić może
nieporozumienia .. i to jest osobna sprawa, i w razie czego o jeszcze ten
jeden krok trzeba się cofnać zanim zaczniemy zmianaić aplikację już na
skalę masową.

Pamietajcie też o jednym: rozwiązanie *MUSI* być czytelne w swej
koncepcji nie tyle dla nawet jeszcze użytkownika co dla maintainerów
poszczególnych pakietów. Bez tego nie mamy dużych szans na relatywnie
szybką integrację poprawek w projektach.
Prostota i przejrzystość samego rozwiązania jest potrzebna także do
działnia w większej grupie nad całą populacją programów.

Mówiąc inaczej: jeżeli mamy dyskutować o tym co i jak robić to właśnie 
teraz traktójąc jeszcze nadal obecne patche dość eksperymentalnie i robiąc
poprawki w kolejnych programach tylko pod kontem tego że łapie sie jakiś
przykładowy program jako konkretnego przedstawiciela klasy programów w 
ramach których patche bendą już naprawdę bardzo podobne.
Wręcz newet na razie zatrzymałbym się tylko na tych pakietach które już
są zmodyfikowane.

Przykładowa rzecz która jeszcze w związku z wątiem mnie trapi to sama 
nazwa zmiennej. Obecnie jest to $CONFIG_DIR ale nie wydaje mi się to za 
dobre. Jest już $TEMPDIR i trzymając sie tego co już jest i działa może
lepiej byłoby jednak uzyć $CFGDIR lub $CONFDIR (raczej z lekkim
wskazaniem na to drugie jak chyba czytelniejsze).
O ile dalej schemat w przyszłości miałby być rozwijany na katalog z 
danymi programów (o tym też próbowaliśmy myśleć z Pawłem w pierwotnym
pomysle) to kolejną zmieną mogłoby być $DATADIR.

$TEMPDIR, $CONFDIR i kiedyś $DATADIR tworzyłyby już pewien dość czytelny
schemat/ciąg.

No i jeszcze prośby czysto techniczne: zastanawiajcie się więcej nad
różnymi (potencjalnymi konsekwencjami, a mniej działajcie przynajmniej
jeszcze na razie :) Jeżeli jakaś idea staje się za bardzo skomplikowana
to już powinno to zapalać żarówe brnięcia w jakś mało oświetloną ślepą
uliczkę :)
Jeżeli ktoś ma coś do dodania to prośba o staranie się nie tyle
przedstawiania własnego zdania co argumentacji tezy czy kontrtezy (np.  
pozytywnych bąć negatywnych konsekwencji rozwiazania). W ten sposób
powinno się też dać łatwo unikać osobistych podtekstów i/lub inni łatwiej
bendą się skupiać na tezach i argumentacjach, a nie na tym kto je
wygłasza. Nie dojdą także wogóle do głosu emocje, a całe rozwiązanie 
zostanie opracowane i dalej wykończone szybciej :o)

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*