Błędy a powiadamianie

[Tomasz Jadowski]

On Mon, Nov 01, 2004 at 11:54:59AM +0100, Paweł Gołaszewski wrote:
> 
> IMO bardziej koszerne byłoby w poldku, wtedy od razu w momencie upgrade 
> możnaby wysyłać listę.

Pozwolę się nie zgodzić jak zaczniemy wrzucać wszystko do poldka to się
zrobi z niego kobyła. I to nie jest raczej zgodne z filozofią Unix'a :)
małych, specjalizowanych programów robiących jedną rzecz a dobrze.

> Osobny program spowoduje, że trzeba o tym pamiętać (mało komu będzie się 
> chciało w efekcie, podobnie jak jest z pldbug (w sumie to należałoby 
> usunąć, bo to było ściśle powiązane ze starym BTS, teraz nie działa...)
> 

A cron jest od czego?

Zresztą i tak generatorem będzie "rpm -qa > plik" odpalany z crona :))
Mnie taki "generator" wystarcza :) 

> 
> Do pewnego stopnia masz rację, ale... masz listę plików na każdej maszynie 
> i w przypadku informacji, którą miałbyś dostawać, będzie tam też 
> informacja na których maszynach masz to zainstalowane. Czasem przy pewnej 
> ilości maszyn człowiek się zaczyna gubić co gdzie jest (prawda RMF? ;) ).
>

Niespecjalnie mnie przekonujesz. Masz taką potrzebę to robisz:
1) Listy pakietów dla każdej z maszyn "rpm -qa > lista"
2) Dostajesz listę z BTS'a
3) Grepujesz listy pakietów względem listy BTS'a i już wiesz co
masz.

Wystarcza do tego bash, grep i kilka chwil pracy. Po co to implementować
w BTS-ie?

> 
> > IMHO wystarczy tylko do eksportera dodać opcję automatycznego usuwania
> > duplikatów i sprawa załatwiona. I tak do zamknięcia błędu niewiele z tym
> > zrobisz, a błędy krytyczne wymagające nadzwyczajnych akcji zdarzają się
> > stosunkowo rzadko.
> 
> W prostym przypadku masz rację.
> 

A w złożonym? Procent pewnie będzie niewielki, poza tym mam zamiar
dać możliwość ustawiania "czułości" powiadamienia dla konkretnego
pakietu co IMHO rozwiązuje sprawę.

> > Poza tym jak ktoś się opiekuje większą ilością maszyn to:
> > a) jest to niewielki procent użytkowników
> 
> ekhm.... ale chyba ważny procent, nie? ;)
> 

Dla mnie nieistotny :)) Zresztą patrz wyżej.

> > b) konfiguracja maszyn jest b. podobna i/lub
> 
> Tu bym się nie zgodził.
> 

Ja akurat mam :)

> > c) ma inwertaryzację softu i tam IMHO jest miejsce na powiązanie
> > pakiet->maszyna.
> 
> Nie chodzi o inwentaryzację softu, ale
> 

Patrz wyżej.

> > W BTS niepotrzebnie zaciemni to obraz.
> 
> Możesz mieć rację.
> 
> > W sumie wydaje mi się że na początek wystarczy eksport listy,
> > automatyczne usuwanie duplikatów, edycja listy. A powiadamianie na razie
> > od wszystkich zdarzeń (ew. niech ktoś bardziej obeznany zaproponuje
> > nierozbudowaną selekcję) i zobaczymy co wyjdzie w praniu :)
> 
> Na początek - może być, choć funkcjonalność będzie ograniczona :)
> 

Wydaje mi się wystarczająca. Moim zdaniem powinniśmy skupić się na
dostarczeniu _prostego_ narzędzia, które będzie śledzić dane pakiety
a każdy zainteresowany zrobi sobie co zechce. Może ją przefiltrować,
powycinać itp.

Hmm, zastanawiam się czy nawet (maksymalna prostota) nie lepiej
zaimplementować czegoś w stylu pld-cvs-commit? Zaraz, zaraz przecież
jest pld-bugs i to właśnie tak działa :))

Po zastanowieniu moim zdaniem lepiej wykorzystać istniejące mechanizmy
(lista pld-bugs) niż tworzyć nowe spełniające de facto tą samą funkcję.

Pozdrawiam
Tomek

-- 
[ Tomasz 'tomcio44' Jadowski  jadowski w post.pl  PGP ID: 0x13AB0663
[ Fingerprint: 3252 FE7F 703C 7A13 A2A0  021A A7B2 74A5 13AB 0663
[ JID: tomcio44 w chrome.pl | GG: 1247741 | http://tomcio44.jogger.pl