Auparavant, lorsqu'un programme bloquait, en particulier lorsqu'un utilisateur utilisait une pré-version d'Ubuntu, il 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 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). En même temps, les gens remarquent un nouveau processus "whoopsie", comme décrit dans 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 tout le 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, 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.
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 fournit simplement 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.
la source
Réponses:
Merci de votre intérêt pour le projet de suivi des erreurs Ubuntu .
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 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.
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.
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:
la source
Pour afficher les rapports de votre propre système, essayez ceci, comme indiqué à l' adresse https://bugs.launchpad.net/ubuntu/+source/apport/+bug/994921/comments/43.
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.
la source
Pour afficher les rapports de plantage accumulés, vous pouvez aller à https://errors.ubuntu.com/
la source