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 bugQuesti 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 2837276questa 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