2009/6/10 Davide Prina <davide.pr...@gmail.com>: > 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
"un po' differenti" mi pare riduttivo... anche ieri sera e arrivato a chiedere "ma non si potrebbe rimuovere questa feature da reportbug cosi' reportbug-ng non deve essere fixato?"... :) > 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. L'ha fatto a modo suo, quindi i punti non sono stati fixati completamente o non soddisfacentemente. > 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. non viene gestito correttamente (per nulla?) il caso in cui i bug script chiedano interazione agli utenti. Inoltre il maintainer di xorg (hai detto poco...) si lamenta che r-ng non contiene tutte le info di cui ha bisogno. > Sandro Tosi, che è anche il DD che mantiene reportbug, mi ha fatto presente ehm ehm... che sia poco imparziale? :) > 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, ... puoi riportare un bug a reportbug chiedendo una cosa simile. i wishlist bug sono proprio per questo. > 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. secondo me e' piu' comodo il web per questo, anche perche' san google ci aiuta. Ciao, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- 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
