Как я могу отслеживать ошибку, вызвавшую сбой, и сообщалось через apport / whoopsie?

49

Раньше было, что при сбое программы, особенно когда пользователь использовал предварительную версию Ubuntu, apport можно было использовать для открытия отчета об ошибке. Затем пользователь может отслеживать ошибку, видеть, влияет ли она на других, исправлять ее и т. Д.

Начиная с Precise 12.04, это поведение и рабочий процесс изменились. Как я обнаружил в ошибке # 993450 "Apport не отправил сообщение об ошибке , по умолчанию apport больше не открывает отчет об ошибке (и это неудобно, но не невозможно заставить его сделать это). В то же время люди замечают новый процесс "раздражения", как описано в Что такое процесс" whoopie "и что он делает? .

После еще нескольких поисковых запросов я выкопал этот чертеж, который описывает весь процесс: ErrorTracker - Ubuntu Wiki . (Он не упомянул о том, что он или она, и я добавил их - пожалуйста, исправьте меня, если я ошибаюсь).

Вау - это звучит как отличная работа для оптимизации и улучшения процесса отчетов о сбоях.

У меня остается вопрос: как пользователь узнает, что такое проблема? Теперь этот проект имеет это требование

  

Пользователь должен каким-то образом проверить статус своего отчета о сбое; например есть идентификатор отчета, который они могут посмотреть, чтобы просмотреть статистику и / или любую связанную с этим ошибку #. Например. предоставить серийный номер во время подачи, который они могут загрузить через веб-страницу позже.

, который кажется нереализованным. Есть ли что-нибудь доступное в то же время?

И как разработчик входит в игру? Переход на Ссылка просто содержит сообщение об ошибке "Неправильный контент-тип".

Наконец, я предлагаю документировать изменения поведения приложения в примечаниях к выпуску. Он должен представлять интерес для всех, кто пытался помочь Ubuntu.

    
задан nealmcb 21.05.2012 в 20:54
источник

2 ответа

43

Благодарим вас за интерес к проекту отслеживания ошибок Ubuntu .

  

Начиная с Precise 12.04, это поведение и рабочий процесс изменились. Как я обнаружил в Bug # 993450, "Apport не представит отчет об ошибке", по умолчанию apport больше не открывает отчет об ошибке (и это неудобно, но не невозможно заставить его сделать это).

Apport никогда не создавал отчеты об ошибках после выпуска. Когда релиз все еще находится в разработке, вы можете использовать apport для записи ошибок Launchpad (и отчетов об ошибках).

В окончательной версии Ubuntu мы теперь показываем диалоговые окна ошибок. Это отличное улучшение от программы "уйти" без обратной связи, и пользователю остается интересно, что только что произошло.

Статистика из данных, собранных, когда люди предпочитают отправлять эти отчеты, отображается на Ссылка .

  

У меня остается вопрос: как пользователь узнает, что такое проблема? Теперь этот проект имеет это требование

     
    

Пользователь должен каким-то образом проверить статус своего отчета о сбое; например есть идентификатор отчета, который они могут посмотреть, чтобы просмотреть статистику и / или любую связанную с этим ошибку #. Например. предоставить серийный номер во время подачи, который они могут загрузить через веб-страницу позже.

  

Я собираюсь удалить это. Это никогда не было целью. Пользовательский интерфейс осторожен, чтобы не давать обещания о получении обратной связи в отчете.

Это не отчеты об ошибках.

Наша цель - сократить время, необходимое разработчикам для поиска наиболее насущных проблем, собрать необходимую информацию для их исправления и получить исправления для пользователей.

Мы решили проблему поиска наиболее насущных проблем. Это первая страница Ссылка .

Сбор необходимой информации быстро и без привлечения длинного цикла обратной связи с пользователями, которые испытывают проблему, адресуется в фундаменты Q-bucketing-улучшения . План состоит в том, чтобы позволить разработчикам подключиться к процессу сбора информации на стороне сервера. Если мне нужно / var / log / syslog, но он еще не предоставлен, я просто изменяю параметр на Ссылка и следующий человек, который испытывает ошибку автоматически добавляет его к отправляемым данным.

Получение исправлений для пользователей быстро описано в фондах-q-updates- из-краш-отчеты . Когда пользователи отправляют отчет об ошибке и эта ошибка уже исправлена ​​и выпущена, появится диалоговое окно с вопросом, хотите ли они обновить версию программного обеспечения, которая устраняет проблему, с которой они только что столкнулись.

  

И как разработчик входит в игру? Переход на Ссылка просто содержит сообщение об ошибке "Неправильный контент-тип".

Ссылка не предназначена для использования людьми. Это для демонстрации сообщений об ошибках (whoopsie) для отправки отчетов.

Было бы замечательно, если бы другие люди были вовлечены. В настоящее время я единственный взлом в этом полном объеме.

В систему входят четыре части.

  • Apport , который предоставляет пользовательский интерфейс на рабочем столе.
  • Whoopsie , который принимает отчеты (и базовые дампы), созданные Apport, и вставляет их в сервер отслеживания ошибок, Daisy.
  • Daisy , который собирает отчеты от Whoopsie и обрабатывает их. Это сердце службы. Это то, что превращает основные файлы в восстановленные отчеты и генерирует статистику, которую вы видите на Ссылка .
  • Ошибки , который является веб-сайтом на основе Django, обеспечивающим как читаемый пользователем вид данных, так и API RESTful для работы с ним.

Существует немного устаревший набор скриптов в каталоге setup / в lp: daisy , который должен дать вам некоторые идеи о том, как штуки подходят друг к другу. Я работаю над прелестями juju, чтобы заменить это. Целью является единая команда для развертывания всей инфраструктуры в облаке для тестирования и разработки.

Вы можете найти мой адрес электронной почты на Launchpad , если у вас есть вопросы по дальнейшему развитию.

Дополнительная информация:

  • Что такое 'whoopsie 'процесс и как его удалить?
  • Ссылка
ответ дан Evan 11.06.2012 в 17:24
источник
1

Чтобы просмотреть накопленные отчеты о сбоях, вы можете перейти на Ссылка

    
ответ дан blueyed 31.05.2012 в 11:49