Buildery dla AC - przem

Witek Kręcicki adasi w grubno.da.ru
Śro, 26 Mar 2003, 19:31:43 CET


W liście z ?ro, 26-03-2003, godz. 19:21, Tomasz Kłoczko pisze: 
> 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".
jak narazie to jest rozpierdolone, w pld-builder zauwazylem same TODO a
ztcp to buildery mialy dzialac pelna para w styczniu-lutym, a sam
mowiles ze pierwsze AC-pre w marcu-kwietniu moglo by sie ukazac... jakos
nie widac...
WK



Więcej informacji o liście dyskusyjnej pld-devel-pl