Buildery dla AC - przem

[Tomasz Kłoczko]

On Wed, 26 Mar 2003, Paweł Gołaszewski wrote:
[..]
> Akurat do tego jest bardzo piękną rzeczą.
> Zauważ, ze bardzo łatwo będzie można dzięki trzymaniu zleceńw bazie zrobić 
> ładne miedzymordzie, którym każdy developer będzie śledził sobie co się z 
> jego zleceniem dzieje - w jakim jest stadium..

Akurat to już też było robione i było załatwiane za pomocą sysloga.
Przypomnę, że założeniem nowej automatyki jest możliwość wysłania zlecenia 
z odpytaniem stanu kolejki. Nic tylko dorobić do tego miedzyemordzie,

> Będzie też mógł tam wcisnąć przycisk STBR.

Takie rzeczy nie muszą się dziać w powiązaniu z obsługą zleceń.
Spokojnie możnaby nawet to próbować zintegrować na poziomie międzymordzia 
BTS-a.

[..]
> Nie wiem czy zauważasz, ale właśnie wysyłanie na buildery i późniejsza 
> obsługa zleceń to aktualnie najwięszy problem organizacynjny.

Nie zauważam. Zauważam za to że ważne jest to żeby obrobić wyniki zleceń 
bezpiecznie. SQL niczego tu nie rozwiązuje. Jest tylko alternatywnym
sirodkiem .. niczymi więcej.

> Bez trzymania zleceńw SQL-u ciężko taki interfejs będzie sprawnie
> sprzęgnąć z rzeczywistymi builderami oraz cvs-em.

Bzdura. Jeszcze raz wysyłasz zlecenie i dostajesz status buildera.


> Wysyłanie z różnych etykiet można dosyć łatwo rozwiązać przy
> odpowiedniej konstrukcji tabel.

Które to tabele nie sa potrzebne. Nadal nei zauwazasz tego, że SMTP 
rozwiazuje przesyłąnie zleceń nawet jeślzie nei ma bezpośredniego 
połącznia mieczy zlecajacym i builderem.
Poprostu dzieki SMTP n ie musisz organizować statusu rury która to 
pzresyłasz bo kolejkowanie wykorzystuje tu immanentne własności protokołu 
które w kazdym innym pzrypadku będziesz musiał dublować implementujac to 
wszystko samemu.

Jeszcze raz. Podstawa nowej konstrukcji to wykorzystanie FAKTU sprawdzenia
się dotychczasowych rozwiązań i poprawienia tego co kulało albo czego brak
było automatyce a nie reimplemtoweanei tego wszystkiego odpoczątku. Jezlei
ktoś nie przyjmie tego do wiadomości, że nie ma najmneijszej potdrzeby
rezygnowanai z czegoś co sie przez ponad dwa lata sprawdzało tylko dlatego
ze ktoś ma taka a nie inna wiedze dotyczacą np. baz danych i najchetneij
wszedzie wszystko ładowałby w owe to w tym miejscyu mozemy skończyć.
Wszytkie dotychczasowe "dywagacje" na temat builderów jawnie ignorowały
lub ignorują powyższem. Nie ma najmniejszych podstaw do tego żeby
rezygnować z tego co dobre w imie czysto estetycznego podejscia do
zagadnienia.
Zamiast skupiać się jak dorobic to co brakowało w ramach istniejacego
schematu co kawałek dochdzi do dyskusji pobawionych realnych podstaw 
opierajacycj sie na "rozpierdolmy to wszystko i zróbmy odnowa .. bo tak
będzie ładniej".

Podstawowa zasada: don't move .. improve.
Nie *rewolucja* tylko *ewolucja* tego co jest dobre i czego pod żadnym 
pozoremnie ma powodu dotkliwie przebudowywać.

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*