vg wrote:
Il giorno 10 giugno 2009 20.41, Davide Prina ha scritto:
Di sicuro querybts soprattutto, ma anche reportbug, solo testo sono
indispensabili in quelle occasioni in cui non si ha o si può/vuole usare una
GUI (ad esempio quando aggiorno il sistema e vedo con apt-listbugs che c'è
un bug non chiuso, allora uso sempre querybts per visualizzarlo, questo
perché voglio vedere soltanto quel bug e ho la "chiave" per identificarlo).
potreste smetterla di parlare arabo e cercare di far capire qualcosa anche a
noi poveri niubbi ???
: )))
Cercherò di spiegare semplicemente tutto il discorso.
reportbug-ng è sviluppato da uno DD che ha idee un po' differenti da
molti altri DD e quindi in un primo tempo ha creato questo suo prodotto
senza includere alcune funzionalità che per altri DD sono indispensabili
(ad esempio la visualizzazione del testo creato dal manteiner di un
pacchetto su cosa fare prima di riportare un bug per quel pacchetto,
informazioni ritenute inutili dall'autore di reportbug-ng), inoltre non
ricavava tutte le informazioni molte volte necessarie per capire cosa
avesse installato il segnalatore del bug e quindi poter magari
determinare il motivo del problema segnalato senza chiedere ulteriori
informazioni al segnalatore.
Per questi motivi sono stati aperti dei bug per reportbug-ng con dei
post abbastanza lunghi e pieni di lamentele verso l'autore di questo
programma (dei bug-flame). Questi bug sono stati messi bloccanti per
impedire il propagare delle nuove versioni di reportbug-ng a testing.
L'autore ha cercato di spiegare i suoi motivi ... ed alla fine sono
state proposte delle soluzioni a volte intermedie per risolvere questi
problemi (ad esempio permettere all'utente di disabilitare la
visualizzazione del testo su cosa fare prima di segnalare un bug creato
dal manutentore del pacchetto).
Da quello che ho capito io reportbug-ng alla fine ha inglobato tutte le
richieste dei DD (alcune come detto disabilitabili dall'utente) e quindi
gli è stato permesso di entrare in testing.
Però Sandro Tosi dice che ci sono ancora problemi nel suo utilizzo
perché, come già faceva, non visualizza alcune informazioni che a volte
sono indispensabili per capire la causa del bug segnalato. Io avevo
controllato questo problema su dei pacchetti prima di segnalare dei bug
che avevo trovato e mi era parso che tutte le informazioni erano
presenti, al massimo in posizioni differenti.
Se Sandro Tosi mi mostra un caso dove questo non è vero io sono disposto
a ricavare sempre i dati per l'invio dei bug da reportbug.
Questa è la storia che conosco io sulla diatriba reportbug, che segue le
richieste della maggior parte dei DD, e reportbug-ng.
Poi:
1) reportbug è il nome di un pacchetto che contiene più programmi:
* querybts: programma che permette di interrogare il database dei bug
* reportbug: programma che permette di segnalare un bug
Questi due programmi possono essere usati con diversi tipi di
interfaccia: testo, ncurses, gtk2
In alcuni casi io preferisco averli a disposizione con interfaccia
testo. Ad esempio se conosco il numero di un bug (ad esempio 2837276) e
voglio vederne il contenuto scrivo semplicemente:
$ querybts 2837276
questa operazione la compio quando sto facendo l'aggiornamento del
sistema (uso apt-get) e il programma apt-listbugs mi riporta che c'è un
pacchetto che voglio aggiornare con un bug non chiuso. Con questa
semplice operazione riesco velocemente a sapere le cause e a capire se
voglio davvero aggiornarlo o preferisco aspettare che il bug sia risolto.
2) reportbug-ng è sia il nome del pacchetto che del programma. Questo
programma include in un'unica interfaccia grafica fissa sia il programma
per interrogare il database dei dati (querybts per intenderci) e il
programma per segnalarne di nuovi, aggiungere informazioni, ...
(reportbug per intenderci).
Sandro Tosi, che è anche il DD che mantiene reportbug, mi ha fatto
presente che ora anche reportbug ha un'interfaccia grafica gtk2, ma,
secondo me, non era tanto l'interfaccia grafica che rendeva migliore,
almeno per me, il "concorrente" reportbug-ng, quanto le funzionalità che
offre: in un'unica finestra fissa è possibile ricercare, filtrare e
visualizzare il contenuto dei bug di un pacchetto o dei pacchetti che
rispettano un determinato criterio (per esempio tutti quelli segnalati
da una determinata persona, ad esempio da me). Nella stessa finestra è
possibile creare un nuovo bug premendo un bottone o aggiungere
informazioni ad un bug esistente, ...
Ho guardato velocemente la versione gtk2 di reportbug e queste cose non
mi sembra di averle viste. reportbug gtk2 è in pratica una composizione
di bug guidata (un wizard): devi conoscere il nome del pacchetto e poi
procedi per step alla compilazione del bug. Questo può essere molto
utile per chi sta segnalando il primo bug, ma in alcuni casi può
risultare macchinoso. Come dicevo alle volte quando si trova un
malfunzionamento non è facile capire qual'è il pacchetto che lo causa e
poter passare facilmente da un pacchetto ad un altro visualizzando i
rispettivi bug può portare facilmente ad individuare lo stesso problema
già segnalato con l'eventuale soluzione per risolvere temporaneamente il
problema.
Prossimamente cercherò di guardare meglio reportbug gkt2 per vedere bene
come funziona, ma per ora le mie impressioni sono quelle che ho indicato.
Ciao
Davide
--
Dizionari: http://linguistico.sourceforge.net/wiki
Browser: http://www.mozilla.org/products/firefox
GNU/Linux User: 302090: http://counter.li.org
Non autorizzo la memorizzazione del mio indirizzo su outlook
--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org
To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org