User postgres

Pon, 18 Sty 1999, 14:09:09 CET

On Sun, 17 Jan 1999, Wojtek Slusarczyk wrote:

> On Sat, 16 Jan 1999, [ISO-8859-2] Tomasz Kłoczko wrote:
> 
> > I co z tego, że usuniesz tego DoS kiedy dalej będziesz(my) tracił kupę
> > czasu na SbO ? Zrozum, że apeluję o zaprzestanie niepotrzebnych działań,
> > działń które pochłaniają cenny czas, które utrudniają w tej intensyfikację
> > nad PLD wspólnie w devel i stable, które czynia proces przechodzenia
> > pakietów z devel do stable trudnym .. cztaj: czas poświęcony na deve
> > trzeba jeszcze pomnoeyć przez 1.x (x bliskie 9), żeby uzyskać pakiet do
> > stable. W tej cwili stawiam poprostu pytanie o sens pewnych działań, o to
> > czy obecny dualizm cxzemuś wogóle służy, czy PLD to są dwie dystrybucje
> > czy jedna w duch odmianach (produkcyjnej i rozwojowej).
> 
> Wczoraj jakos uszedl mi uwadze ten fragment wiec dzisiaj bedac wypoczetym
> sie do niego ustosunkuje.
> 
> 1. W develu nie musimy juz tracic cennego czasu na ustawianie odpowiednich
> atrybutow na binarkach i plikach systemowych, poniewaz to zostalo zrobione
> do konca na przelomie listopada/grudnia zeszlego roku.

Czy zauważyłeś to, że w tej chwili to co mamy to tylko ułamek tego co
możemy mieć i że każdy następny pakiet włączany do zasobów devel będzie
musiał być przerabiany pod kątek SbO ?

> 2. Kiedy zaczynalismy prace nad Tornadem, w okolicy sierpnia przezylem
> piewrwszy szok gdy zapadla decyzja o przenoszeniu %changeloga na koniec
> speca .... nic zostalo to zrobione.

Czy to było coś złego skoro jest używane jako argument (na co ? lub
przeciwko czemu ?) ?

> 3. We wrzesniu ponownie doznalem 'wstrzasu' kiedy zapadla decyzja o
> stosowaniu %defattr(644,root,root,755) -- nic tam, wszystko zostalo
> przeprawione zgodnie z obowiazujacym standardem ...

Czy to było coś złego skoro jest używane jako argument (na co ? lub 
przeciwko czemu ?) ?

> 4. Pod koniec wrzesnia zapadla decyzja o 'wdrazaniu estetyki specow'
> (a mielismy juz na devel kilkaset pakietow !) Wszystko zostalo przerobione
> i wyrownane i wypolerowane tak, ze teraz stable (bez obrazy oczywiscie
> ...) jest w porownaniu z develem niechlujny i nieczytelny (za wyjatkiem
> moze 5-10 % pakietow).

Można prosić o szczegóły ?

> 5. Kolejna sprawa to so-linki manow... Poszedl rozkaz aby
> wywalac symlinki bo to sie pozniej przyda do kompresji ... Nic tam
> rozpakowano kilkaset pakietow i stopniowo (3-4 tyg. dokonano zmian) ...

Czy to było coś złego skoro jest używane jako argument (na co ? lub 
przeciwko czemu ?) ?

> 6. Poszedl kolejny 'prikaz' ze dla zachowania zgodnosci ze stable i dla
> oszczedzenia miejsca na dysku trzeba kompresowac many ... uff.. O.K jak
> kompresowac to porzadnie, czyli bzipem ... nikt oczywiscie o tym nie
> pomyslal wczesniej a i teraz jakos do bledu nik nie chce sie przyznac i
> nadal w stable many sa kompresowane malo-wydajnym (w porownaniu z bzipem)
> gzipem ... ale to juz nie moja dzialka ...

Czy to było coś złego skoro jest używane jako argument (na co ? lub 
przeciwko czemu ?) ?
Po za tym czy to ja rzuciłem pomysł o kompresowaniu ?

> 7. Niedawno dodatkowe rozporzadzenie traktowalo o 'nowym standardzie' 
> wprowadzania *.info w skryptach %post i %pre .... nic nie powiedzialem i
> jak moze zauwazyles wszystko jest stpniowo i z rozwaga portowane ze stable
> do devela ....

Czy to było coś złego skoro jest używane jako argument (na co ? lub 
przeciwko czemu ?) ?

> Jak mnie pamiec nie zawodzi latem zeszlego roku byla rozmowa na temat
> sensu istnienia devel'a. Z ustalen wynikalo, ze to bedzie taki rawhide
> dla PLD i tam wszystkie nowe oprogramowanie bedzie testowane, przy czym
> jak sie nie sprawdzi (czyt. beda opory np. z binarkami o atrybutach 711)
> to takie rowiaznie ma nie wejsc do stable i kropka. 
> 
> Jak zdazylem zauwazyc ostatnimi czasy cale PLD zostalo postawione na
> glowie, tzn. awantra jest o to ze na develu sa binarki 711, 4710 i masz
> problemy potem z przeniesieniem tego na stable ... Generalnie IMHO sprawy
> powinny wygladac tak, ze to my biezemy ze stable pakiety i na podstawie
> specow stablowych generujemy pakiety dla devela. I owszem na poczatku tak
> bylo wszsystko zostalo pobrane ze stable, SRCRPM'y wyczyszczono
> doszczetnie incoming cenzora ( do tej pory co dziennie jest
> sprawdzany czy nie ma nic nowego jak rowniez /test i nowe src.rpmy). 
> Wszystko co sie pojawi na anonsie CVS jest skrzetnie odnotowywane i to co
> Ty poprawiasz dla stable w przeciagu kilku godzin znajduje sie rowniez w
> develu (a co jest oczywiscie rozsadne...) Czyli z mojego punktu widzenia
> sprawa wyglada tak, ze devel caly czas obserwuje co sie na stable dzieje i
> jakie pakiety wchodza do incominaga weryfikujac pewne rzeczy, natomiast
> "stable" wyklada laske na devel i jeszcze opier*** ze na binarkach jest
> 711 i to jest security by obscurity, i wogole, ze sa remote exploity na
> Tornado i ze  lepiej zrobic tak jak na stable czyli 'wypiac tylek' i
> narysowac na nim tarcze strzelnicza .. (czyt. zachowac uprawnienia jakie
> sa proponowane dla stable ...)  A przeciez byla mowa, ze devel robi
> 'experymenta' i jak nie wypali jakies rozwiazanie to nie wchodzi do 
> stable ...

Nikt na nikogo nie kładzie laski. Poprostu w sytuacji kiedy rozbierzności
są dość duże jak wyobrażasz sobie płynne przechoidzeni devel -> stable
(zdaje się, że to ten kietunek miał być poprawny).
Po za tym jescze raz się spytam .. czy zmiana uprawnień to nie jest SbO ?
Jeżeli tak to jest to nie potrzebne i pochłania niepotrzebnie czas.

> Dalej wracajac do stable ... dawno skonczyl sie juz na nim zapas
> zrodel (czyt. wszystko co bylo mozna i nie tylko zostalo przeniesione do
> devela) i teraz sami juz musimy sie troszczyc o nabywanie nowych pakietow.

Tu chyba nieco przesadziłeś. Ja przez cały czas o SbO. Czy mamy się
licytować na ilość pakietów i zmian ?

> Co wiecej uwazam ze na develu sa zachowane wszelkie standardy odnosnie
> wygladu specow (odstepy, wyrownania, %defattr(644,root,root,755, itp.) 
> Jak na moj gust przekompilowanie pakietu na stable wiaze sie ze zmaina
> atrybutow, czyli przy naszej rozpisce uprawnien jest to mniej wiecej
> cosik takiego:
> 
> -%attr(711,root,root) /usr/bin/aaabb
> -%attr(711,root,root) /usr/bin/bbcc
> -%attr(711,root,root) /usr/bin/ddee
> -%attr(755,root,root) /usr/bin/ffee.sh
> 
> +%attr(755,root,root) /usr/bin/*

Bo to jest SbO.

> Dalej odnosze wrazenie, ze olewane sa dokladnie pakiety z devela i raczej
> stable jest wzorowane na poczynaniach rawhide'a (przyklad z bashem)  ;(

Konkretnie .. wcześniej nie było o tym sygnałów.

> W tej chwili pozostala nam jeszcze jedna rzecz czyli dokladna rozpiska
> grup Admin, Libraries, Base itp. co ulatwi zycie chlopakom od instalatora
> oraz dokladne i szczegolowe okreslenie przynaleznosci katalogow do
> poszczegolnych pakietow (dla plikow  to juz prawie w 100%
> zostalo zrobione)... Oczywiscie nie da sie tego tak 'hop siup' zalatwic
> dlatego kazdy pakiet jeszcze szczegolowo kontrolowany pod kontem innych
> np. setup, filesystem itp ... Wiekszosc pakietow i ich katalogow jest juz
> okreslona zostaly najwieksze landary typu TeX (poprawiany w tej chwili), 
> X'y (raczej poprawnie ale trzeba jeszcze kilka katalogow przydzielic),
> Xemacs, emasc -- podczas upgrade zostanie zalatwione .... 
> 
> Przyznam, ze jestem troche rozczarowany Twoja postawa i stosunkiem do
> devela i jego pakietow... Zrola devela juz kilka razy byl rozpakowywane
> doszczetnie i kazdy doslownie _KAZDY_ spec poprawiny po kontem nowych
> dyrektyw -- slysznych zreszta, wprawdzie ja mam zawsze opory do zmian 
> ale musze przyznac ze raczej wszsytkie Twoje decyzje byly dobre (za
> wyjatkiem gzipowanych manow i uprawnien 644 na plikach konfiguracyjnych)
> Jak siegne pamiecia, ile czasu sie wkurzalem, ze wszsytko co nowe
> sh-utilsy, apache, kde idzie tylko do incominga stable a na devela lache
> wykladaja i we dwojke z Marcinem musimy ciulac pakiety i patrzec czy sie
> jeszcze ktory nie pierdykne gdzies ... Ale nadeszly i dobre czasy kiedy
> devela zaczal poprawiac Ziemek z Arkiem ... Zauwaz ile poprawek
> zwiazanych z poprawnoscia funkcjonowania zostalo zrobionych od grudnia...
> 
> A z reszta koncze ten dlugawy list i mam ndzieje, ze nie zrozumiesz mnie
> zle,

Właśnie nie wiem jak to rozumieć.

> ale myslalem ze devel ma wygladac, tak samo jak stable (czyt. te same
> pakiety + nowe ) i to my mamy testowac wszelkie zachowania nowych
> programow i podpowiadac co ma a co nie wrzucone do stable, stable
> developerzy natomiast wprowadzja/nie wprowadzja rozwiazan z devela ale
> nigdy mi sie nie przysnilo ze mam robic pakiety w ten sposob zeby byly
> tylko i wylacznie do uzytku na stable a olac cala kupe zawilych zaleznosci
> na rodzimym develu i nie przjmowac sie nim -- niech bedzie bajzel na
> Tornadzie to nie wazne najwzniejsze aby stablowcy mogli sobie pobrac
> pakiet. dopisac do %changeloga:
> 
> - minor changes,
> - build against PLD-stable,
> - standarized %prep && %build .
> 
> i wykonac rpm  -ba *.spec ... A jak cos nie tak to opier*** nas zesmy lipe
> wypuscili i wogole ...   

Nie ustosunkowałeś się do jednej rzeczy mianowicie do SbO, co do
konieczności i zasadności tej praktyki, a przecież tylko i wyłącznie o to
mi chodziło. Reszta to są szczeły nie związane z tematem.

Po za tym czy ja op* Ciebie czy cokolwiek z devel ? Przez cały czas piszę
o zaprzestaniu SbO (i podaję konkretne powody) i o tym, że bez tego spece
w stable i devel będą mogły być takiesame. Dzisiaj zgodzić się na
SbO nie zgodzę bo jest to _bez sensu_. A to, że w sendmailu był DoS to
przypadek i przykład tego że SbO jest nie skuteczne (czysty zbieg
okoliczności, który miałem nadzieję, że ułatwi mi pokazanie tego że od
SbO należy definitywnie odejść).

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*