Merci de votre intérêt pour le projet de suivi des erreurs Ubuntu .
Depuis 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 à envoyer un rapport de bogue», par défaut, un rapport de bogue n'apparaît plus (et il est gênant, mais pas impossible, de le faire).
Apport n'a jamais créé de rapports de bogues après la publication. Lorsqu'une version est encore en cours de développement, vous pouvez utiliser la méthode apport pour classer les bogues (et les rapports d'erreur) du Launchpad.
Dans une version finale d'Ubuntu, nous affichons maintenant les boîtes de dialogue d'erreur. Il s’agit là d’une grande amélioration par rapport à un programme qui «disparaît» sans aucun retour et l’utilisateur se demandant ce qui vient de se passer.
Les statistiques des données collectées lorsque les utilisateurs choisissent d’envoyer ces rapports apparaissent sur http://errors.ubuntu.com .
Je reste avec cette question: comment un utilisateur peut-il connaître l'état du problème? Le plan a maintenant cette exigence
L'utilisateur devrait avoir un moyen de vérifier l'état de son rapport d'incident; Par exemple, ils peuvent consulter un ID de rapport pour consulter des statistiques et / ou tout bogue associé. Par exemple, fournissez un numéro de série au moment du dépôt qu’ils pourront charger ultérieurement via une page Web.
Je vais enlever ça. Cela n'a jamais été l'intention. L'interface utilisateur veille à ne pas faire de promesses quant à l'obtention de commentaires sur le rapport.
Ce ne sont pas des rapports de bugs.
Notre objectif est de réduire le temps nécessaire aux développeurs pour rechercher les problèmes les plus urgents, collecter les informations nécessaires à leur résolution et permettre aux utilisateurs de les résoudre.
Nous avons résolu le problème de la recherche des problèmes les plus urgents. C'est la page d'accueil de http://errors.ubuntu.com .
La collecte des informations nécessaires rapidement, sans impliquer une longue boucle de rétroaction avec les utilisateurs confrontés au problème, est abordée dans les améliorations de foundation-q-bucketing . L'objectif est de permettre aux développeurs de se connecter au serveur côté processus de collecte d'informations. Si j'ai besoin de / var / log / syslog mais que ce n'est pas déjà fourni, je modifie simplement un paramètre sur http://errors.ubuntu.com et la personne suivante qui rencontre l'erreur ajoute automatiquement cette erreur aux données envoyées.
Les correctifs rapides pour les utilisateurs sont abordés dans les rapports sur les fondations-q-updates-à partir de crash . Lorsque les utilisateurs envoient un rapport d'erreur et que cette erreur a déjà été corrigée et publiée, une boîte de dialogue s'ouvre leur demandant s'ils souhaitent effectuer une mise à niveau vers 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? Aller à https://daisy.ubuntu.com fournit simplement un message d'erreur "Type de contenu incorrect".
http://daisy.ubuntu.com n'est pas destiné à être utilisé par des humains. C'est là que le démon de rapport d'erreur (whoopsie) doit envoyer des rapports.
Il serait absolument merveilleux que d’autres personnes s’impliquent. Je suis actuellement le seul à pirater ce poste à temps plein.
Le système comporte quatre parties.
- Apport , qui fournit l'interface utilisateur du bureau.
- Whoopsie , qui prend les rapports (et les core dumps) créés par Apport et les transfère au serveur de suivi des erreurs, Daisy.
- Daisy , qui collecte les rapports de Whoopsie et les traite. C'est le coeur 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 .
- Errors , un site Web basé sur Django offrant à la fois une vue des données lisible par l'homme et une API RESTful permettant de les utiliser.
Il y a un ensemble de scripts légèrement obsolète dans le répertoire setup / de lp: daisy qui devrait vous donner une idée de la manière dont les morceaux s’assemblent. J'ai travaillé sur des charmes de juju pour remplacer ceci. L'objectif est de disposer d'une commande unique pour déployer toute l'infrastructure dans le nuage à des fins de test et de développement.
Vous pouvez trouver mon adresse email sur Launchpad si vous avez d'autres questions sur le développement.
Plus d'informations: