Re: bug che non vengono segnalati in Sid (ERA: [OT] traduzione di: microsoft: una storia di comportamenti anti-competitivi e dannosi per gli utenti)
2009/6/10 Davide Prina <davide.prina@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
Reply to: