Merci de votre intérêt pour le Projet de suivi des erreurs d'Ubuntu .
À partir de Precise 12.04, ce comportement et ce flux de travail ont changé. Comme je l'ai découvert dans le bogue n° 993450 "Apport ne parvient pas à soumettre un rapport de bogue", par défaut, apport n'ouvre plus de rapport de bogue (et il est difficile mais pas impossible de le faire faire).
Apport n'a jamais créé de rapports de bogue après la sortie de la version. Lorsqu'une version est encore en cours de développement, vous pouvez utiliser Apport pour enregistrer les bogues (et les rapports d'erreur) de Launchpad.
Dans une version finale d'Ubuntu, nous montrons maintenant les dialogues d'erreur. C'est une grande amélioration par rapport à un programme qui "s'en va" sans aucun retour d'information et qui laisse l'utilisateur se demander ce qui vient de se passer.
Les statistiques issues des données collectées lorsque les personnes choisissent d'envoyer ces rapports apparaissent sur http://errors.ubuntu.com .
Je me retrouve avec cette question : comment un utilisateur peut-il savoir où en est le problème ? L'ébauche a maintenant cette exigence
L'utilisateur devrait avoir un moyen de vérifier l'état de son rapport de collision ; par exemple, il devrait avoir un ID de rapport qu'il peut consulter pour voir les statistiques et/ou tout bogue associé. Par exemple, fournir un numéro de série au moment de l'enregistrement qu'il peut charger ultérieurement via une page web.
Je vais l'enlever. Cela n'a jamais été l'intention. L'interface utilisateur prend soin de ne pas promettre d'obtenir un quelconque retour d'information sur le rapport.
Ce ne sont pas des rapports de bogue.
Notre objectif est de réduire le temps nécessaire aux développeurs pour trouver les problèmes les plus urgents, collecter les informations nécessaires pour les résoudre et transmettre les corrections aux utilisateurs.
Nous avons résolu le problème de la recherche des problèmes les plus urgents. C'est la première page de http://errors.ubuntu.com .
La collecte des informations nécessaires rapidement, et sans impliquer une longue boucle de rétroaction avec les utilisateurs qui rencontrent le problème, est abordée dans le document fondations-q-bucketing-improvements . L'objectif est de permettre aux développeurs d'accéder au processus de collecte d'informations côté serveur. Si j'ai besoin de /var/log/syslog mais qu'il n'est pas déjà fourni, il me suffit de modifier un paramètre de l'option http://errors.ubuntu.com et la personne suivante qui rencontre l'erreur l'ajoute automatiquement aux données qu'elle envoie.
La transmission rapide des correctifs aux utilisateurs est abordée dans foundations-q-updates-from-crash-reports . Lorsque les utilisateurs soumettent un rapport d'erreur et que cette erreur a déjà été corrigée et publiée, une boîte de dialogue s'affiche pour leur demander s'ils souhaitent passer à la version du logiciel qui corrige le problème qu'ils viennent de rencontrer.
Et comment un développeur entre-t-il dans le jeu ? En allant à https://daisy.ubuntu.com fournit simplement un message d'erreur "Incorrect Content-Type".
http://daisy.ubuntu.com n'est pas destiné à être utilisé par des humains. Il est là pour que le démon de rapport d'erreur (whoopsie) envoie des rapports.
Il serait absolument merveilleux que d'autres personnes s'impliquent. Je suis actuellement le seul à travailler à plein temps sur ce projet.
Le système se compose de quatre parties.
-
Apport qui fournit l'interface utilisateur du bureau.
-
Whoopsie qui prend les rapports (et les vidages de noyau) créés par Apport et les envoie au serveur de suivi des erreurs, Daisy.
-
Daisy qui collecte les rapports de Whoopsie et les traite. C'est le cœur du service. C'est ce qui transforme les fichiers de base en rapports retracés et génère les statistiques que vous voyez sur http://errors.ubuntu.com .
-
Erreurs Il s'agit d'un site web basé sur Django qui fournit à la fois une vue lisible par l'homme des données et une API RESTful pour travailler avec elles.
Il y a un ensemble légèrement dépassé de scripts sous le répertoire setup/ de lp:marguerite qui devrait vous donner une idée de la façon dont les pièces s'assemblent. J'ai travaillé sur des charmes juju pour remplacer ça. Le but est d'avoir une commande unique pour déployer toute l'infrastructure dans le cloud pour les tests et le développement.
Vous pouvez trouver mon adresse électronique sur Launchpad si vous avez d'autres questions sur le développement.
Plus d'informations :
