Portal:Български/Често задавани въпроси за грешките

Съобщаване за грешка:
Съобщаване за грешка - Често задавани въпроси за грешките - списък на известните грешки - Testing

Тази статия описва как да използвате bugzilla at bugzilla.novell.com и списък на най-често задаваните въпроси при докладване на грешки.

Какъв тип обратна връзка търсите?

Ние обичаме да има както положителна, така и отрицателна обратна връзка - и също така идеи за подобрение.

• Положителните (позитивни) отзиви означават, че системата е инсталирана успешно и работи, че някои зони са били тествани, и че те работят. Моля, съобщавайте за това на opensuse@opensuse.org mailinglist.Положителните обратни връзки се записват в нашия testdb.

• За отрицателна (негативна) обратна връзка, което означава всички проблеми, които се срещат, ние използваме Bugzilla.Моля, подайте доклад за грешка отделно за всеки проблем, който сте срещнали. Има и други области, в този FAQ, които обясняват подробно как да се подаде доклад за грешка.

• Освен това се издирват идеи за подобрения. Вижте списъка Wishlist на страницата за добавяне на тези идеи.

---

Основни правила при регистрация на грешки

Този документ описва как да се използва bugzilla на bugzilla.novell.com.

Какви полета трябва да бъдат попълнени при регистрация на грешки? Какво мога да изменям, и какво не?

• Component: (Компонент на системата)
  Забележка: Не всички грешки, възникващи в процеса на установка се отнасят до YaST, това могат да бъдат и грешки на ядрото или други приложения.
• Platform: (Платформа)
  Използвайте “all" ако считате че дадена грешка не зависи от платформата, в противен случай указвайте своята апаратна конфигурация.
• Summary: (Pезюме)
  Хората,които четат резюмето трябва бързо да разберат за какво става въпрос, каква точно е тази грешка.
• Bug description: (Описание на грешки)
  Опишете всички детайли при възникване на грешката. Не следва да разчитате на резюме (например, See Summary), доколкото резюмето може да бъде променено.
• How to Reproduce?: (Как да възпроизведем ситуацията?)
  Този пункт е толкова важен, че заслужава отделно описание: виж Въпрос: 1.1.5
• Severity: (Сериозност)
  Правилно оценявайте важността на грешката. Използвайте обозначение “blocker" само случай, че считате пуска на продукта с този дефект за невъзможен.
• Останалите полета:
  Останалите полета по добре оставете непопълнени.

Ще получа ли някакъв отговор след мое съобщение за грешка?

Да, ако Вашите персонални данни не са били изменени, Вие ще бъдете информирани за всички изменения по електронната поща.

Кои полета мога да изменям,и кои не?

Като не-разработчик Вие имате право да добавяте коментари в СС. Ако грешката се намира в състояние “NEEDINFO" не забравяйте да я приведете в статус “ASSIGNED" след като се предостави всичката необходима информация.

Как да постъпим ако такава или подобна грешка е зарегистрирана за по-стара версия на SUSE Linux?

Добре е да се промени версията на пакета (програмата) и след това добавете коментар: "This bug was reported for SUSE Linux x.y and still fails for SUSE Linux u.v. I'm adjusting the version"("Този бъг се съобщава за SUSE Linux XY и все още не за SUSE Linux UV Аз съм за адаптиране на версията").По този начин,дори и грешката да е вече закрита, Вие ще задействате процедурата повторно.

Хората се разсърдиха,че в полето "how to reproduce" съм указал "Install SUSE x.y-Beta-z".Защо?

Описано по този начин,това е абсолютно безполезна информация,тъй като по никакъв способ не помага да се възпроизведе грешката.Ние можем да помислим, че това е грешка при инсталацията, понеже Вие сте избрали този компонент в Bugzilla , и можем да счетем, че не се касае за конкретния релиз,а за следващата версия.

Това което действително трябва да знаем - какво точно сте направили, и как Вие сте го направили. Например: "boot from CD1, select "Installation", select language "Klingon", leave the installation settings as they are, confirm installation, watch as your hard disk goes up in flames."

Повярвайте,това не са излишни дребнавости-ние имаме огромно количество инсталационни настройки и начини да се инсталира!Ще ни е нужно много време за да възстановим последователността на Вашите действия от лог файла. Вие разполагате с готова информация,просто я въведете в това поле.

Разбира се,ние не изискваме задълбочен анализ в детайлизация на грешката,- но от описание на последователността от действия,довели до грешката,действително се нуждаем.

Хората са недоволни че в описанието на грешката в Bugzilla съм написал "see subject"- макар че според мен това наистина обяснява всичко! Не е ли чиста дребнавост да настояват за повече подробности в описанието?

Не,нужно е.

Тъй като "Subject" се изменява през цялото време,то проблема, за който Вие сте съобщили, може да бъде само върха на айсберга - реалния проблем може да е на съвършено друго място, и уточняването на мястото където е възникнала грешката ще доведе до това, че Вашия първоначален Subject ще бъде изгубен. От този пример е видно, че Subject не се явява удачно място за съхраняване на съобщения за грешки.

Да се свали всичката информация в subject, и после да се осланяте само на subject-това е банална ленивост! Достатъчно е един път да се запьлнят всички необходими полета и на хората, работещи с грешката,няма да се налага да търсят необходимата информация отново и отново.

Изобщо: Subject трябва да бьде кратък, а описанието на грешката толкова пълно,колкото е необходимо.

---

Грешка със статус NEEDINFO

Що е това грешка със статус NEEDINFO и какво е необходимо да се направи с нея?

NEEDINFO означава, че човекът, работещ над тази грешка,се нуждае от допълнителна информация,по правило от този, който е зарегистрирал грешката.

Ако зарегистрираната от Вас грешка е приведена в статус NEEDINFO, прегледайте последните коментари по темата,или въпросите за допълнителна информация.В случай че намерите такъв коментар, моля, отговорете на въпросите или предоставете необходимата информация и след това променяйте статуса на грешката на ASSIGNED - кликнете на Accept bug (измени статус на ASSIGNED) на съответстващата страница в Bugzilla.

---

Грешка със статус VERIFIED / CLOSED

Трябва ли да маркираме грешка, когато виждам, че проблемът ще бъде решен в новата версия или с актуализациите?

[TBD]

---

грешки със Статус WONTFIX

Този раздел е бил преместен на страница Bug Status WONTFIX

---

Как да съобщим за бъг ...

За повече информация за това как да се докладва за грешки на други компоненти, като напр. ядрото, KDE или YaST,вижте Подаване на доклади за грешки

---

openSUSE Документация

Съобщенията за грешки в документацията на openSUSE отправяйте към Bugzilla (component: "Documentation").

---

Beta Testing

Бих искал да участвам в тестването на бета версии на openSUSE.Как да осъществя контакт?

openSUSE is open. Просто се абонирате за openSUSE проект мейлинг лист и докладвайте откритите от вас бъгове, както е описано в Portal:BG-Submitting bug reports.

Бих искал да участвам в тестването на бета версии за други продукти като SLES или SLED. Как и с кого да се свържа ?

Not all these products have beta programs, but if they do have, they might be accessible via The Novell Beta Program.