Grazie per il tuo interesse nel progetto di localizzatore errori di Ubuntu .
A partire da Precise 12.04, questo comportamento e il flusso di lavoro sono cambiati. Come ho scoperto nel bug # 993450 "Apport non riesce a inviare segnalazioni di bug", per impostazione predefinita l'app non apre più una segnalazione di bug (ed è imbarazzante ma non impossibile farlo per farlo).
Apport non ha mai creato segnalazioni di bug post-rilascio. Quando una versione è ancora in sviluppo, puoi utilizzare apport per presentare bug di Launchpad (e segnalazioni di errori).
In una versione finale rilasciata di Ubuntu ora mostriamo le finestre di dialogo degli errori. Questo è un grande miglioramento rispetto al programma "andare via" senza alcun feedback e l'utente viene lasciato a chiedersi cosa è appena successo.
Le statistiche dei dati raccolti quando le persone scelgono di inviare questi rapporti appaiono sul link .
Mi rimane questa domanda: come fa un utente a sapere qual è lo stato del problema? Il progetto ora ha questo requisito
L'utente dovrebbe avere un modo per controllare lo stato del loro rapporto di arresto anomalo; per esempio. avere qualche ID di report che possono vedere per vedere le statistiche e / o eventuali bug # associati. Per esempio. fornire un numero di serie al momento del deposito che è possibile caricare tramite una pagina Web in seguito.
Ho intenzione di rimuoverlo. Non è mai stato l'intento. L'interfaccia utente fa attenzione a non fare promesse su come ottenere un feedback sul rapporto.
Queste non sono segnalazioni di bug.
Il nostro obiettivo è ridurre il tempo necessario agli sviluppatori per trovare i problemi più urgenti, raccogliere le informazioni necessarie per risolverli e ottenere le correzioni agli utenti.
Abbiamo risolto il problema di trovare i problemi più urgenti. Questa è la prima pagina del link .
Raccogliere rapidamente le informazioni necessarie e senza coinvolgere un lungo ciclo di feedback con gli utenti che stanno riscontrando il problema, viene affrontato in fondazioni-Q-bucket-miglioramenti . Il piano è di consentire agli sviluppatori di collegarsi al processo di raccolta delle informazioni lato server. Se ho bisogno di / var / log / syslog ma non è già fornito, ho appena cambiato un'impostazione su link e la prossima persona che ha riscontrato l'errore lo aggiunge automaticamente ai dati che stanno inviando.
La risoluzione rapida degli utenti è affrontata in foundations-q-updates- da-crash-report . Quando gli utenti inviano un rapporto di errore e tale errore è già stato risolto e rilasciato, verrà visualizzata una finestra di dialogo che chiede se desiderano aggiornare la versione del software che risolve il problema che hanno appena sperimentato.
E come entra in gioco uno sviluppatore? L'accesso al collegamento fornisce solo un messaggio di errore "Tipo di contenuto errato".
Il link non è destinato all'uso da parte di esseri umani. È lì per il demone di segnalazione degli errori (whoopsie) a cui inviare i rapporti.
Sarebbe assolutamente meraviglioso per gli altri essere coinvolti. Al momento sono l'unico hacker a tempo pieno.
Ci sono quattro parti nel sistema.
-
Apport , che fornisce l'interfaccia utente desktop.
-
Whoopsie , che raccoglie report (e core dump) creati da Apport e li spala nel server error tracker, Daisy.
-
Daisy , che raccoglie i report da Whoopsie e li elabora. Questo è il cuore del servizio. È ciò che trasforma i file core in rapporti ritracciati e genera le statistiche che vedi sul link .
-
Errori , che è un sito web basato su Django che fornisce sia una visione leggibile dei dati umana che un'API RESTful per lavorare con esso.
C'è un set di script leggermente obsoleto nella directory setup / in lp: daisy che dovrebbe darti qualche idea di come i pezzi combaciano. Ho lavorato su juju charms per rimpiazzarlo. L'obiettivo è un singolo comando per distribuire l'intera infrastruttura nel cloud per test e sviluppo.
Puoi trovare il mio indirizzo email su Launchpad se hai ulteriori domande sullo sviluppo.
Altre informazioni: