[SBTR/security] cups

Tomasz Kłoczko kloczek w rudy.mif.pg.gda.pl
Czw, 22 Maj 2003, 00:17:19 CEST


On Wed, 21 May 2003, Andrzej Krzysztofowicz wrote:
[..]
> Tzn. nie czytasz, co ci builder po zbudowaniu odsyla?

Jest tego dużo. Za dużo.
Wolałbym dostawać tylko to co nie przeszło i takie rozdzielenie buildlogów 
wysyłanych na listę trzeba będzie zrobić.

> Ja czytam, i nie podoba mi sie sytuacja, kiedy wysylam zlecenie i nic nie
> dostaje. IMO powinienem dostac co najmniej zawiadomienie, ze nadpisales moje
> zlecenie i przejales paleczke.

Zlecenie czy to przykryte przez inne wysłane przez kogoś innego czy moje
włane o ile prawdłowo się przebudowało jako takie mniej już mnie
interesuje. Na razie pewność że zlecenie zostanie jednak obsłużone jest
niemal 100%. W tym sensie przy przeważającej ilości prawidłowych buildów
dużo ważniejsza jest informacja o tym że coś poszlo nie tajk i że 
potrzebuje sparwdzenia dlaczego :)

> Sprawdzanie wylacznie po http/ftp nie jest chyba najlepszym pomyslem.
> 
> >    W pesemistycznym wariancie najwyzej pakiet zbuduje się dwa razy pod 
> >    rząd,a w obu przyapdkach powinny być otrzymane takei same wyniki -> nei 
> >    ma tu nic groźnego.
> 
> Groznego - nie. Nie twierdzilem, ze jest to grozne. Ale pakiet przebuduje
> sie 2 razy, niepotrzebnie obciazajac buildery. Czas to tez jest zasob,
> ktorym warto by gospodarowac bardziej optymalnie.

Używając słowa "groźne" maiałem na myśloi że nie należy się tym 
przejmować i/lub nie wprowadza to jakiegoś hazardu :)

> > 2) między zleceniami wykonano zmianę w cvs
> 
> To jest poza tematem. Jak wysylajacy bedzie wiedzial, co bylo puszczone, to
> sam zdecyduje, czy trzeba puscic jeszcze raz.

To jest niemniej jedynma chyba sytuacja która wprowadza potencjalnie 
jakeiś istotne zagrożenia.

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