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