Kodyfikacja i "linia" Ac (Re: TAGowanie zakazane.)

Tomasz Kłoczko kloczek at rudy.mif.pg.gda.pl
Sat May 24 23:29:51 CEST 2003


On Sat, 24 May 2003, Marcin Wyszomierski wrote:

> * Tomasz Kłoczko <kloczek at rudy.mif.pg.gda.pl> [2003-05-24 18:49:52 +0200]:
> 
> > Prosty test: zadaj sobie pytanie czy takie poczynanie byłoby w interesie 
> > PLD i/lub czy PLD jako dysstrybucja zyskałoby coś na tym albo przynajmniej 
> > czy nie straciłoby pzrez to czegoś ?
> > Jeżeli odpowiedź będzie twierdząca (a tym wypadku wygląda że tak jest) to 
> > masz odpowiedź na powyższe w dowolnej kwestji.
> 
> Nazwałem to pytanie przekornym, bo w istocie im wiecej może, czytaj więcej
> wspiera platform dana tystrybucja tym lepiej dla niej samej. 
> 
> > Niech ktoś zacznie formułować takie zasady i zacznie dyskusję nad tym co 
> > uda mu Ci się zebrać w postaci tekstu.
> 
> Tak to musi być spisane w postaci tekstu i przedyskutowane wszystkie aspekty.
> Nie wykluczone, w moim skromnym mniemaniu, że bez głosowań nad spornymi
> kwestiami się nie obejdzie. Nie waże ile proces budowania takiego dokumentu
> miałby trfać, ważne by zaczął funkcjonowąć jako obowiązujące prawo.

Nie wiem dalczego ale odnosze wrążenie, że możesz być tą osoba która może
być na tyle rozsądna i komunikatywna że może spróbować pociagnać tą
kwestię z dobrym skutkiem (?).

> > Długo twierdziłem, że coś takiego nie jest potrzebne. Długo było to nie 
> > potrzebne o ile grono osób było jeszcze małe.
> 
> Czyli dobrze rozumiem, że uważasz iż podziął władzy/obowiązków w ramach
> najzwijmy to przyszłej konstytucji pld powinien zafunkcjonować i być
> nieodzownym elementem/podstawą jej dalszego rozwoju.

Nie pasują mi tu konotacje wynikające ze znaczenia słowa "władza" w tym 
sensie że wprowadzenie tego słowa w tym miejscu wprowadza niepotrzebne
skojarzenia i to takie które mogą spowodować zagubienie istoty celu
kodyfikacji pewnych niezbędncyh kwestji.

> > Jedna tylko uwaga co do tego otóż zestawu takich regół powinien być
> > możliwie maksymalnie krótki. Zażdy kolejny punkt w pewnym sensie będzie
> > wpływał na jakieś usztywnienie poczynań. Dla mnie osobiście będzie to
> > zapwewne zespół regół dość oczywistych ale najwidoczniej nie dla 
> > wszystkich wszystko jest oczywiste .. więcej coraz wyraźniej widać że w
> > chwilach kryzysowych których nie sposób unikać przez to że takich regół
> > nie mamy nie ma do czego się odwołać jako do punktu odniesienia.
> 
> Zbyt "daleko" jestem od tych newralgicznych problemów z jakimi boryka
> się PLD, dlatego nieostrożnością z mojej strony byłoby proponowanie
> szczegółowych rozwiązań. Jednak pewien podział nasuwa się sam: np.
> Każda platforma powinna mieć osobę/zespół odpowiedzialn{ą:y} za wszystko 
> co się dzieje wokół danej platformy. Począwszy od wydawania oficjalnych
> wersji distr. poprzez zatwierdzania update-security, aż po nadawanie
> zabieranie rw w cvs'e, w ramach danej platformy oczywizda; chyba technicznie
> jest to możliwe. 

Takie zespołu sa wręcz niezbędne.

Musze wrzucić tu nieco beletrystycznego wprowadzenia żeby przekazać o
co mniejwiecej od kilku miesiecy łazi mi po głowie (uwazam że i tak będzie 
to najprostrza metoda ;)

Przedstawie konkretny scenariusz który chcę tu realizować.

Wyobrażam sobie, że cała praca nad Ac dużo bardziej zacznie przypominać
pracę przy linni produkcyjnej co zresztą już widać z racji tego że
niektóre pakiety są w szkielecie kompletne i konserwacja ich sprowadza się
w sumie do zmiany numerków wersji i/lib rel przy przebudowywaniu tego w 
środowisku coraz to nowych bibliotek :)

Otóż .. 
Japończycy rozpoczyając konkurowanie z amerykanami na ryunku produkcji 
samochodów wprowaqdzili zdawałoby sie bezsensowną innowację .. dali
każdemu pracownikowi na linni prawio wstrzymanai linni o ile ktoś
zauważyłby usterkę.

Zmiana wydawała się o tyle bezsensowna że można było założyć że ludzie
będa tego mechanizmu nadużywać (lenistwo, zmeczenie) powodując tym samym 
straty .. i tak było w istocie, bo przerwy któtkie acz sie pojawiały.
Ale:
- praca dzięki temu była mniej nużąca, a osoby pracujace przy linni przez 
  to popełniały efektywnie mniej błędów,
- każdy czuł się lepiej dowartościowanym bo rónie ważnym jak 
  resta członkiem zespołu przez co uważniej i lepiej spełniał fukcje w 
  tymże zespole,
- straty wynikłe z przestojów były .. ale zaczęły być niwelowane przez
  zmniejszenie się strat wynikajacych z napraw (gwarancyjnych i 
  pogwarancyjnych),
- produkt końcowy w ocenie końcowej użytkowników zaczął pzrez 
  mzniejszenie usterek ujawnionych u użytkownika zyskiwać z czaem 
  opinnie wysikiej jakości (wyrób japoński przestł być definitywnie
  kojarzony z tandetą).

Wracając na podwórko PLD .. jak to odnieść do tego co mamy robić ?
Otóż bedę starał się utrzymać możliwie za wszelką cene synchroniczność
builderów na róznych architektórach. Da to następujące skutki:

- pewne sekewncje zleceń będą mogły iść w partiach nie wymagajacych 
  powtarzania na którymś z builderów z raji tego że zacznie coś
  szwankować na konkretnej arcitektórze. Wydanei setki pakietów źródłowych 
  w kolejnej wer/rel zdażało już się nam kilka razy przy szykowaniu Ra.

  Uwaga jaka tu trzeba poświecać jest wbre wpozorom kluczowa. Wiem że mało
  osób zdaje sobie z tego sprawę bo mało osób próbuje utrzymać w ryzach 
  builder, a jeszcze mniej kilka na potrzeby więcej niż jednej 
  architektóry.

- na pewno dbałość o ten szczegół zdobywać bedzie umysły tych osób kótre
  bedą sobie zadawać pytanie o spodziawaną/przewidywalna jakość PLD
  i to zanim jeszcze zdecyduja się sięgnać po to.

- praca dzięki temu będzie nazwijmy to nieco eufemistycznie "bogata w
  urozmaicenia" :_) .. czyli mówiąc inaczej nie będzie nudno :o)

- zmiany wprowadzone na jednej architektórze tak czy inaczej odbiją się
  niezerową/dodatnią zmianą jakości na pozostałych architektórach.

- nie będzie architektóry referencyjnej dzięki temi nie będzie miało 
  najmneijszego znaczenia to kto na czym przedewszytkim pracuje (jak komuś 
  wpadnie w ręce maszyna za milka mln$ ręce to bedzie mógł dzieki temu 
  może przekompilwoac np. OO w kilka minut czyli bedzie mógł w pełni 
  skorzystać z tego dobrodziejstwa ;)

Mogę mieć ogólne baczenie żeby taką linie synchronicznie posuwać. Mogę
reagować na to żeby usuwać drobne niedociagniecia blokujace
synchoroniczność parc ale w razie czego muszą być pod ręką osoby które
bedą miały determinacje usuniecia błędów zależncyh od architektóry w
możliwie krótkim czasie. Na ten czas IMHO warto całość nieco wstrzymać 
(innych zajeć jest aż nadto :)

> > Od razu ostrzegę, że jeżeli zespół takich regół będzie formułowany
> > *z myślą* o tym jak tylko ograniczyć moje własne poczynania w sensie, że
> > będzie zespołem haków na mnie osobiście bez zachowania pełnej symetrii czy
> > też obiektywizmu podejścia to to nie wypali.
> 
> Myślę Tomku, że jeżeli takowa konstytucja PLD kiedykolwiek powstanie wprowadzi
> zaczej demokratyczne zasady budowy dystrybucji.

"Po owocach poznasz .." :)

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



More information about the pld-devel-pl mailing list