Miedzy stabilnoscia a rozwojem
Paweł Kołodziej
pawelk w pld.org.pl
Czw, 21 Gru 2000, 22:39:04 CET
Dnia Sun, Dec 10, 2000 at 10:27:15PM +0100, Tomasz Kłoczko napisał(a):
> On Sun, 10 Dec 2000, Paweł Kołodziej wrote:
>
[..]
> Taki anon licznik pomyślnych instalacji konkretnego zasobu zapewne też
> włynąłby na pewność posługiwania się tymi zasobami dając namacalne fakty
> do tego żeby im ufać bąć nie.
no właśnie. Była by podstwa do twierdzenia "to działa".
> Mówiąc inaczej ocena ryzyka używania naszych zasobów byłoby możliwa w tym
> wypadku w kategoriach czysto statystyczncyh. Czyli mielibyśmy atut którego
> nikt w okolicy jeszcze nieposiada (kurcze ten pomysł jest warty skrzunki
> dobrego piwa .. ech żeby to jednej skrzynki :-)
:) kiedyś się przypomnę ;)
No dobra. Moze przejdzmy do konkretow. Po pierwsze trzeba okreslić jakiego
typu informacje będą przydatne.
1. Myśle że składanie raportów powinno odbywać się w kontekście jednego
pakietu. Tzn. że jeśli wysyłany jest raport o powiedzmy apache który
wymaga sed'a to wystawiona ocena dotyczy apache a nie seda.
2. W skład zgłoszenia powinny wchodzić informacje o zainstalowanych pakietach
stojących niżej w hierarchi zależności. Czyli w przypadku vim'a była
by tam informacja o zainstalowanym glib'cu, ncursesach itp.
Natomiast pakiety będące "wyżej" w hierarchi zależności nie były by
wymieniane. No bo one nie decydują o działaniu bądź nie pakietu.
Takwięc w raporcie o glibc'u nie było by informacji wsztstkich
zainstalowanych pakietach wymagających go.
3. Ocena użytkownika. Ten element należy chyba najgruntowniej przemyśleć.
IMHO ocena powinna składać się z kilku elementów:
- stopień wykożystania różnych cech pakietu
inna wage ma raport o gimpie wyslany przez programiste (uzywającego
go do np. wyłączie przeskalowyania obrazków) a inną wysłany przez
zawodowego grafika.
- ocena działania. Dość kłopotliwy ale bardzo ważny element.
rozwiązanie I (prymitywne):
- ocena punktowa
rozwiązanie II
- użytkonik ma 2 możliwości
- wszystko działa z pewnymi wyjątkami które w syntetycznej
formie opiuje. Być może cenna była by też informacja który z
pakietów niżej w hierarchi może być przyczyną problemów.
- właściwie nic nie działa. Użytkownik wysyła więc informacje
"wszystko w tym pakiecie jest popsute"
rozwiązanie III (pracochłone ale dające więcej danych natury
statystycznej)
- dla każdego pakietu jest określona przez jego twórców lista cech
jakie on udostępnia. Zadaniem użytkownika jest odpowiedzenie na
każde pytanie: 'dziala', 'niedziala', 'nie uzywam tej funkcji
wiec niewiem'. W przypadku odpowiedzi "niedziala" powinna być
możliwiść krótkiego opisania problemu.
Zawsze jest pole "inne". Po pojawieniu się raportu z zaznaczonym
takim polem informowana była by osoba opiekująca się nim i
ewentualnie dodawała by odpowiedni wpis do listy
'funkcjonalności do sprawdzenia' dla tego pakietu. Takie
rozwiązanie pozwoliło by przerzućić ciężar tworzenia kategori na
użytkowników.
To tyle na dziś. Jak by komuś chciało się nad powyższym zastanowić to
bardzo proszę o odzew.
--
Paweł Kołodziej
pawelk w pld.org.pl
,,O ile nam wiadomo, komputer nigdy nie popełnił niewykrytego błędu.''
-- Weisert
Więcej informacji o liście dyskusyjnej pld-devel-pl