Comment puis-je suivre un bogue qui a provoqué un crash et qui a été rapporté via apport / whoopsie?
Auparavant, lorsqu'un programme échouait, en particulier lorsqu'un utilisateur utilisait une pré-version d'Ubuntu, SharePoint pouvait être utilisé pour ouvrir un rapport de bogue. L'utilisateur peut ensuite suivre le bogue, voir s'il en affecte d'autres, aider à le résoudre, etc.
Depuis Precise 12.04, ce comportement et ce flux de travail ont changé. Comme je l'ai découvert dans bug n ° 993450, “Apport ne parvient pas à envoyer un rapport de bogue” , par défaut, apport n'ouvre plus de rapport de bogue (et il est gênant mais pas impossible de l'obtenir). En même temps, les gens remarquent un nouveau processus "whoopsie", décrit à la rubrique Qu'est-ce que le processus "whoopsie" et que fait-il? .
Après un peu plus de recherches sur Google, j'ai creusé ce schéma, qui décrit l'ensemble du processus: ErrorTracker - Ubuntu Wiki . (Il n’a pas été question de whoopsie ou de marguerite, je les ai donc ajoutées - corrigez-moi si je me suis trompé).
Wow - cela semble être un excellent travail pour rationaliser et améliorer le processus de signalement des incidents.
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. avoir un identifiant de rapport qu’ils peuvent consulter pour consulter les statistiques et/ou tout bogue associé. Par exemple. fournir un numéro de série au moment du dépôt qu’ils pourront charger ultérieurement via une page Web.
ce qui semble non implémenté. Y a-t-il quelque chose de disponible dans l'intervalle?
Et comment un développeur entre-t-il dans le jeu? Aller à https://daisy.ubuntu.com ne fournit qu'un message d'erreur "Type de contenu incorrect".
Enfin, je suggère de documenter les modifications du comportement de la répartition dans les notes de publication. Cela devrait intéresser quiconque a essayé d'aider Ubuntu.
Merci de votre intérêt pour le projet de suivi des erreurs Ubunt .
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, apport n'ouvre plus de rapport de bogue (et il est difficile, 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 provenant des données collectées lorsque les utilisateurs choisissent d'envoyer ces rapports s'affichent 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. avoir un identifiant de rapport qu’ils peuvent consulter pour consulter les statistiques et/ou tout bogue associé. Par exemple. fournir 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 qui rencontrent le problème, est traitée dans améliorations-de-fondation-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 cela ne soit pas déjà fourni, je modifie simplement un paramètre sur http://errors.ubuntu.com et la personne suivante qui rencontre l'erreur l'ajoute automatiquement à la les données qu'ils envoient.
Obtenir rapidement des correctifs pour les utilisateurs est abordé dans foundation-q-updates-from-crash-reports . 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'affiche 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 ne fournit qu'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 comprend quatre parties.
- Apport , qui fournit l'interface utilisateur du bureau.
- Whoopsie , qui prend les rapports (et les dumps principaux) créés par Apport et les transfère au serveur de suivi des erreurs, Daisy.
- Daisy , qui collecte et traite les rapports de Whoopsie. 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 , site Web basé sur Django offrant à la fois une vue lisible des données et une API RESTful permettant de travailler avec ces données.
Il existe un ensemble de scripts légèrement obsolètes dans le répertoire setup/de lp: daisy , ce qui devrait vous donner une idée de la façon dont les éléments 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 électronique sur Launchpad si vous avez d'autres questions sur le développement.
Plus d'informations:
Pour afficher les rapports de votre propre système, essayez ceci, comme indiqué à la section https://bugs.launchpad.net/ubuntu/+source/apport/+bug/994921/comments/4
xdg-open https://errors.ubuntu.com/user/`Sudo cat /var/lib/whoopsie/whoopsie-id`
Sans autorisations spéciales sur le tableau de bord, vous ne pouvez pas afficher les rapports réels, mais vous pouvez voir les programmes sur lesquels ils ont été signalés et utiliser les identifiants fournis pour les consulter lorsque vous parlez aux développeurs disposant des autorisations appropriées.
Pour afficher les rapports de plantage accumulés, vous pouvez aller à https://errors.ubuntu.com/