TAGowanie zakazane.

Tomasz Kłoczko kloczek w rudy.mif.pg.gda.pl
Sob, 24 Maj 2003, 22:45:22 CEST


On Sat, 24 May 2003, Andrzej Krzysztofowicz wrote:
[..]
> > Nie koniecznie. Dróg do celu może być wiele. Pewne rzeczy pozostają
> > kwestią wyboru. Pewne wybory mają konsekwencje doraźne i długofalowe.
> 
> To dlaczego w przypadku kernela preferujesz jedna z nich, co do ktorej sa
> *powazne* zastrzezenia natury technicznej?

Powod jest trywialny.
Przez dwa lata od kiedy rzuciłem ten pomysł dopiero przedwczoraj Jakub
spróbował nakreślić pewne konkretne modyfikacje jedynego jak
dotąd alternatywnego do wdrożonego podejścia jakie zostało wyartykuowane.

> Nie dajac przy tym dostatecznego
> uzasadnienia merytorycznego (tzn. takiego, ktore zdolaloby przekonac
> *kogokolwiek* z oponentow)? Uwazasz, ze wszyscy, ktorzy sie z toba w tym
> momencie nie zgadzaja sa *przeciwnikami* PLD?

Może i nie wystarczającego ... może.
Czy wiedząc o tym że nikt inny nie ma nawet chęci ruszyć fgłowa żeby się 
nad tym zastanowić miałem prawo przyjąć że skoro nikt inny nie podejmuje
tematu to tym samym poziostawia mi wolną rękę rozwiaznia konkretncyh 
kwestji ?
Poprostu była tu próżnia którą trzęba było IMHO czymś wypełnić. To że 
reszta tego przez dwaa lata nie dostrzegała to osobna sprawa. Czas był tu 
sedzią bardzo sprawiedliwym i pokazał że to czego się wtedy obawiałem
prędzej czy później musiało się stać.

Jeszcze inaczje: nie uważam żeby rozwiąznie jakie zaproponowałem było czy 
jest doskonałe ale jako JEDYNE wogóle próbowało jakoś rozwiązać sprawe.

> W przypadku, gdy masz zastrzezenia do jakiegos rozwiazania wymagasz od
> innych, by przekonali _ciebie_. Zastosuj wiec w tym przypadku te sama zasade
> w druga strone.

Nie Andrzej. Spójrz dokładnie jak było krytykowane to co prentowałem. 
Generalnie krytyka sprowadzała się do inwektyw zaczajanąc na tym że to
jest debilne idąc dalej pzrez nieco bardziej stonowane że to jest głupie, 
a skończywszy na nic nie wnoszącej do całości ocenie, że to co przyjałem 
jest nierealne.
NIKT nie zaproponował alternatywy która niwelowałaby w spsób jednoznaczny
mankamentów o jakich pisałem.

Jeżeli ktokolwiek może się doszukiwac źródłą siły uporu i determinacji z
jakim jestem w stanie sie bronić dowolnymi sirodkami jakie beda mi wpadać
w ręce to źródło tej siły jest włąsnie tutaj .. brak
widocznej/wyartykuowanej alternatywy.

> > Jeżeli użyty sirodek techniczny będzie bardziej skomplikowany niż ten
> > użyty doraźnie to badź pewny że nie będę się starał niedpuścić do zmiany
> > doraźnej o ile będę tylko mógł przewidzieć takie kwestie.
> 
> I znowu ogolniki, a malo konkretow.

Tak bo też i to co napisał Pawłe było też bardzo ogólne.

> Co to znaczy "będę się starał niedpuścić" ? Bedziesz podejmowal 
> dyskusje merytoryczna, formulowal zakazy, czy zabieral rw?

Czy do tej pory unikałem merytorycznej dyskusji ?
Czy odbierałem RW osobom tylko dlatego że nie zgadzały się ze mną co do
konkretnych podnoszonych (technicznych) kwestji w trakcie dyskusji ? Czy 
może odebranie RW było moją bezpośrednią REAKCJĄ na czyjes działnia ?

Wydaje mi się że pytania te mają jednak jednoznaczne odpowiedzi i to takie 
które nie dają przesłanek co do tego żeby mieć nawet cień 
wątpliwości, że oponentów w dyskusji będę "likwidował" poprzez odebranie RW.

Rozmów zawsze w sytuacjach spornych było dużo. Do tego stopnia że wiele
razy wiele osób sygnalizowło przesyt z tego powodu. Nigdy w trakcie tego
typu sporów nie używąłem RW jako knebla. Wrecz odwrotnie .. nieco może
szermując RW staramelem się zmusić wręcz do mówienia (tak jak to było w
przypadku Arka z którego trzeba najwidoczniej przyjać że wołami należy
jeżeli już wyciągać jego własne zdanie i/lub że nie nalezy oczekiwać że
one je w istocie ma ;-).

> Co do meritum, czyli kernela i wszystkich modulow w jednym specu, to mi to
> nie przeszkadza pod trzema warunkami:
> - nie bede potrzebowal w tym grzebac (pewnie nie bede, bo rzadko uzywam
>   spakietowanego kernela)
> - stwierdzimy, ze nie zalecamy upgrejdu przez modem (ja tego nie robie)
> - system bedzie dobrze wspolpracowal z niedystrybucyjnym jadrem.

Hołk.
Co do powyższego dorzuce że zmiany na poczekaniu mogłby wpadać w postaci
małych patchy żeby nie tracić czasami czasu. Zaraz po tym niemniej powinno
się rozpocząć integrowanie tych zmian z zasobami konserwowanymi na
zewnątrz. NA pewno takei podejście powinno uproscić wsepne opracowywanie
kolejnej wer/rel kernela które przy końcu cyklu prac na branchu
powinny być integrowane w zewnetrznych zasobach po to żeby na czyzto an 
HEAD utrzymać możliwie prosta postać zasobu speca kernala.

Sam zamierzam uczestniczyć w kompetowaniu zewnętrznych patchy także w
konkretncyh wypadkach kiedy osoba szykujaca konkretną kolejną wer/rel
kernela uzna że skończyła etap wspnych prób będzie choćby mogła liczyć na
to że moze mi spokojnie próbować przekazać zadanie integracji tego w na
zewnątrz konserwowanym zasobie.

Jeszcze raz ... sprawa kernela jest dość wyjątkowa. Wynika z dużej
komoplikacji wewnętrznej tego zasobu. Potencjalnie drugima takim pakietem
który być może zasługiwałby na tego typu wyjątkowe traktowanie mogłoby być
XFree86 .. ale dopiero po tym jak w praniu wyjdzie że na kenerlu się to
sprawdziło i/lub w międzyczasie okaże się że na gwałt trzeba będzie szukać
tu jakiejś alternatywy w kestji uproszczenia konserwacji i tego pakietu.

Jeszcze dwie rzeczy.

Pierwsza to to że cheć spróbowania konserwowania poprawk po za kernelem
wynika z chęci podjęcia przy okazji próby uproszczenia zarządzania dość
mocno rozproszonymi i skomplikowanymi w istocie zasobami.
Nie mam pojecia czy to się sprawdzi ale na razie (znowu) nie widzę innej 
rozsądnej alternatywy gospodarowanai tym w duższej skali czasu (w skali 
zycia konkretnej głównej wersji kernal 2.4.x, 2.6.x ...)

I druga sprawa.
Po dzisiejszych rozmowach z Wojtkiem wychodzi na to, że przynajmniej w
pewnych kwestiach miało miesce niezrozumienie o co mi chodzi. Na pewno
część z tych kwesji sobie wyjaśniliśmy.

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*



Więcej informacji o liście dyskusyjnej pld-devel-pl