http://wiki.rosalab.com/ru/api.php?action=feedcontributions&user=Vladimir.potapov&feedformat=atom
Rosalab Wiki - Вклад участника [ru]
2024-03-29T15:00:56Z
Вклад участника
MediaWiki 1.26.4
http://wiki.rosalab.com/ru/index.php?title=%D0%A2%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_4-18_%D1%81%D0%B5%D0%BD%D1%82%D1%8F%D0%B1%D1%80%D1%8F&diff=18719
Тестирование 4-18 сентября
2020-09-18T15:31:18Z
<p>Vladimir.potapov: Новая страница: «Категория:Расширенное тестирование == Общая схема тестирования == В настоящее время вс…»</p>
<hr />
<div>[[Категория:Расширенное тестирование]]<br />
== Общая схема тестирования ==<br />
В настоящее время все обновления, кроме срочных обновлений безопасности, проходят дополнительное тестирование по следующей схеме:<br />
# После первичной проверки они попадают в репозиторий testing, соответствующий обычному репозиторию (для main - main testing, для restricted - restricted testing и.т.д)<br />
# В пятницу служба QA проводит дополнительные регламентированные тесты всех обновлений, в это же время на форуме анонсируются обновления и приглашаются желающие их тестировать.<br />
# В понедельник протестированные таким образом обновления публикуются в основные репозитории единой "пачкой"<br />
<br />
== Почему пользователям интересно участвовать в тестировании? ==<br />
Как известно, платой за бесплатность линукса является участие в разработке - и это интересно само по себе.<br />
Но в данном случае есть и другой стимул - пока обновление лежит в тестинге, можно его откатить, отключив тестинг и запустив утилиту urpm-reposync из пакета urpm-tools.<br />
И если обновление приводит к какой-то ошибке, можно сообщить разработчикам, а обновление - просто откатить обратно. Если же в тестировании не участвовать, как знать - может ошибочное обновление дойдет до репозиториев и уже в понедельник проявится у вас - уже без возможности отката? <br />
{{Примечание|Cистемы тех пользователей, которые участвуют в тестировании, гораздо больше защищены от ошибок обновлений!}}<br />
<br />
== Как участвовать в тестировании? ==<br />
Для участия достаточно включить testing-репозитории и обновиться.<br />
Еще довольно важно держать свою систему стандартной, т.е. соответствующей по версиям основным репозиториям. Для этого достаточно обновляться, а перед тестированием убедиться в соответствии, запустив утилиту urpm-reposync.<br />
{{Примечание|Обязательно смотрите на список того, что пытается удалить-поставить urpm-reposync или служба обновлений. Если что-то полезное удаляется, возможно вы не включили все тестинг-репозитории? Или же отключая тестинг, отключили что-то стандартное?}}<br />
<br />
== Что делать, если после обновления проявилась ошибка? ==<br />
# Прежде всего, нужно проверить - с обновлениями-ли эта ошибка связана? Для этого отключите все тестинг-репозитории (не трогая все остальные!) и запустите urpm-reposync для того, чтоб привести свою систему в соответствие с основными репозиториями, потом перегрузитесь. <br />
# Если ошибка исчезла - опять накатите тестовые обновления, включив тестинг и обновившись. <br />
# Если ошибка опять появилась то да, теперь мы определили, что она связана с обновлениями. Самая пора сообщить об этом разработчикам, вместе с ними определить конкретный пакет, обновление которого вызвало ошибку и не пустить его в репозитории.<br />
<br />
== Что делать, если после тестового обновления я не могу зайти в систему? ==<br />
Поздравляем, вы приняли удар на себя. Теперь осталось после этого удара подняться! В большинстве случаев это несложно. Нужно<br />
# Зайти в текстовом режиме с правами ''root'' через Ctrl+alt+F2<br />
# Запустить текстовый редактор, например '''mcedit /etc/urpmi/urpmi.cfg''' <br />
# В списке репозиториев найти тестовые и там, перед командой "update" вставить строчку "ignore". <br />
Должно получиться что-то вроде: <br />
Main\ Testing http://mirror.rosalab.ru/rosa/rosa2016.1/repository/x86_64/media/main/testing { <br />
ignore <br />
update <br />
} <br />
Дальше остается сохранить файл конфигурации репозиториев и командой '''urpm-reposync''' вернуть свою систему к дотестовому состоянию.<br />
И, обязательно, сообщить об ошибке команде тестирования! Это можно сделать в теме на форуме <br />
http://forum.rosalab.ru/viewtopic.php?f=48&t=5372<br />
или соответствующем этому тестированию сообщению на стене вконтакте.<br />
<br />
== Подробный список обновлений на эту неделю ==<br />
Здесь приводится список текущих запросов на обновление - для опытных пользователей, которые могут более подробно разбираться с обновлениями при ошибках.<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10739 perl<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10804 docker-containerd<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10807 samba<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10808 deadbeef<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10823 gpac<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10827 firefox-esr78<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10828 curl<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10829 yarn<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10830 get-skypeonlinux<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10831 rust<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10832 chromium-browser<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10833 firefox<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10834 thunderbird<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10835 htop<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10838 mesa<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10839 python-rdflib<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10840 virtualbox<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10841 get-yandex-browser<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10842 flash<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10843 libva vaapi</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A2%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_17-28_%D0%B0%D0%B2%D0%B3%D1%83%D1%81%D1%82%D0%B0&diff=18715
Тестирование 17-28 августа
2020-08-28T15:54:47Z
<p>Vladimir.potapov: Новая страница: «Категория:Расширенное тестирование == Общая схема тестирования == В настоящее время вс…»</p>
<hr />
<div>[[Категория:Расширенное тестирование]]<br />
== Общая схема тестирования ==<br />
В настоящее время все обновления, кроме срочных обновлений безопасности, проходят дополнительное тестирование по следующей схеме:<br />
# После первичной проверки они попадают в репозиторий testing, соответствующий обычному репозиторию (для main - main testing, для restricted - restricted testing и.т.д)<br />
# В пятницу служба QA проводит дополнительные регламентированные тесты всех обновлений, в это же время на форуме анонсируются обновления и приглашаются желающие их тестировать.<br />
# В понедельник протестированные таким образом обновления публикуются в основные репозитории единой "пачкой"<br />
<br />
== Почему пользователям интересно участвовать в тестировании? ==<br />
Как известно, платой за бесплатность линукса является участие в разработке - и это интересно само по себе.<br />
Но в данном случае есть и другой стимул - пока обновление лежит в тестинге, можно его откатить, отключив тестинг и запустив утилиту urpm-reposync из пакета urpm-tools.<br />
И если обновление приводит к какой-то ошибке, можно сообщить разработчикам, а обновление - просто откатить обратно. Если же в тестировании не участвовать, как знать - может ошибочное обновление дойдет до репозиториев и уже в понедельник проявится у вас - уже без возможности отката? <br />
{{Примечание|Cистемы тех пользователей, которые участвуют в тестировании, гораздо больше защищены от ошибок обновлений!}}<br />
<br />
== Как участвовать в тестировании? ==<br />
Для участия достаточно включить testing-репозитории и обновиться.<br />
Еще довольно важно держать свою систему стандартной, т.е. соответствующей по версиям основным репозиториям. Для этого достаточно обновляться, а перед тестированием убедиться в соответствии, запустив утилиту urpm-reposync.<br />
{{Примечание|Обязательно смотрите на список того, что пытается удалить-поставить urpm-reposync или служба обновлений. Если что-то полезное удаляется, возможно вы не включили все тестинг-репозитории? Или же отключая тестинг, отключили что-то стандартное?}}<br />
<br />
== Что делать, если после обновления проявилась ошибка? ==<br />
# Прежде всего, нужно проверить - с обновлениями-ли эта ошибка связана? Для этого отключите все тестинг-репозитории (не трогая все остальные!) и запустите urpm-reposync для того, чтоб привести свою систему в соответствие с основными репозиториями, потом перегрузитесь. <br />
# Если ошибка исчезла - опять накатите тестовые обновления, включив тестинг и обновившись. <br />
# Если ошибка опять появилась то да, теперь мы определили, что она связана с обновлениями. Самая пора сообщить об этом разработчикам, вместе с ними определить конкретный пакет, обновление которого вызвало ошибку и не пустить его в репозитории.<br />
<br />
== Что делать, если после тестового обновления я не могу зайти в систему? ==<br />
Поздравляем, вы приняли удар на себя. Теперь осталось после этого удара подняться! В большинстве случаев это несложно. Нужно<br />
# Зайти в текстовом режиме с правами ''root'' через Ctrl+alt+F2<br />
# Запустить текстовый редактор, например '''mcedit /etc/urpmi/urpmi.cfg''' <br />
# В списке репозиториев найти тестовые и там, перед командой "update" вставить строчку "ignore". <br />
Должно получиться что-то вроде: <br />
Main\ Testing http://mirror.rosalab.ru/rosa/rosa2016.1/repository/x86_64/media/main/testing { <br />
ignore <br />
update <br />
} <br />
Дальше остается сохранить файл конфигурации репозиториев и командой '''urpm-reposync''' вернуть свою систему к дотестовому состоянию.<br />
И, обязательно, сообщить об ошибке команде тестирования! Это можно сделать в теме на форуме <br />
http://forum.rosalab.ru/viewtopic.php?f=48&t=5372<br />
или соответствующем этому тестированию сообщению на стене вконтакте.<br />
<br />
== Подробный список обновлений на эту неделю ==<br />
Здесь приводится список текущих запросов на обновление - для опытных пользователей, которые могут более подробно разбираться с обновлениями при ошибках.<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=9359 dbus<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10722 xawtv<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10792 ark plasma5-ark<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10797 farstream<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10800 nano<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10804 docker-containerd<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10806 strace<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10808 deadbeef<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10812 espeak<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10813 thunderbird<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10816 llvm mesa chromium-browser<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10817 mariadb<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10818 libreoffce<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10819 fdk-aac<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10820 master-pdf-editor<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10821 python-yaml</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A2%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_27_%D0%B8%D1%8E%D0%BB%D1%8F_-_7_%D0%B0%D0%B2%D0%B3%D1%83%D1%81%D1%82%D0%B0&diff=18692
Тестирование 27 июля - 7 августа
2020-08-07T16:02:19Z
<p>Vladimir.potapov: Новая страница: «Категория:Расширенное тестирование == Общая схема тестирования == В настоящее время вс…»</p>
<hr />
<div>[[Категория:Расширенное тестирование]]<br />
== Общая схема тестирования ==<br />
В настоящее время все обновления, кроме срочных обновлений безопасности, проходят дополнительное тестирование по следующей схеме:<br />
# После первичной проверки они попадают в репозиторий testing, соответствующий обычному репозиторию (для main - main testing, для restricted - restricted testing и.т.д)<br />
# В пятницу служба QA проводит дополнительные регламентированные тесты всех обновлений, в это же время на форуме анонсируются обновления и приглашаются желающие их тестировать.<br />
# В понедельник протестированные таким образом обновления публикуются в основные репозитории единой "пачкой"<br />
<br />
== Почему пользователям интересно участвовать в тестировании? ==<br />
Как известно, платой за бесплатность линукса является участие в разработке - и это интересно само по себе.<br />
Но в данном случае есть и другой стимул - пока обновление лежит в тестинге, можно его откатить, отключив тестинг и запустив утилиту urpm-reposync из пакета urpm-tools.<br />
И если обновление приводит к какой-то ошибке, можно сообщить разработчикам, а обновление - просто откатить обратно. Если же в тестировании не участвовать, как знать - может ошибочное обновление дойдет до репозиториев и уже в понедельник проявится у вас - уже без возможности отката? <br />
{{Примечание|Cистемы тех пользователей, которые участвуют в тестировании, гораздо больше защищены от ошибок обновлений!}}<br />
<br />
== Как участвовать в тестировании? ==<br />
Для участия достаточно включить testing-репозитории и обновиться.<br />
Еще довольно важно держать свою систему стандартной, т.е. соответствующей по версиям основным репозиториям. Для этого достаточно обновляться, а перед тестированием убедиться в соответствии, запустив утилиту urpm-reposync.<br />
{{Примечание|Обязательно смотрите на список того, что пытается удалить-поставить urpm-reposync или служба обновлений. Если что-то полезное удаляется, возможно вы не включили все тестинг-репозитории? Или же отключая тестинг, отключили что-то стандартное?}}<br />
<br />
== Что делать, если после обновления проявилась ошибка? ==<br />
# Прежде всего, нужно проверить - с обновлениями-ли эта ошибка связана? Для этого отключите все тестинг-репозитории (не трогая все остальные!) и запустите urpm-reposync для того, чтоб привести свою систему в соответствие с основными репозиториями, потом перегрузитесь. <br />
# Если ошибка исчезла - опять накатите тестовые обновления, включив тестинг и обновившись. <br />
# Если ошибка опять появилась то да, теперь мы определили, что она связана с обновлениями. Самая пора сообщить об этом разработчикам, вместе с ними определить конкретный пакет, обновление которого вызвало ошибку и не пустить его в репозитории.<br />
<br />
== Что делать, если после тестового обновления я не могу зайти в систему? ==<br />
Поздравляем, вы приняли удар на себя. Теперь осталось после этого удара подняться! В большинстве случаев это несложно. Нужно<br />
# Зайти в текстовом режиме с правами ''root'' через Ctrl+alt+F2<br />
# Запустить текстовый редактор, например '''mcedit /etc/urpmi/urpmi.cfg''' <br />
# В списке репозиториев найти тестовые и там, перед командой "update" вставить строчку "ignore". <br />
Должно получиться что-то вроде: <br />
Main\ Testing http://mirror.rosalab.ru/rosa/rosa2016.1/repository/x86_64/media/main/testing { <br />
ignore <br />
update <br />
} <br />
Дальше остается сохранить файл конфигурации репозиториев и командой '''urpm-reposync''' вернуть свою систему к дотестовому состоянию.<br />
И, обязательно, сообщить об ошибке команде тестирования! Это можно сделать в теме на форуме <br />
http://forum.rosalab.ru/viewtopic.php?f=48&t=5372<br />
или соответствующем этому тестированию сообщению на стене вконтакте.<br />
<br />
== Подробный список обновлений на эту неделю ==<br />
Здесь приводится список текущих запросов на обновление - для опытных пользователей, которые могут более подробно разбираться с обновлениями при ошибках.<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10740 snort<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10751 adplug<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10752 audiacious audicious-plugins<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10768 nodejs<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10770 gnuplot<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10771 lv2<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10772 serd<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10773 sord<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10774 sratom<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10775 suil<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10776 lilv<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10778 chromaprint<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10779 cmt<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10782 git<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10783 opera-blink<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10785 fpc<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10786 lazarus<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10788 libmicrohttpd<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10789 kodi</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A2%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_13-24_%D0%B8%D1%8E%D0%BB%D1%8F&diff=18687
Тестирование 13-24 июля
2020-07-24T16:44:31Z
<p>Vladimir.potapov: Новая страница: «Категория:Расширенное тестирование == Общая схема тестирования == В настоящее время вс…»</p>
<hr />
<div>[[Категория:Расширенное тестирование]]<br />
== Общая схема тестирования ==<br />
В настоящее время все обновления, кроме срочных обновлений безопасности, проходят дополнительное тестирование по следующей схеме:<br />
# После первичной проверки они попадают в репозиторий testing, соответствующий обычному репозиторию (для main - main testing, для restricted - restricted testing и.т.д)<br />
# В пятницу служба QA проводит дополнительные регламентированные тесты всех обновлений, в это же время на форуме анонсируются обновления и приглашаются желающие их тестировать.<br />
# В понедельник протестированные таким образом обновления публикуются в основные репозитории единой "пачкой"<br />
<br />
== Почему пользователям интересно участвовать в тестировании? ==<br />
Как известно, платой за бесплатность линукса является участие в разработке - и это интересно само по себе.<br />
Но в данном случае есть и другой стимул - пока обновление лежит в тестинге, можно его откатить, отключив тестинг и запустив утилиту urpm-reposync из пакета urpm-tools.<br />
И если обновление приводит к какой-то ошибке, можно сообщить разработчикам, а обновление - просто откатить обратно. Если же в тестировании не участвовать, как знать - может ошибочное обновление дойдет до репозиториев и уже в понедельник проявится у вас - уже без возможности отката? <br />
{{Примечание|Cистемы тех пользователей, которые участвуют в тестировании, гораздо больше защищены от ошибок обновлений!}}<br />
<br />
== Как участвовать в тестировании? ==<br />
Для участия достаточно включить testing-репозитории и обновиться.<br />
Еще довольно важно держать свою систему стандартной, т.е. соответствующей по версиям основным репозиториям. Для этого достаточно обновляться, а перед тестированием убедиться в соответствии, запустив утилиту urpm-reposync.<br />
{{Примечание|Обязательно смотрите на список того, что пытается удалить-поставить urpm-reposync или служба обновлений. Если что-то полезное удаляется, возможно вы не включили все тестинг-репозитории? Или же отключая тестинг, отключили что-то стандартное?}}<br />
<br />
== Что делать, если после обновления проявилась ошибка? ==<br />
# Прежде всего, нужно проверить - с обновлениями-ли эта ошибка связана? Для этого отключите все тестинг-репозитории (не трогая все остальные!) и запустите urpm-reposync для того, чтоб привести свою систему в соответствие с основными репозиториями, потом перегрузитесь. <br />
# Если ошибка исчезла - опять накатите тестовые обновления, включив тестинг и обновившись. <br />
# Если ошибка опять появилась то да, теперь мы определили, что она связана с обновлениями. Самая пора сообщить об этом разработчикам, вместе с ними определить конкретный пакет, обновление которого вызвало ошибку и не пустить его в репозитории.<br />
<br />
== Что делать, если после тестового обновления я не могу зайти в систему? ==<br />
Поздравляем, вы приняли удар на себя. Теперь осталось после этого удара подняться! В большинстве случаев это несложно. Нужно<br />
# Зайти в текстовом режиме с правами ''root'' через Ctrl+alt+F2<br />
# Запустить текстовый редактор, например '''mcedit /etc/urpmi/urpmi.cfg''' <br />
# В списке репозиториев найти тестовые и там, перед командой "update" вставить строчку "ignore". <br />
Должно получиться что-то вроде: <br />
Main\ Testing http://mirror.rosalab.ru/rosa/rosa2016.1/repository/x86_64/media/main/testing { <br />
ignore <br />
update <br />
} <br />
Дальше остается сохранить файл конфигурации репозиториев и командой '''urpm-reposync''' вернуть свою систему к дотестовому состоянию.<br />
И, обязательно, сообщить об ошибке команде тестирования! Это можно сделать в теме на форуме <br />
http://forum.rosalab.ru/viewtopic.php?f=48&t=5372<br />
или соответствующем этому тестированию сообщению на стене вконтакте.<br />
<br />
== Подробный список обновлений на эту неделю ==<br />
Здесь приводится список текущих запросов на обновление - для опытных пользователей, которые могут более подробно разбираться с обновлениями при ошибках.<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10615 ardor<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10723 mesa<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10729 avahi<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10734 python3<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10735 python2<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10738 newmoon<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10741 systemd<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10751 adplug<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10752 audacious audacious-plugins<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10753 get-skypeforlinux<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10756 firefox<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10757 thunderbid<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10758 opera-blink<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10761 clamav<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10762 rust<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10763 eigen<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10764 flash<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10765 mc<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10766 scrooge<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10767 fftw<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10768 nodejs</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A2%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_11-22_%D0%BC%D0%B0%D1%8F&diff=18664
Тестирование 11-22 мая
2020-05-22T17:10:49Z
<p>Vladimir.potapov: Новая страница: «Категория:Расширенное тестирование == Общая схема тестирования == В настоящее время вс…»</p>
<hr />
<div>[[Категория:Расширенное тестирование]]<br />
== Общая схема тестирования ==<br />
В настоящее время все обновления, кроме срочных обновлений безопасности, проходят дополнительное тестирование по следующей схеме:<br />
# После первичной проверки они попадают в репозиторий testing, соответствующий обычному репозиторию (для main - main testing, для restricted - restricted testing и.т.д)<br />
# В пятницу служба QA проводит дополнительные регламентированные тесты всех обновлений, в это же время на форуме анонсируются обновления и приглашаются желающие их тестировать.<br />
# В понедельник протестированные таким образом обновления публикуются в основные репозитории единой "пачкой"<br />
<br />
== Почему пользователям интересно участвовать в тестировании? ==<br />
Как известно, платой за бесплатность линукса является участие в разработке - и это интересно само по себе.<br />
Но в данном случае есть и другой стимул - пока обновление лежит в тестинге, можно его откатить, отключив тестинг и запустив утилиту urpm-reposync из пакета urpm-tools.<br />
И если обновление приводит к какой-то ошибке, можно сообщить разработчикам, а обновление - просто откатить обратно. Если же в тестировании не участвовать, как знать - может ошибочное обновление дойдет до репозиториев и уже в понедельник проявится у вас - уже без возможности отката? <br />
{{Примечание|Cистемы тех пользователей, которые участвуют в тестировании, гораздо больше защищены от ошибок обновлений!}}<br />
<br />
== Как участвовать в тестировании? ==<br />
Для участия достаточно включить testing-репозитории и обновиться.<br />
Еще довольно важно держать свою систему стандартной, т.е. соответствующей по версиям основным репозиториям. Для этого достаточно обновляться, а перед тестированием убедиться в соответствии, запустив утилиту urpm-reposync.<br />
{{Примечание|Обязательно смотрите на список того, что пытается удалить-поставить urpm-reposync или служба обновлений. Если что-то полезное удаляется, возможно вы не включили все тестинг-репозитории? Или же отключая тестинг, отключили что-то стандартное?}}<br />
<br />
== Что делать, если после обновления проявилась ошибка? ==<br />
# Прежде всего, нужно проверить - с обновлениями-ли эта ошибка связана? Для этого отключите все тестинг-репозитории (не трогая все остальные!) и запустите urpm-reposync для того, чтоб привести свою систему в соответствие с основными репозиториями, потом перегрузитесь. <br />
# Если ошибка исчезла - опять накатите тестовые обновления, включив тестинг и обновившись. <br />
# Если ошибка опять появилась то да, теперь мы определили, что она связана с обновлениями. Самая пора сообщить об этом разработчикам, вместе с ними определить конкретный пакет, обновление которого вызвало ошибку и не пустить его в репозитории.<br />
<br />
== Что делать, если после тестового обновления я не могу зайти в систему? ==<br />
Поздравляем, вы приняли удар на себя. Теперь осталось после этого удара подняться! В большинстве случаев это несложно. Нужно<br />
# Зайти в текстовом режиме с правами ''root'' через Ctrl+alt+F2<br />
# Запустить текстовый редактор, например '''mcedit /etc/urpmi/urpmi.cfg''' <br />
# В списке репозиториев найти тестовые и там, перед командой "update" вставить строчку "ignore". <br />
Должно получиться что-то вроде: <br />
Main\ Testing http://mirror.rosalab.ru/rosa/rosa2016.1/repository/x86_64/media/main/testing { <br />
ignore <br />
update <br />
} <br />
Дальше остается сохранить файл конфигурации репозиториев и командой '''urpm-reposync''' вернуть свою систему к дотестовому состоянию.<br />
И, обязательно, сообщить об ошибке команде тестирования! Это можно сделать в теме на форуме <br />
http://forum.rosalab.ru/viewtopic.php?f=48&t=5372<br />
или соответствующем этому тестированию сообщению на стене вконтакте.<br />
<br />
== Подробный список обновлений на эту неделю ==<br />
Здесь приводится список текущих запросов на обновление - для опытных пользователей, которые могут более подробно разбираться с обновлениями при ошибках.<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10495 thunderbird<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10545 samba<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10622 wine<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10627 vlc<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10631 timezone<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10638 linux-firmware<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10649 kernel<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10650 microcode<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10652 zlib<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10653 chromium-browser<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10658 clamav<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10659 firefox-esr68<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10660 opera-blink<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10663 curl<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10664 rust<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10665 postfix<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10671 get-skypeforlinux<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10672 chkconfog</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A2%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_4-8_%D0%BC%D0%B0%D1%8F_2020_%D0%B3%D0%BE%D0%B4%D0%B0&diff=18663
Тестирование 4-8 мая 2020 года
2020-05-08T16:10:13Z
<p>Vladimir.potapov: Новая страница: «Категория:Расширенное тестирование == Общая схема тестирования == В настоящее время вс…»</p>
<hr />
<div>[[Категория:Расширенное тестирование]]<br />
== Общая схема тестирования ==<br />
В настоящее время все обновления, кроме срочных обновлений безопасности, проходят дополнительное тестирование по следующей схеме:<br />
# После первичной проверки они попадают в репозиторий testing, соответствующий обычному репозиторию (для main - main testing, для restricted - restricted testing и.т.д)<br />
# В пятницу служба QA проводит дополнительные регламентированные тесты всех обновлений, в это же время на форуме анонсируются обновления и приглашаются желающие их тестировать.<br />
# В понедельник протестированные таким образом обновления публикуются в основные репозитории единой "пачкой"<br />
<br />
== Почему пользователям интересно участвовать в тестировании? ==<br />
Как известно, платой за бесплатность линукса является участие в разработке - и это интересно само по себе.<br />
Но в данном случае есть и другой стимул - пока обновление лежит в тестинге, можно его откатить, отключив тестинг и запустив утилиту urpm-reposync из пакета urpm-tools.<br />
И если обновление приводит к какой-то ошибке, можно сообщить разработчикам, а обновление - просто откатить обратно. Если же в тестировании не участвовать, как знать - может ошибочное обновление дойдет до репозиториев и уже в понедельник проявится у вас - уже без возможности отката? <br />
{{Примечание|Cистемы тех пользователей, которые участвуют в тестировании, гораздо больше защищены от ошибок обновлений!}}<br />
<br />
== Как участвовать в тестировании? ==<br />
Для участия достаточно включить testing-репозитории и обновиться.<br />
Еще довольно важно держать свою систему стандартной, т.е. соответствующей по версиям основным репозиториям. Для этого достаточно обновляться, а перед тестированием убедиться в соответствии, запустив утилиту urpm-reposync.<br />
{{Примечание|Обязательно смотрите на список того, что пытается удалить-поставить urpm-reposync или служба обновлений. Если что-то полезное удаляется, возможно вы не включили все тестинг-репозитории? Или же отключая тестинг, отключили что-то стандартное?}}<br />
<br />
== Что делать, если после обновления проявилась ошибка? ==<br />
# Прежде всего, нужно проверить - с обновлениями-ли эта ошибка связана? Для этого отключите все тестинг-репозитории (не трогая все остальные!) и запустите urpm-reposync для того, чтоб привести свою систему в соответствие с основными репозиториями, потом перегрузитесь. <br />
# Если ошибка исчезла - опять накатите тестовые обновления, включив тестинг и обновившись. <br />
# Если ошибка опять появилась то да, теперь мы определили, что она связана с обновлениями. Самая пора сообщить об этом разработчикам, вместе с ними определить конкретный пакет, обновление которого вызвало ошибку и не пустить его в репозитории.<br />
<br />
== Что делать, если после тестового обновления я не могу зайти в систему? ==<br />
Поздравляем, вы приняли удар на себя. Теперь осталось после этого удара подняться! В большинстве случаев это несложно. Нужно<br />
# Зайти в текстовом режиме с правами ''root'' через Ctrl+alt+F2<br />
# Запустить текстовый редактор, например '''mcedit /etc/urpmi/urpmi.cfg''' <br />
# В списке репозиториев найти тестовые и там, перед командой "update" вставить строчку "ignore". <br />
Должно получиться что-то вроде: <br />
Main\ Testing http://mirror.rosalab.ru/rosa/rosa2016.1/repository/x86_64/media/main/testing { <br />
ignore <br />
update <br />
} <br />
Дальше остается сохранить файл конфигурации репозиториев и командой '''urpm-reposync''' вернуть свою систему к дотестовому состоянию.<br />
И, обязательно, сообщить об ошибке команде тестирования! Это можно сделать в теме на форуме <br />
http://forum.rosalab.ru/viewtopic.php?f=48&t=5372<br />
или соответствующем этому тестированию сообщению на стене вконтакте.<br />
<br />
== Подробный список обновлений на эту неделю ==<br />
Здесь приводится список текущих запросов на обновление - для опытных пользователей, которые могут более подробно разбираться с обновлениями при ошибках.<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10465 tesseract<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10543 hylafax<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10549 clementine<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10585 libgudev<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10604 gnupg gnupg2<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10611 git<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10613 virtualbox<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10619 pcsc-lite<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10622 wine<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10627 vlc<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10630 libyubikey<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10633 rust<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10637 cracklib libpwquality<br />
# https://bugzilla.rosalinux.ru/show_bug.cgi?id=10638 linux-firmware</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_%D0%B2_%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%BD%D1%8B%D1%85_%D1%80%D0%B5%D0%BF%D0%BE%D0%B7%D0%B8%D1%82%D0%BE%D1%80%D0%B8%D1%8F%D1%85_ROSA_Linux&diff=18659
Регламент обновления пакетов в основных репозиториях ROSA Linux
2020-04-29T15:37:57Z
<p>Vladimir.potapov: /* Публикатор */</p>
<hr />
<div>=== Применимость ===<br />
Настоящий регламент описывает порядок добавления и исправления пакетов в репозиториях ROSA при взаимодействии пяти команд:<br />
# Команды репортеров, сообщающих об ошибках и уязвимостях в пакетной базе и выступающих с предложениями обновления пакетов<br />
# Команды сборщиков (мейнтейнеров), собирающих пакеты с новыми версиями программ и исправлениями ошибок и уязвимостей<br />
# Команды контроля качества (QA), контролирующих работоспособность исправленных пакетов и всей системы в целом после обновления<br />
# Команда контроля уязвимостей (SecTeam), отслеживающих текущие уязвимости дистрибутива и корректность исправления этих уязвимостей сборщиками<br />
# Публикатора, задачи которого - доступность исправленных пакетов на зеркалах дистрибутива, контроль целостности/замкнутости репозиториев после публикации, а также качества сборки самих пакетов (соответствие политикам сборки, принятым в дистрибутиве и т.п.)<br />
<br />
Данный порядок относится к работе с основными репозиториями ROSA Linux, за исключением репозитория сообщества ROSA Fresh (contrib) где контроль качества не производится.<br />
<br />
=== Общий порядок обновления ===<br />
# Общий порядок адресации каждого запроса на обновление - <br />
Репортеры (в т.ч. из SecTeam) -> Cборщики -> QA & SecTeam -> Публикатор<br />
# Допустимо совмещение ролей "репортер", "сборщик" и "публикатор", но недопустима ситуация, когда человек проверяет результаты своей сборки и публикует их. <br />
# Вся работа по обновлению пакетов происходит с помощью специально созданных в багзилле ROSA Linux багов - запросов на обновление<br />
<br />
=== Репортеры ===<br />
# Репортеры заводят в багзилле баги, обосновывающие необходимость исправления или добавления, с описанием ошибки, кодом уязвимости или необходимым им новым функционалом.<br />
# Альтернативным путем создания запроса на изменение пакетов в репозиториях для репортеров является пул-реквест в системе сборки ABF.<br />
# Репортеры являются заказчиками исправления, т.е. контролируют весь его процесс до попадания в репозитории.<br />
<br />
=== Сборщики ===<br />
# Сборщики получают информацию о багах от репортеров через почтовую рассылку багзиллы<br />
# Пакеты обновляются на основании заведенного в [http://bugs.rosalinux.ru багзилле] бага, называемого далее "запросом на обновление"<br />
# В комментариях к запросу на обновление указываются ссылки на контейнеры с собранным для указанной платформы обновлением пакета и advisory - написанное по-английски обоснование обновления (например выход новой версии, исправление уязвимости)<br />
# После того, как закончено формирование запроса на обновление, он отправляется на контроль качества команде QA установкой флажка qa_verified в знак вопроса "?"<br />
<br />
=== Мейнтейнеры ===<br />
Мейнтейнер (сопровождающий) - совмещает в себе функции сборщика, репортера и ответственного за функциональность пакета. Мейнтейнер отслеживает его изменения, исправляет уязвимости и ошибки.<br />
# Если какой-то пакет имеет мейнтейнера, это должно быть прописано на abf<br />
# В пакет с указанным мейнтейнером имеет право вносить правки только сам мейнтейнер, остальные могут только предлагать правки, например с помощью пул-реквестов<br />
# Пул-реквесты или другие предложения на обновление пакета должны рассматриваться мейнтейнером в течение недели, а критические - в течение 48 часов (за возможным исключением выходных и праздничных дней)<br />
# 0-day уязвимости в своем пакете мейнтейнер должен исправлять и передавать на тестирование в течение 48 часов с момента появления рабочих патчей, закрывающих уязвимость (за возможным исключением выходных и праздничных дней), критические - в течение недели<br />
# Баги в пакете, имеющем мейнтейнера, должны им рассматриваться (исправляться, отменяться или хотя бы комментироваться) в течение двух недель после назначения.<br />
# Мейнтейнер пакета при необходимости самостоятельно взаимодействует с разработчиками пакетируемого ПО для исправления найденных службой QA или другими репортерами ошибок.<br />
# В случае, если мейнтейнер не выдерживает указанные сроки по реагированию на предложения правок, исправления уязвимостей и ошибок, они могут быть исправлены другим сборщиком по процедуре, аналогичной для пакета, не имеющего мейнтейнера<br />
<br />
=== Команда контроля качества (QA) ===<br />
# Команда QA получает запросы с установленным сборщиками флажком qa_verified<br />
# Команда QA проводит тестирование пакетов, используя [[Регламент тестирования]]<br />
# Если обновление содержит исправления уязвимостей, устанавливается флажок sectime_verified в "?" для параллельной проверки корректности исправления уязвимостей командой SecTeam<br />
# После проверки отсутствия регрессий функциональности у собранного пакета команда QA ставит флаг QA_verified "+" при успешной проверке и "-" при неуспешной.<br />
# При отсутствии регрессий и, при необходимости, после получения одобрения запроса от команды SecTeam (флажок sectime_verified меняется на "+") запрос отправляется на публикацию установкой флажка publishied в "?"<br />
# QA каждую пятницу публикует бюллетень с перечнем исправленных багов за истекшую неделю<br />
<br />
=== Команда поиска и устранения уязвимостей (SecTeam) ===<br />
# Подробности поиска уязвимостей описаны в документе [[Регламент по устранению уязвимостей]]<br />
# Список уязвимостей ведется на странице вики [http://wiki.rosalab.ru/ru/index.php/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:Security_Advisories Список уязвимостей] командой SecTeam.<br />
# Для каждой уязвимости из списка команда SecTeam выступает репортером и заводит баг<br />
# После того, как сборщики соберут исправленные пакеты и QA установить флажок secteam_verified в "?", SecTeam проверяет исправление уязвимости<br />
# Дополнительно могут проверяться и запросы с исправлениями уязвимостей, сделанные и не участниками команды SecTeam<br />
# При успешной проверке secteam_verified устанавливается в "+"<br />
<br />
=== Публикатор ===<br />
# Публикатор получает запрос на обновление после его одобрения командами QA и (если он содержит исправления уязвимостей) SecTeam<br />
# Публикатор отвечает за доступность пакетов обновлений для пользователей в репозиториях на зеркалах дистрибутива<br />
# Задача публикатора - проверка контроля целостности/замкнутости репозиториев после публикации, оценка возможного неправильного взаимодействия различных компонентов с учетом внесенных обновлением изменений, оценка корректности сборки пакета с учетом принятых в дистрибутиве правил сборки<br />
# После успешной публикации флажок "publishied" устанавливается в "+" и запрос на обновление считается полностью закрытым.<br />
# При нахождении ошибок в отправленном на публикацию обновлении публикатор может установить флажок publishied в "-", таким образом отклонив публикацию, при этом он должен написать в запросе на обновление причину<br />
# Публикатор должен опубликовать направленный на публикацию пакет или отклонить его публикацию в течение 48 часов (за исключением выходных и праздничных дней)<br />
<br />
[[Категория:Регламенты ROSA]]</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_%D0%B2_%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%BD%D1%8B%D1%85_%D1%80%D0%B5%D0%BF%D0%BE%D0%B7%D0%B8%D1%82%D0%BE%D1%80%D0%B8%D1%8F%D1%85_ROSA_Linux&diff=18658
Регламент обновления пакетов в основных репозиториях ROSA Linux
2020-04-29T15:35:18Z
<p>Vladimir.potapov: /* Мейнтейнеры */</p>
<hr />
<div>=== Применимость ===<br />
Настоящий регламент описывает порядок добавления и исправления пакетов в репозиториях ROSA при взаимодействии пяти команд:<br />
# Команды репортеров, сообщающих об ошибках и уязвимостях в пакетной базе и выступающих с предложениями обновления пакетов<br />
# Команды сборщиков (мейнтейнеров), собирающих пакеты с новыми версиями программ и исправлениями ошибок и уязвимостей<br />
# Команды контроля качества (QA), контролирующих работоспособность исправленных пакетов и всей системы в целом после обновления<br />
# Команда контроля уязвимостей (SecTeam), отслеживающих текущие уязвимости дистрибутива и корректность исправления этих уязвимостей сборщиками<br />
# Публикатора, задачи которого - доступность исправленных пакетов на зеркалах дистрибутива, контроль целостности/замкнутости репозиториев после публикации, а также качества сборки самих пакетов (соответствие политикам сборки, принятым в дистрибутиве и т.п.)<br />
<br />
Данный порядок относится к работе с основными репозиториями ROSA Linux, за исключением репозитория сообщества ROSA Fresh (contrib) где контроль качества не производится.<br />
<br />
=== Общий порядок обновления ===<br />
# Общий порядок адресации каждого запроса на обновление - <br />
Репортеры (в т.ч. из SecTeam) -> Cборщики -> QA & SecTeam -> Публикатор<br />
# Допустимо совмещение ролей "репортер", "сборщик" и "публикатор", но недопустима ситуация, когда человек проверяет результаты своей сборки и публикует их. <br />
# Вся работа по обновлению пакетов происходит с помощью специально созданных в багзилле ROSA Linux багов - запросов на обновление<br />
<br />
=== Репортеры ===<br />
# Репортеры заводят в багзилле баги, обосновывающие необходимость исправления или добавления, с описанием ошибки, кодом уязвимости или необходимым им новым функционалом.<br />
# Альтернативным путем создания запроса на изменение пакетов в репозиториях для репортеров является пул-реквест в системе сборки ABF.<br />
# Репортеры являются заказчиками исправления, т.е. контролируют весь его процесс до попадания в репозитории.<br />
<br />
=== Сборщики ===<br />
# Сборщики получают информацию о багах от репортеров через почтовую рассылку багзиллы<br />
# Пакеты обновляются на основании заведенного в [http://bugs.rosalinux.ru багзилле] бага, называемого далее "запросом на обновление"<br />
# В комментариях к запросу на обновление указываются ссылки на контейнеры с собранным для указанной платформы обновлением пакета и advisory - написанное по-английски обоснование обновления (например выход новой версии, исправление уязвимости)<br />
# После того, как закончено формирование запроса на обновление, он отправляется на контроль качества команде QA установкой флажка qa_verified в знак вопроса "?"<br />
<br />
=== Мейнтейнеры ===<br />
Мейнтейнер (сопровождающий) - совмещает в себе функции сборщика, репортера и ответственного за функциональность пакета. Мейнтейнер отслеживает его изменения, исправляет уязвимости и ошибки.<br />
# Если какой-то пакет имеет мейнтейнера, это должно быть прописано на abf<br />
# В пакет с указанным мейнтейнером имеет право вносить правки только сам мейнтейнер, остальные могут только предлагать правки, например с помощью пул-реквестов<br />
# Пул-реквесты или другие предложения на обновление пакета должны рассматриваться мейнтейнером в течение недели, а критические - в течение 48 часов (за возможным исключением выходных и праздничных дней)<br />
# 0-day уязвимости в своем пакете мейнтейнер должен исправлять и передавать на тестирование в течение 48 часов с момента появления рабочих патчей, закрывающих уязвимость (за возможным исключением выходных и праздничных дней), критические - в течение недели<br />
# Баги в пакете, имеющем мейнтейнера, должны им рассматриваться (исправляться, отменяться или хотя бы комментироваться) в течение двух недель после назначения.<br />
# Мейнтейнер пакета при необходимости самостоятельно взаимодействует с разработчиками пакетируемого ПО для исправления найденных службой QA или другими репортерами ошибок.<br />
# В случае, если мейнтейнер не выдерживает указанные сроки по реагированию на предложения правок, исправления уязвимостей и ошибок, они могут быть исправлены другим сборщиком по процедуре, аналогичной для пакета, не имеющего мейнтейнера<br />
<br />
=== Команда контроля качества (QA) ===<br />
# Команда QA получает запросы с установленным сборщиками флажком qa_verified<br />
# Команда QA проводит тестирование пакетов, используя [[Регламент тестирования]]<br />
# Если обновление содержит исправления уязвимостей, устанавливается флажок sectime_verified в "?" для параллельной проверки корректности исправления уязвимостей командой SecTeam<br />
# После проверки отсутствия регрессий функциональности у собранного пакета команда QA ставит флаг QA_verified "+" при успешной проверке и "-" при неуспешной.<br />
# При отсутствии регрессий и, при необходимости, после получения одобрения запроса от команды SecTeam (флажок sectime_verified меняется на "+") запрос отправляется на публикацию установкой флажка publishied в "?"<br />
# QA каждую пятницу публикует бюллетень с перечнем исправленных багов за истекшую неделю<br />
<br />
=== Команда поиска и устранения уязвимостей (SecTeam) ===<br />
# Подробности поиска уязвимостей описаны в документе [[Регламент по устранению уязвимостей]]<br />
# Список уязвимостей ведется на странице вики [http://wiki.rosalab.ru/ru/index.php/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:Security_Advisories Список уязвимостей] командой SecTeam.<br />
# Для каждой уязвимости из списка команда SecTeam выступает репортером и заводит баг<br />
# После того, как сборщики соберут исправленные пакеты и QA установить флажок secteam_verified в "?", SecTeam проверяет исправление уязвимости<br />
# Дополнительно могут проверяться и запросы с исправлениями уязвимостей, сделанные и не участниками команды SecTeam<br />
# При успешной проверке secteam_verified устанавливается в "+"<br />
<br />
=== Публикатор ===<br />
# Публикатор получает запрос на обновление после его одобрения командами QA и (если он содержит исправления уязвимостей) SecTeam<br />
# Публикатор отвечает за доступность пакетов обновлений для пользователей в репозиториях на зеркалах дистрибутива<br />
# Задача публикатора - проверка контроля целостности/замкнутости репозиториев после публикации, оценка возможного неправильного взаимодействия различных компонентов с учетом внесенных обновлением изменений, оценка корректности сборки пакета с учетом принятых в дистрибутиве правил сборки<br />
# После успешной публикации флажок "publishied" устанавливается в "+" и запрос на обновление считается полностью закрытым.<br />
# При нахождении ошибок в отправленном на публикацию обновлении, публикатор может установить флажок publishied в "-", таким образом отклонив публикацию, при этом он должен написать в запросе на обновление причину<br />
# Публикатор должен опубликовать направленный на публикацию пакет или отклонить его публикацию в течение 48 часов (за исключением выходных и праздничных дней)<br />
<br />
[[Категория:Регламенты ROSA]]</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_%D0%B2_%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%BD%D1%8B%D1%85_%D1%80%D0%B5%D0%BF%D0%BE%D0%B7%D0%B8%D1%82%D0%BE%D1%80%D0%B8%D1%8F%D1%85_ROSA_Linux&diff=18657
Регламент обновления пакетов в основных репозиториях ROSA Linux
2020-04-29T15:34:32Z
<p>Vladimir.potapov: /* Публикатор */</p>
<hr />
<div>=== Применимость ===<br />
Настоящий регламент описывает порядок добавления и исправления пакетов в репозиториях ROSA при взаимодействии пяти команд:<br />
# Команды репортеров, сообщающих об ошибках и уязвимостях в пакетной базе и выступающих с предложениями обновления пакетов<br />
# Команды сборщиков (мейнтейнеров), собирающих пакеты с новыми версиями программ и исправлениями ошибок и уязвимостей<br />
# Команды контроля качества (QA), контролирующих работоспособность исправленных пакетов и всей системы в целом после обновления<br />
# Команда контроля уязвимостей (SecTeam), отслеживающих текущие уязвимости дистрибутива и корректность исправления этих уязвимостей сборщиками<br />
# Публикатора, задачи которого - доступность исправленных пакетов на зеркалах дистрибутива, контроль целостности/замкнутости репозиториев после публикации, а также качества сборки самих пакетов (соответствие политикам сборки, принятым в дистрибутиве и т.п.)<br />
<br />
Данный порядок относится к работе с основными репозиториями ROSA Linux, за исключением репозитория сообщества ROSA Fresh (contrib) где контроль качества не производится.<br />
<br />
=== Общий порядок обновления ===<br />
# Общий порядок адресации каждого запроса на обновление - <br />
Репортеры (в т.ч. из SecTeam) -> Cборщики -> QA & SecTeam -> Публикатор<br />
# Допустимо совмещение ролей "репортер", "сборщик" и "публикатор", но недопустима ситуация, когда человек проверяет результаты своей сборки и публикует их. <br />
# Вся работа по обновлению пакетов происходит с помощью специально созданных в багзилле ROSA Linux багов - запросов на обновление<br />
<br />
=== Репортеры ===<br />
# Репортеры заводят в багзилле баги, обосновывающие необходимость исправления или добавления, с описанием ошибки, кодом уязвимости или необходимым им новым функционалом.<br />
# Альтернативным путем создания запроса на изменение пакетов в репозиториях для репортеров является пул-реквест в системе сборки ABF.<br />
# Репортеры являются заказчиками исправления, т.е. контролируют весь его процесс до попадания в репозитории.<br />
<br />
=== Сборщики ===<br />
# Сборщики получают информацию о багах от репортеров через почтовую рассылку багзиллы<br />
# Пакеты обновляются на основании заведенного в [http://bugs.rosalinux.ru багзилле] бага, называемого далее "запросом на обновление"<br />
# В комментариях к запросу на обновление указываются ссылки на контейнеры с собранным для указанной платформы обновлением пакета и advisory - написанное по-английски обоснование обновления (например выход новой версии, исправление уязвимости)<br />
# После того, как закончено формирование запроса на обновление, он отправляется на контроль качества команде QA установкой флажка qa_verified в знак вопроса "?"<br />
<br />
=== Мейнтейнеры ===<br />
Мейнтейнер (сопровождающий) - совмещает в себе функции сборщика, репортера и ответственного за функциональность пакета. Мейнтейнер отслеживает его изменения, исправляет уязвимости и ошибки.<br />
# Если какой-то пакет имеет мейнтейнера, это должно быть прописано на abf<br />
# В пакет с указанным мейнтейнером имеет право вносить правки только сам мейнтейнер, остальные могут только предлагать правки, например с помощью пул-реквестов<br />
# Пул-реквесты или другие предложения на обновление пакета должны рассматриваться мейнтейнером в течение недели, а критические - в течение 48 часов (за возможным исключением выходных и праздничных дней)<br />
# 0-day уязвимости в своем пакете мейнтейнер должен исправлять и передавать на тестирование в течение 48 часов (за возможным исключением выходных и праздничных дней), критические - в течение недели<br />
# Баги в пакете, имеющем мейнтейнера, должны им рассматриваться (исправляться, отменяться или хотя бы комментироваться) в течение двух недель после назначения.<br />
# Мейнтейнер пакета при необходимости самостоятельно взаимодействует с разработчиками пакетируемого ПО для исправления найденных службой QA или другими репортерами ошибок.<br />
# В случае, если мейнтейнер не выдерживает указанные сроки по реагированию на предложения правок, исправления уязвимостей и ошибок, они могут быть исправлены другим сборщиком по процедуре, аналогичной для пакета, не имеющего мейнтейнера<br />
<br />
=== Команда контроля качества (QA) ===<br />
# Команда QA получает запросы с установленным сборщиками флажком qa_verified<br />
# Команда QA проводит тестирование пакетов, используя [[Регламент тестирования]]<br />
# Если обновление содержит исправления уязвимостей, устанавливается флажок sectime_verified в "?" для параллельной проверки корректности исправления уязвимостей командой SecTeam<br />
# После проверки отсутствия регрессий функциональности у собранного пакета команда QA ставит флаг QA_verified "+" при успешной проверке и "-" при неуспешной.<br />
# При отсутствии регрессий и, при необходимости, после получения одобрения запроса от команды SecTeam (флажок sectime_verified меняется на "+") запрос отправляется на публикацию установкой флажка publishied в "?"<br />
# QA каждую пятницу публикует бюллетень с перечнем исправленных багов за истекшую неделю<br />
<br />
=== Команда поиска и устранения уязвимостей (SecTeam) ===<br />
# Подробности поиска уязвимостей описаны в документе [[Регламент по устранению уязвимостей]]<br />
# Список уязвимостей ведется на странице вики [http://wiki.rosalab.ru/ru/index.php/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:Security_Advisories Список уязвимостей] командой SecTeam.<br />
# Для каждой уязвимости из списка команда SecTeam выступает репортером и заводит баг<br />
# После того, как сборщики соберут исправленные пакеты и QA установить флажок secteam_verified в "?", SecTeam проверяет исправление уязвимости<br />
# Дополнительно могут проверяться и запросы с исправлениями уязвимостей, сделанные и не участниками команды SecTeam<br />
# При успешной проверке secteam_verified устанавливается в "+"<br />
<br />
=== Публикатор ===<br />
# Публикатор получает запрос на обновление после его одобрения командами QA и (если он содержит исправления уязвимостей) SecTeam<br />
# Публикатор отвечает за доступность пакетов обновлений для пользователей в репозиториях на зеркалах дистрибутива<br />
# Задача публикатора - проверка контроля целостности/замкнутости репозиториев после публикации, оценка возможного неправильного взаимодействия различных компонентов с учетом внесенных обновлением изменений, оценка корректности сборки пакета с учетом принятых в дистрибутиве правил сборки<br />
# После успешной публикации флажок "publishied" устанавливается в "+" и запрос на обновление считается полностью закрытым.<br />
# При нахождении ошибок в отправленном на публикацию обновлении, публикатор может установить флажок publishied в "-", таким образом отклонив публикацию, при этом он должен написать в запросе на обновление причину<br />
# Публикатор должен опубликовать направленный на публикацию пакет или отклонить его публикацию в течение 48 часов (за исключением выходных и праздничных дней)<br />
<br />
[[Категория:Регламенты ROSA]]</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_%D0%B2_%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%BD%D1%8B%D1%85_%D1%80%D0%B5%D0%BF%D0%BE%D0%B7%D0%B8%D1%82%D0%BE%D1%80%D0%B8%D1%8F%D1%85_ROSA_Linux&diff=18656
Регламент обновления пакетов в основных репозиториях ROSA Linux
2020-04-29T15:00:04Z
<p>Vladimir.potapov: /* Мейнтейнеры */</p>
<hr />
<div>=== Применимость ===<br />
Настоящий регламент описывает порядок добавления и исправления пакетов в репозиториях ROSA при взаимодействии пяти команд:<br />
# Команды репортеров, сообщающих об ошибках и уязвимостях в пакетной базе и выступающих с предложениями обновления пакетов<br />
# Команды сборщиков (мейнтейнеров), собирающих пакеты с новыми версиями программ и исправлениями ошибок и уязвимостей<br />
# Команды контроля качества (QA), контролирующих работоспособность исправленных пакетов и всей системы в целом после обновления<br />
# Команда контроля уязвимостей (SecTeam), отслеживающих текущие уязвимости дистрибутива и корректность исправления этих уязвимостей сборщиками<br />
# Публикатора, задачи которого - доступность исправленных пакетов на зеркалах дистрибутива, контроль целостности/замкнутости репозиториев после публикации, а также качества сборки самих пакетов (соответствие политикам сборки, принятым в дистрибутиве и т.п.)<br />
<br />
Данный порядок относится к работе с основными репозиториями ROSA Linux, за исключением репозитория сообщества ROSA Fresh (contrib) где контроль качества не производится.<br />
<br />
=== Общий порядок обновления ===<br />
# Общий порядок адресации каждого запроса на обновление - <br />
Репортеры (в т.ч. из SecTeam) -> Cборщики -> QA & SecTeam -> Публикатор<br />
# Допустимо совмещение ролей "репортер", "сборщик" и "публикатор", но недопустима ситуация, когда человек проверяет результаты своей сборки и публикует их. <br />
# Вся работа по обновлению пакетов происходит с помощью специально созданных в багзилле ROSA Linux багов - запросов на обновление<br />
<br />
=== Репортеры ===<br />
# Репортеры заводят в багзилле баги, обосновывающие необходимость исправления или добавления, с описанием ошибки, кодом уязвимости или необходимым им новым функционалом.<br />
# Альтернативным путем создания запроса на изменение пакетов в репозиториях для репортеров является пул-реквест в системе сборки ABF.<br />
# Репортеры являются заказчиками исправления, т.е. контролируют весь его процесс до попадания в репозитории.<br />
<br />
=== Сборщики ===<br />
# Сборщики получают информацию о багах от репортеров через почтовую рассылку багзиллы<br />
# Пакеты обновляются на основании заведенного в [http://bugs.rosalinux.ru багзилле] бага, называемого далее "запросом на обновление"<br />
# В комментариях к запросу на обновление указываются ссылки на контейнеры с собранным для указанной платформы обновлением пакета и advisory - написанное по-английски обоснование обновления (например выход новой версии, исправление уязвимости)<br />
# После того, как закончено формирование запроса на обновление, он отправляется на контроль качества команде QA установкой флажка qa_verified в знак вопроса "?"<br />
<br />
=== Мейнтейнеры ===<br />
Мейнтейнер (сопровождающий) - совмещает в себе функции сборщика, репортера и ответственного за функциональность пакета. Мейнтейнер отслеживает его изменения, исправляет уязвимости и ошибки.<br />
# Если какой-то пакет имеет мейнтейнера, это должно быть прописано на abf<br />
# В пакет с указанным мейнтейнером имеет право вносить правки только сам мейнтейнер, остальные могут только предлагать правки, например с помощью пул-реквестов<br />
# Пул-реквесты или другие предложения на обновление пакета должны рассматриваться мейнтейнером в течение недели, а критические - в течение 48 часов (за возможным исключением выходных и праздничных дней)<br />
# 0-day уязвимости в своем пакете мейнтейнер должен исправлять и передавать на тестирование в течение 48 часов (за возможным исключением выходных и праздничных дней), критические - в течение недели<br />
# Баги в пакете, имеющем мейнтейнера, должны им рассматриваться (исправляться, отменяться или хотя бы комментироваться) в течение двух недель после назначения.<br />
# Мейнтейнер пакета при необходимости самостоятельно взаимодействует с разработчиками пакетируемого ПО для исправления найденных службой QA или другими репортерами ошибок.<br />
# В случае, если мейнтейнер не выдерживает указанные сроки по реагированию на предложения правок, исправления уязвимостей и ошибок, они могут быть исправлены другим сборщиком по процедуре, аналогичной для пакета, не имеющего мейнтейнера<br />
<br />
=== Команда контроля качества (QA) ===<br />
# Команда QA получает запросы с установленным сборщиками флажком qa_verified<br />
# Команда QA проводит тестирование пакетов, используя [[Регламент тестирования]]<br />
# Если обновление содержит исправления уязвимостей, устанавливается флажок sectime_verified в "?" для параллельной проверки корректности исправления уязвимостей командой SecTeam<br />
# После проверки отсутствия регрессий функциональности у собранного пакета команда QA ставит флаг QA_verified "+" при успешной проверке и "-" при неуспешной.<br />
# При отсутствии регрессий и, при необходимости, после получения одобрения запроса от команды SecTeam (флажок sectime_verified меняется на "+") запрос отправляется на публикацию установкой флажка publishied в "?"<br />
# QA каждую пятницу публикует бюллетень с перечнем исправленных багов за истекшую неделю<br />
<br />
=== Команда поиска и устранения уязвимостей (SecTeam) ===<br />
# Подробности поиска уязвимостей описаны в документе [[Регламент по устранению уязвимостей]]<br />
# Список уязвимостей ведется на странице вики [http://wiki.rosalab.ru/ru/index.php/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:Security_Advisories Список уязвимостей] командой SecTeam.<br />
# Для каждой уязвимости из списка команда SecTeam выступает репортером и заводит баг<br />
# После того, как сборщики соберут исправленные пакеты и QA установить флажок secteam_verified в "?", SecTeam проверяет исправление уязвимости<br />
# Дополнительно могут проверяться и запросы с исправлениями уязвимостей, сделанные и не участниками команды SecTeam<br />
# При успешной проверке secteam_verified устанавливается в "+"<br />
<br />
=== Публикатор ===<br />
# Публикатор получает запрос на обновление после его одобрения командами QA и (если он содержит исправления уязвимостей) SecTeam<br />
# Публикатор отвечает за доступность пакетов обновлений для пользователей в репозиториях на зеркалах дистрибутива<br />
# Задача публикатора - проверка контроля целостности/замкнутости репозиториев после публикации, оценка возможного неправильного взаимодействия различных компонентов с учетом внесенных обновлением изменений, оценка корректности сборки пакета с учетом принятых в дистрибутиве правил сборки<br />
# После успешной публикации флажок "publishied" устанавливается в "+" и запрос на обновление считается полностью закрытым.<br />
# При нахождении ошибок сборки пакетов, публикатор может установить флажок publishied в "-", таким образом отклонив публикацию, при этом он должен написать в запросе на обновление причину<br />
# Публикатор должен опубликовать направленный на публикацию пакет или отклонить его публикацию в течение 48 часов (за исключением выходных и праздничных дней)<br />
<br />
[[Категория:Регламенты ROSA]]</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F&diff=18655
Регламент тестирования
2020-04-29T14:53:56Z
<p>Vladimir.potapov: /* Срок тестирования */</p>
<hr />
<div>[[Category:Регламенты ROSA]]<br />
<br />
=== Политика ===<br />
QA, наряду с мейнтейнерами пакетов отвечает за стабильность и функциональность установленного у пользователей дистрибутива при его обновлениях. <br />
<br />
До установки обновлений дистрибутив работает. Любое обновление — риск его обрушить.<br />
Поэтому политика QA обязана быть консервативной и даже несколько параноидальной — при малейших сомнениях должны назначаться дополнительные проверки, пакеты должны отклоняться, направляться на пересборку.<br />
<br />
Политика QA вступает в конфликт с интересами сборщиков пакетов, желающих быстрее увидеть в репозиториях исправленную версию — конфликт этот должен быть конструктивным, приводящим к непрерывному повышению функциональности и стабильности дистрибутива.<br />
<br />
==== Классификация обновлений по степени опасности ====<br />
<blockquote><br />
Меня не интересуют их намерения, меня интересуют их возможности — © Отто Фон Бисмарк<br />
</blockquote><br />
<br />
Классификация исходит из максимально возможного урона (полный отказ функционирования компонента), который может нанести устанавливаемое обновление. Чем выше степень опасности, тем более тщательным должно быть тестирование.<br />
<br />
;0: Критические обновления. Ядро, файловая система, система прав доступа, скрипты загрузки, <tt>systemd</tt>, <tt>glibc</tt>, <tt>dracut</tt>, <tt>grub</tt>, <tt>bash</tt> и прочие основные вещи, если удалить которые система не загрузится даже в консоли.<br />
;1: Обновления драйверов устройств, т.е. те же критические обновления, но актуальные не для всех пользователей. <br />
;2: Обновления сетевых компонентов: NetworkManager, сетевых скриптов, системы сетевой инициализации и системы обновлений. Они опасны тем, что если сеть упадет, пользователю без сети будет затруднительно получить исправленный пакет, когда мы его выпустим и установить обновление. <br />
;3: Обновления графических компонент и скриптов — X-ов, менеджера входа, графических библиотек, драйверов, '''perl, python''' — то, без чего невозможен вход в систему в графическом режиме. Т.к. обновление системы, при наличии сети, возможно и не в графике - класс опасности обновлений не самый высокий<br />
;4: Обновление пользовательских пакетов, установленных по-умолчанию в системе. Эти пакеты стоят практически у всех и их ошибки будут влиять на максимальное количество пользователей, однако они могут быть оперативно исправлены потому класс опасности не очень высокий. Туда же нужно отнести популярные программы не входящие в поставку — <tt>gimp</tt>, <tt>inkscape</tt>, <tt>audacity</tt>, <tt>vlc</tt>, <tt>kdenive</tt>, <tt>opera</tt>, <tt>chromium-browser</tt>, <tt>skype</tt>.<br />
;5: Обновление прочих пользовательских пакетов. Они затронут только тех, у кого эти программы стоят.<br />
;6: Обновление пакетов, необходимых только для сборки дистрибутива или работы с abf. Почти никому кроме нас они не интересны, потому класс опасности самый низкий.<br />
<br />
==== Задача ====<br />
* Главная задача QA — поиск регрессий, то есть таких изменений в дистрибутиве, которые уменьшают его функциональность по сравнению с предыдущим состоянием.<br />
* Также задачей QA является внесение в багзиллу всех найденных в процессе тестирования ошибок, не относящихся к регрессиям.<br />
<br />
==== Общие положения ====<br />
* Запрос на обновление пишется в багзилле <br />
* Все сообщения пишутся на английском языке.<br />
* Порядок принятие запросов на тестирование командой QA в общем случае — в порядке возрастания номеров багов, возможны исключения, связанные со срочностью или трудностями в тестировании определенных пакетов.<br />
* Список запросов на обновление можно открыть по ссылке http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=qa_verified%3F&o1=substring&list_id=38774<br />
<br />
==== Срок тестирования ====<br />
* Срок тестирования пакета — '''одна неделя''', за это время служба QA должня проверить пакет и вынести заключение. Срок тестирования может быть увеличен при необходимости тестирования внешними тестерами на отсутствующих у службы QA аппаратно-программных конфигурациях, в этом случае в запросе на обновление задержка должна быть обоснована службой QA.<br />
* Для пакета, который нужно проверить очень срочно, сборщик должен установить приоритет <tt>Highest Critical</tt>, чтобы он выделялся красным цветом в списке. Такие пакеты рассматриваются в течение '''48 часов''' (за возможным исключением выходных и праздничных дней).<br />
* Норма выработки на одного тестера QA - 20 одобренных запросов в неделю, обычно ошибки содержат 10-20% запросов, так что тестер QA в среднем обрабатывает 5 запросов в день.<br />
<br />
=== Процедура тестирования ===<br />
<br />
==== Требования к запросу на обновление ====<br />
# QA Team тестирует пакеты-кандидаты на добавление в репозитории <tt>main/updates, non-free/updates и restricted/updates</tt>.<br />
# Пакет должен быть собран в общедоступном репозитории на ABF (не <tt>_personal</tt>).<br />
# Для архитектурно-зависимых пакетов должны быть представлены все поддерживаемые платформой архитектуры<br />
# Описание обновления должно содержать все изменения, которые нужно протестировать.<br />
При несоответствии запроса на обновление этим требованиям необходимо сообщить об этом инициатору запроса с помощью комментария.<br />
В случае, если до пятницы запрос не исправлен согласно требованиям, он отклоняется.<br />
<br />
==== Тестирование установки пакетов ====<br />
# Система перед тестовым обновлением должна соответствовать стандартным репозиториям, с подключенными тестингами. Это можно проверить запуском <tt>urpm-reposync</tt> из пакета <tt>urpm-tools</tt><br />
# Пакеты для тестирования устанавливаются и в графическом, и в текстовом режиме.<br />
## Репозиторий подключается как репозиторий с обновлениями.<br />
## Запускается стандартная процедура обновления.<br />
# Для пакетов, установленных в системе по-умолчанию, проверяется их обновление.<br />
# Для пакетов, не установленных в системе, проверяется как их обновление, так и первоначальная установка при подключенных тестовых контейнерах.<br />
# Установка пакетов проверяется для обеих архитектур. Так как ошибки установки не обычно не зависят от архитектуры, обычно достаточно проверить на одной архитектуре установку в графическом режиме, а на другой — обновление в текстовом, или наоборот.<br />
<br />
При ошибках установки или обновления пакета необходимо сообщить об этом инициатору запроса с помощью комментария. В случае, если до пятницы ошибка установки не исправлена, запрос отклоняется.<br />
<br />
==== Тестирование на функционирование и устойчивость системы после обновления ====<br />
При тестировании системы проверяется:<br />
# Стабильность и внешний вид обновленной системы после перезагрузки.<br />
# Стабильность и внешний вид обновленной системы после пробуждения из спящего режима. Тестирование стабильности и производительности может проводиться, например, с помощью теста Unigine Valley под wine и тестом браузера https://webglsamples.org/aquarium/aquarium.html<br />
# Ошибки загрузки демонов, например, с помощью <tt>systemctl | grep failed</tt>.<br />
# Ошибки непрерывного роста файла <tt>.xsession-errors</tt>.<br />
# Журнал ошибок, командами '''journalctl -b |grep fail''' и '''journalctl -b |grep error''' (не должно быть новых ошибок, если они появились - нужно найти связанное с ошибкой обновление и написать инициатору)<br />
# Работа менеджера обновлений — дальнейшее обновление пакетов.<br />
# Установка и удаление dkms-модулей (например, установкой проприетарных драйверов с последующим откатом на свободные)<br />
# Сохранением загрузчиком определения других операционных систем, установленных на тестовом компьютере<br />
# Сохранение даты-времени на тестируемой машине после перезагрузки и пробуждения из спящего режима<br />
# Работа системы поиска по содержимому офисных файлов<br />
<br />
При ошибках функционирования или устойчивости системы, связанной с обновлением, необходимо сообщить об этом инициатору запроса с помощью комментария. <br />
В случае, если до пятницы ошибка не исправлена, запрос отклоняется.<br />
<br />
==== Тестирование запуска и работы связанных с обновлением приложений ====<br />
Проверяются:<br />
# Тестирование запуска и простейших операций со связанными с тестируемым пакетом программами, рекомендуется контроль сообщений при запуске программы из консоли.<br />
# Связанные с библиотеками из проверяемого пакета программы легче всего установить, попробовав удалить пакет с помощью <tt>urpme</tt> (для установленных в системе программ) или <tt>urpmq --whatrequires</tt> (для всех программ из подключенных репозиториев).<br />
# Изменения в интерфейсах обновляемых библиотек и, соответственно, необходимость перекомпиляции связанных пакетов с помощью сервиса https://abi-laboratory.pro/tracker/<br />
# Для пакетов, предоставляющих библиотеки, проверяются использующие эти библиотеки приложения из main, их можно определить командой <tt>urpmq --whatrequires <названиепакета></tt><br />
# Регрессии в локализации графического интерфейса и страниц справки.<br />
# Для тестирования браузеров в дополнение к https://webglsamples.org/aquarium/aquarium.html применяются.<br />
## Тест html5 https://html5test.com/ (сравнить результат до и после обновления, не должно быть регресса)<br />
## Почтовые онлайновые сервисы http://mail.yandex.ru http://mail.google.com<br />
## Яндекс и гугл-карты https://yandex.ru/maps/-/CVTQITy0 https://www.google.ru/maps/@52.2609339,104.3096872,15z?hl=ru<br />
## xml|xsl трансляцию и кодировки на http://base.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=160129;div=LAW;rnd=0.4700782325977544 и<br />
## Воспроизведение видео http://techslides.com/sample-webm-ogg-and-mp4-video-files-for-html5/ <br />
## Воспроизведение [http://youtu.be/37l7P5V1eXU видео с youtube]<br />
## Работа флэша на примере игры [http://vseigru.net/igry-zombi/2541-igra-zombi-protiv-rastenij.html Растения против зомби] и [http://kino.sputnik.ru/films/ivan+vasilyevich+menyayet+professiyu+1973]<br />
## Уязвимости SSL с помощью https://www.ssllabs.com/ssltest/viewMyClient.html<br />
## Тестирование печати<br />
## Тестирование установки браузера по-умолчанию из настроек<br />
<br />
В случае:<br />
# нахождения регрессии функционала или локализации, о них сообщается инициатору запроса в комментариях к запросу на обновление. <br />
# отсутствия до пятницы исправления найденной QA регрессии или обоснования мейнтейнером пакета невозможности исправления - запрос отклоняется.<br />
# если пакет не имеет постоянного мейнтейнера и собирается случайным сборщиком, QA отвечает за функциональность пакета и может заблокировать обновление при её регрессии<br />
# нахождения ошибок (не регрессий!) - заводится новый баг, его номер указывается в запросе на обновление.<br />
<br />
==== Тестирование изменений ====<br />
* Применяется при тестировании обновлений, изменяющих внешний вид или поведение системы.<br />
<br />
Включает себя<br />
# Воспроизведение особенностей внешнего вида или поведения системы ДО исправления.<br />
# Воспроизведение измененных обновлений особенностей по их описанию.<br />
<br />
Например, если в advisory сказано, что «вышла новая версия программы» при тестировании изменений нужно, как минимум, убедиться что версия изменилась.<br />
<br />
В случае если не все описанные изменения действительно присутствуют в тестируемом пакете, пакет принимается и в итоговый отчет (Advisory), вносятся только реально проведенные изменения.<br />
В случае значительного отклонения запрошенных и полученных изменений пакет может быть отклонен.<br />
<br />
==== Расширенное тестирование ====<br />
# Расширенное тестирование проводится добровольцами с помощью репозиториев testing, соответствующих основным репозиториям. <br />
# В течение недели (понедельник-четверг) все проверяемые QA обновления, кроме срочных, отправляются в тестинг, при этом в багзилле ставится статус verified и пишется The update is sent to expanded testing<br />
# В пятницу, руководитель QA:<br />
## Еще раз контролирует, все ли пакеты направлены в тестинг-репозитории, при помощи отключения источников-контейнеров и выполнения программы '''urpm-reposync''' с включенными тестингами. Результатом выполнения команды должно быть отсутствие пакетов на синхронизацию<br />
## Проверяет, дошли ли обновления до зеркал<br />
## Контролирует возможность обновления до тестингов с момента предыдущего релиза платформы путем установки релизного образа и его обновления с подключенными тестингами <br />
## Обновляет до тестингов системы на всех доступных тестовых стендах и проверяет их на устойчивость<br />
## На форуме и в сообществе вконтакте объявляет "пятничное тестирование", к нему выпускает бюллетень с полным списком обновлений и методикой их тестирования.<br />
# В понедельник руководитель QA читает отзывы пользователей и по их итогам, а также по итогам эксплуатации тестовых стендов в выходные дни, обрабатывает запросы на обновление и передает их на публикацию (или отклоняет)<br />
<br />
=== Завершение тестирования ===<br />
<br />
==== Положительный результат тестирования ====<br />
# По окончании тестирования при его успехе ставится индикатор успешного тестирования QA «+» и пишется отчет (Advisory), содержащий:<br />
## Название пакета с исходниками (src.rpm).<br />
## Версию пакета.<br />
## Отчет о тестировании (advisory).<br />
## Надпись «QA verified».<br />
# Если пакет содержит изменения, связанные с секретностью или же собран не сотрудником Росы — посылается запрос Secure team (взводится флажок secteam_verified «?»).<br />
# Если тестирование secure не нужно, пакет передается на публикацию (взводится соответствующий published «?»).<br />
# В случае успешного тестирования пакет может быть оставлен в системе. В случае ошибок систему нужно привести к первоначальному виду с помощью деинсталляции пакета или утилиты <tt>urpm-reposync</tt> из <tt>urpm-repotools</tt>.<br />
<br />
==== Отрицательный результат тестирования ====<br />
# При отклонении пакета ставится индикатор отклонения QA «-»,<br />
# В комментариях пишется причина отклонения запроса и в конце комментария добавляется «QA Denied».<br />
# При отрицательном результате тестирования сборщик может выложить исправленные контейнеры в тот же запрос и снова установить «?» в «qa_requested».</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_%D0%B2_%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%BD%D1%8B%D1%85_%D1%80%D0%B5%D0%BF%D0%BE%D0%B7%D0%B8%D1%82%D0%BE%D1%80%D0%B8%D1%8F%D1%85_ROSA_Linux&diff=18654
Регламент обновления пакетов в основных репозиториях ROSA Linux
2020-04-29T14:53:07Z
<p>Vladimir.potapov: /* Мейнтейнеры */</p>
<hr />
<div>=== Применимость ===<br />
Настоящий регламент описывает порядок добавления и исправления пакетов в репозиториях ROSA при взаимодействии пяти команд:<br />
# Команды репортеров, сообщающих об ошибках и уязвимостях в пакетной базе и выступающих с предложениями обновления пакетов<br />
# Команды сборщиков (мейнтейнеров), собирающих пакеты с новыми версиями программ и исправлениями ошибок и уязвимостей<br />
# Команды контроля качества (QA), контролирующих работоспособность исправленных пакетов и всей системы в целом после обновления<br />
# Команда контроля уязвимостей (SecTeam), отслеживающих текущие уязвимости дистрибутива и корректность исправления этих уязвимостей сборщиками<br />
# Публикатора, задачи которого - доступность исправленных пакетов на зеркалах дистрибутива, контроль целостности/замкнутости репозиториев после публикации, а также качества сборки самих пакетов (соответствие политикам сборки, принятым в дистрибутиве и т.п.)<br />
<br />
Данный порядок относится к работе с основными репозиториями ROSA Linux, за исключением репозитория сообщества ROSA Fresh (contrib) где контроль качества не производится.<br />
<br />
=== Общий порядок обновления ===<br />
# Общий порядок адресации каждого запроса на обновление - <br />
Репортеры (в т.ч. из SecTeam) -> Cборщики -> QA & SecTeam -> Публикатор<br />
# Допустимо совмещение ролей "репортер", "сборщик" и "публикатор", но недопустима ситуация, когда человек проверяет результаты своей сборки и публикует их. <br />
# Вся работа по обновлению пакетов происходит с помощью специально созданных в багзилле ROSA Linux багов - запросов на обновление<br />
<br />
=== Репортеры ===<br />
# Репортеры заводят в багзилле баги, обосновывающие необходимость исправления или добавления, с описанием ошибки, кодом уязвимости или необходимым им новым функционалом.<br />
# Альтернативным путем создания запроса на изменение пакетов в репозиториях для репортеров является пул-реквест в системе сборки ABF.<br />
# Репортеры являются заказчиками исправления, т.е. контролируют весь его процесс до попадания в репозитории.<br />
<br />
=== Сборщики ===<br />
# Сборщики получают информацию о багах от репортеров через почтовую рассылку багзиллы<br />
# Пакеты обновляются на основании заведенного в [http://bugs.rosalinux.ru багзилле] бага, называемого далее "запросом на обновление"<br />
# В комментариях к запросу на обновление указываются ссылки на контейнеры с собранным для указанной платформы обновлением пакета и advisory - написанное по-английски обоснование обновления (например выход новой версии, исправление уязвимости)<br />
# После того, как закончено формирование запроса на обновление, он отправляется на контроль качества команде QA установкой флажка qa_verified в знак вопроса "?"<br />
<br />
=== Мейнтейнеры ===<br />
Мейнтейнер (сопровождающий) - совмещает в себе функции сборщика, репортера и ответственного за функциональность пакета. Мейнтейнер отслеживает его изменения, исправляет уязвимости и ошибки.<br />
# Если какой-то пакет имеет мейнтейнера, это должно быть прописано на abf<br />
# В пакет с указанным мейнтейнером имеет право вносить правки только сам мейнтейнер, остальные могут только предлагать правки, например с помощью пул-реквестов<br />
# Пул-реквесты или другие предложения на обновление пакета должны рассматриваться мейнтейнером в течение недели, а критические - в течение 48 часов (за возможным исключением выходных и праздничных дней)<br />
# 0-day уязвимости в своем пакете мейнтейнер должен исправлять и передавать на тестирование в течение 48 часов (за возможным исключением выходных и праздничных дней), критические - в течение недели<br />
# Баги в пакете, имеющем мейнтейнера, должны им рассматриваться (исправляться, отменяться или хотя бы комментироваться) в течение двух недель после назначения.<br />
# В случае, если мейнтейнер не выдерживает указанные сроки по реагированию на предложения правок, исправления уязвимостей и ошибок, они могут быть исправлены другим сборщиком по процедуре, аналогичной для пакета, не имеющего мейнтейнера<br />
<br />
=== Команда контроля качества (QA) ===<br />
# Команда QA получает запросы с установленным сборщиками флажком qa_verified<br />
# Команда QA проводит тестирование пакетов, используя [[Регламент тестирования]]<br />
# Если обновление содержит исправления уязвимостей, устанавливается флажок sectime_verified в "?" для параллельной проверки корректности исправления уязвимостей командой SecTeam<br />
# После проверки отсутствия регрессий функциональности у собранного пакета команда QA ставит флаг QA_verified "+" при успешной проверке и "-" при неуспешной.<br />
# При отсутствии регрессий и, при необходимости, после получения одобрения запроса от команды SecTeam (флажок sectime_verified меняется на "+") запрос отправляется на публикацию установкой флажка publishied в "?"<br />
# QA каждую пятницу публикует бюллетень с перечнем исправленных багов за истекшую неделю<br />
<br />
=== Команда поиска и устранения уязвимостей (SecTeam) ===<br />
# Подробности поиска уязвимостей описаны в документе [[Регламент по устранению уязвимостей]]<br />
# Список уязвимостей ведется на странице вики [http://wiki.rosalab.ru/ru/index.php/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:Security_Advisories Список уязвимостей] командой SecTeam.<br />
# Для каждой уязвимости из списка команда SecTeam выступает репортером и заводит баг<br />
# После того, как сборщики соберут исправленные пакеты и QA установить флажок secteam_verified в "?", SecTeam проверяет исправление уязвимости<br />
# Дополнительно могут проверяться и запросы с исправлениями уязвимостей, сделанные и не участниками команды SecTeam<br />
# При успешной проверке secteam_verified устанавливается в "+"<br />
<br />
=== Публикатор ===<br />
# Публикатор получает запрос на обновление после его одобрения командами QA и (если он содержит исправления уязвимостей) SecTeam<br />
# Публикатор отвечает за доступность пакетов обновлений для пользователей в репозиториях на зеркалах дистрибутива<br />
# Задача публикатора - проверка контроля целостности/замкнутости репозиториев после публикации, оценка возможного неправильного взаимодействия различных компонентов с учетом внесенных обновлением изменений, оценка корректности сборки пакета с учетом принятых в дистрибутиве правил сборки<br />
# После успешной публикации флажок "publishied" устанавливается в "+" и запрос на обновление считается полностью закрытым.<br />
# При нахождении ошибок сборки пакетов, публикатор может установить флажок publishied в "-", таким образом отклонив публикацию, при этом он должен написать в запросе на обновление причину<br />
# Публикатор должен опубликовать направленный на публикацию пакет или отклонить его публикацию в течение 48 часов (за исключением выходных и праздничных дней)<br />
<br />
[[Категория:Регламенты ROSA]]</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_%D0%B2_%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%BD%D1%8B%D1%85_%D1%80%D0%B5%D0%BF%D0%BE%D0%B7%D0%B8%D1%82%D0%BE%D1%80%D0%B8%D1%8F%D1%85_ROSA_Linux&diff=18653
Регламент обновления пакетов в основных репозиториях ROSA Linux
2020-04-29T14:52:18Z
<p>Vladimir.potapov: /* Мейнтейнеры */</p>
<hr />
<div>=== Применимость ===<br />
Настоящий регламент описывает порядок добавления и исправления пакетов в репозиториях ROSA при взаимодействии пяти команд:<br />
# Команды репортеров, сообщающих об ошибках и уязвимостях в пакетной базе и выступающих с предложениями обновления пакетов<br />
# Команды сборщиков (мейнтейнеров), собирающих пакеты с новыми версиями программ и исправлениями ошибок и уязвимостей<br />
# Команды контроля качества (QA), контролирующих работоспособность исправленных пакетов и всей системы в целом после обновления<br />
# Команда контроля уязвимостей (SecTeam), отслеживающих текущие уязвимости дистрибутива и корректность исправления этих уязвимостей сборщиками<br />
# Публикатора, задачи которого - доступность исправленных пакетов на зеркалах дистрибутива, контроль целостности/замкнутости репозиториев после публикации, а также качества сборки самих пакетов (соответствие политикам сборки, принятым в дистрибутиве и т.п.)<br />
<br />
Данный порядок относится к работе с основными репозиториями ROSA Linux, за исключением репозитория сообщества ROSA Fresh (contrib) где контроль качества не производится.<br />
<br />
=== Общий порядок обновления ===<br />
# Общий порядок адресации каждого запроса на обновление - <br />
Репортеры (в т.ч. из SecTeam) -> Cборщики -> QA & SecTeam -> Публикатор<br />
# Допустимо совмещение ролей "репортер", "сборщик" и "публикатор", но недопустима ситуация, когда человек проверяет результаты своей сборки и публикует их. <br />
# Вся работа по обновлению пакетов происходит с помощью специально созданных в багзилле ROSA Linux багов - запросов на обновление<br />
<br />
=== Репортеры ===<br />
# Репортеры заводят в багзилле баги, обосновывающие необходимость исправления или добавления, с описанием ошибки, кодом уязвимости или необходимым им новым функционалом.<br />
# Альтернативным путем создания запроса на изменение пакетов в репозиториях для репортеров является пул-реквест в системе сборки ABF.<br />
# Репортеры являются заказчиками исправления, т.е. контролируют весь его процесс до попадания в репозитории.<br />
<br />
=== Сборщики ===<br />
# Сборщики получают информацию о багах от репортеров через почтовую рассылку багзиллы<br />
# Пакеты обновляются на основании заведенного в [http://bugs.rosalinux.ru багзилле] бага, называемого далее "запросом на обновление"<br />
# В комментариях к запросу на обновление указываются ссылки на контейнеры с собранным для указанной платформы обновлением пакета и advisory - написанное по-английски обоснование обновления (например выход новой версии, исправление уязвимости)<br />
# После того, как закончено формирование запроса на обновление, он отправляется на контроль качества команде QA установкой флажка qa_verified в знак вопроса "?"<br />
<br />
=== Мейнтейнеры ===<br />
Мейнтейнер (сопровождающий) - совмещает в себе функции сборщика, репортера и ответственного за функциональность пакета. Мейнтейнер отслеживает его изменения, исправляет уязвимости и ошибки.<br />
# Если какой-то пакет имеет мейнтейнера, это должно быть прописано на abf<br />
# В пакет с указанным мейнтейнером имеет право вносить правки только сам мейнтейнер, остальные могут только предлагать правки, например с помощью пул-реквестов<br />
# Пул-реквесты или другие предложения на обновление пакета должны рассматриваться мейнтейнером в течение недели, а критические - в течение 48 часов (за возможным исключением выходных и праздничных дней)<br />
# 0-day уязвимости в своем пакете мейнтейнер должен исправлять и передавать на тестирование в течение 48 часов, критические - в течение недели<br />
# Баги в пакете, имеющем мейнтейнера, должны им рассматриваться (исправляться, отменяться или хотя бы комментироваться) в течение двух недель после назначения.<br />
# В случае, если мейнтейнер не выдерживает указанные сроки по реагированию на предложения правок, исправления уязвимостей и ошибок, они могут быть исправлены другим сборщиком по процедуре, аналогичной для пакета, не имеющего мейнтейнера<br />
<br />
=== Команда контроля качества (QA) ===<br />
# Команда QA получает запросы с установленным сборщиками флажком qa_verified<br />
# Команда QA проводит тестирование пакетов, используя [[Регламент тестирования]]<br />
# Если обновление содержит исправления уязвимостей, устанавливается флажок sectime_verified в "?" для параллельной проверки корректности исправления уязвимостей командой SecTeam<br />
# После проверки отсутствия регрессий функциональности у собранного пакета команда QA ставит флаг QA_verified "+" при успешной проверке и "-" при неуспешной.<br />
# При отсутствии регрессий и, при необходимости, после получения одобрения запроса от команды SecTeam (флажок sectime_verified меняется на "+") запрос отправляется на публикацию установкой флажка publishied в "?"<br />
# QA каждую пятницу публикует бюллетень с перечнем исправленных багов за истекшую неделю<br />
<br />
=== Команда поиска и устранения уязвимостей (SecTeam) ===<br />
# Подробности поиска уязвимостей описаны в документе [[Регламент по устранению уязвимостей]]<br />
# Список уязвимостей ведется на странице вики [http://wiki.rosalab.ru/ru/index.php/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:Security_Advisories Список уязвимостей] командой SecTeam.<br />
# Для каждой уязвимости из списка команда SecTeam выступает репортером и заводит баг<br />
# После того, как сборщики соберут исправленные пакеты и QA установить флажок secteam_verified в "?", SecTeam проверяет исправление уязвимости<br />
# Дополнительно могут проверяться и запросы с исправлениями уязвимостей, сделанные и не участниками команды SecTeam<br />
# При успешной проверке secteam_verified устанавливается в "+"<br />
<br />
=== Публикатор ===<br />
# Публикатор получает запрос на обновление после его одобрения командами QA и (если он содержит исправления уязвимостей) SecTeam<br />
# Публикатор отвечает за доступность пакетов обновлений для пользователей в репозиториях на зеркалах дистрибутива<br />
# Задача публикатора - проверка контроля целостности/замкнутости репозиториев после публикации, оценка возможного неправильного взаимодействия различных компонентов с учетом внесенных обновлением изменений, оценка корректности сборки пакета с учетом принятых в дистрибутиве правил сборки<br />
# После успешной публикации флажок "publishied" устанавливается в "+" и запрос на обновление считается полностью закрытым.<br />
# При нахождении ошибок сборки пакетов, публикатор может установить флажок publishied в "-", таким образом отклонив публикацию, при этом он должен написать в запросе на обновление причину<br />
# Публикатор должен опубликовать направленный на публикацию пакет или отклонить его публикацию в течение 48 часов (за исключением выходных и праздничных дней)<br />
<br />
[[Категория:Регламенты ROSA]]</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_%D0%B2_%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%BD%D1%8B%D1%85_%D1%80%D0%B5%D0%BF%D0%BE%D0%B7%D0%B8%D1%82%D0%BE%D1%80%D0%B8%D1%8F%D1%85_ROSA_Linux&diff=18652
Регламент обновления пакетов в основных репозиториях ROSA Linux
2020-04-29T14:41:46Z
<p>Vladimir.potapov: /* Публикатор */</p>
<hr />
<div>=== Применимость ===<br />
Настоящий регламент описывает порядок добавления и исправления пакетов в репозиториях ROSA при взаимодействии пяти команд:<br />
# Команды репортеров, сообщающих об ошибках и уязвимостях в пакетной базе и выступающих с предложениями обновления пакетов<br />
# Команды сборщиков (мейнтейнеров), собирающих пакеты с новыми версиями программ и исправлениями ошибок и уязвимостей<br />
# Команды контроля качества (QA), контролирующих работоспособность исправленных пакетов и всей системы в целом после обновления<br />
# Команда контроля уязвимостей (SecTeam), отслеживающих текущие уязвимости дистрибутива и корректность исправления этих уязвимостей сборщиками<br />
# Публикатора, задачи которого - доступность исправленных пакетов на зеркалах дистрибутива, контроль целостности/замкнутости репозиториев после публикации, а также качества сборки самих пакетов (соответствие политикам сборки, принятым в дистрибутиве и т.п.)<br />
<br />
Данный порядок относится к работе с основными репозиториями ROSA Linux, за исключением репозитория сообщества ROSA Fresh (contrib) где контроль качества не производится.<br />
<br />
=== Общий порядок обновления ===<br />
# Общий порядок адресации каждого запроса на обновление - <br />
Репортеры (в т.ч. из SecTeam) -> Cборщики -> QA & SecTeam -> Публикатор<br />
# Допустимо совмещение ролей "репортер", "сборщик" и "публикатор", но недопустима ситуация, когда человек проверяет результаты своей сборки и публикует их. <br />
# Вся работа по обновлению пакетов происходит с помощью специально созданных в багзилле ROSA Linux багов - запросов на обновление<br />
<br />
=== Репортеры ===<br />
# Репортеры заводят в багзилле баги, обосновывающие необходимость исправления или добавления, с описанием ошибки, кодом уязвимости или необходимым им новым функционалом.<br />
# Альтернативным путем создания запроса на изменение пакетов в репозиториях для репортеров является пул-реквест в системе сборки ABF.<br />
# Репортеры являются заказчиками исправления, т.е. контролируют весь его процесс до попадания в репозитории.<br />
<br />
=== Сборщики ===<br />
# Сборщики получают информацию о багах от репортеров через почтовую рассылку багзиллы<br />
# Пакеты обновляются на основании заведенного в [http://bugs.rosalinux.ru багзилле] бага, называемого далее "запросом на обновление"<br />
# В комментариях к запросу на обновление указываются ссылки на контейнеры с собранным для указанной платформы обновлением пакета и advisory - написанное по-английски обоснование обновления (например выход новой версии, исправление уязвимости)<br />
# После того, как закончено формирование запроса на обновление, он отправляется на контроль качества команде QA установкой флажка qa_verified в знак вопроса "?"<br />
<br />
=== Мейнтейнеры ===<br />
Мейнтейнер (сопровождающий) - совмещает в себе функции сборщика, репортера и ответственного за функциональность пакета. Мейнтейнер отслеживает его изменения, исправляет уязвимости и ошибки.<br />
# Если какой-то пакет имеет мейнтейнера, это должно быть прописано на abf<br />
# В пакет с указанным мейнтейнером имеет право вносить правки только сам мейнтейнер, остальные могут только предлагать правки, например с помощью пул-реквестов<br />
# Пул-реквесты или другие предложения на обновление пакета должны рассматриваться мейнтейнером в течение недели, а критические - в течение 48 часов<br />
# 0-day уязвимости в своем пакете мейнтейнер должен исправлять и передавать на тестирование в течение 48 часов, критические - в течение недели<br />
# Баги в пакете, имеющем мейнтейнера, должны им рассматриваться (исправляться, отменяться или хотя бы комментироваться) в течение двух недель после назначения.<br />
# В случае, если мейнтейнер не выдерживает указанные сроки по реагированию на предложения правок, исправления уязвимостей и ошибок, они могут быть исправлены другим сборщиком по процедуре, аналогичной для пакета, не имеющего мейнтейнера<br />
<br />
=== Команда контроля качества (QA) ===<br />
# Команда QA получает запросы с установленным сборщиками флажком qa_verified<br />
# Команда QA проводит тестирование пакетов, используя [[Регламент тестирования]]<br />
# Если обновление содержит исправления уязвимостей, устанавливается флажок sectime_verified в "?" для параллельной проверки корректности исправления уязвимостей командой SecTeam<br />
# После проверки отсутствия регрессий функциональности у собранного пакета команда QA ставит флаг QA_verified "+" при успешной проверке и "-" при неуспешной.<br />
# При отсутствии регрессий и, при необходимости, после получения одобрения запроса от команды SecTeam (флажок sectime_verified меняется на "+") запрос отправляется на публикацию установкой флажка publishied в "?"<br />
# QA каждую пятницу публикует бюллетень с перечнем исправленных багов за истекшую неделю<br />
<br />
=== Команда поиска и устранения уязвимостей (SecTeam) ===<br />
# Подробности поиска уязвимостей описаны в документе [[Регламент по устранению уязвимостей]]<br />
# Список уязвимостей ведется на странице вики [http://wiki.rosalab.ru/ru/index.php/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:Security_Advisories Список уязвимостей] командой SecTeam.<br />
# Для каждой уязвимости из списка команда SecTeam выступает репортером и заводит баг<br />
# После того, как сборщики соберут исправленные пакеты и QA установить флажок secteam_verified в "?", SecTeam проверяет исправление уязвимости<br />
# Дополнительно могут проверяться и запросы с исправлениями уязвимостей, сделанные и не участниками команды SecTeam<br />
# При успешной проверке secteam_verified устанавливается в "+"<br />
<br />
=== Публикатор ===<br />
# Публикатор получает запрос на обновление после его одобрения командами QA и (если он содержит исправления уязвимостей) SecTeam<br />
# Публикатор отвечает за доступность пакетов обновлений для пользователей в репозиториях на зеркалах дистрибутива<br />
# Задача публикатора - проверка контроля целостности/замкнутости репозиториев после публикации, оценка возможного неправильного взаимодействия различных компонентов с учетом внесенных обновлением изменений, оценка корректности сборки пакета с учетом принятых в дистрибутиве правил сборки<br />
# После успешной публикации флажок "publishied" устанавливается в "+" и запрос на обновление считается полностью закрытым.<br />
# При нахождении ошибок сборки пакетов, публикатор может установить флажок publishied в "-", таким образом отклонив публикацию, при этом он должен написать в запросе на обновление причину<br />
# Публикатор должен опубликовать направленный на публикацию пакет или отклонить его публикацию в течение 48 часов (за исключением выходных и праздничных дней)<br />
<br />
[[Категория:Регламенты ROSA]]</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F&diff=18651
Регламент тестирования
2020-04-29T14:16:36Z
<p>Vladimir.potapov: /* Тестирование на функционирование и устойчивость системы после обновления */</p>
<hr />
<div>[[Category:Регламенты ROSA]]<br />
<br />
=== Политика ===<br />
QA, наряду с мейнтейнерами пакетов отвечает за стабильность и функциональность установленного у пользователей дистрибутива при его обновлениях. <br />
<br />
До установки обновлений дистрибутив работает. Любое обновление — риск его обрушить.<br />
Поэтому политика QA обязана быть консервативной и даже несколько параноидальной — при малейших сомнениях должны назначаться дополнительные проверки, пакеты должны отклоняться, направляться на пересборку.<br />
<br />
Политика QA вступает в конфликт с интересами сборщиков пакетов, желающих быстрее увидеть в репозиториях исправленную версию — конфликт этот должен быть конструктивным, приводящим к непрерывному повышению функциональности и стабильности дистрибутива.<br />
<br />
==== Классификация обновлений по степени опасности ====<br />
<blockquote><br />
Меня не интересуют их намерения, меня интересуют их возможности — © Отто Фон Бисмарк<br />
</blockquote><br />
<br />
Классификация исходит из максимально возможного урона (полный отказ функционирования компонента), который может нанести устанавливаемое обновление. Чем выше степень опасности, тем более тщательным должно быть тестирование.<br />
<br />
;0: Критические обновления. Ядро, файловая система, система прав доступа, скрипты загрузки, <tt>systemd</tt>, <tt>glibc</tt>, <tt>dracut</tt>, <tt>grub</tt>, <tt>bash</tt> и прочие основные вещи, если удалить которые система не загрузится даже в консоли.<br />
;1: Обновления драйверов устройств, т.е. те же критические обновления, но актуальные не для всех пользователей. <br />
;2: Обновления сетевых компонентов: NetworkManager, сетевых скриптов, системы сетевой инициализации и системы обновлений. Они опасны тем, что если сеть упадет, пользователю без сети будет затруднительно получить исправленный пакет, когда мы его выпустим и установить обновление. <br />
;3: Обновления графических компонент и скриптов — X-ов, менеджера входа, графических библиотек, драйверов, '''perl, python''' — то, без чего невозможен вход в систему в графическом режиме. Т.к. обновление системы, при наличии сети, возможно и не в графике - класс опасности обновлений не самый высокий<br />
;4: Обновление пользовательских пакетов, установленных по-умолчанию в системе. Эти пакеты стоят практически у всех и их ошибки будут влиять на максимальное количество пользователей, однако они могут быть оперативно исправлены потому класс опасности не очень высокий. Туда же нужно отнести популярные программы не входящие в поставку — <tt>gimp</tt>, <tt>inkscape</tt>, <tt>audacity</tt>, <tt>vlc</tt>, <tt>kdenive</tt>, <tt>opera</tt>, <tt>chromium-browser</tt>, <tt>skype</tt>.<br />
;5: Обновление прочих пользовательских пакетов. Они затронут только тех, у кого эти программы стоят.<br />
;6: Обновление пакетов, необходимых только для сборки дистрибутива или работы с abf. Почти никому кроме нас они не интересны, потому класс опасности самый низкий.<br />
<br />
==== Задача ====<br />
* Главная задача QA — поиск регрессий, то есть таких изменений в дистрибутиве, которые уменьшают его функциональность по сравнению с предыдущим состоянием.<br />
* Также задачей QA является внесение в багзиллу всех найденных в процессе тестирования ошибок, не относящихся к регрессиям.<br />
<br />
==== Общие положения ====<br />
* Запрос на обновление пишется в багзилле <br />
* Все сообщения пишутся на английском языке.<br />
* Порядок принятие запросов на тестирование командой QA в общем случае — в порядке возрастания номеров багов, возможны исключения, связанные со срочностью или трудностями в тестировании определенных пакетов.<br />
* Список запросов на обновление можно открыть по ссылке http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=qa_verified%3F&o1=substring&list_id=38774<br />
<br />
==== Срок тестирования ====<br />
* Срок тестирования пакета — '''одна неделя''', за это время служба QA должня проверить пакет и вынести заключение. Срок тестирования может быть увеличен при необходимости тестирования внешними тестерами на отсутствующих у службы QA аппаратно-программных конфигурациях, в этом случае в запросе на обновление задержка должна быть обоснована службой QA.<br />
* Для пакета, который нужно проверить очень срочно, сборщик должен установить приоритет <tt>Highest Critical</tt>, чтобы он выделялся красным цветом в списке. Такие пакеты рассматриваются в течение '''48 часов''' рабочего времени.<br />
* Норма выработки на одного тестера QA - 20 одобренных запросов в неделю, обычно ошибки содержат 10-20% запросов, так что тестер QA в среднем обрабатывает 5 запросов в день.<br />
<br />
=== Процедура тестирования ===<br />
<br />
==== Требования к запросу на обновление ====<br />
# QA Team тестирует пакеты-кандидаты на добавление в репозитории <tt>main/updates, non-free/updates и restricted/updates</tt>.<br />
# Пакет должен быть собран в общедоступном репозитории на ABF (не <tt>_personal</tt>).<br />
# Для архитектурно-зависимых пакетов должны быть представлены все поддерживаемые платформой архитектуры<br />
# Описание обновления должно содержать все изменения, которые нужно протестировать.<br />
При несоответствии запроса на обновление этим требованиям необходимо сообщить об этом инициатору запроса с помощью комментария.<br />
В случае, если до пятницы запрос не исправлен согласно требованиям, он отклоняется.<br />
<br />
==== Тестирование установки пакетов ====<br />
# Система перед тестовым обновлением должна соответствовать стандартным репозиториям, с подключенными тестингами. Это можно проверить запуском <tt>urpm-reposync</tt> из пакета <tt>urpm-tools</tt><br />
# Пакеты для тестирования устанавливаются и в графическом, и в текстовом режиме.<br />
## Репозиторий подключается как репозиторий с обновлениями.<br />
## Запускается стандартная процедура обновления.<br />
# Для пакетов, установленных в системе по-умолчанию, проверяется их обновление.<br />
# Для пакетов, не установленных в системе, проверяется как их обновление, так и первоначальная установка при подключенных тестовых контейнерах.<br />
# Установка пакетов проверяется для обеих архитектур. Так как ошибки установки не обычно не зависят от архитектуры, обычно достаточно проверить на одной архитектуре установку в графическом режиме, а на другой — обновление в текстовом, или наоборот.<br />
<br />
При ошибках установки или обновления пакета необходимо сообщить об этом инициатору запроса с помощью комментария. В случае, если до пятницы ошибка установки не исправлена, запрос отклоняется.<br />
<br />
==== Тестирование на функционирование и устойчивость системы после обновления ====<br />
При тестировании системы проверяется:<br />
# Стабильность и внешний вид обновленной системы после перезагрузки.<br />
# Стабильность и внешний вид обновленной системы после пробуждения из спящего режима. Тестирование стабильности и производительности может проводиться, например, с помощью теста Unigine Valley под wine и тестом браузера https://webglsamples.org/aquarium/aquarium.html<br />
# Ошибки загрузки демонов, например, с помощью <tt>systemctl | grep failed</tt>.<br />
# Ошибки непрерывного роста файла <tt>.xsession-errors</tt>.<br />
# Журнал ошибок, командами '''journalctl -b |grep fail''' и '''journalctl -b |grep error''' (не должно быть новых ошибок, если они появились - нужно найти связанное с ошибкой обновление и написать инициатору)<br />
# Работа менеджера обновлений — дальнейшее обновление пакетов.<br />
# Установка и удаление dkms-модулей (например, установкой проприетарных драйверов с последующим откатом на свободные)<br />
# Сохранением загрузчиком определения других операционных систем, установленных на тестовом компьютере<br />
# Сохранение даты-времени на тестируемой машине после перезагрузки и пробуждения из спящего режима<br />
# Работа системы поиска по содержимому офисных файлов<br />
<br />
При ошибках функционирования или устойчивости системы, связанной с обновлением, необходимо сообщить об этом инициатору запроса с помощью комментария. <br />
В случае, если до пятницы ошибка не исправлена, запрос отклоняется.<br />
<br />
==== Тестирование запуска и работы связанных с обновлением приложений ====<br />
Проверяются:<br />
# Тестирование запуска и простейших операций со связанными с тестируемым пакетом программами, рекомендуется контроль сообщений при запуске программы из консоли.<br />
# Связанные с библиотеками из проверяемого пакета программы легче всего установить, попробовав удалить пакет с помощью <tt>urpme</tt> (для установленных в системе программ) или <tt>urpmq --whatrequires</tt> (для всех программ из подключенных репозиториев).<br />
# Изменения в интерфейсах обновляемых библиотек и, соответственно, необходимость перекомпиляции связанных пакетов с помощью сервиса https://abi-laboratory.pro/tracker/<br />
# Для пакетов, предоставляющих библиотеки, проверяются использующие эти библиотеки приложения из main, их можно определить командой <tt>urpmq --whatrequires <названиепакета></tt><br />
# Регрессии в локализации графического интерфейса и страниц справки.<br />
# Для тестирования браузеров в дополнение к https://webglsamples.org/aquarium/aquarium.html применяются.<br />
## Тест html5 https://html5test.com/ (сравнить результат до и после обновления, не должно быть регресса)<br />
## Почтовые онлайновые сервисы http://mail.yandex.ru http://mail.google.com<br />
## Яндекс и гугл-карты https://yandex.ru/maps/-/CVTQITy0 https://www.google.ru/maps/@52.2609339,104.3096872,15z?hl=ru<br />
## xml|xsl трансляцию и кодировки на http://base.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=160129;div=LAW;rnd=0.4700782325977544 и<br />
## Воспроизведение видео http://techslides.com/sample-webm-ogg-and-mp4-video-files-for-html5/ <br />
## Воспроизведение [http://youtu.be/37l7P5V1eXU видео с youtube]<br />
## Работа флэша на примере игры [http://vseigru.net/igry-zombi/2541-igra-zombi-protiv-rastenij.html Растения против зомби] и [http://kino.sputnik.ru/films/ivan+vasilyevich+menyayet+professiyu+1973]<br />
## Уязвимости SSL с помощью https://www.ssllabs.com/ssltest/viewMyClient.html<br />
## Тестирование печати<br />
## Тестирование установки браузера по-умолчанию из настроек<br />
<br />
В случае:<br />
# нахождения регрессии функционала или локализации, о них сообщается инициатору запроса в комментариях к запросу на обновление. <br />
# отсутствия до пятницы исправления найденной QA регрессии или обоснования мейнтейнером пакета невозможности исправления - запрос отклоняется.<br />
# если пакет не имеет постоянного мейнтейнера и собирается случайным сборщиком, QA отвечает за функциональность пакета и может заблокировать обновление при её регрессии<br />
# нахождения ошибок (не регрессий!) - заводится новый баг, его номер указывается в запросе на обновление.<br />
<br />
==== Тестирование изменений ====<br />
* Применяется при тестировании обновлений, изменяющих внешний вид или поведение системы.<br />
<br />
Включает себя<br />
# Воспроизведение особенностей внешнего вида или поведения системы ДО исправления.<br />
# Воспроизведение измененных обновлений особенностей по их описанию.<br />
<br />
Например, если в advisory сказано, что «вышла новая версия программы» при тестировании изменений нужно, как минимум, убедиться что версия изменилась.<br />
<br />
В случае если не все описанные изменения действительно присутствуют в тестируемом пакете, пакет принимается и в итоговый отчет (Advisory), вносятся только реально проведенные изменения.<br />
В случае значительного отклонения запрошенных и полученных изменений пакет может быть отклонен.<br />
<br />
==== Расширенное тестирование ====<br />
# Расширенное тестирование проводится добровольцами с помощью репозиториев testing, соответствующих основным репозиториям. <br />
# В течение недели (понедельник-четверг) все проверяемые QA обновления, кроме срочных, отправляются в тестинг, при этом в багзилле ставится статус verified и пишется The update is sent to expanded testing<br />
# В пятницу, руководитель QA:<br />
## Еще раз контролирует, все ли пакеты направлены в тестинг-репозитории, при помощи отключения источников-контейнеров и выполнения программы '''urpm-reposync''' с включенными тестингами. Результатом выполнения команды должно быть отсутствие пакетов на синхронизацию<br />
## Проверяет, дошли ли обновления до зеркал<br />
## Контролирует возможность обновления до тестингов с момента предыдущего релиза платформы путем установки релизного образа и его обновления с подключенными тестингами <br />
## Обновляет до тестингов системы на всех доступных тестовых стендах и проверяет их на устойчивость<br />
## На форуме и в сообществе вконтакте объявляет "пятничное тестирование", к нему выпускает бюллетень с полным списком обновлений и методикой их тестирования.<br />
# В понедельник руководитель QA читает отзывы пользователей и по их итогам, а также по итогам эксплуатации тестовых стендов в выходные дни, обрабатывает запросы на обновление и передает их на публикацию (или отклоняет)<br />
<br />
=== Завершение тестирования ===<br />
<br />
==== Положительный результат тестирования ====<br />
# По окончании тестирования при его успехе ставится индикатор успешного тестирования QA «+» и пишется отчет (Advisory), содержащий:<br />
## Название пакета с исходниками (src.rpm).<br />
## Версию пакета.<br />
## Отчет о тестировании (advisory).<br />
## Надпись «QA verified».<br />
# Если пакет содержит изменения, связанные с секретностью или же собран не сотрудником Росы — посылается запрос Secure team (взводится флажок secteam_verified «?»).<br />
# Если тестирование secure не нужно, пакет передается на публикацию (взводится соответствующий published «?»).<br />
# В случае успешного тестирования пакет может быть оставлен в системе. В случае ошибок систему нужно привести к первоначальному виду с помощью деинсталляции пакета или утилиты <tt>urpm-reposync</tt> из <tt>urpm-repotools</tt>.<br />
<br />
==== Отрицательный результат тестирования ====<br />
# При отклонении пакета ставится индикатор отклонения QA «-»,<br />
# В комментариях пишется причина отклонения запроса и в конце комментария добавляется «QA Denied».<br />
# При отрицательном результате тестирования сборщик может выложить исправленные контейнеры в тот же запрос и снова установить «?» в «qa_requested».</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F&diff=18650
Регламент тестирования
2020-04-29T14:16:10Z
<p>Vladimir.potapov: /* Классификация обновлений по степени опасности */</p>
<hr />
<div>[[Category:Регламенты ROSA]]<br />
<br />
=== Политика ===<br />
QA, наряду с мейнтейнерами пакетов отвечает за стабильность и функциональность установленного у пользователей дистрибутива при его обновлениях. <br />
<br />
До установки обновлений дистрибутив работает. Любое обновление — риск его обрушить.<br />
Поэтому политика QA обязана быть консервативной и даже несколько параноидальной — при малейших сомнениях должны назначаться дополнительные проверки, пакеты должны отклоняться, направляться на пересборку.<br />
<br />
Политика QA вступает в конфликт с интересами сборщиков пакетов, желающих быстрее увидеть в репозиториях исправленную версию — конфликт этот должен быть конструктивным, приводящим к непрерывному повышению функциональности и стабильности дистрибутива.<br />
<br />
==== Классификация обновлений по степени опасности ====<br />
<blockquote><br />
Меня не интересуют их намерения, меня интересуют их возможности — © Отто Фон Бисмарк<br />
</blockquote><br />
<br />
Классификация исходит из максимально возможного урона (полный отказ функционирования компонента), который может нанести устанавливаемое обновление. Чем выше степень опасности, тем более тщательным должно быть тестирование.<br />
<br />
;0: Критические обновления. Ядро, файловая система, система прав доступа, скрипты загрузки, <tt>systemd</tt>, <tt>glibc</tt>, <tt>dracut</tt>, <tt>grub</tt>, <tt>bash</tt> и прочие основные вещи, если удалить которые система не загрузится даже в консоли.<br />
;1: Обновления драйверов устройств, т.е. те же критические обновления, но актуальные не для всех пользователей. <br />
;2: Обновления сетевых компонентов: NetworkManager, сетевых скриптов, системы сетевой инициализации и системы обновлений. Они опасны тем, что если сеть упадет, пользователю без сети будет затруднительно получить исправленный пакет, когда мы его выпустим и установить обновление. <br />
;3: Обновления графических компонент и скриптов — X-ов, менеджера входа, графических библиотек, драйверов, '''perl, python''' — то, без чего невозможен вход в систему в графическом режиме. Т.к. обновление системы, при наличии сети, возможно и не в графике - класс опасности обновлений не самый высокий<br />
;4: Обновление пользовательских пакетов, установленных по-умолчанию в системе. Эти пакеты стоят практически у всех и их ошибки будут влиять на максимальное количество пользователей, однако они могут быть оперативно исправлены потому класс опасности не очень высокий. Туда же нужно отнести популярные программы не входящие в поставку — <tt>gimp</tt>, <tt>inkscape</tt>, <tt>audacity</tt>, <tt>vlc</tt>, <tt>kdenive</tt>, <tt>opera</tt>, <tt>chromium-browser</tt>, <tt>skype</tt>.<br />
;5: Обновление прочих пользовательских пакетов. Они затронут только тех, у кого эти программы стоят.<br />
;6: Обновление пакетов, необходимых только для сборки дистрибутива или работы с abf. Почти никому кроме нас они не интересны, потому класс опасности самый низкий.<br />
<br />
==== Задача ====<br />
* Главная задача QA — поиск регрессий, то есть таких изменений в дистрибутиве, которые уменьшают его функциональность по сравнению с предыдущим состоянием.<br />
* Также задачей QA является внесение в багзиллу всех найденных в процессе тестирования ошибок, не относящихся к регрессиям.<br />
<br />
==== Общие положения ====<br />
* Запрос на обновление пишется в багзилле <br />
* Все сообщения пишутся на английском языке.<br />
* Порядок принятие запросов на тестирование командой QA в общем случае — в порядке возрастания номеров багов, возможны исключения, связанные со срочностью или трудностями в тестировании определенных пакетов.<br />
* Список запросов на обновление можно открыть по ссылке http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=qa_verified%3F&o1=substring&list_id=38774<br />
<br />
==== Срок тестирования ====<br />
* Срок тестирования пакета — '''одна неделя''', за это время служба QA должня проверить пакет и вынести заключение. Срок тестирования может быть увеличен при необходимости тестирования внешними тестерами на отсутствующих у службы QA аппаратно-программных конфигурациях, в этом случае в запросе на обновление задержка должна быть обоснована службой QA.<br />
* Для пакета, который нужно проверить очень срочно, сборщик должен установить приоритет <tt>Highest Critical</tt>, чтобы он выделялся красным цветом в списке. Такие пакеты рассматриваются в течение '''48 часов''' рабочего времени.<br />
* Норма выработки на одного тестера QA - 20 одобренных запросов в неделю, обычно ошибки содержат 10-20% запросов, так что тестер QA в среднем обрабатывает 5 запросов в день.<br />
<br />
=== Процедура тестирования ===<br />
<br />
==== Требования к запросу на обновление ====<br />
# QA Team тестирует пакеты-кандидаты на добавление в репозитории <tt>main/updates, non-free/updates и restricted/updates</tt>.<br />
# Пакет должен быть собран в общедоступном репозитории на ABF (не <tt>_personal</tt>).<br />
# Для архитектурно-зависимых пакетов должны быть представлены все поддерживаемые платформой архитектуры<br />
# Описание обновления должно содержать все изменения, которые нужно протестировать.<br />
При несоответствии запроса на обновление этим требованиям необходимо сообщить об этом инициатору запроса с помощью комментария.<br />
В случае, если до пятницы запрос не исправлен согласно требованиям, он отклоняется.<br />
<br />
==== Тестирование установки пакетов ====<br />
# Система перед тестовым обновлением должна соответствовать стандартным репозиториям, с подключенными тестингами. Это можно проверить запуском <tt>urpm-reposync</tt> из пакета <tt>urpm-tools</tt><br />
# Пакеты для тестирования устанавливаются и в графическом, и в текстовом режиме.<br />
## Репозиторий подключается как репозиторий с обновлениями.<br />
## Запускается стандартная процедура обновления.<br />
# Для пакетов, установленных в системе по-умолчанию, проверяется их обновление.<br />
# Для пакетов, не установленных в системе, проверяется как их обновление, так и первоначальная установка при подключенных тестовых контейнерах.<br />
# Установка пакетов проверяется для обеих архитектур. Так как ошибки установки не обычно не зависят от архитектуры, обычно достаточно проверить на одной архитектуре установку в графическом режиме, а на другой — обновление в текстовом, или наоборот.<br />
<br />
При ошибках установки или обновления пакета необходимо сообщить об этом инициатору запроса с помощью комментария. В случае, если до пятницы ошибка установки не исправлена, запрос отклоняется.<br />
<br />
==== Тестирование на функционирование и устойчивость системы после обновления ====<br />
При тестировании системы проверяется:<br />
# Стабильность и внешний вид обновленной системы после перезагрузки.<br />
# Стабильность и внешний вид обновленной системы после пробуждения из спящего режима. Тестирование стабильности и производительности может проводиться, например, с помощью теста Unigine Valley под wine и тестом браузера https://webglsamples.org/aquarium/aquarium.html<br />
# Ошибки загрузки демонов, например, с помощью <tt>systemctl | grep failed</tt>.<br />
# Ошибки непрерывного роста файла <tt>.xsession-errors</tt>.<br />
# Журнал ошибок, командами '''journalctl -b |grep fail''' и '''journalctl -b |grep error''' (не должно быть новых ошибок, если они появились - нужно найти связанное с ошибкой обновление и написать инициатору)<br />
# Работа URPMI — дальнейшее обновление пакетов.<br />
# Установка и удаление dkms-модулей (например, установкой проприетарных драйверов с последующим откатом на свободные)<br />
# Сохранением загрузчиком определения других операционных систем, установленных на тестовом компьютере<br />
# Сохранение даты-времени на тестируемой машине после перезагрузки и пробуждения из спящего режима<br />
# Работа системы поиска по содержимому офисных файлов<br />
<br />
При ошибках функционирования или устойчивости системы, связанной с обновлением, необходимо сообщить об этом инициатору запроса с помощью комментария. <br />
В случае, если до пятницы ошибка не исправлена, запрос отклоняется.<br />
<br />
==== Тестирование запуска и работы связанных с обновлением приложений ====<br />
Проверяются:<br />
# Тестирование запуска и простейших операций со связанными с тестируемым пакетом программами, рекомендуется контроль сообщений при запуске программы из консоли.<br />
# Связанные с библиотеками из проверяемого пакета программы легче всего установить, попробовав удалить пакет с помощью <tt>urpme</tt> (для установленных в системе программ) или <tt>urpmq --whatrequires</tt> (для всех программ из подключенных репозиториев).<br />
# Изменения в интерфейсах обновляемых библиотек и, соответственно, необходимость перекомпиляции связанных пакетов с помощью сервиса https://abi-laboratory.pro/tracker/<br />
# Для пакетов, предоставляющих библиотеки, проверяются использующие эти библиотеки приложения из main, их можно определить командой <tt>urpmq --whatrequires <названиепакета></tt><br />
# Регрессии в локализации графического интерфейса и страниц справки.<br />
# Для тестирования браузеров в дополнение к https://webglsamples.org/aquarium/aquarium.html применяются.<br />
## Тест html5 https://html5test.com/ (сравнить результат до и после обновления, не должно быть регресса)<br />
## Почтовые онлайновые сервисы http://mail.yandex.ru http://mail.google.com<br />
## Яндекс и гугл-карты https://yandex.ru/maps/-/CVTQITy0 https://www.google.ru/maps/@52.2609339,104.3096872,15z?hl=ru<br />
## xml|xsl трансляцию и кодировки на http://base.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=160129;div=LAW;rnd=0.4700782325977544 и<br />
## Воспроизведение видео http://techslides.com/sample-webm-ogg-and-mp4-video-files-for-html5/ <br />
## Воспроизведение [http://youtu.be/37l7P5V1eXU видео с youtube]<br />
## Работа флэша на примере игры [http://vseigru.net/igry-zombi/2541-igra-zombi-protiv-rastenij.html Растения против зомби] и [http://kino.sputnik.ru/films/ivan+vasilyevich+menyayet+professiyu+1973]<br />
## Уязвимости SSL с помощью https://www.ssllabs.com/ssltest/viewMyClient.html<br />
## Тестирование печати<br />
## Тестирование установки браузера по-умолчанию из настроек<br />
<br />
В случае:<br />
# нахождения регрессии функционала или локализации, о них сообщается инициатору запроса в комментариях к запросу на обновление. <br />
# отсутствия до пятницы исправления найденной QA регрессии или обоснования мейнтейнером пакета невозможности исправления - запрос отклоняется.<br />
# если пакет не имеет постоянного мейнтейнера и собирается случайным сборщиком, QA отвечает за функциональность пакета и может заблокировать обновление при её регрессии<br />
# нахождения ошибок (не регрессий!) - заводится новый баг, его номер указывается в запросе на обновление.<br />
<br />
==== Тестирование изменений ====<br />
* Применяется при тестировании обновлений, изменяющих внешний вид или поведение системы.<br />
<br />
Включает себя<br />
# Воспроизведение особенностей внешнего вида или поведения системы ДО исправления.<br />
# Воспроизведение измененных обновлений особенностей по их описанию.<br />
<br />
Например, если в advisory сказано, что «вышла новая версия программы» при тестировании изменений нужно, как минимум, убедиться что версия изменилась.<br />
<br />
В случае если не все описанные изменения действительно присутствуют в тестируемом пакете, пакет принимается и в итоговый отчет (Advisory), вносятся только реально проведенные изменения.<br />
В случае значительного отклонения запрошенных и полученных изменений пакет может быть отклонен.<br />
<br />
==== Расширенное тестирование ====<br />
# Расширенное тестирование проводится добровольцами с помощью репозиториев testing, соответствующих основным репозиториям. <br />
# В течение недели (понедельник-четверг) все проверяемые QA обновления, кроме срочных, отправляются в тестинг, при этом в багзилле ставится статус verified и пишется The update is sent to expanded testing<br />
# В пятницу, руководитель QA:<br />
## Еще раз контролирует, все ли пакеты направлены в тестинг-репозитории, при помощи отключения источников-контейнеров и выполнения программы '''urpm-reposync''' с включенными тестингами. Результатом выполнения команды должно быть отсутствие пакетов на синхронизацию<br />
## Проверяет, дошли ли обновления до зеркал<br />
## Контролирует возможность обновления до тестингов с момента предыдущего релиза платформы путем установки релизного образа и его обновления с подключенными тестингами <br />
## Обновляет до тестингов системы на всех доступных тестовых стендах и проверяет их на устойчивость<br />
## На форуме и в сообществе вконтакте объявляет "пятничное тестирование", к нему выпускает бюллетень с полным списком обновлений и методикой их тестирования.<br />
# В понедельник руководитель QA читает отзывы пользователей и по их итогам, а также по итогам эксплуатации тестовых стендов в выходные дни, обрабатывает запросы на обновление и передает их на публикацию (или отклоняет)<br />
<br />
=== Завершение тестирования ===<br />
<br />
==== Положительный результат тестирования ====<br />
# По окончании тестирования при его успехе ставится индикатор успешного тестирования QA «+» и пишется отчет (Advisory), содержащий:<br />
## Название пакета с исходниками (src.rpm).<br />
## Версию пакета.<br />
## Отчет о тестировании (advisory).<br />
## Надпись «QA verified».<br />
# Если пакет содержит изменения, связанные с секретностью или же собран не сотрудником Росы — посылается запрос Secure team (взводится флажок secteam_verified «?»).<br />
# Если тестирование secure не нужно, пакет передается на публикацию (взводится соответствующий published «?»).<br />
# В случае успешного тестирования пакет может быть оставлен в системе. В случае ошибок систему нужно привести к первоначальному виду с помощью деинсталляции пакета или утилиты <tt>urpm-reposync</tt> из <tt>urpm-repotools</tt>.<br />
<br />
==== Отрицательный результат тестирования ====<br />
# При отклонении пакета ставится индикатор отклонения QA «-»,<br />
# В комментариях пишется причина отклонения запроса и в конце комментария добавляется «QA Denied».<br />
# При отрицательном результате тестирования сборщик может выложить исправленные контейнеры в тот же запрос и снова установить «?» в «qa_requested».</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F&diff=18649
Регламент тестирования
2020-04-29T14:15:43Z
<p>Vladimir.potapov: /* Требования к запросу на обновление */</p>
<hr />
<div>[[Category:Регламенты ROSA]]<br />
<br />
=== Политика ===<br />
QA, наряду с мейнтейнерами пакетов отвечает за стабильность и функциональность установленного у пользователей дистрибутива при его обновлениях. <br />
<br />
До установки обновлений дистрибутив работает. Любое обновление — риск его обрушить.<br />
Поэтому политика QA обязана быть консервативной и даже несколько параноидальной — при малейших сомнениях должны назначаться дополнительные проверки, пакеты должны отклоняться, направляться на пересборку.<br />
<br />
Политика QA вступает в конфликт с интересами сборщиков пакетов, желающих быстрее увидеть в репозиториях исправленную версию — конфликт этот должен быть конструктивным, приводящим к непрерывному повышению функциональности и стабильности дистрибутива.<br />
<br />
==== Классификация обновлений по степени опасности ====<br />
<blockquote><br />
Меня не интересуют их намерения, меня интересуют их возможности — © Отто Фон Бисмарк<br />
</blockquote><br />
<br />
Классификация исходит из максимально возможного урона (полный отказ функционирования компонента), который может нанести устанавливаемое обновление. Чем выше степень опасности, тем более тщательным должно быть тестирование.<br />
<br />
;0: Критические обновления. Ядро, файловая система, система прав доступа, скрипты загрузки, <tt>systemd</tt>, <tt>glibc</tt>, <tt>dracut</tt>, <tt>grub</tt>, <tt>bash</tt> и прочие основные вещи, если удалить которые система не загрузится даже в консоли.<br />
;1: Обновления драйверов устройств, т.е. те же критические обновления, но актуальные не для всех пользователей. <br />
;2: Обновления сетевых компонентов: NetworkManager, сетевых скриптов, системы сетевой инициализации и системы обновлений (curl, urpmi). Они опасны тем, что если сеть упадет, пользователю без сети будет затруднительно получить исправленный пакет, когда мы его выпустим и установить обновление. <br />
;3: Обновления графических компонент и скриптов — X-ов, менеджера входа, графических библиотек, драйверов, '''perl, python''' — то, без чего невозможен вход в систему в графическом режиме. Т.к. обновление системы, при наличии сети, возможно и не в графике - класс опасности обновлений не самый высокий<br />
;4: Обновление пользовательских пакетов, установленных по-умолчанию в системе. Эти пакеты стоят практически у всех и их ошибки будут влиять на максимальное количество пользователей, однако они могут быть оперативно исправлены потому класс опасности не очень высокий. Туда же нужно отнести популярные программы не входящие в поставку — <tt>gimp</tt>, <tt>inkscape</tt>, <tt>audacity</tt>, <tt>vlc</tt>, <tt>kdenive</tt>, <tt>opera</tt>, <tt>chromium-browser</tt>, <tt>skype</tt>.<br />
;5: Обновление прочих пользовательских пакетов. Они затронут только тех, у кого эти программы стоят.<br />
;6: Обновление пакетов, необходимых только для сборки дистрибутива или работы с abf. Почти никому кроме нас они не интересны, потому класс опасности самый низкий.<br />
<br />
==== Задача ====<br />
* Главная задача QA — поиск регрессий, то есть таких изменений в дистрибутиве, которые уменьшают его функциональность по сравнению с предыдущим состоянием.<br />
* Также задачей QA является внесение в багзиллу всех найденных в процессе тестирования ошибок, не относящихся к регрессиям.<br />
<br />
==== Общие положения ====<br />
* Запрос на обновление пишется в багзилле <br />
* Все сообщения пишутся на английском языке.<br />
* Порядок принятие запросов на тестирование командой QA в общем случае — в порядке возрастания номеров багов, возможны исключения, связанные со срочностью или трудностями в тестировании определенных пакетов.<br />
* Список запросов на обновление можно открыть по ссылке http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=qa_verified%3F&o1=substring&list_id=38774<br />
<br />
==== Срок тестирования ====<br />
* Срок тестирования пакета — '''одна неделя''', за это время служба QA должня проверить пакет и вынести заключение. Срок тестирования может быть увеличен при необходимости тестирования внешними тестерами на отсутствующих у службы QA аппаратно-программных конфигурациях, в этом случае в запросе на обновление задержка должна быть обоснована службой QA.<br />
* Для пакета, который нужно проверить очень срочно, сборщик должен установить приоритет <tt>Highest Critical</tt>, чтобы он выделялся красным цветом в списке. Такие пакеты рассматриваются в течение '''48 часов''' рабочего времени.<br />
* Норма выработки на одного тестера QA - 20 одобренных запросов в неделю, обычно ошибки содержат 10-20% запросов, так что тестер QA в среднем обрабатывает 5 запросов в день.<br />
<br />
=== Процедура тестирования ===<br />
<br />
==== Требования к запросу на обновление ====<br />
# QA Team тестирует пакеты-кандидаты на добавление в репозитории <tt>main/updates, non-free/updates и restricted/updates</tt>.<br />
# Пакет должен быть собран в общедоступном репозитории на ABF (не <tt>_personal</tt>).<br />
# Для архитектурно-зависимых пакетов должны быть представлены все поддерживаемые платформой архитектуры<br />
# Описание обновления должно содержать все изменения, которые нужно протестировать.<br />
При несоответствии запроса на обновление этим требованиям необходимо сообщить об этом инициатору запроса с помощью комментария.<br />
В случае, если до пятницы запрос не исправлен согласно требованиям, он отклоняется.<br />
<br />
==== Тестирование установки пакетов ====<br />
# Система перед тестовым обновлением должна соответствовать стандартным репозиториям, с подключенными тестингами. Это можно проверить запуском <tt>urpm-reposync</tt> из пакета <tt>urpm-tools</tt><br />
# Пакеты для тестирования устанавливаются и в графическом, и в текстовом режиме.<br />
## Репозиторий подключается как репозиторий с обновлениями.<br />
## Запускается стандартная процедура обновления.<br />
# Для пакетов, установленных в системе по-умолчанию, проверяется их обновление.<br />
# Для пакетов, не установленных в системе, проверяется как их обновление, так и первоначальная установка при подключенных тестовых контейнерах.<br />
# Установка пакетов проверяется для обеих архитектур. Так как ошибки установки не обычно не зависят от архитектуры, обычно достаточно проверить на одной архитектуре установку в графическом режиме, а на другой — обновление в текстовом, или наоборот.<br />
<br />
При ошибках установки или обновления пакета необходимо сообщить об этом инициатору запроса с помощью комментария. В случае, если до пятницы ошибка установки не исправлена, запрос отклоняется.<br />
<br />
==== Тестирование на функционирование и устойчивость системы после обновления ====<br />
При тестировании системы проверяется:<br />
# Стабильность и внешний вид обновленной системы после перезагрузки.<br />
# Стабильность и внешний вид обновленной системы после пробуждения из спящего режима. Тестирование стабильности и производительности может проводиться, например, с помощью теста Unigine Valley под wine и тестом браузера https://webglsamples.org/aquarium/aquarium.html<br />
# Ошибки загрузки демонов, например, с помощью <tt>systemctl | grep failed</tt>.<br />
# Ошибки непрерывного роста файла <tt>.xsession-errors</tt>.<br />
# Журнал ошибок, командами '''journalctl -b |grep fail''' и '''journalctl -b |grep error''' (не должно быть новых ошибок, если они появились - нужно найти связанное с ошибкой обновление и написать инициатору)<br />
# Работа URPMI — дальнейшее обновление пакетов.<br />
# Установка и удаление dkms-модулей (например, установкой проприетарных драйверов с последующим откатом на свободные)<br />
# Сохранением загрузчиком определения других операционных систем, установленных на тестовом компьютере<br />
# Сохранение даты-времени на тестируемой машине после перезагрузки и пробуждения из спящего режима<br />
# Работа системы поиска по содержимому офисных файлов<br />
<br />
При ошибках функционирования или устойчивости системы, связанной с обновлением, необходимо сообщить об этом инициатору запроса с помощью комментария. <br />
В случае, если до пятницы ошибка не исправлена, запрос отклоняется.<br />
<br />
==== Тестирование запуска и работы связанных с обновлением приложений ====<br />
Проверяются:<br />
# Тестирование запуска и простейших операций со связанными с тестируемым пакетом программами, рекомендуется контроль сообщений при запуске программы из консоли.<br />
# Связанные с библиотеками из проверяемого пакета программы легче всего установить, попробовав удалить пакет с помощью <tt>urpme</tt> (для установленных в системе программ) или <tt>urpmq --whatrequires</tt> (для всех программ из подключенных репозиториев).<br />
# Изменения в интерфейсах обновляемых библиотек и, соответственно, необходимость перекомпиляции связанных пакетов с помощью сервиса https://abi-laboratory.pro/tracker/<br />
# Для пакетов, предоставляющих библиотеки, проверяются использующие эти библиотеки приложения из main, их можно определить командой <tt>urpmq --whatrequires <названиепакета></tt><br />
# Регрессии в локализации графического интерфейса и страниц справки.<br />
# Для тестирования браузеров в дополнение к https://webglsamples.org/aquarium/aquarium.html применяются.<br />
## Тест html5 https://html5test.com/ (сравнить результат до и после обновления, не должно быть регресса)<br />
## Почтовые онлайновые сервисы http://mail.yandex.ru http://mail.google.com<br />
## Яндекс и гугл-карты https://yandex.ru/maps/-/CVTQITy0 https://www.google.ru/maps/@52.2609339,104.3096872,15z?hl=ru<br />
## xml|xsl трансляцию и кодировки на http://base.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=160129;div=LAW;rnd=0.4700782325977544 и<br />
## Воспроизведение видео http://techslides.com/sample-webm-ogg-and-mp4-video-files-for-html5/ <br />
## Воспроизведение [http://youtu.be/37l7P5V1eXU видео с youtube]<br />
## Работа флэша на примере игры [http://vseigru.net/igry-zombi/2541-igra-zombi-protiv-rastenij.html Растения против зомби] и [http://kino.sputnik.ru/films/ivan+vasilyevich+menyayet+professiyu+1973]<br />
## Уязвимости SSL с помощью https://www.ssllabs.com/ssltest/viewMyClient.html<br />
## Тестирование печати<br />
## Тестирование установки браузера по-умолчанию из настроек<br />
<br />
В случае:<br />
# нахождения регрессии функционала или локализации, о них сообщается инициатору запроса в комментариях к запросу на обновление. <br />
# отсутствия до пятницы исправления найденной QA регрессии или обоснования мейнтейнером пакета невозможности исправления - запрос отклоняется.<br />
# если пакет не имеет постоянного мейнтейнера и собирается случайным сборщиком, QA отвечает за функциональность пакета и может заблокировать обновление при её регрессии<br />
# нахождения ошибок (не регрессий!) - заводится новый баг, его номер указывается в запросе на обновление.<br />
<br />
==== Тестирование изменений ====<br />
* Применяется при тестировании обновлений, изменяющих внешний вид или поведение системы.<br />
<br />
Включает себя<br />
# Воспроизведение особенностей внешнего вида или поведения системы ДО исправления.<br />
# Воспроизведение измененных обновлений особенностей по их описанию.<br />
<br />
Например, если в advisory сказано, что «вышла новая версия программы» при тестировании изменений нужно, как минимум, убедиться что версия изменилась.<br />
<br />
В случае если не все описанные изменения действительно присутствуют в тестируемом пакете, пакет принимается и в итоговый отчет (Advisory), вносятся только реально проведенные изменения.<br />
В случае значительного отклонения запрошенных и полученных изменений пакет может быть отклонен.<br />
<br />
==== Расширенное тестирование ====<br />
# Расширенное тестирование проводится добровольцами с помощью репозиториев testing, соответствующих основным репозиториям. <br />
# В течение недели (понедельник-четверг) все проверяемые QA обновления, кроме срочных, отправляются в тестинг, при этом в багзилле ставится статус verified и пишется The update is sent to expanded testing<br />
# В пятницу, руководитель QA:<br />
## Еще раз контролирует, все ли пакеты направлены в тестинг-репозитории, при помощи отключения источников-контейнеров и выполнения программы '''urpm-reposync''' с включенными тестингами. Результатом выполнения команды должно быть отсутствие пакетов на синхронизацию<br />
## Проверяет, дошли ли обновления до зеркал<br />
## Контролирует возможность обновления до тестингов с момента предыдущего релиза платформы путем установки релизного образа и его обновления с подключенными тестингами <br />
## Обновляет до тестингов системы на всех доступных тестовых стендах и проверяет их на устойчивость<br />
## На форуме и в сообществе вконтакте объявляет "пятничное тестирование", к нему выпускает бюллетень с полным списком обновлений и методикой их тестирования.<br />
# В понедельник руководитель QA читает отзывы пользователей и по их итогам, а также по итогам эксплуатации тестовых стендов в выходные дни, обрабатывает запросы на обновление и передает их на публикацию (или отклоняет)<br />
<br />
=== Завершение тестирования ===<br />
<br />
==== Положительный результат тестирования ====<br />
# По окончании тестирования при его успехе ставится индикатор успешного тестирования QA «+» и пишется отчет (Advisory), содержащий:<br />
## Название пакета с исходниками (src.rpm).<br />
## Версию пакета.<br />
## Отчет о тестировании (advisory).<br />
## Надпись «QA verified».<br />
# Если пакет содержит изменения, связанные с секретностью или же собран не сотрудником Росы — посылается запрос Secure team (взводится флажок secteam_verified «?»).<br />
# Если тестирование secure не нужно, пакет передается на публикацию (взводится соответствующий published «?»).<br />
# В случае успешного тестирования пакет может быть оставлен в системе. В случае ошибок систему нужно привести к первоначальному виду с помощью деинсталляции пакета или утилиты <tt>urpm-reposync</tt> из <tt>urpm-repotools</tt>.<br />
<br />
==== Отрицательный результат тестирования ====<br />
# При отклонении пакета ставится индикатор отклонения QA «-»,<br />
# В комментариях пишется причина отклонения запроса и в конце комментария добавляется «QA Denied».<br />
# При отрицательном результате тестирования сборщик может выложить исправленные контейнеры в тот же запрос и снова установить «?» в «qa_requested».</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_%D0%B2_%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%BD%D1%8B%D1%85_%D1%80%D0%B5%D0%BF%D0%BE%D0%B7%D0%B8%D1%82%D0%BE%D1%80%D0%B8%D1%8F%D1%85_ROSA_Linux&diff=18648
Регламент обновления пакетов в основных репозиториях ROSA Linux
2020-04-29T14:13:01Z
<p>Vladimir.potapov: /* Сборщики */</p>
<hr />
<div>=== Применимость ===<br />
Настоящий регламент описывает порядок добавления и исправления пакетов в репозиториях ROSA при взаимодействии пяти команд:<br />
# Команды репортеров, сообщающих об ошибках и уязвимостях в пакетной базе и выступающих с предложениями обновления пакетов<br />
# Команды сборщиков (мейнтейнеров), собирающих пакеты с новыми версиями программ и исправлениями ошибок и уязвимостей<br />
# Команды контроля качества (QA), контролирующих работоспособность исправленных пакетов и всей системы в целом после обновления<br />
# Команда контроля уязвимостей (SecTeam), отслеживающих текущие уязвимости дистрибутива и корректность исправления этих уязвимостей сборщиками<br />
# Публикатора, задачи которого - доступность исправленных пакетов на зеркалах дистрибутива, контроль целостности/замкнутости репозиториев после публикации, а также качества сборки самих пакетов (соответствие политикам сборки, принятым в дистрибутиве и т.п.)<br />
<br />
Данный порядок относится к работе с основными репозиториями ROSA Linux, за исключением репозитория сообщества ROSA Fresh (contrib) где контроль качества не производится.<br />
<br />
=== Общий порядок обновления ===<br />
# Общий порядок адресации каждого запроса на обновление - <br />
Репортеры (в т.ч. из SecTeam) -> Cборщики -> QA & SecTeam -> Публикатор<br />
# Допустимо совмещение ролей "репортер", "сборщик" и "публикатор", но недопустима ситуация, когда человек проверяет результаты своей сборки и публикует их. <br />
# Вся работа по обновлению пакетов происходит с помощью специально созданных в багзилле ROSA Linux багов - запросов на обновление<br />
<br />
=== Репортеры ===<br />
# Репортеры заводят в багзилле баги, обосновывающие необходимость исправления или добавления, с описанием ошибки, кодом уязвимости или необходимым им новым функционалом.<br />
# Альтернативным путем создания запроса на изменение пакетов в репозиториях для репортеров является пул-реквест в системе сборки ABF.<br />
# Репортеры являются заказчиками исправления, т.е. контролируют весь его процесс до попадания в репозитории.<br />
<br />
=== Сборщики ===<br />
# Сборщики получают информацию о багах от репортеров через почтовую рассылку багзиллы<br />
# Пакеты обновляются на основании заведенного в [http://bugs.rosalinux.ru багзилле] бага, называемого далее "запросом на обновление"<br />
# В комментариях к запросу на обновление указываются ссылки на контейнеры с собранным для указанной платформы обновлением пакета и advisory - написанное по-английски обоснование обновления (например выход новой версии, исправление уязвимости)<br />
# После того, как закончено формирование запроса на обновление, он отправляется на контроль качества команде QA установкой флажка qa_verified в знак вопроса "?"<br />
<br />
=== Мейнтейнеры ===<br />
Мейнтейнер (сопровождающий) - совмещает в себе функции сборщика, репортера и ответственного за функциональность пакета. Мейнтейнер отслеживает его изменения, исправляет уязвимости и ошибки.<br />
# Если какой-то пакет имеет мейнтейнера, это должно быть прописано на abf<br />
# В пакет с указанным мейнтейнером имеет право вносить правки только сам мейнтейнер, остальные могут только предлагать правки, например с помощью пул-реквестов<br />
# Пул-реквесты или другие предложения на обновление пакета должны рассматриваться мейнтейнером в течение недели, а критические - в течение 48 часов<br />
# 0-day уязвимости в своем пакете мейнтейнер должен исправлять и передавать на тестирование в течение 48 часов, критические - в течение недели<br />
# Баги в пакете, имеющем мейнтейнера, должны им рассматриваться (исправляться, отменяться или хотя бы комментироваться) в течение двух недель после назначения.<br />
# В случае, если мейнтейнер не выдерживает указанные сроки по реагированию на предложения правок, исправления уязвимостей и ошибок, они могут быть исправлены другим сборщиком по процедуре, аналогичной для пакета, не имеющего мейнтейнера<br />
<br />
=== Команда контроля качества (QA) ===<br />
# Команда QA получает запросы с установленным сборщиками флажком qa_verified<br />
# Команда QA проводит тестирование пакетов, используя [[Регламент тестирования]]<br />
# Если обновление содержит исправления уязвимостей, устанавливается флажок sectime_verified в "?" для параллельной проверки корректности исправления уязвимостей командой SecTeam<br />
# После проверки отсутствия регрессий функциональности у собранного пакета команда QA ставит флаг QA_verified "+" при успешной проверке и "-" при неуспешной.<br />
# При отсутствии регрессий и, при необходимости, после получения одобрения запроса от команды SecTeam (флажок sectime_verified меняется на "+") запрос отправляется на публикацию установкой флажка publishied в "?"<br />
# QA каждую пятницу публикует бюллетень с перечнем исправленных багов за истекшую неделю<br />
<br />
=== Команда поиска и устранения уязвимостей (SecTeam) ===<br />
# Подробности поиска уязвимостей описаны в документе [[Регламент по устранению уязвимостей]]<br />
# Список уязвимостей ведется на странице вики [http://wiki.rosalab.ru/ru/index.php/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:Security_Advisories Список уязвимостей] командой SecTeam.<br />
# Для каждой уязвимости из списка команда SecTeam выступает репортером и заводит баг<br />
# После того, как сборщики соберут исправленные пакеты и QA установить флажок secteam_verified в "?", SecTeam проверяет исправление уязвимости<br />
# Дополнительно могут проверяться и запросы с исправлениями уязвимостей, сделанные и не участниками команды SecTeam<br />
# При успешной проверке secteam_verified устанавливается в "+"<br />
<br />
=== Публикатор ===<br />
# Публикатор получает запрос на обновление после его одобрения командами QA и (если он содержит исправления уязвимостей) SecTeam<br />
# Публикатор обеспечивает появление пакетов обновлений в репозиториях и непротиворечивость репозиториев после публикации.<br />
# После успешной публикации флажок "publishied" устанавливается в "+" и запрос на обновление считается полностью закрытым.<br />
<br />
[[Категория:Регламенты ROSA]]</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_%D0%B2_%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%BD%D1%8B%D1%85_%D1%80%D0%B5%D0%BF%D0%BE%D0%B7%D0%B8%D1%82%D0%BE%D1%80%D0%B8%D1%8F%D1%85_ROSA_Linux&diff=18647
Регламент обновления пакетов в основных репозиториях ROSA Linux
2020-04-29T14:11:50Z
<p>Vladimir.potapov: /* Мейнтейнеры */</p>
<hr />
<div>=== Применимость ===<br />
Настоящий регламент описывает порядок добавления и исправления пакетов в репозиториях ROSA при взаимодействии пяти команд:<br />
# Команды репортеров, сообщающих об ошибках и уязвимостях в пакетной базе и выступающих с предложениями обновления пакетов<br />
# Команды сборщиков (мейнтейнеров), собирающих пакеты с новыми версиями программ и исправлениями ошибок и уязвимостей<br />
# Команды контроля качества (QA), контролирующих работоспособность исправленных пакетов и всей системы в целом после обновления<br />
# Команда контроля уязвимостей (SecTeam), отслеживающих текущие уязвимости дистрибутива и корректность исправления этих уязвимостей сборщиками<br />
# Публикатора, задачи которого - доступность исправленных пакетов на зеркалах дистрибутива, контроль целостности/замкнутости репозиториев после публикации, а также качества сборки самих пакетов (соответствие политикам сборки, принятым в дистрибутиве и т.п.)<br />
<br />
Данный порядок относится к работе с основными репозиториями ROSA Linux, за исключением репозитория сообщества ROSA Fresh (contrib) где контроль качества не производится.<br />
<br />
=== Общий порядок обновления ===<br />
# Общий порядок адресации каждого запроса на обновление - <br />
Репортеры (в т.ч. из SecTeam) -> Cборщики -> QA & SecTeam -> Публикатор<br />
# Допустимо совмещение ролей "репортер", "сборщик" и "публикатор", но недопустима ситуация, когда человек проверяет результаты своей сборки и публикует их. <br />
# Вся работа по обновлению пакетов происходит с помощью специально созданных в багзилле ROSA Linux багов - запросов на обновление<br />
<br />
=== Репортеры ===<br />
# Репортеры заводят в багзилле баги, обосновывающие необходимость исправления или добавления, с описанием ошибки, кодом уязвимости или необходимым им новым функционалом.<br />
# Альтернативным путем создания запроса на изменение пакетов в репозиториях для репортеров является пул-реквест в системе сборки ABF.<br />
# Репортеры являются заказчиками исправления, т.е. контролируют весь его процесс до попадания в репозитории.<br />
<br />
=== Сборщики ===<br />
# Сборщики получают информацию о багах от репортеров через почтовую рассылку багзиллы<br />
# Пакеты обновляются на основании заведенного в [http://bugs.rosalinux.ru багзилле] бага с заголовком [UPDATE REQUEST <платформа>] называемого запросом на обновление<br />
# В комментариях к запросу на обновления указываются ссылки на контейнеры с собранным для указанной платформы обновлением пакета и advisory - написанное по-английски обоснование обновления (например выход новой версии, исправление уязвимости)<br />
# После того, как закончено формирование запроса на обновление, он отправляется на контроль качества команде QA установкой флажка qa_verified в знак вопроса "?"<br />
<br />
=== Мейнтейнеры ===<br />
Мейнтейнер (сопровождающий) - совмещает в себе функции сборщика, репортера и ответственного за функциональность пакета. Мейнтейнер отслеживает его изменения, исправляет уязвимости и ошибки.<br />
# Если какой-то пакет имеет мейнтейнера, это должно быть прописано на abf<br />
# В пакет с указанным мейнтейнером имеет право вносить правки только сам мейнтейнер, остальные могут только предлагать правки, например с помощью пул-реквестов<br />
# Пул-реквесты или другие предложения на обновление пакета должны рассматриваться мейнтейнером в течение недели, а критические - в течение 48 часов<br />
# 0-day уязвимости в своем пакете мейнтейнер должен исправлять и передавать на тестирование в течение 48 часов, критические - в течение недели<br />
# Баги в пакете, имеющем мейнтейнера, должны им рассматриваться (исправляться, отменяться или хотя бы комментироваться) в течение двух недель после назначения.<br />
# В случае, если мейнтейнер не выдерживает указанные сроки по реагированию на предложения правок, исправления уязвимостей и ошибок, они могут быть исправлены другим сборщиком по процедуре, аналогичной для пакета, не имеющего мейнтейнера<br />
<br />
=== Команда контроля качества (QA) ===<br />
# Команда QA получает запросы с установленным сборщиками флажком qa_verified<br />
# Команда QA проводит тестирование пакетов, используя [[Регламент тестирования]]<br />
# Если обновление содержит исправления уязвимостей, устанавливается флажок sectime_verified в "?" для параллельной проверки корректности исправления уязвимостей командой SecTeam<br />
# После проверки отсутствия регрессий функциональности у собранного пакета команда QA ставит флаг QA_verified "+" при успешной проверке и "-" при неуспешной.<br />
# При отсутствии регрессий и, при необходимости, после получения одобрения запроса от команды SecTeam (флажок sectime_verified меняется на "+") запрос отправляется на публикацию установкой флажка publishied в "?"<br />
# QA каждую пятницу публикует бюллетень с перечнем исправленных багов за истекшую неделю<br />
<br />
=== Команда поиска и устранения уязвимостей (SecTeam) ===<br />
# Подробности поиска уязвимостей описаны в документе [[Регламент по устранению уязвимостей]]<br />
# Список уязвимостей ведется на странице вики [http://wiki.rosalab.ru/ru/index.php/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:Security_Advisories Список уязвимостей] командой SecTeam.<br />
# Для каждой уязвимости из списка команда SecTeam выступает репортером и заводит баг<br />
# После того, как сборщики соберут исправленные пакеты и QA установить флажок secteam_verified в "?", SecTeam проверяет исправление уязвимости<br />
# Дополнительно могут проверяться и запросы с исправлениями уязвимостей, сделанные и не участниками команды SecTeam<br />
# При успешной проверке secteam_verified устанавливается в "+"<br />
<br />
=== Публикатор ===<br />
# Публикатор получает запрос на обновление после его одобрения командами QA и (если он содержит исправления уязвимостей) SecTeam<br />
# Публикатор обеспечивает появление пакетов обновлений в репозиториях и непротиворечивость репозиториев после публикации.<br />
# После успешной публикации флажок "publishied" устанавливается в "+" и запрос на обновление считается полностью закрытым.<br />
<br />
[[Категория:Регламенты ROSA]]</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_%D0%B2_%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%BD%D1%8B%D1%85_%D1%80%D0%B5%D0%BF%D0%BE%D0%B7%D0%B8%D1%82%D0%BE%D1%80%D0%B8%D1%8F%D1%85_ROSA_Linux&diff=18646
Регламент обновления пакетов в основных репозиториях ROSA Linux
2020-04-29T10:48:29Z
<p>Vladimir.potapov: /* Мейнтейнеры */</p>
<hr />
<div>=== Применимость ===<br />
Настоящий регламент описывает порядок добавления и исправления пакетов в репозиториях ROSA при взаимодействии пяти команд:<br />
# Команды репортеров, сообщающих об ошибках и уязвимостях в пакетной базе и выступающих с предложениями обновления пакетов<br />
# Команды сборщиков (мейнтейнеров), собирающих пакеты с новыми версиями программ и исправлениями ошибок и уязвимостей<br />
# Команды контроля качества (QA), контролирующих работоспособность исправленных пакетов и всей системы в целом после обновления<br />
# Команда контроля уязвимостей (SecTeam), отслеживающих текущие уязвимости дистрибутива и корректность исправления этих уязвимостей сборщиками<br />
# Публикатора, задачи которого - доступность исправленных пакетов на зеркалах дистрибутива, контроль целостности/замкнутости репозиториев после публикации, а также качества сборки самих пакетов (соответствие политикам сборки, принятым в дистрибутиве и т.п.)<br />
<br />
Данный порядок относится к работе с основными репозиториями ROSA Linux, за исключением репозитория сообщества ROSA Fresh (contrib) где контроль качества не производится.<br />
<br />
=== Общий порядок обновления ===<br />
# Общий порядок адресации каждого запроса на обновление - <br />
Репортеры (в т.ч. из SecTeam) -> Cборщики -> QA & SecTeam -> Публикатор<br />
# Допустимо совмещение ролей "репортер", "сборщик" и "публикатор", но недопустима ситуация, когда человек проверяет результаты своей сборки и публикует их. <br />
# Вся работа по обновлению пакетов происходит с помощью специально созданных в багзилле ROSA Linux багов - запросов на обновление<br />
<br />
=== Репортеры ===<br />
# Репортеры заводят в багзилле баги, обосновывающие необходимость исправления или добавления, с описанием ошибки, кодом уязвимости или необходимым им новым функционалом.<br />
# Альтернативным путем создания запроса на изменение пакетов в репозиториях для репортеров является пул-реквест в системе сборки ABF.<br />
# Репортеры являются заказчиками исправления, т.е. контролируют весь его процесс до попадания в репозитории.<br />
<br />
=== Сборщики ===<br />
# Сборщики получают информацию о багах от репортеров через почтовую рассылку багзиллы<br />
# Пакеты обновляются на основании заведенного в [http://bugs.rosalinux.ru багзилле] бага с заголовком [UPDATE REQUEST <платформа>] называемого запросом на обновление<br />
# В комментариях к запросу на обновления указываются ссылки на контейнеры с собранным для указанной платформы обновлением пакета и advisory - написанное по-английски обоснование обновления (например выход новой версии, исправление уязвимости)<br />
# После того, как закончено формирование запроса на обновление, он отправляется на контроль качества команде QA установкой флажка qa_verified в знак вопроса "?"<br />
<br />
=== Мейнтейнеры ===<br />
Мейнтейнер (сопровождающий) - совмещает в себе функции сборщика, репортера и ответственного за функциональность пакета. Мейнтейнер отслеживает его изменения, исправляет уязвимости и ошибки.<br />
# Если какой-то пакет имеет мейнтейнера, это должно быть прописано на abf<br />
# В пакет с указанным мейнтейнером имеет право вносить правки только мейнтейнер, остальные должны пользоваться пул-реквестами<br />
# Пул-реквесты должны рассматриваться мейнтейнером в течение недели, а критические - в течение 48 часов<br />
# 0-day уязвимости в своем пакете мейнтейнер должен исправлять и передавать на тестирование в течение 48 часов, критические - в течение недели<br />
# Баги в пакете, имеющем мейнтейнера, должны им рассматриваться (исправляться, отменяться или хотя бы комментироваться) в течение двух недель после назначения.<br />
<br />
=== Команда контроля качества (QA) ===<br />
# Команда QA получает запросы с установленным сборщиками флажком qa_verified<br />
# Команда QA проводит тестирование пакетов, используя [[Регламент тестирования]]<br />
# Если обновление содержит исправления уязвимостей, устанавливается флажок sectime_verified в "?" для параллельной проверки корректности исправления уязвимостей командой SecTeam<br />
# После проверки отсутствия регрессий функциональности у собранного пакета команда QA ставит флаг QA_verified "+" при успешной проверке и "-" при неуспешной.<br />
# При отсутствии регрессий и, при необходимости, после получения одобрения запроса от команды SecTeam (флажок sectime_verified меняется на "+") запрос отправляется на публикацию установкой флажка publishied в "?"<br />
# QA каждую пятницу публикует бюллетень с перечнем исправленных багов за истекшую неделю<br />
<br />
=== Команда поиска и устранения уязвимостей (SecTeam) ===<br />
# Подробности поиска уязвимостей описаны в документе [[Регламент по устранению уязвимостей]]<br />
# Список уязвимостей ведется на странице вики [http://wiki.rosalab.ru/ru/index.php/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:Security_Advisories Список уязвимостей] командой SecTeam.<br />
# Для каждой уязвимости из списка команда SecTeam выступает репортером и заводит баг<br />
# После того, как сборщики соберут исправленные пакеты и QA установить флажок secteam_verified в "?", SecTeam проверяет исправление уязвимости<br />
# Дополнительно могут проверяться и запросы с исправлениями уязвимостей, сделанные и не участниками команды SecTeam<br />
# При успешной проверке secteam_verified устанавливается в "+"<br />
<br />
=== Публикатор ===<br />
# Публикатор получает запрос на обновление после его одобрения командами QA и (если он содержит исправления уязвимостей) SecTeam<br />
# Публикатор обеспечивает появление пакетов обновлений в репозиториях и непротиворечивость репозиториев после публикации.<br />
# После успешной публикации флажок "publishied" устанавливается в "+" и запрос на обновление считается полностью закрытым.<br />
<br />
[[Категория:Регламенты ROSA]]</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_%D0%B2_%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%BD%D1%8B%D1%85_%D1%80%D0%B5%D0%BF%D0%BE%D0%B7%D0%B8%D1%82%D0%BE%D1%80%D0%B8%D1%8F%D1%85_ROSA_Linux&diff=18645
Регламент обновления пакетов в основных репозиториях ROSA Linux
2020-04-29T10:46:30Z
<p>Vladimir.potapov: /* Мейнтейнеры */</p>
<hr />
<div>=== Применимость ===<br />
Настоящий регламент описывает порядок добавления и исправления пакетов в репозиториях ROSA при взаимодействии пяти команд:<br />
# Команды репортеров, сообщающих об ошибках и уязвимостях в пакетной базе и выступающих с предложениями обновления пакетов<br />
# Команды сборщиков (мейнтейнеров), собирающих пакеты с новыми версиями программ и исправлениями ошибок и уязвимостей<br />
# Команды контроля качества (QA), контролирующих работоспособность исправленных пакетов и всей системы в целом после обновления<br />
# Команда контроля уязвимостей (SecTeam), отслеживающих текущие уязвимости дистрибутива и корректность исправления этих уязвимостей сборщиками<br />
# Публикатора, задачи которого - доступность исправленных пакетов на зеркалах дистрибутива, контроль целостности/замкнутости репозиториев после публикации, а также качества сборки самих пакетов (соответствие политикам сборки, принятым в дистрибутиве и т.п.)<br />
<br />
Данный порядок относится к работе с основными репозиториями ROSA Linux, за исключением репозитория сообщества ROSA Fresh (contrib) где контроль качества не производится.<br />
<br />
=== Общий порядок обновления ===<br />
# Общий порядок адресации каждого запроса на обновление - <br />
Репортеры (в т.ч. из SecTeam) -> Cборщики -> QA & SecTeam -> Публикатор<br />
# Допустимо совмещение ролей "репортер", "сборщик" и "публикатор", но недопустима ситуация, когда человек проверяет результаты своей сборки и публикует их. <br />
# Вся работа по обновлению пакетов происходит с помощью специально созданных в багзилле ROSA Linux багов - запросов на обновление<br />
<br />
=== Репортеры ===<br />
# Репортеры заводят в багзилле баги, обосновывающие необходимость исправления или добавления, с описанием ошибки, кодом уязвимости или необходимым им новым функционалом.<br />
# Альтернативным путем создания запроса на изменение пакетов в репозиториях для репортеров является пул-реквест в системе сборки ABF.<br />
# Репортеры являются заказчиками исправления, т.е. контролируют весь его процесс до попадания в репозитории.<br />
<br />
=== Сборщики ===<br />
# Сборщики получают информацию о багах от репортеров через почтовую рассылку багзиллы<br />
# Пакеты обновляются на основании заведенного в [http://bugs.rosalinux.ru багзилле] бага с заголовком [UPDATE REQUEST <платформа>] называемого запросом на обновление<br />
# В комментариях к запросу на обновления указываются ссылки на контейнеры с собранным для указанной платформы обновлением пакета и advisory - написанное по-английски обоснование обновления (например выход новой версии, исправление уязвимости)<br />
# После того, как закончено формирование запроса на обновление, он отправляется на контроль качества команде QA установкой флажка qa_verified в знак вопроса "?"<br />
<br />
=== Мейнтейнеры ===<br />
Мейнтейнер (сопровождающий) - совмещает в себе функции сборщика, репортера и ответственного за функциональность пакета. Мейнтейнер отслеживает его изменения, исправяет уязвимости и ошибки.<br />
# Если какой-то пакет имеет мейнтейнера, это должно быть прописано на abf<br />
# В пакет с указанным мейнтейнером имеет право вносить правки только мейнтейнер, остальные должны пользоваться пул-реквестами<br />
# Пул-реквесты должны рассматриваться мейнтейнером в течение недели, а критические - в течение 48 часов<br />
# 0-day уязвимости в своем пакете мейнтейнер должен исправлять и передавать на тестирование в течение 48 часов, критические - в течение недели<br />
# Баги в пакете, имеющем мейнтейнера, должны им рассматриваться (исправляться, отменяться или хотя бы комментироваться) в течение двух недель после назначения.<br />
<br />
=== Команда контроля качества (QA) ===<br />
# Команда QA получает запросы с установленным сборщиками флажком qa_verified<br />
# Команда QA проводит тестирование пакетов, используя [[Регламент тестирования]]<br />
# Если обновление содержит исправления уязвимостей, устанавливается флажок sectime_verified в "?" для параллельной проверки корректности исправления уязвимостей командой SecTeam<br />
# После проверки отсутствия регрессий функциональности у собранного пакета команда QA ставит флаг QA_verified "+" при успешной проверке и "-" при неуспешной.<br />
# При отсутствии регрессий и, при необходимости, после получения одобрения запроса от команды SecTeam (флажок sectime_verified меняется на "+") запрос отправляется на публикацию установкой флажка publishied в "?"<br />
# QA каждую пятницу публикует бюллетень с перечнем исправленных багов за истекшую неделю<br />
<br />
=== Команда поиска и устранения уязвимостей (SecTeam) ===<br />
# Подробности поиска уязвимостей описаны в документе [[Регламент по устранению уязвимостей]]<br />
# Список уязвимостей ведется на странице вики [http://wiki.rosalab.ru/ru/index.php/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:Security_Advisories Список уязвимостей] командой SecTeam.<br />
# Для каждой уязвимости из списка команда SecTeam выступает репортером и заводит баг<br />
# После того, как сборщики соберут исправленные пакеты и QA установить флажок secteam_verified в "?", SecTeam проверяет исправление уязвимости<br />
# Дополнительно могут проверяться и запросы с исправлениями уязвимостей, сделанные и не участниками команды SecTeam<br />
# При успешной проверке secteam_verified устанавливается в "+"<br />
<br />
=== Публикатор ===<br />
# Публикатор получает запрос на обновление после его одобрения командами QA и (если он содержит исправления уязвимостей) SecTeam<br />
# Публикатор обеспечивает появление пакетов обновлений в репозиториях и непротиворечивость репозиториев после публикации.<br />
# После успешной публикации флажок "publishied" устанавливается в "+" и запрос на обновление считается полностью закрытым.<br />
<br />
[[Категория:Регламенты ROSA]]</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_%D0%B2_%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%BD%D1%8B%D1%85_%D1%80%D0%B5%D0%BF%D0%BE%D0%B7%D0%B8%D1%82%D0%BE%D1%80%D0%B8%D1%8F%D1%85_ROSA_Linux&diff=18644
Регламент обновления пакетов в основных репозиториях ROSA Linux
2020-04-29T10:44:18Z
<p>Vladimir.potapov: /* Общий порядок обновления */</p>
<hr />
<div>=== Применимость ===<br />
Настоящий регламент описывает порядок добавления и исправления пакетов в репозиториях ROSA при взаимодействии пяти команд:<br />
# Команды репортеров, сообщающих об ошибках и уязвимостях в пакетной базе и выступающих с предложениями обновления пакетов<br />
# Команды сборщиков (мейнтейнеров), собирающих пакеты с новыми версиями программ и исправлениями ошибок и уязвимостей<br />
# Команды контроля качества (QA), контролирующих работоспособность исправленных пакетов и всей системы в целом после обновления<br />
# Команда контроля уязвимостей (SecTeam), отслеживающих текущие уязвимости дистрибутива и корректность исправления этих уязвимостей сборщиками<br />
# Публикатора, задачи которого - доступность исправленных пакетов на зеркалах дистрибутива, контроль целостности/замкнутости репозиториев после публикации, а также качества сборки самих пакетов (соответствие политикам сборки, принятым в дистрибутиве и т.п.)<br />
<br />
Данный порядок относится к работе с основными репозиториями ROSA Linux, за исключением репозитория сообщества ROSA Fresh (contrib) где контроль качества не производится.<br />
<br />
=== Общий порядок обновления ===<br />
# Общий порядок адресации каждого запроса на обновление - <br />
Репортеры (в т.ч. из SecTeam) -> Cборщики -> QA & SecTeam -> Публикатор<br />
# Допустимо совмещение ролей "репортер", "сборщик" и "публикатор", но недопустима ситуация, когда человек проверяет результаты своей сборки и публикует их. <br />
# Вся работа по обновлению пакетов происходит с помощью специально созданных в багзилле ROSA Linux багов - запросов на обновление<br />
<br />
=== Репортеры ===<br />
# Репортеры заводят в багзилле баги, обосновывающие необходимость исправления или добавления, с описанием ошибки, кодом уязвимости или необходимым им новым функционалом.<br />
# Альтернативным путем создания запроса на изменение пакетов в репозиториях для репортеров является пул-реквест в системе сборки ABF.<br />
# Репортеры являются заказчиками исправления, т.е. контролируют весь его процесс до попадания в репозитории.<br />
<br />
=== Сборщики ===<br />
# Сборщики получают информацию о багах от репортеров через почтовую рассылку багзиллы<br />
# Пакеты обновляются на основании заведенного в [http://bugs.rosalinux.ru багзилле] бага с заголовком [UPDATE REQUEST <платформа>] называемого запросом на обновление<br />
# В комментариях к запросу на обновления указываются ссылки на контейнеры с собранным для указанной платформы обновлением пакета и advisory - написанное по-английски обоснование обновления (например выход новой версии, исправление уязвимости)<br />
# После того, как закончено формирование запроса на обновление, он отправляется на контроль качества команде QA установкой флажка qa_verified в знак вопроса "?"<br />
<br />
=== Мейнтейнеры ===<br />
Мейнтейнер - больше, чем сборщик, это сопровождающий пакет в репозиториях ROSA, отслеживающий его изменения, исправляющий уязвимости и ошибки.<br />
# Если какой-то пакет имеет мейнтейнера, это должно быть прописано на abf<br />
# В пакет с указанным мейнтейнером имеет право вносить правки только мейнтейнер, остальные должны пользоваться пул-реквестами<br />
# Пул-реквесты должны рассматриваться мейнтейнером в течение недели, а критические - в течение 48 часов<br />
# 0-day уязвимости в своем пакете мейнтейнер должен исправлять и передавать на тестирование в течение 48 часов, критические - в течение недели<br />
# Баги в пакете, имеющем мейнтейнера, должны им рассматриваться (исправляться, отменяться или хотя бы комментироваться) в течение двух недель после назначения.<br />
<br />
=== Команда контроля качества (QA) ===<br />
# Команда QA получает запросы с установленным сборщиками флажком qa_verified<br />
# Команда QA проводит тестирование пакетов, используя [[Регламент тестирования]]<br />
# Если обновление содержит исправления уязвимостей, устанавливается флажок sectime_verified в "?" для параллельной проверки корректности исправления уязвимостей командой SecTeam<br />
# После проверки отсутствия регрессий функциональности у собранного пакета команда QA ставит флаг QA_verified "+" при успешной проверке и "-" при неуспешной.<br />
# При отсутствии регрессий и, при необходимости, после получения одобрения запроса от команды SecTeam (флажок sectime_verified меняется на "+") запрос отправляется на публикацию установкой флажка publishied в "?"<br />
# QA каждую пятницу публикует бюллетень с перечнем исправленных багов за истекшую неделю<br />
<br />
=== Команда поиска и устранения уязвимостей (SecTeam) ===<br />
# Подробности поиска уязвимостей описаны в документе [[Регламент по устранению уязвимостей]]<br />
# Список уязвимостей ведется на странице вики [http://wiki.rosalab.ru/ru/index.php/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:Security_Advisories Список уязвимостей] командой SecTeam.<br />
# Для каждой уязвимости из списка команда SecTeam выступает репортером и заводит баг<br />
# После того, как сборщики соберут исправленные пакеты и QA установить флажок secteam_verified в "?", SecTeam проверяет исправление уязвимости<br />
# Дополнительно могут проверяться и запросы с исправлениями уязвимостей, сделанные и не участниками команды SecTeam<br />
# При успешной проверке secteam_verified устанавливается в "+"<br />
<br />
=== Публикатор ===<br />
# Публикатор получает запрос на обновление после его одобрения командами QA и (если он содержит исправления уязвимостей) SecTeam<br />
# Публикатор обеспечивает появление пакетов обновлений в репозиториях и непротиворечивость репозиториев после публикации.<br />
# После успешной публикации флажок "publishied" устанавливается в "+" и запрос на обновление считается полностью закрытым.<br />
<br />
[[Категория:Регламенты ROSA]]</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_%D0%B2_%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%BD%D1%8B%D1%85_%D1%80%D0%B5%D0%BF%D0%BE%D0%B7%D0%B8%D1%82%D0%BE%D1%80%D0%B8%D1%8F%D1%85_ROSA_Linux&diff=18643
Регламент обновления пакетов в основных репозиториях ROSA Linux
2020-04-29T10:43:08Z
<p>Vladimir.potapov: /* Сборщики */</p>
<hr />
<div>=== Применимость ===<br />
Настоящий регламент описывает порядок добавления и исправления пакетов в репозиториях ROSA при взаимодействии пяти команд:<br />
# Команды репортеров, сообщающих об ошибках и уязвимостях в пакетной базе и выступающих с предложениями обновления пакетов<br />
# Команды сборщиков (мейнтейнеров), собирающих пакеты с новыми версиями программ и исправлениями ошибок и уязвимостей<br />
# Команды контроля качества (QA), контролирующих работоспособность исправленных пакетов и всей системы в целом после обновления<br />
# Команда контроля уязвимостей (SecTeam), отслеживающих текущие уязвимости дистрибутива и корректность исправления этих уязвимостей сборщиками<br />
# Публикатора, задачи которого - доступность исправленных пакетов на зеркалах дистрибутива, контроль целостности/замкнутости репозиториев после публикации, а также качества сборки самих пакетов (соответствие политикам сборки, принятым в дистрибутиве и т.п.)<br />
<br />
Данный порядок относится к работе с основными репозиториями ROSA Linux, за исключением репозитория сообщества ROSA Fresh (contrib) где контроль качества не производится.<br />
<br />
=== Общий порядок обновления ===<br />
# Общий порядок адресации каждого запроса на обновление - <br />
Репортеры (в т.ч. из SecTeam) -> Cборщики -> QA & SecTeam -> Публикатор<br />
# Допустимо совмещение ролей "репортер", "сборщик" и "публикатор", но недопустима ситуация, когда человек проверяет результаты своей сборки и публикует их. <br />
# Репортер-сборщик, отслеживающий обновления необходимого ему пакета и самостоятельно собирающий его, называется сопровождающим (мейнтейнером) и прописывается на abf.<br />
# Вся работа по обновлению пакетов происходит с помощью специально созданных в багзилле ROSA Linux багов - запросов на обновление<br />
<br />
=== Репортеры ===<br />
# Репортеры заводят в багзилле баги, обосновывающие необходимость исправления или добавления, с описанием ошибки, кодом уязвимости или необходимым им новым функционалом.<br />
# Альтернативным путем создания запроса на изменение пакетов в репозиториях для репортеров является пул-реквест в системе сборки ABF.<br />
# Репортеры являются заказчиками исправления, т.е. контролируют весь его процесс до попадания в репозитории.<br />
<br />
=== Сборщики ===<br />
# Сборщики получают информацию о багах от репортеров через почтовую рассылку багзиллы<br />
# Пакеты обновляются на основании заведенного в [http://bugs.rosalinux.ru багзилле] бага с заголовком [UPDATE REQUEST <платформа>] называемого запросом на обновление<br />
# В комментариях к запросу на обновления указываются ссылки на контейнеры с собранным для указанной платформы обновлением пакета и advisory - написанное по-английски обоснование обновления (например выход новой версии, исправление уязвимости)<br />
# После того, как закончено формирование запроса на обновление, он отправляется на контроль качества команде QA установкой флажка qa_verified в знак вопроса "?"<br />
<br />
=== Мейнтейнеры ===<br />
Мейнтейнер - больше, чем сборщик, это сопровождающий пакет в репозиториях ROSA, отслеживающий его изменения, исправляющий уязвимости и ошибки.<br />
# Если какой-то пакет имеет мейнтейнера, это должно быть прописано на abf<br />
# В пакет с указанным мейнтейнером имеет право вносить правки только мейнтейнер, остальные должны пользоваться пул-реквестами<br />
# Пул-реквесты должны рассматриваться мейнтейнером в течение недели, а критические - в течение 48 часов<br />
# 0-day уязвимости в своем пакете мейнтейнер должен исправлять и передавать на тестирование в течение 48 часов, критические - в течение недели<br />
# Баги в пакете, имеющем мейнтейнера, должны им рассматриваться (исправляться, отменяться или хотя бы комментироваться) в течение двух недель после назначения.<br />
<br />
=== Команда контроля качества (QA) ===<br />
# Команда QA получает запросы с установленным сборщиками флажком qa_verified<br />
# Команда QA проводит тестирование пакетов, используя [[Регламент тестирования]]<br />
# Если обновление содержит исправления уязвимостей, устанавливается флажок sectime_verified в "?" для параллельной проверки корректности исправления уязвимостей командой SecTeam<br />
# После проверки отсутствия регрессий функциональности у собранного пакета команда QA ставит флаг QA_verified "+" при успешной проверке и "-" при неуспешной.<br />
# При отсутствии регрессий и, при необходимости, после получения одобрения запроса от команды SecTeam (флажок sectime_verified меняется на "+") запрос отправляется на публикацию установкой флажка publishied в "?"<br />
# QA каждую пятницу публикует бюллетень с перечнем исправленных багов за истекшую неделю<br />
<br />
=== Команда поиска и устранения уязвимостей (SecTeam) ===<br />
# Подробности поиска уязвимостей описаны в документе [[Регламент по устранению уязвимостей]]<br />
# Список уязвимостей ведется на странице вики [http://wiki.rosalab.ru/ru/index.php/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:Security_Advisories Список уязвимостей] командой SecTeam.<br />
# Для каждой уязвимости из списка команда SecTeam выступает репортером и заводит баг<br />
# После того, как сборщики соберут исправленные пакеты и QA установить флажок secteam_verified в "?", SecTeam проверяет исправление уязвимости<br />
# Дополнительно могут проверяться и запросы с исправлениями уязвимостей, сделанные и не участниками команды SecTeam<br />
# При успешной проверке secteam_verified устанавливается в "+"<br />
<br />
=== Публикатор ===<br />
# Публикатор получает запрос на обновление после его одобрения командами QA и (если он содержит исправления уязвимостей) SecTeam<br />
# Публикатор обеспечивает появление пакетов обновлений в репозиториях и непротиворечивость репозиториев после публикации.<br />
# После успешной публикации флажок "publishied" устанавливается в "+" и запрос на обновление считается полностью закрытым.<br />
<br />
[[Категория:Регламенты ROSA]]</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_%D0%B2_%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%BD%D1%8B%D1%85_%D1%80%D0%B5%D0%BF%D0%BE%D0%B7%D0%B8%D1%82%D0%BE%D1%80%D0%B8%D1%8F%D1%85_ROSA_Linux&diff=18642
Регламент обновления пакетов в основных репозиториях ROSA Linux
2020-04-29T10:38:12Z
<p>Vladimir.potapov: /* Применимость */</p>
<hr />
<div>=== Применимость ===<br />
Настоящий регламент описывает порядок добавления и исправления пакетов в репозиториях ROSA при взаимодействии пяти команд:<br />
# Команды репортеров, сообщающих об ошибках и уязвимостях в пакетной базе и выступающих с предложениями обновления пакетов<br />
# Команды сборщиков (мейнтейнеров), собирающих пакеты с новыми версиями программ и исправлениями ошибок и уязвимостей<br />
# Команды контроля качества (QA), контролирующих работоспособность исправленных пакетов и всей системы в целом после обновления<br />
# Команда контроля уязвимостей (SecTeam), отслеживающих текущие уязвимости дистрибутива и корректность исправления этих уязвимостей сборщиками<br />
# Публикатора, задачи которого - доступность исправленных пакетов на зеркалах дистрибутива, контроль целостности/замкнутости репозиториев после публикации, а также качества сборки самих пакетов (соответствие политикам сборки, принятым в дистрибутиве и т.п.)<br />
<br />
Данный порядок относится к работе с основными репозиториями ROSA Linux, за исключением репозитория сообщества ROSA Fresh (contrib) где контроль качества не производится.<br />
<br />
=== Общий порядок обновления ===<br />
# Общий порядок адресации каждого запроса на обновление - <br />
Репортеры (в т.ч. из SecTeam) -> Cборщики -> QA & SecTeam -> Публикатор<br />
# Допустимо совмещение ролей "репортер", "сборщик" и "публикатор", но недопустима ситуация, когда человек проверяет результаты своей сборки и публикует их. <br />
# Репортер-сборщик, отслеживающий обновления необходимого ему пакета и самостоятельно собирающий его, называется сопровождающим (мейнтейнером) и прописывается на abf.<br />
# Вся работа по обновлению пакетов происходит с помощью специально созданных в багзилле ROSA Linux багов - запросов на обновление<br />
<br />
=== Репортеры ===<br />
# Репортеры заводят в багзилле баги, обосновывающие необходимость исправления или добавления, с описанием ошибки, кодом уязвимости или необходимым им новым функционалом.<br />
# Альтернативным путем создания запроса на изменение пакетов в репозиториях для репортеров является пул-реквест в системе сборки ABF.<br />
# Репортеры являются заказчиками исправления, т.е. контролируют весь его процесс до попадания в репозитории.<br />
<br />
=== Сборщики ===<br />
# Сборщики получают информацию о багах от репортеров через почтовую рассылку багзиллы<br />
# Пакеты обновляются на основании заведенного в [http://bugs.rosalinux.ru багзилле] бага с заголовком [UPDATE REQUEST <платформа>] называемого запросом на обновление<br />
# В комментариях к запросу на обновления указываются ссылки на контейнеры с собранным для указанной платформы обновлением пакета и advisory - написанное по-английски обоснование обновления (например выход новой версии, исправление уязвимости)<br />
# После того, как закончено формирование запроса на обновление, он отправляется на контроль качества команде QA установкой флажка qa_verified в знак вопроса "?"<br />
<br />
=== Команда контроля качества (QA) ===<br />
# Команда QA получает запросы с установленным сборщиками флажком qa_verified<br />
# Команда QA проводит тестирование пакетов, используя [[Регламент тестирования]]<br />
# Если обновление содержит исправления уязвимостей, устанавливается флажок sectime_verified в "?" для параллельной проверки корректности исправления уязвимостей командой SecTeam<br />
# После проверки отсутствия регрессий функциональности у собранного пакета команда QA ставит флаг QA_verified "+" при успешной проверке и "-" при неуспешной.<br />
# При отсутствии регрессий и, при необходимости, после получения одобрения запроса от команды SecTeam (флажок sectime_verified меняется на "+") запрос отправляется на публикацию установкой флажка publishied в "?"<br />
# QA каждую пятницу публикует бюллетень с перечнем исправленных багов за истекшую неделю<br />
<br />
=== Команда поиска и устранения уязвимостей (SecTeam) ===<br />
# Подробности поиска уязвимостей описаны в документе [[Регламент по устранению уязвимостей]]<br />
# Список уязвимостей ведется на странице вики [http://wiki.rosalab.ru/ru/index.php/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:Security_Advisories Список уязвимостей] командой SecTeam.<br />
# Для каждой уязвимости из списка команда SecTeam выступает репортером и заводит баг<br />
# После того, как сборщики соберут исправленные пакеты и QA установить флажок secteam_verified в "?", SecTeam проверяет исправление уязвимости<br />
# Дополнительно могут проверяться и запросы с исправлениями уязвимостей, сделанные и не участниками команды SecTeam<br />
# При успешной проверке secteam_verified устанавливается в "+"<br />
<br />
=== Публикатор ===<br />
# Публикатор получает запрос на обновление после его одобрения командами QA и (если он содержит исправления уязвимостей) SecTeam<br />
# Публикатор обеспечивает появление пакетов обновлений в репозиториях и непротиворечивость репозиториев после публикации.<br />
# После успешной публикации флажок "publishied" устанавливается в "+" и запрос на обновление считается полностью закрытым.<br />
<br />
[[Категория:Регламенты ROSA]]</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F&diff=18641
Регламент тестирования
2020-04-29T10:32:08Z
<p>Vladimir.potapov: /* Тестирование запуска и работы связанных с обновлением приложений */</p>
<hr />
<div>[[Category:Регламенты ROSA]]<br />
<br />
=== Политика ===<br />
QA, наряду с мейнтейнерами пакетов отвечает за стабильность и функциональность установленного у пользователей дистрибутива при его обновлениях. <br />
<br />
До установки обновлений дистрибутив работает. Любое обновление — риск его обрушить.<br />
Поэтому политика QA обязана быть консервативной и даже несколько параноидальной — при малейших сомнениях должны назначаться дополнительные проверки, пакеты должны отклоняться, направляться на пересборку.<br />
<br />
Политика QA вступает в конфликт с интересами сборщиков пакетов, желающих быстрее увидеть в репозиториях исправленную версию — конфликт этот должен быть конструктивным, приводящим к непрерывному повышению функциональности и стабильности дистрибутива.<br />
<br />
==== Классификация обновлений по степени опасности ====<br />
<blockquote><br />
Меня не интересуют их намерения, меня интересуют их возможности — © Отто Фон Бисмарк<br />
</blockquote><br />
<br />
Классификация исходит из максимально возможного урона (полный отказ функционирования компонента), который может нанести устанавливаемое обновление. Чем выше степень опасности, тем более тщательным должно быть тестирование.<br />
<br />
;0: Критические обновления. Ядро, файловая система, система прав доступа, скрипты загрузки, <tt>systemd</tt>, <tt>glibc</tt>, <tt>dracut</tt>, <tt>grub</tt>, <tt>bash</tt> и прочие основные вещи, если удалить которые система не загрузится даже в консоли.<br />
;1: Обновления драйверов устройств, т.е. те же критические обновления, но актуальные не для всех пользователей. <br />
;2: Обновления сетевых компонентов: NetworkManager, сетевых скриптов, системы сетевой инициализации и системы обновлений (curl, urpmi). Они опасны тем, что если сеть упадет, пользователю без сети будет затруднительно получить исправленный пакет, когда мы его выпустим и установить обновление. <br />
;3: Обновления графических компонент и скриптов — X-ов, менеджера входа, графических библиотек, драйверов, '''perl, python''' — то, без чего невозможен вход в систему в графическом режиме. Т.к. обновление системы, при наличии сети, возможно и не в графике - класс опасности обновлений не самый высокий<br />
;4: Обновление пользовательских пакетов, установленных по-умолчанию в системе. Эти пакеты стоят практически у всех и их ошибки будут влиять на максимальное количество пользователей, однако они могут быть оперативно исправлены потому класс опасности не очень высокий. Туда же нужно отнести популярные программы не входящие в поставку — <tt>gimp</tt>, <tt>inkscape</tt>, <tt>audacity</tt>, <tt>vlc</tt>, <tt>kdenive</tt>, <tt>opera</tt>, <tt>chromium-browser</tt>, <tt>skype</tt>.<br />
;5: Обновление прочих пользовательских пакетов. Они затронут только тех, у кого эти программы стоят.<br />
;6: Обновление пакетов, необходимых только для сборки дистрибутива или работы с abf. Почти никому кроме нас они не интересны, потому класс опасности самый низкий.<br />
<br />
==== Задача ====<br />
* Главная задача QA — поиск регрессий, то есть таких изменений в дистрибутиве, которые уменьшают его функциональность по сравнению с предыдущим состоянием.<br />
* Также задачей QA является внесение в багзиллу всех найденных в процессе тестирования ошибок, не относящихся к регрессиям.<br />
<br />
==== Общие положения ====<br />
* Запрос на обновление пишется в багзилле <br />
* Все сообщения пишутся на английском языке.<br />
* Порядок принятие запросов на тестирование командой QA в общем случае — в порядке возрастания номеров багов, возможны исключения, связанные со срочностью или трудностями в тестировании определенных пакетов.<br />
* Список запросов на обновление можно открыть по ссылке http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=qa_verified%3F&o1=substring&list_id=38774<br />
<br />
==== Срок тестирования ====<br />
* Срок тестирования пакета — '''одна неделя''', за это время служба QA должня проверить пакет и вынести заключение. Срок тестирования может быть увеличен при необходимости тестирования внешними тестерами на отсутствующих у службы QA аппаратно-программных конфигурациях, в этом случае в запросе на обновление задержка должна быть обоснована службой QA.<br />
* Для пакета, который нужно проверить очень срочно, сборщик должен установить приоритет <tt>Highest Critical</tt>, чтобы он выделялся красным цветом в списке. Такие пакеты рассматриваются в течение '''48 часов''' рабочего времени.<br />
* Норма выработки на одного тестера QA - 20 одобренных запросов в неделю, обычно ошибки содержат 10-20% запросов, так что тестер QA в среднем обрабатывает 5 запросов в день.<br />
<br />
=== Процедура тестирования ===<br />
<br />
==== Требования к запросу на обновление ====<br />
# QA Team тестирует пакеты-кандидаты на добавление в репозитории <tt>main/updates, non-free/updates и restricted/updates</tt>.<br />
# Пакет должен быть собран в общедоступном репозитории (не <tt>_personal</tt>).<br />
# Для архитектурно-зависимых пакетов должны быть представлены все поддерживаемые архитектуры (<tt>i586</tt> и <tt>x64</tt>).<br />
# Описание обновления должно содержать все изменения, которые нужно протестировать.<br />
При несоответствии запроса на обновление этим требованиям необходимо сообщить об этом инициатору запроса с помощью комментария.<br />
В случае, если до пятницы запрос не исправлен согласно требованиям, он отклоняется.<br />
<br />
==== Тестирование установки пакетов ====<br />
# Система перед тестовым обновлением должна соответствовать стандартным репозиториям, с подключенными тестингами. Это можно проверить запуском <tt>urpm-reposync</tt> из пакета <tt>urpm-tools</tt><br />
# Пакеты для тестирования устанавливаются и в графическом, и в текстовом режиме.<br />
## Репозиторий подключается как репозиторий с обновлениями.<br />
## Запускается стандартная процедура обновления.<br />
# Для пакетов, установленных в системе по-умолчанию, проверяется их обновление.<br />
# Для пакетов, не установленных в системе, проверяется как их обновление, так и первоначальная установка при подключенных тестовых контейнерах.<br />
# Установка пакетов проверяется для обеих архитектур. Так как ошибки установки не обычно не зависят от архитектуры, обычно достаточно проверить на одной архитектуре установку в графическом режиме, а на другой — обновление в текстовом, или наоборот.<br />
<br />
При ошибках установки или обновления пакета необходимо сообщить об этом инициатору запроса с помощью комментария. В случае, если до пятницы ошибка установки не исправлена, запрос отклоняется.<br />
<br />
==== Тестирование на функционирование и устойчивость системы после обновления ====<br />
При тестировании системы проверяется:<br />
# Стабильность и внешний вид обновленной системы после перезагрузки.<br />
# Стабильность и внешний вид обновленной системы после пробуждения из спящего режима. Тестирование стабильности и производительности может проводиться, например, с помощью теста Unigine Valley под wine и тестом браузера https://webglsamples.org/aquarium/aquarium.html<br />
# Ошибки загрузки демонов, например, с помощью <tt>systemctl | grep failed</tt>.<br />
# Ошибки непрерывного роста файла <tt>.xsession-errors</tt>.<br />
# Журнал ошибок, командами '''journalctl -b |grep fail''' и '''journalctl -b |grep error''' (не должно быть новых ошибок, если они появились - нужно найти связанное с ошибкой обновление и написать инициатору)<br />
# Работа URPMI — дальнейшее обновление пакетов.<br />
# Установка и удаление dkms-модулей (например, установкой проприетарных драйверов с последующим откатом на свободные)<br />
# Сохранением загрузчиком определения других операционных систем, установленных на тестовом компьютере<br />
# Сохранение даты-времени на тестируемой машине после перезагрузки и пробуждения из спящего режима<br />
# Работа системы поиска по содержимому офисных файлов<br />
<br />
При ошибках функционирования или устойчивости системы, связанной с обновлением, необходимо сообщить об этом инициатору запроса с помощью комментария. <br />
В случае, если до пятницы ошибка не исправлена, запрос отклоняется.<br />
<br />
==== Тестирование запуска и работы связанных с обновлением приложений ====<br />
Проверяются:<br />
# Тестирование запуска и простейших операций со связанными с тестируемым пакетом программами, рекомендуется контроль сообщений при запуске программы из консоли.<br />
# Связанные с библиотеками из проверяемого пакета программы легче всего установить, попробовав удалить пакет с помощью <tt>urpme</tt> (для установленных в системе программ) или <tt>urpmq --whatrequires</tt> (для всех программ из подключенных репозиториев).<br />
# Изменения в интерфейсах обновляемых библиотек и, соответственно, необходимость перекомпиляции связанных пакетов с помощью сервиса https://abi-laboratory.pro/tracker/<br />
# Для пакетов, предоставляющих библиотеки, проверяются использующие эти библиотеки приложения из main, их можно определить командой <tt>urpmq --whatrequires <названиепакета></tt><br />
# Регрессии в локализации графического интерфейса и страниц справки.<br />
# Для тестирования браузеров в дополнение к https://webglsamples.org/aquarium/aquarium.html применяются.<br />
## Тест html5 https://html5test.com/ (сравнить результат до и после обновления, не должно быть регресса)<br />
## Почтовые онлайновые сервисы http://mail.yandex.ru http://mail.google.com<br />
## Яндекс и гугл-карты https://yandex.ru/maps/-/CVTQITy0 https://www.google.ru/maps/@52.2609339,104.3096872,15z?hl=ru<br />
## xml|xsl трансляцию и кодировки на http://base.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=160129;div=LAW;rnd=0.4700782325977544 и<br />
## Воспроизведение видео http://techslides.com/sample-webm-ogg-and-mp4-video-files-for-html5/ <br />
## Воспроизведение [http://youtu.be/37l7P5V1eXU видео с youtube]<br />
## Работа флэша на примере игры [http://vseigru.net/igry-zombi/2541-igra-zombi-protiv-rastenij.html Растения против зомби] и [http://kino.sputnik.ru/films/ivan+vasilyevich+menyayet+professiyu+1973]<br />
## Уязвимости SSL с помощью https://www.ssllabs.com/ssltest/viewMyClient.html<br />
## Тестирование печати<br />
## Тестирование установки браузера по-умолчанию из настроек<br />
<br />
В случае:<br />
# нахождения регрессии функционала или локализации, о них сообщается инициатору запроса в комментариях к запросу на обновление. <br />
# отсутствия до пятницы исправления найденной QA регрессии или обоснования мейнтейнером пакета невозможности исправления - запрос отклоняется.<br />
# если пакет не имеет постоянного мейнтейнера и собирается случайным сборщиком, QA отвечает за функциональность пакета и может заблокировать обновление при её регрессии<br />
# нахождения ошибок (не регрессий!) - заводится новый баг, его номер указывается в запросе на обновление.<br />
<br />
==== Тестирование изменений ====<br />
* Применяется при тестировании обновлений, изменяющих внешний вид или поведение системы.<br />
<br />
Включает себя<br />
# Воспроизведение особенностей внешнего вида или поведения системы ДО исправления.<br />
# Воспроизведение измененных обновлений особенностей по их описанию.<br />
<br />
Например, если в advisory сказано, что «вышла новая версия программы» при тестировании изменений нужно, как минимум, убедиться что версия изменилась.<br />
<br />
В случае если не все описанные изменения действительно присутствуют в тестируемом пакете, пакет принимается и в итоговый отчет (Advisory), вносятся только реально проведенные изменения.<br />
В случае значительного отклонения запрошенных и полученных изменений пакет может быть отклонен.<br />
<br />
==== Расширенное тестирование ====<br />
# Расширенное тестирование проводится добровольцами с помощью репозиториев testing, соответствующих основным репозиториям. <br />
# В течение недели (понедельник-четверг) все проверяемые QA обновления, кроме срочных, отправляются в тестинг, при этом в багзилле ставится статус verified и пишется The update is sent to expanded testing<br />
# В пятницу, руководитель QA:<br />
## Еще раз контролирует, все ли пакеты направлены в тестинг-репозитории, при помощи отключения источников-контейнеров и выполнения программы '''urpm-reposync''' с включенными тестингами. Результатом выполнения команды должно быть отсутствие пакетов на синхронизацию<br />
## Проверяет, дошли ли обновления до зеркал<br />
## Контролирует возможность обновления до тестингов с момента предыдущего релиза платформы путем установки релизного образа и его обновления с подключенными тестингами <br />
## Обновляет до тестингов системы на всех доступных тестовых стендах и проверяет их на устойчивость<br />
## На форуме и в сообществе вконтакте объявляет "пятничное тестирование", к нему выпускает бюллетень с полным списком обновлений и методикой их тестирования.<br />
# В понедельник руководитель QA читает отзывы пользователей и по их итогам, а также по итогам эксплуатации тестовых стендов в выходные дни, обрабатывает запросы на обновление и передает их на публикацию (или отклоняет)<br />
<br />
=== Завершение тестирования ===<br />
<br />
==== Положительный результат тестирования ====<br />
# По окончании тестирования при его успехе ставится индикатор успешного тестирования QA «+» и пишется отчет (Advisory), содержащий:<br />
## Название пакета с исходниками (src.rpm).<br />
## Версию пакета.<br />
## Отчет о тестировании (advisory).<br />
## Надпись «QA verified».<br />
# Если пакет содержит изменения, связанные с секретностью или же собран не сотрудником Росы — посылается запрос Secure team (взводится флажок secteam_verified «?»).<br />
# Если тестирование secure не нужно, пакет передается на публикацию (взводится соответствующий published «?»).<br />
# В случае успешного тестирования пакет может быть оставлен в системе. В случае ошибок систему нужно привести к первоначальному виду с помощью деинсталляции пакета или утилиты <tt>urpm-reposync</tt> из <tt>urpm-repotools</tt>.<br />
<br />
==== Отрицательный результат тестирования ====<br />
# При отклонении пакета ставится индикатор отклонения QA «-»,<br />
# В комментариях пишется причина отклонения запроса и в конце комментария добавляется «QA Denied».<br />
# При отрицательном результате тестирования сборщик может выложить исправленные контейнеры в тот же запрос и снова установить «?» в «qa_requested».</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F&diff=18640
Регламент тестирования
2020-04-29T10:30:52Z
<p>Vladimir.potapov: /* Тестирование запуска и работы связанных с обновлением приложений */</p>
<hr />
<div>[[Category:Регламенты ROSA]]<br />
<br />
=== Политика ===<br />
QA, наряду с мейнтейнерами пакетов отвечает за стабильность и функциональность установленного у пользователей дистрибутива при его обновлениях. <br />
<br />
До установки обновлений дистрибутив работает. Любое обновление — риск его обрушить.<br />
Поэтому политика QA обязана быть консервативной и даже несколько параноидальной — при малейших сомнениях должны назначаться дополнительные проверки, пакеты должны отклоняться, направляться на пересборку.<br />
<br />
Политика QA вступает в конфликт с интересами сборщиков пакетов, желающих быстрее увидеть в репозиториях исправленную версию — конфликт этот должен быть конструктивным, приводящим к непрерывному повышению функциональности и стабильности дистрибутива.<br />
<br />
==== Классификация обновлений по степени опасности ====<br />
<blockquote><br />
Меня не интересуют их намерения, меня интересуют их возможности — © Отто Фон Бисмарк<br />
</blockquote><br />
<br />
Классификация исходит из максимально возможного урона (полный отказ функционирования компонента), который может нанести устанавливаемое обновление. Чем выше степень опасности, тем более тщательным должно быть тестирование.<br />
<br />
;0: Критические обновления. Ядро, файловая система, система прав доступа, скрипты загрузки, <tt>systemd</tt>, <tt>glibc</tt>, <tt>dracut</tt>, <tt>grub</tt>, <tt>bash</tt> и прочие основные вещи, если удалить которые система не загрузится даже в консоли.<br />
;1: Обновления драйверов устройств, т.е. те же критические обновления, но актуальные не для всех пользователей. <br />
;2: Обновления сетевых компонентов: NetworkManager, сетевых скриптов, системы сетевой инициализации и системы обновлений (curl, urpmi). Они опасны тем, что если сеть упадет, пользователю без сети будет затруднительно получить исправленный пакет, когда мы его выпустим и установить обновление. <br />
;3: Обновления графических компонент и скриптов — X-ов, менеджера входа, графических библиотек, драйверов, '''perl, python''' — то, без чего невозможен вход в систему в графическом режиме. Т.к. обновление системы, при наличии сети, возможно и не в графике - класс опасности обновлений не самый высокий<br />
;4: Обновление пользовательских пакетов, установленных по-умолчанию в системе. Эти пакеты стоят практически у всех и их ошибки будут влиять на максимальное количество пользователей, однако они могут быть оперативно исправлены потому класс опасности не очень высокий. Туда же нужно отнести популярные программы не входящие в поставку — <tt>gimp</tt>, <tt>inkscape</tt>, <tt>audacity</tt>, <tt>vlc</tt>, <tt>kdenive</tt>, <tt>opera</tt>, <tt>chromium-browser</tt>, <tt>skype</tt>.<br />
;5: Обновление прочих пользовательских пакетов. Они затронут только тех, у кого эти программы стоят.<br />
;6: Обновление пакетов, необходимых только для сборки дистрибутива или работы с abf. Почти никому кроме нас они не интересны, потому класс опасности самый низкий.<br />
<br />
==== Задача ====<br />
* Главная задача QA — поиск регрессий, то есть таких изменений в дистрибутиве, которые уменьшают его функциональность по сравнению с предыдущим состоянием.<br />
* Также задачей QA является внесение в багзиллу всех найденных в процессе тестирования ошибок, не относящихся к регрессиям.<br />
<br />
==== Общие положения ====<br />
* Запрос на обновление пишется в багзилле <br />
* Все сообщения пишутся на английском языке.<br />
* Порядок принятие запросов на тестирование командой QA в общем случае — в порядке возрастания номеров багов, возможны исключения, связанные со срочностью или трудностями в тестировании определенных пакетов.<br />
* Список запросов на обновление можно открыть по ссылке http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=qa_verified%3F&o1=substring&list_id=38774<br />
<br />
==== Срок тестирования ====<br />
* Срок тестирования пакета — '''одна неделя''', за это время служба QA должня проверить пакет и вынести заключение. Срок тестирования может быть увеличен при необходимости тестирования внешними тестерами на отсутствующих у службы QA аппаратно-программных конфигурациях, в этом случае в запросе на обновление задержка должна быть обоснована службой QA.<br />
* Для пакета, который нужно проверить очень срочно, сборщик должен установить приоритет <tt>Highest Critical</tt>, чтобы он выделялся красным цветом в списке. Такие пакеты рассматриваются в течение '''48 часов''' рабочего времени.<br />
* Норма выработки на одного тестера QA - 20 одобренных запросов в неделю, обычно ошибки содержат 10-20% запросов, так что тестер QA в среднем обрабатывает 5 запросов в день.<br />
<br />
=== Процедура тестирования ===<br />
<br />
==== Требования к запросу на обновление ====<br />
# QA Team тестирует пакеты-кандидаты на добавление в репозитории <tt>main/updates, non-free/updates и restricted/updates</tt>.<br />
# Пакет должен быть собран в общедоступном репозитории (не <tt>_personal</tt>).<br />
# Для архитектурно-зависимых пакетов должны быть представлены все поддерживаемые архитектуры (<tt>i586</tt> и <tt>x64</tt>).<br />
# Описание обновления должно содержать все изменения, которые нужно протестировать.<br />
При несоответствии запроса на обновление этим требованиям необходимо сообщить об этом инициатору запроса с помощью комментария.<br />
В случае, если до пятницы запрос не исправлен согласно требованиям, он отклоняется.<br />
<br />
==== Тестирование установки пакетов ====<br />
# Система перед тестовым обновлением должна соответствовать стандартным репозиториям, с подключенными тестингами. Это можно проверить запуском <tt>urpm-reposync</tt> из пакета <tt>urpm-tools</tt><br />
# Пакеты для тестирования устанавливаются и в графическом, и в текстовом режиме.<br />
## Репозиторий подключается как репозиторий с обновлениями.<br />
## Запускается стандартная процедура обновления.<br />
# Для пакетов, установленных в системе по-умолчанию, проверяется их обновление.<br />
# Для пакетов, не установленных в системе, проверяется как их обновление, так и первоначальная установка при подключенных тестовых контейнерах.<br />
# Установка пакетов проверяется для обеих архитектур. Так как ошибки установки не обычно не зависят от архитектуры, обычно достаточно проверить на одной архитектуре установку в графическом режиме, а на другой — обновление в текстовом, или наоборот.<br />
<br />
При ошибках установки или обновления пакета необходимо сообщить об этом инициатору запроса с помощью комментария. В случае, если до пятницы ошибка установки не исправлена, запрос отклоняется.<br />
<br />
==== Тестирование на функционирование и устойчивость системы после обновления ====<br />
При тестировании системы проверяется:<br />
# Стабильность и внешний вид обновленной системы после перезагрузки.<br />
# Стабильность и внешний вид обновленной системы после пробуждения из спящего режима. Тестирование стабильности и производительности может проводиться, например, с помощью теста Unigine Valley под wine и тестом браузера https://webglsamples.org/aquarium/aquarium.html<br />
# Ошибки загрузки демонов, например, с помощью <tt>systemctl | grep failed</tt>.<br />
# Ошибки непрерывного роста файла <tt>.xsession-errors</tt>.<br />
# Журнал ошибок, командами '''journalctl -b |grep fail''' и '''journalctl -b |grep error''' (не должно быть новых ошибок, если они появились - нужно найти связанное с ошибкой обновление и написать инициатору)<br />
# Работа URPMI — дальнейшее обновление пакетов.<br />
# Установка и удаление dkms-модулей (например, установкой проприетарных драйверов с последующим откатом на свободные)<br />
# Сохранением загрузчиком определения других операционных систем, установленных на тестовом компьютере<br />
# Сохранение даты-времени на тестируемой машине после перезагрузки и пробуждения из спящего режима<br />
# Работа системы поиска по содержимому офисных файлов<br />
<br />
При ошибках функционирования или устойчивости системы, связанной с обновлением, необходимо сообщить об этом инициатору запроса с помощью комментария. <br />
В случае, если до пятницы ошибка не исправлена, запрос отклоняется.<br />
<br />
==== Тестирование запуска и работы связанных с обновлением приложений ====<br />
Проверяются:<br />
# Тестирование запуска и простейших операций со связанными с тестируемым пакетом программами, рекомендуется контроль сообщений при запуске программы из консоли.<br />
# Связанные с библиотеками из проверяемого пакета программы легче всего установить, попробовав удалить пакет с помощью <tt>urpme</tt> (для установленных в системе программ) или <tt>urpmq --whatrequires</tt> (для всех программ из подключенных репозиториев).<br />
# Изменения в интерфейсах обновляемых библиотек и, соответственно, необходимость перекомпиляции связанных пакетов с помощью сервиса https://abi-laboratory.pro/tracker/<br />
# Для пакетов, предоставляющих библиотеки, проверяются использующие эти библиотеки приложения из main, их можно определить командой <tt>urpmq --whatrequires <названиепакета></tt><br />
# Регрессии в локализации графического интерфейса и страниц справки.<br />
# Для тестирования браузеров в дополнение к https://webglsamples.org/aquarium/aquarium.html применяются.<br />
## Тест html5 https://html5test.com/ (сравнить результат до и после обновления, не должно быть регресса)<br />
## Почтовые онлайновые сервисы http://mail.yandex.ru http://mail.google.com<br />
## Яндекс и гугл-карты https://yandex.ru/maps/-/CVTQITy0 https://www.google.ru/maps/@52.2609339,104.3096872,15z?hl=ru<br />
## xml|xsl трансляцию и кодировки на http://base.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=160129;div=LAW;rnd=0.4700782325977544 и<br />
## Воспроизведение видео http://techslides.com/sample-webm-ogg-and-mp4-video-files-for-html5/ <br />
## Воспроизведение [http://youtu.be/37l7P5V1eXU видео с youtube]<br />
## Работа флэша на примере игры [http://vseigru.net/igry-zombi/2541-igra-zombi-protiv-rastenij.html Растения против зомби] и [http://kino.sputnik.ru/films/ivan+vasilyevich+menyayet+professiyu+1973]<br />
## Уязвимости SSL с помощью https://www.ssllabs.com/ssltest/viewMyClient.html<br />
## Тестирование печати<br />
## Тестирование установки браузера по-умолчанию из настроек<br />
<br />
В случае:<br />
# нахождения регрессии функционала или локализации, о них сообщается инициатору запроса в комментариях к запросу на обновление. <br />
# отсутствия до пятницы исправления найденной QA регрессии или обоснования мейнтейнером пакета невозможности исправления - запрос отклоняется.<br />
# если пакет не имеет постоянного мейнтейнера и собирается случайным сборщиком, QA отвечает за его функциональность и может заблокировать обновление при её регрессии<br />
# нахождения ошибок (не регрессий!) - заводится новый баг, его номер указывается в запросе на обновление.<br />
<br />
==== Тестирование изменений ====<br />
* Применяется при тестировании обновлений, изменяющих внешний вид или поведение системы.<br />
<br />
Включает себя<br />
# Воспроизведение особенностей внешнего вида или поведения системы ДО исправления.<br />
# Воспроизведение измененных обновлений особенностей по их описанию.<br />
<br />
Например, если в advisory сказано, что «вышла новая версия программы» при тестировании изменений нужно, как минимум, убедиться что версия изменилась.<br />
<br />
В случае если не все описанные изменения действительно присутствуют в тестируемом пакете, пакет принимается и в итоговый отчет (Advisory), вносятся только реально проведенные изменения.<br />
В случае значительного отклонения запрошенных и полученных изменений пакет может быть отклонен.<br />
<br />
==== Расширенное тестирование ====<br />
# Расширенное тестирование проводится добровольцами с помощью репозиториев testing, соответствующих основным репозиториям. <br />
# В течение недели (понедельник-четверг) все проверяемые QA обновления, кроме срочных, отправляются в тестинг, при этом в багзилле ставится статус verified и пишется The update is sent to expanded testing<br />
# В пятницу, руководитель QA:<br />
## Еще раз контролирует, все ли пакеты направлены в тестинг-репозитории, при помощи отключения источников-контейнеров и выполнения программы '''urpm-reposync''' с включенными тестингами. Результатом выполнения команды должно быть отсутствие пакетов на синхронизацию<br />
## Проверяет, дошли ли обновления до зеркал<br />
## Контролирует возможность обновления до тестингов с момента предыдущего релиза платформы путем установки релизного образа и его обновления с подключенными тестингами <br />
## Обновляет до тестингов системы на всех доступных тестовых стендах и проверяет их на устойчивость<br />
## На форуме и в сообществе вконтакте объявляет "пятничное тестирование", к нему выпускает бюллетень с полным списком обновлений и методикой их тестирования.<br />
# В понедельник руководитель QA читает отзывы пользователей и по их итогам, а также по итогам эксплуатации тестовых стендов в выходные дни, обрабатывает запросы на обновление и передает их на публикацию (или отклоняет)<br />
<br />
=== Завершение тестирования ===<br />
<br />
==== Положительный результат тестирования ====<br />
# По окончании тестирования при его успехе ставится индикатор успешного тестирования QA «+» и пишется отчет (Advisory), содержащий:<br />
## Название пакета с исходниками (src.rpm).<br />
## Версию пакета.<br />
## Отчет о тестировании (advisory).<br />
## Надпись «QA verified».<br />
# Если пакет содержит изменения, связанные с секретностью или же собран не сотрудником Росы — посылается запрос Secure team (взводится флажок secteam_verified «?»).<br />
# Если тестирование secure не нужно, пакет передается на публикацию (взводится соответствующий published «?»).<br />
# В случае успешного тестирования пакет может быть оставлен в системе. В случае ошибок систему нужно привести к первоначальному виду с помощью деинсталляции пакета или утилиты <tt>urpm-reposync</tt> из <tt>urpm-repotools</tt>.<br />
<br />
==== Отрицательный результат тестирования ====<br />
# При отклонении пакета ставится индикатор отклонения QA «-»,<br />
# В комментариях пишется причина отклонения запроса и в конце комментария добавляется «QA Denied».<br />
# При отрицательном результате тестирования сборщик может выложить исправленные контейнеры в тот же запрос и снова установить «?» в «qa_requested».</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F&diff=18639
Регламент тестирования
2020-04-29T10:30:00Z
<p>Vladimir.potapov: /* Тестирование запуска и работы связанных с обновлением приложений */</p>
<hr />
<div>[[Category:Регламенты ROSA]]<br />
<br />
=== Политика ===<br />
QA, наряду с мейнтейнерами пакетов отвечает за стабильность и функциональность установленного у пользователей дистрибутива при его обновлениях. <br />
<br />
До установки обновлений дистрибутив работает. Любое обновление — риск его обрушить.<br />
Поэтому политика QA обязана быть консервативной и даже несколько параноидальной — при малейших сомнениях должны назначаться дополнительные проверки, пакеты должны отклоняться, направляться на пересборку.<br />
<br />
Политика QA вступает в конфликт с интересами сборщиков пакетов, желающих быстрее увидеть в репозиториях исправленную версию — конфликт этот должен быть конструктивным, приводящим к непрерывному повышению функциональности и стабильности дистрибутива.<br />
<br />
==== Классификация обновлений по степени опасности ====<br />
<blockquote><br />
Меня не интересуют их намерения, меня интересуют их возможности — © Отто Фон Бисмарк<br />
</blockquote><br />
<br />
Классификация исходит из максимально возможного урона (полный отказ функционирования компонента), который может нанести устанавливаемое обновление. Чем выше степень опасности, тем более тщательным должно быть тестирование.<br />
<br />
;0: Критические обновления. Ядро, файловая система, система прав доступа, скрипты загрузки, <tt>systemd</tt>, <tt>glibc</tt>, <tt>dracut</tt>, <tt>grub</tt>, <tt>bash</tt> и прочие основные вещи, если удалить которые система не загрузится даже в консоли.<br />
;1: Обновления драйверов устройств, т.е. те же критические обновления, но актуальные не для всех пользователей. <br />
;2: Обновления сетевых компонентов: NetworkManager, сетевых скриптов, системы сетевой инициализации и системы обновлений (curl, urpmi). Они опасны тем, что если сеть упадет, пользователю без сети будет затруднительно получить исправленный пакет, когда мы его выпустим и установить обновление. <br />
;3: Обновления графических компонент и скриптов — X-ов, менеджера входа, графических библиотек, драйверов, '''perl, python''' — то, без чего невозможен вход в систему в графическом режиме. Т.к. обновление системы, при наличии сети, возможно и не в графике - класс опасности обновлений не самый высокий<br />
;4: Обновление пользовательских пакетов, установленных по-умолчанию в системе. Эти пакеты стоят практически у всех и их ошибки будут влиять на максимальное количество пользователей, однако они могут быть оперативно исправлены потому класс опасности не очень высокий. Туда же нужно отнести популярные программы не входящие в поставку — <tt>gimp</tt>, <tt>inkscape</tt>, <tt>audacity</tt>, <tt>vlc</tt>, <tt>kdenive</tt>, <tt>opera</tt>, <tt>chromium-browser</tt>, <tt>skype</tt>.<br />
;5: Обновление прочих пользовательских пакетов. Они затронут только тех, у кого эти программы стоят.<br />
;6: Обновление пакетов, необходимых только для сборки дистрибутива или работы с abf. Почти никому кроме нас они не интересны, потому класс опасности самый низкий.<br />
<br />
==== Задача ====<br />
* Главная задача QA — поиск регрессий, то есть таких изменений в дистрибутиве, которые уменьшают его функциональность по сравнению с предыдущим состоянием.<br />
* Также задачей QA является внесение в багзиллу всех найденных в процессе тестирования ошибок, не относящихся к регрессиям.<br />
<br />
==== Общие положения ====<br />
* Запрос на обновление пишется в багзилле <br />
* Все сообщения пишутся на английском языке.<br />
* Порядок принятие запросов на тестирование командой QA в общем случае — в порядке возрастания номеров багов, возможны исключения, связанные со срочностью или трудностями в тестировании определенных пакетов.<br />
* Список запросов на обновление можно открыть по ссылке http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=qa_verified%3F&o1=substring&list_id=38774<br />
<br />
==== Срок тестирования ====<br />
* Срок тестирования пакета — '''одна неделя''', за это время служба QA должня проверить пакет и вынести заключение. Срок тестирования может быть увеличен при необходимости тестирования внешними тестерами на отсутствующих у службы QA аппаратно-программных конфигурациях, в этом случае в запросе на обновление задержка должна быть обоснована службой QA.<br />
* Для пакета, который нужно проверить очень срочно, сборщик должен установить приоритет <tt>Highest Critical</tt>, чтобы он выделялся красным цветом в списке. Такие пакеты рассматриваются в течение '''48 часов''' рабочего времени.<br />
* Норма выработки на одного тестера QA - 20 одобренных запросов в неделю, обычно ошибки содержат 10-20% запросов, так что тестер QA в среднем обрабатывает 5 запросов в день.<br />
<br />
=== Процедура тестирования ===<br />
<br />
==== Требования к запросу на обновление ====<br />
# QA Team тестирует пакеты-кандидаты на добавление в репозитории <tt>main/updates, non-free/updates и restricted/updates</tt>.<br />
# Пакет должен быть собран в общедоступном репозитории (не <tt>_personal</tt>).<br />
# Для архитектурно-зависимых пакетов должны быть представлены все поддерживаемые архитектуры (<tt>i586</tt> и <tt>x64</tt>).<br />
# Описание обновления должно содержать все изменения, которые нужно протестировать.<br />
При несоответствии запроса на обновление этим требованиям необходимо сообщить об этом инициатору запроса с помощью комментария.<br />
В случае, если до пятницы запрос не исправлен согласно требованиям, он отклоняется.<br />
<br />
==== Тестирование установки пакетов ====<br />
# Система перед тестовым обновлением должна соответствовать стандартным репозиториям, с подключенными тестингами. Это можно проверить запуском <tt>urpm-reposync</tt> из пакета <tt>urpm-tools</tt><br />
# Пакеты для тестирования устанавливаются и в графическом, и в текстовом режиме.<br />
## Репозиторий подключается как репозиторий с обновлениями.<br />
## Запускается стандартная процедура обновления.<br />
# Для пакетов, установленных в системе по-умолчанию, проверяется их обновление.<br />
# Для пакетов, не установленных в системе, проверяется как их обновление, так и первоначальная установка при подключенных тестовых контейнерах.<br />
# Установка пакетов проверяется для обеих архитектур. Так как ошибки установки не обычно не зависят от архитектуры, обычно достаточно проверить на одной архитектуре установку в графическом режиме, а на другой — обновление в текстовом, или наоборот.<br />
<br />
При ошибках установки или обновления пакета необходимо сообщить об этом инициатору запроса с помощью комментария. В случае, если до пятницы ошибка установки не исправлена, запрос отклоняется.<br />
<br />
==== Тестирование на функционирование и устойчивость системы после обновления ====<br />
При тестировании системы проверяется:<br />
# Стабильность и внешний вид обновленной системы после перезагрузки.<br />
# Стабильность и внешний вид обновленной системы после пробуждения из спящего режима. Тестирование стабильности и производительности может проводиться, например, с помощью теста Unigine Valley под wine и тестом браузера https://webglsamples.org/aquarium/aquarium.html<br />
# Ошибки загрузки демонов, например, с помощью <tt>systemctl | grep failed</tt>.<br />
# Ошибки непрерывного роста файла <tt>.xsession-errors</tt>.<br />
# Журнал ошибок, командами '''journalctl -b |grep fail''' и '''journalctl -b |grep error''' (не должно быть новых ошибок, если они появились - нужно найти связанное с ошибкой обновление и написать инициатору)<br />
# Работа URPMI — дальнейшее обновление пакетов.<br />
# Установка и удаление dkms-модулей (например, установкой проприетарных драйверов с последующим откатом на свободные)<br />
# Сохранением загрузчиком определения других операционных систем, установленных на тестовом компьютере<br />
# Сохранение даты-времени на тестируемой машине после перезагрузки и пробуждения из спящего режима<br />
# Работа системы поиска по содержимому офисных файлов<br />
<br />
При ошибках функционирования или устойчивости системы, связанной с обновлением, необходимо сообщить об этом инициатору запроса с помощью комментария. <br />
В случае, если до пятницы ошибка не исправлена, запрос отклоняется.<br />
<br />
==== Тестирование запуска и работы связанных с обновлением приложений ====<br />
Проверяются:<br />
# Тестирование запуска и простейших операций со связанными с тестируемым пакетом программами, рекомендуется контроль сообщений при запуске программы из консоли.<br />
# Связанные с библиотеками из проверяемого пакета программы легче всего установить, попробовав удалить пакет с помощью <tt>urpme</tt> (для установленных в системе программ) или <tt>urpmq --whatrequires</tt> (для всех программ из подключенных репозиториев).<br />
# Изменения в интерфейсах обновляемых библиотек и, соответственно, необходимость перекомпиляции связанных пакетов с помощью сервиса https://abi-laboratory.pro/tracker/<br />
# Для пакетов, предоставляющих библиотеки, проверяются использующие эти библиотеки приложения из main, их можно определить командой <tt>urpmq --whatrequires <названиепакета></tt><br />
# Регрессии в локализации графического интерфейса и страниц справки.<br />
# Для тестирования браузеров в дополнение к https://webglsamples.org/aquarium/aquarium.html применяются.<br />
## Тест html5 https://html5test.com/ (сравнить результат до и после обновления, не должно быть регресса)<br />
## Почтовые онлайновые сервисы http://mail.yandex.ru http://mail.google.com<br />
## Яндекс и гугл-карты https://yandex.ru/maps/-/CVTQITy0 https://www.google.ru/maps/@52.2609339,104.3096872,15z?hl=ru<br />
## xml|xsl трансляцию и кодировки на http://base.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=160129;div=LAW;rnd=0.4700782325977544 и<br />
## Воспроизведение видео http://techslides.com/sample-webm-ogg-and-mp4-video-files-for-html5/ <br />
## Воспроизведение [http://youtu.be/37l7P5V1eXU видео с youtube]<br />
## Работа флэша на примере игры [http://vseigru.net/igry-zombi/2541-igra-zombi-protiv-rastenij.html Растения против зомби] и [http://kino.sputnik.ru/films/ivan+vasilyevich+menyayet+professiyu+1973]<br />
## Уязвимости SSL с помощью https://www.ssllabs.com/ssltest/viewMyClient.html<br />
## Тестирование печати<br />
## Тестирование установки браузера по-умолчанию из настроек<br />
<br />
В случае:<br />
# нахождения регрессии функционала или локализации, о них сообщается инициатору запроса в комментариях к запросу на обновление. <br />
# отсутствия до пятницы исправления найденной QA регрессии или обоснования мейнтейнером пакета невозможности исправления - запрос отклоняется.<br />
# если пакет не имеет постоянного мейнтейнера и собирается случайным сборщиком, QA может заблокировать запрос на обновление при нахождении любой функциональной регрессии<br />
# нахождения ошибок (не регрессий!) - заводится новый баг, его номер указывается в запросе на обновление.<br />
<br />
==== Тестирование изменений ====<br />
* Применяется при тестировании обновлений, изменяющих внешний вид или поведение системы.<br />
<br />
Включает себя<br />
# Воспроизведение особенностей внешнего вида или поведения системы ДО исправления.<br />
# Воспроизведение измененных обновлений особенностей по их описанию.<br />
<br />
Например, если в advisory сказано, что «вышла новая версия программы» при тестировании изменений нужно, как минимум, убедиться что версия изменилась.<br />
<br />
В случае если не все описанные изменения действительно присутствуют в тестируемом пакете, пакет принимается и в итоговый отчет (Advisory), вносятся только реально проведенные изменения.<br />
В случае значительного отклонения запрошенных и полученных изменений пакет может быть отклонен.<br />
<br />
==== Расширенное тестирование ====<br />
# Расширенное тестирование проводится добровольцами с помощью репозиториев testing, соответствующих основным репозиториям. <br />
# В течение недели (понедельник-четверг) все проверяемые QA обновления, кроме срочных, отправляются в тестинг, при этом в багзилле ставится статус verified и пишется The update is sent to expanded testing<br />
# В пятницу, руководитель QA:<br />
## Еще раз контролирует, все ли пакеты направлены в тестинг-репозитории, при помощи отключения источников-контейнеров и выполнения программы '''urpm-reposync''' с включенными тестингами. Результатом выполнения команды должно быть отсутствие пакетов на синхронизацию<br />
## Проверяет, дошли ли обновления до зеркал<br />
## Контролирует возможность обновления до тестингов с момента предыдущего релиза платформы путем установки релизного образа и его обновления с подключенными тестингами <br />
## Обновляет до тестингов системы на всех доступных тестовых стендах и проверяет их на устойчивость<br />
## На форуме и в сообществе вконтакте объявляет "пятничное тестирование", к нему выпускает бюллетень с полным списком обновлений и методикой их тестирования.<br />
# В понедельник руководитель QA читает отзывы пользователей и по их итогам, а также по итогам эксплуатации тестовых стендов в выходные дни, обрабатывает запросы на обновление и передает их на публикацию (или отклоняет)<br />
<br />
=== Завершение тестирования ===<br />
<br />
==== Положительный результат тестирования ====<br />
# По окончании тестирования при его успехе ставится индикатор успешного тестирования QA «+» и пишется отчет (Advisory), содержащий:<br />
## Название пакета с исходниками (src.rpm).<br />
## Версию пакета.<br />
## Отчет о тестировании (advisory).<br />
## Надпись «QA verified».<br />
# Если пакет содержит изменения, связанные с секретностью или же собран не сотрудником Росы — посылается запрос Secure team (взводится флажок secteam_verified «?»).<br />
# Если тестирование secure не нужно, пакет передается на публикацию (взводится соответствующий published «?»).<br />
# В случае успешного тестирования пакет может быть оставлен в системе. В случае ошибок систему нужно привести к первоначальному виду с помощью деинсталляции пакета или утилиты <tt>urpm-reposync</tt> из <tt>urpm-repotools</tt>.<br />
<br />
==== Отрицательный результат тестирования ====<br />
# При отклонении пакета ставится индикатор отклонения QA «-»,<br />
# В комментариях пишется причина отклонения запроса и в конце комментария добавляется «QA Denied».<br />
# При отрицательном результате тестирования сборщик может выложить исправленные контейнеры в тот же запрос и снова установить «?» в «qa_requested».</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F&diff=18638
Регламент тестирования
2020-04-29T10:27:54Z
<p>Vladimir.potapov: </p>
<hr />
<div>[[Category:Регламенты ROSA]]<br />
<br />
=== Политика ===<br />
QA, наряду с мейнтейнерами пакетов отвечает за стабильность и функциональность установленного у пользователей дистрибутива при его обновлениях. <br />
<br />
До установки обновлений дистрибутив работает. Любое обновление — риск его обрушить.<br />
Поэтому политика QA обязана быть консервативной и даже несколько параноидальной — при малейших сомнениях должны назначаться дополнительные проверки, пакеты должны отклоняться, направляться на пересборку.<br />
<br />
Политика QA вступает в конфликт с интересами сборщиков пакетов, желающих быстрее увидеть в репозиториях исправленную версию — конфликт этот должен быть конструктивным, приводящим к непрерывному повышению функциональности и стабильности дистрибутива.<br />
<br />
==== Классификация обновлений по степени опасности ====<br />
<blockquote><br />
Меня не интересуют их намерения, меня интересуют их возможности — © Отто Фон Бисмарк<br />
</blockquote><br />
<br />
Классификация исходит из максимально возможного урона (полный отказ функционирования компонента), который может нанести устанавливаемое обновление. Чем выше степень опасности, тем более тщательным должно быть тестирование.<br />
<br />
;0: Критические обновления. Ядро, файловая система, система прав доступа, скрипты загрузки, <tt>systemd</tt>, <tt>glibc</tt>, <tt>dracut</tt>, <tt>grub</tt>, <tt>bash</tt> и прочие основные вещи, если удалить которые система не загрузится даже в консоли.<br />
;1: Обновления драйверов устройств, т.е. те же критические обновления, но актуальные не для всех пользователей. <br />
;2: Обновления сетевых компонентов: NetworkManager, сетевых скриптов, системы сетевой инициализации и системы обновлений (curl, urpmi). Они опасны тем, что если сеть упадет, пользователю без сети будет затруднительно получить исправленный пакет, когда мы его выпустим и установить обновление. <br />
;3: Обновления графических компонент и скриптов — X-ов, менеджера входа, графических библиотек, драйверов, '''perl, python''' — то, без чего невозможен вход в систему в графическом режиме. Т.к. обновление системы, при наличии сети, возможно и не в графике - класс опасности обновлений не самый высокий<br />
;4: Обновление пользовательских пакетов, установленных по-умолчанию в системе. Эти пакеты стоят практически у всех и их ошибки будут влиять на максимальное количество пользователей, однако они могут быть оперативно исправлены потому класс опасности не очень высокий. Туда же нужно отнести популярные программы не входящие в поставку — <tt>gimp</tt>, <tt>inkscape</tt>, <tt>audacity</tt>, <tt>vlc</tt>, <tt>kdenive</tt>, <tt>opera</tt>, <tt>chromium-browser</tt>, <tt>skype</tt>.<br />
;5: Обновление прочих пользовательских пакетов. Они затронут только тех, у кого эти программы стоят.<br />
;6: Обновление пакетов, необходимых только для сборки дистрибутива или работы с abf. Почти никому кроме нас они не интересны, потому класс опасности самый низкий.<br />
<br />
==== Задача ====<br />
* Главная задача QA — поиск регрессий, то есть таких изменений в дистрибутиве, которые уменьшают его функциональность по сравнению с предыдущим состоянием.<br />
* Также задачей QA является внесение в багзиллу всех найденных в процессе тестирования ошибок, не относящихся к регрессиям.<br />
<br />
==== Общие положения ====<br />
* Запрос на обновление пишется в багзилле <br />
* Все сообщения пишутся на английском языке.<br />
* Порядок принятие запросов на тестирование командой QA в общем случае — в порядке возрастания номеров багов, возможны исключения, связанные со срочностью или трудностями в тестировании определенных пакетов.<br />
* Список запросов на обновление можно открыть по ссылке http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=qa_verified%3F&o1=substring&list_id=38774<br />
<br />
==== Срок тестирования ====<br />
* Срок тестирования пакета — '''одна неделя''', за это время служба QA должня проверить пакет и вынести заключение. Срок тестирования может быть увеличен при необходимости тестирования внешними тестерами на отсутствующих у службы QA аппаратно-программных конфигурациях, в этом случае в запросе на обновление задержка должна быть обоснована службой QA.<br />
* Для пакета, который нужно проверить очень срочно, сборщик должен установить приоритет <tt>Highest Critical</tt>, чтобы он выделялся красным цветом в списке. Такие пакеты рассматриваются в течение '''48 часов''' рабочего времени.<br />
* Норма выработки на одного тестера QA - 20 одобренных запросов в неделю, обычно ошибки содержат 10-20% запросов, так что тестер QA в среднем обрабатывает 5 запросов в день.<br />
<br />
=== Процедура тестирования ===<br />
<br />
==== Требования к запросу на обновление ====<br />
# QA Team тестирует пакеты-кандидаты на добавление в репозитории <tt>main/updates, non-free/updates и restricted/updates</tt>.<br />
# Пакет должен быть собран в общедоступном репозитории (не <tt>_personal</tt>).<br />
# Для архитектурно-зависимых пакетов должны быть представлены все поддерживаемые архитектуры (<tt>i586</tt> и <tt>x64</tt>).<br />
# Описание обновления должно содержать все изменения, которые нужно протестировать.<br />
При несоответствии запроса на обновление этим требованиям необходимо сообщить об этом инициатору запроса с помощью комментария.<br />
В случае, если до пятницы запрос не исправлен согласно требованиям, он отклоняется.<br />
<br />
==== Тестирование установки пакетов ====<br />
# Система перед тестовым обновлением должна соответствовать стандартным репозиториям, с подключенными тестингами. Это можно проверить запуском <tt>urpm-reposync</tt> из пакета <tt>urpm-tools</tt><br />
# Пакеты для тестирования устанавливаются и в графическом, и в текстовом режиме.<br />
## Репозиторий подключается как репозиторий с обновлениями.<br />
## Запускается стандартная процедура обновления.<br />
# Для пакетов, установленных в системе по-умолчанию, проверяется их обновление.<br />
# Для пакетов, не установленных в системе, проверяется как их обновление, так и первоначальная установка при подключенных тестовых контейнерах.<br />
# Установка пакетов проверяется для обеих архитектур. Так как ошибки установки не обычно не зависят от архитектуры, обычно достаточно проверить на одной архитектуре установку в графическом режиме, а на другой — обновление в текстовом, или наоборот.<br />
<br />
При ошибках установки или обновления пакета необходимо сообщить об этом инициатору запроса с помощью комментария. В случае, если до пятницы ошибка установки не исправлена, запрос отклоняется.<br />
<br />
==== Тестирование на функционирование и устойчивость системы после обновления ====<br />
При тестировании системы проверяется:<br />
# Стабильность и внешний вид обновленной системы после перезагрузки.<br />
# Стабильность и внешний вид обновленной системы после пробуждения из спящего режима. Тестирование стабильности и производительности может проводиться, например, с помощью теста Unigine Valley под wine и тестом браузера https://webglsamples.org/aquarium/aquarium.html<br />
# Ошибки загрузки демонов, например, с помощью <tt>systemctl | grep failed</tt>.<br />
# Ошибки непрерывного роста файла <tt>.xsession-errors</tt>.<br />
# Журнал ошибок, командами '''journalctl -b |grep fail''' и '''journalctl -b |grep error''' (не должно быть новых ошибок, если они появились - нужно найти связанное с ошибкой обновление и написать инициатору)<br />
# Работа URPMI — дальнейшее обновление пакетов.<br />
# Установка и удаление dkms-модулей (например, установкой проприетарных драйверов с последующим откатом на свободные)<br />
# Сохранением загрузчиком определения других операционных систем, установленных на тестовом компьютере<br />
# Сохранение даты-времени на тестируемой машине после перезагрузки и пробуждения из спящего режима<br />
# Работа системы поиска по содержимому офисных файлов<br />
<br />
При ошибках функционирования или устойчивости системы, связанной с обновлением, необходимо сообщить об этом инициатору запроса с помощью комментария. <br />
В случае, если до пятницы ошибка не исправлена, запрос отклоняется.<br />
<br />
==== Тестирование запуска и работы связанных с обновлением приложений ====<br />
Проверяются:<br />
# Тестирование запуска и простейших операций со связанными с тестируемым пакетом программами, рекомендуется контроль сообщений при запуске программы из консоли.<br />
# Связанные с библиотеками из проверяемого пакета программы легче всего установить, попробовав удалить пакет с помощью <tt>urpme</tt> (для установленных в системе программ) или <tt>urpmq --whatrequires</tt> (для всех программ из подключенных репозиториев).<br />
# Изменения в интерфейсах обновляемых библиотек и, соответственно, необходимость перекомпиляции связанных пакетов с помощью сервиса https://abi-laboratory.pro/tracker/<br />
# Для пакетов, предоставляющих библиотеки, проверяются использующие эти библиотеки приложения из main, их можно определить командой <tt>urpmq --whatrequires <названиепакета></tt><br />
# Регрессии в локализации графического интерфейса и страниц справки.<br />
# Для тестирования браузеров в дополнение к https://webglsamples.org/aquarium/aquarium.html применяются.<br />
## Тест html5 https://html5test.com/ (сравнить результат до и после обновления, не должно быть регресса)<br />
## Почтовые онлайновые сервисы http://mail.yandex.ru http://mail.google.com<br />
## Яндекс и гугл-карты https://yandex.ru/maps/-/CVTQITy0 https://www.google.ru/maps/@52.2609339,104.3096872,15z?hl=ru<br />
## xml|xsl трансляцию и кодировки на http://base.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=160129;div=LAW;rnd=0.4700782325977544 и<br />
## Воспроизведение видео http://techslides.com/sample-webm-ogg-and-mp4-video-files-for-html5/ <br />
## Воспроизведение [http://youtu.be/37l7P5V1eXU видео с youtube]<br />
## Работа флэша на примере игры [http://vseigru.net/igry-zombi/2541-igra-zombi-protiv-rastenij.html Растения против зомби] и [http://kino.sputnik.ru/films/ivan+vasilyevich+menyayet+professiyu+1973]<br />
## Уязвимости SSL с помощью https://www.ssllabs.com/ssltest/viewMyClient.html<br />
## Тестирование печати<br />
## Тестирование установки браузера по-умолчанию из настроек<br />
<br />
В случае:<br />
# нахождения регрессии функционала или локализации, о них сообщается инициатору запроса в комментариях к запросу на обновление. <br />
# отсутствия до пятницы исправления найденной QA регрессии или обоснования мейнтейнером пакета невозможности исправления - запрос отклоняется.<br />
# если пакет не имеет постоянного мейнтейнера и собирается случайным сборщиком, QA может заблокировать запрос на обновление при нахождении любой регрессии или изменению функциональности.<br />
# нахождения ошибок (не регрессий!) - заводится новый баг, его номер указывается в запросе на обновление.<br />
<br />
==== Тестирование изменений ====<br />
* Применяется при тестировании обновлений, изменяющих внешний вид или поведение системы.<br />
<br />
Включает себя<br />
# Воспроизведение особенностей внешнего вида или поведения системы ДО исправления.<br />
# Воспроизведение измененных обновлений особенностей по их описанию.<br />
<br />
Например, если в advisory сказано, что «вышла новая версия программы» при тестировании изменений нужно, как минимум, убедиться что версия изменилась.<br />
<br />
В случае если не все описанные изменения действительно присутствуют в тестируемом пакете, пакет принимается и в итоговый отчет (Advisory), вносятся только реально проведенные изменения.<br />
В случае значительного отклонения запрошенных и полученных изменений пакет может быть отклонен.<br />
<br />
==== Расширенное тестирование ====<br />
# Расширенное тестирование проводится добровольцами с помощью репозиториев testing, соответствующих основным репозиториям. <br />
# В течение недели (понедельник-четверг) все проверяемые QA обновления, кроме срочных, отправляются в тестинг, при этом в багзилле ставится статус verified и пишется The update is sent to expanded testing<br />
# В пятницу, руководитель QA:<br />
## Еще раз контролирует, все ли пакеты направлены в тестинг-репозитории, при помощи отключения источников-контейнеров и выполнения программы '''urpm-reposync''' с включенными тестингами. Результатом выполнения команды должно быть отсутствие пакетов на синхронизацию<br />
## Проверяет, дошли ли обновления до зеркал<br />
## Контролирует возможность обновления до тестингов с момента предыдущего релиза платформы путем установки релизного образа и его обновления с подключенными тестингами <br />
## Обновляет до тестингов системы на всех доступных тестовых стендах и проверяет их на устойчивость<br />
## На форуме и в сообществе вконтакте объявляет "пятничное тестирование", к нему выпускает бюллетень с полным списком обновлений и методикой их тестирования.<br />
# В понедельник руководитель QA читает отзывы пользователей и по их итогам, а также по итогам эксплуатации тестовых стендов в выходные дни, обрабатывает запросы на обновление и передает их на публикацию (или отклоняет)<br />
<br />
=== Завершение тестирования ===<br />
<br />
==== Положительный результат тестирования ====<br />
# По окончании тестирования при его успехе ставится индикатор успешного тестирования QA «+» и пишется отчет (Advisory), содержащий:<br />
## Название пакета с исходниками (src.rpm).<br />
## Версию пакета.<br />
## Отчет о тестировании (advisory).<br />
## Надпись «QA verified».<br />
# Если пакет содержит изменения, связанные с секретностью или же собран не сотрудником Росы — посылается запрос Secure team (взводится флажок secteam_verified «?»).<br />
# Если тестирование secure не нужно, пакет передается на публикацию (взводится соответствующий published «?»).<br />
# В случае успешного тестирования пакет может быть оставлен в системе. В случае ошибок систему нужно привести к первоначальному виду с помощью деинсталляции пакета или утилиты <tt>urpm-reposync</tt> из <tt>urpm-repotools</tt>.<br />
<br />
==== Отрицательный результат тестирования ====<br />
# При отклонении пакета ставится индикатор отклонения QA «-»,<br />
# В комментариях пишется причина отклонения запроса и в конце комментария добавляется «QA Denied».<br />
# При отрицательном результате тестирования сборщик может выложить исправленные контейнеры в тот же запрос и снова установить «?» в «qa_requested».</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F&diff=18637
Регламент тестирования
2020-04-29T09:46:39Z
<p>Vladimir.potapov: /* Тестирование запуска и работы связанных с обновлением приложений */</p>
<hr />
<div>[[Category:Регламенты ROSA]]<br />
<br />
=== Политика ===<br />
QA отвечает за стабильность установленного у пользователей дистрибутива при его обновлениях.<br />
<br />
До установки обновлений дистрибутив работает. Любое обновление — риск его обрушить.<br />
Поэтому политика QA обязана быть консервативной и даже несколько параноидальной — при малейших сомнениях должны назначаться дополнительные проверки, пакеты должны отклоняться, направляться на пересборку.<br />
<br />
Политика QA вступает в конфликт с интересами сборщиков пакетов, желающих быстрее увидеть в репозиториях исправленную версию — конфликт этот должен быть конструктивным, приводящим к непрерывному повышению функциональности и стабильности дистрибутива.<br />
<br />
==== Классификация обновлений по степени опасности ====<br />
<blockquote><br />
Меня не интересуют их намерения, меня интересуют их возможности — © Отто Фон Бисмарк<br />
</blockquote><br />
<br />
Классификация исходит из максимально возможного урона (полный отказ функционирования компонента), который может нанести устанавливаемое обновление. Чем выше степень опасности, тем более тщательным должно быть тестирование.<br />
<br />
;0: Критические обновления. Ядро, файловая система, система прав доступа, скрипты загрузки, <tt>systemd</tt>, <tt>glibc</tt>, <tt>dracut</tt>, <tt>grub</tt>, <tt>bash</tt> и прочие основные вещи, если удалить которые система не загрузится даже в консоли.<br />
;1: Обновления драйверов устройств, т.е. те же критические обновления, но актуальные не для всех пользователей. <br />
;2: Обновления сетевых компонентов: NetworkManager, сетевых скриптов, системы сетевой инициализации и системы обновлений (curl, urpmi). Они опасны тем, что если сеть упадет, пользователю без сети будет затруднительно получить исправленный пакет, когда мы его выпустим и установить обновление. <br />
;3: Обновления графических компонент и скриптов — X-ов, менеджера входа, графических библиотек, драйверов, '''perl, python''' — то, без чего невозможен вход в систему в графическом режиме. Т.к. обновление системы, при наличии сети, возможно и не в графике - класс опасности обновлений не самый высокий<br />
;4: Обновление пользовательских пакетов, установленных по-умолчанию в системе. Эти пакеты стоят практически у всех и их ошибки будут влиять на максимальное количество пользователей, однако они могут быть оперативно исправлены потому класс опасности не очень высокий. Туда же нужно отнести популярные программы не входящие в поставку — <tt>gimp</tt>, <tt>inkscape</tt>, <tt>audacity</tt>, <tt>vlc</tt>, <tt>kdenive</tt>, <tt>opera</tt>, <tt>chromium-browser</tt>, <tt>skype</tt>.<br />
;5: Обновление прочих пользовательских пакетов. Они затронут только тех, у кого эти программы стоят.<br />
;6: Обновление пакетов, необходимых только для сборки дистрибутива или работы с abf. Почти никому кроме нас они не интересны, потому класс опасности самый низкий.<br />
<br />
==== Задача ====<br />
* Главная задача QA — поиск регрессий, то есть таких изменений в дистрибутиве, которые уменьшают его функциональность по сравнению с предыдущим состоянием.<br />
* Также задачей QA является внесение в багзиллу всех найденных в процессе тестирования ошибок, не относящихся к регрессиям.<br />
<br />
==== Общие положения ====<br />
* Запрос на обновление пишется в багзилле <br />
* Все сообщения пишутся на английском языке.<br />
* Порядок принятие запросов на тестирование командой QA в общем случае — в порядке возрастания номеров багов, возможны исключения, связанные со срочностью или трудностями в тестировании определенных пакетов.<br />
* Список запросов на обновление можно открыть по ссылке http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=qa_verified%3F&o1=substring&list_id=38774<br />
<br />
==== Срок тестирования ====<br />
* Срок тестирования пакета — '''одна неделя''', за это время служба QA должня проверить пакет и вынести заключение. Срок тестирования может быть увеличен при необходимости тестирования внешними тестерами на отсутствующих у службы QA аппаратно-программных конфигурациях, в этом случае в запросе на обновление задержка должна быть обоснована службой QA.<br />
* Для пакета, который нужно проверить очень срочно, сборщик должен установить приоритет <tt>Highest Critical</tt>, чтобы он выделялся красным цветом в списке. Такие пакеты рассматриваются в течение '''48 часов''' рабочего времени.<br />
* Норма выработки на одного тестера QA - 20 одобренных запросов в неделю, обычно ошибки содержат 10-20% запросов, так что тестер QA в среднем обрабатывает 5 запросов в день.<br />
<br />
=== Процедура тестирования ===<br />
<br />
==== Требования к запросу на обновление ====<br />
# QA Team тестирует пакеты-кандидаты на добавление в репозитории <tt>main/updates, non-free/updates и restricted/updates</tt>.<br />
# Пакет должен быть собран в общедоступном репозитории (не <tt>_personal</tt>).<br />
# Для архитектурно-зависимых пакетов должны быть представлены все поддерживаемые архитектуры (<tt>i586</tt> и <tt>x64</tt>).<br />
# Описание обновления должно содержать все изменения, которые нужно протестировать.<br />
При несоответствии запроса на обновление этим требованиям необходимо сообщить об этом инициатору запроса с помощью комментария.<br />
В случае, если до пятницы запрос не исправлен согласно требованиям, он отклоняется.<br />
<br />
==== Тестирование установки пакетов ====<br />
# Система перед тестовым обновлением должна соответствовать стандартным репозиториям, с подключенными тестингами. Это можно проверить запуском <tt>urpm-reposync</tt> из пакета <tt>urpm-tools</tt><br />
# Пакеты для тестирования устанавливаются и в графическом, и в текстовом режиме.<br />
## Репозиторий подключается как репозиторий с обновлениями.<br />
## Запускается стандартная процедура обновления.<br />
# Для пакетов, установленных в системе по-умолчанию, проверяется их обновление.<br />
# Для пакетов, не установленных в системе, проверяется как их обновление, так и первоначальная установка при подключенных тестовых контейнерах.<br />
# Установка пакетов проверяется для обеих архитектур. Так как ошибки установки не обычно не зависят от архитектуры, обычно достаточно проверить на одной архитектуре установку в графическом режиме, а на другой — обновление в текстовом, или наоборот.<br />
<br />
При ошибках установки или обновления пакета необходимо сообщить об этом инициатору запроса с помощью комментария. В случае, если до пятницы ошибка установки не исправлена, запрос отклоняется.<br />
<br />
==== Тестирование на функционирование и устойчивость системы после обновления ====<br />
При тестировании системы проверяется:<br />
# Стабильность и внешний вид обновленной системы после перезагрузки.<br />
# Стабильность и внешний вид обновленной системы после пробуждения из спящего режима. Тестирование стабильности и производительности может проводиться, например, с помощью теста Unigine Valley под wine и тестом браузера https://webglsamples.org/aquarium/aquarium.html<br />
# Ошибки загрузки демонов, например, с помощью <tt>systemctl | grep failed</tt>.<br />
# Ошибки непрерывного роста файла <tt>.xsession-errors</tt>.<br />
# Журнал ошибок, командами '''journalctl -b |grep fail''' и '''journalctl -b |grep error''' (не должно быть новых ошибок, если они появились - нужно найти связанное с ошибкой обновление и написать инициатору)<br />
# Работа URPMI — дальнейшее обновление пакетов.<br />
# Установка и удаление dkms-модулей (например, установкой проприетарных драйверов с последующим откатом на свободные)<br />
# Сохранением загрузчиком определения других операционных систем, установленных на тестовом компьютере<br />
# Сохранение даты-времени на тестируемой машине после перезагрузки и пробуждения из спящего режима<br />
# Работа системы поиска по содержимому офисных файлов<br />
<br />
При ошибках функционирования или устойчивости системы, связанной с обновлением, необходимо сообщить об этом инициатору запроса с помощью комментария. <br />
В случае, если до пятницы ошибка не исправлена, запрос отклоняется.<br />
<br />
==== Тестирование запуска и работы связанных с обновлением приложений ====<br />
Проверяются:<br />
# Тестирование запуска и простейших операций со связанными с тестируемым пакетом программами, рекомендуется контроль сообщений при запуске программы из консоли.<br />
# Связанные с библиотеками из проверяемого пакета программы легче всего установить, попробовав удалить пакет с помощью <tt>urpme</tt> (для установленных в системе программ) или <tt>urpmq --whatrequires</tt> (для всех программ из подключенных репозиториев).<br />
# Изменения в интерфейсах обновляемых библиотек и, соответственно, необходимость перекомпиляции связанных пакетов с помощью сервиса https://abi-laboratory.pro/tracker/<br />
# Для пакетов, предоставляющих библиотеки, проверяются использующие эти библиотеки приложения из main, их можно определить командой <tt>urpmq --whatrequires <названиепакета></tt><br />
# Регрессии в локализации графического интерфейса и страниц справки.<br />
# Для тестирования браузеров в дополнение к https://webglsamples.org/aquarium/aquarium.html применяются.<br />
## Тест html5 https://html5test.com/ (сравнить результат до и после обновления, не должно быть регресса)<br />
## Почтовые онлайновые сервисы http://mail.yandex.ru http://mail.google.com<br />
## Яндекс и гугл-карты https://yandex.ru/maps/-/CVTQITy0 https://www.google.ru/maps/@52.2609339,104.3096872,15z?hl=ru<br />
## xml|xsl трансляцию и кодировки на http://base.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=160129;div=LAW;rnd=0.4700782325977544 и<br />
## Воспроизведение видео http://techslides.com/sample-webm-ogg-and-mp4-video-files-for-html5/ <br />
## Воспроизведение [http://youtu.be/37l7P5V1eXU видео с youtube]<br />
## Работа флэша на примере игры [http://vseigru.net/igry-zombi/2541-igra-zombi-protiv-rastenij.html Растения против зомби] и [http://kino.sputnik.ru/films/ivan+vasilyevich+menyayet+professiyu+1973]<br />
## Уязвимости SSL с помощью https://www.ssllabs.com/ssltest/viewMyClient.html<br />
## Тестирование печати<br />
## Тестирование установки браузера по-умолчанию из настроек<br />
<br />
В случае:<br />
# нахождения регрессии функционала или локализации, о них сообщается инициатору запроса в комментариях к запросу на обновление. <br />
# отсутствия до пятницы исправления найденной QA регрессии или обоснования его невозможности - запрос отклоняется.<br />
# нахождения ошибок (не регрессий!) - заводится новый баг, его номер указывается в запросе на обновление.<br />
<br />
==== Тестирование изменений ====<br />
* Применяется при тестировании обновлений, изменяющих внешний вид или поведение системы.<br />
<br />
Включает себя<br />
# Воспроизведение особенностей внешнего вида или поведения системы ДО исправления.<br />
# Воспроизведение измененных обновлений особенностей по их описанию.<br />
<br />
Например, если в advisory сказано, что «вышла новая версия программы» при тестировании изменений нужно, как минимум, убедиться что версия изменилась.<br />
<br />
В случае если не все описанные изменения действительно присутствуют в тестируемом пакете, пакет принимается и в итоговый отчет (Advisory), вносятся только реально проведенные изменения.<br />
В случае значительного отклонения запрошенных и полученных изменений пакет может быть отклонен.<br />
<br />
==== Расширенное тестирование ====<br />
# Расширенное тестирование проводится добровольцами с помощью репозиториев testing, соответствующих основным репозиториям. <br />
# В течение недели (понедельник-четверг) все проверяемые QA обновления, кроме срочных, отправляются в тестинг, при этом в багзилле ставится статус verified и пишется The update is sent to expanded testing<br />
# В пятницу, руководитель QA:<br />
## Еще раз контролирует, все ли пакеты направлены в тестинг-репозитории, при помощи отключения источников-контейнеров и выполнения программы '''urpm-reposync''' с включенными тестингами. Результатом выполнения команды должно быть отсутствие пакетов на синхронизацию<br />
## Проверяет, дошли ли обновления до зеркал<br />
## Контролирует возможность обновления до тестингов с момента предыдущего релиза платформы путем установки релизного образа и его обновления с подключенными тестингами <br />
## Обновляет до тестингов системы на всех доступных тестовых стендах и проверяет их на устойчивость<br />
## На форуме и в сообществе вконтакте объявляет "пятничное тестирование", к нему выпускает бюллетень с полным списком обновлений и методикой их тестирования.<br />
# В понедельник руководитель QA читает отзывы пользователей и по их итогам, а также по итогам эксплуатации тестовых стендов в выходные дни, обрабатывает запросы на обновление и передает их на публикацию (или отклоняет)<br />
<br />
=== Завершение тестирования ===<br />
<br />
==== Положительный результат тестирования ====<br />
# По окончании тестирования при его успехе ставится индикатор успешного тестирования QA «+» и пишется отчет (Advisory), содержащий:<br />
## Название пакета с исходниками (src.rpm).<br />
## Версию пакета.<br />
## Отчет о тестировании (advisory).<br />
## Надпись «QA verified».<br />
# Если пакет содержит изменения, связанные с секретностью или же собран не сотрудником Росы — посылается запрос Secure team (взводится флажок secteam_verified «?»).<br />
# Если тестирование secure не нужно, пакет передается на публикацию (взводится соответствующий published «?»).<br />
# В случае успешного тестирования пакет может быть оставлен в системе. В случае ошибок систему нужно привести к первоначальному виду с помощью деинсталляции пакета или утилиты <tt>urpm-reposync</tt> из <tt>urpm-repotools</tt>.<br />
<br />
==== Отрицательный результат тестирования ====<br />
# При отклонении пакета ставится индикатор отклонения QA «-»,<br />
# В комментариях пишется причина отклонения запроса и в конце комментария добавляется «QA Denied».<br />
# При отрицательном результате тестирования сборщик может выложить исправленные контейнеры в тот же запрос и снова установить «?» в «qa_requested».</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F&diff=18636
Регламент тестирования
2020-04-29T09:45:49Z
<p>Vladimir.potapov: /* Тестирование запуска и работы связанных с обновлением приложений */</p>
<hr />
<div>[[Category:Регламенты ROSA]]<br />
<br />
=== Политика ===<br />
QA отвечает за стабильность установленного у пользователей дистрибутива при его обновлениях.<br />
<br />
До установки обновлений дистрибутив работает. Любое обновление — риск его обрушить.<br />
Поэтому политика QA обязана быть консервативной и даже несколько параноидальной — при малейших сомнениях должны назначаться дополнительные проверки, пакеты должны отклоняться, направляться на пересборку.<br />
<br />
Политика QA вступает в конфликт с интересами сборщиков пакетов, желающих быстрее увидеть в репозиториях исправленную версию — конфликт этот должен быть конструктивным, приводящим к непрерывному повышению функциональности и стабильности дистрибутива.<br />
<br />
==== Классификация обновлений по степени опасности ====<br />
<blockquote><br />
Меня не интересуют их намерения, меня интересуют их возможности — © Отто Фон Бисмарк<br />
</blockquote><br />
<br />
Классификация исходит из максимально возможного урона (полный отказ функционирования компонента), который может нанести устанавливаемое обновление. Чем выше степень опасности, тем более тщательным должно быть тестирование.<br />
<br />
;0: Критические обновления. Ядро, файловая система, система прав доступа, скрипты загрузки, <tt>systemd</tt>, <tt>glibc</tt>, <tt>dracut</tt>, <tt>grub</tt>, <tt>bash</tt> и прочие основные вещи, если удалить которые система не загрузится даже в консоли.<br />
;1: Обновления драйверов устройств, т.е. те же критические обновления, но актуальные не для всех пользователей. <br />
;2: Обновления сетевых компонентов: NetworkManager, сетевых скриптов, системы сетевой инициализации и системы обновлений (curl, urpmi). Они опасны тем, что если сеть упадет, пользователю без сети будет затруднительно получить исправленный пакет, когда мы его выпустим и установить обновление. <br />
;3: Обновления графических компонент и скриптов — X-ов, менеджера входа, графических библиотек, драйверов, '''perl, python''' — то, без чего невозможен вход в систему в графическом режиме. Т.к. обновление системы, при наличии сети, возможно и не в графике - класс опасности обновлений не самый высокий<br />
;4: Обновление пользовательских пакетов, установленных по-умолчанию в системе. Эти пакеты стоят практически у всех и их ошибки будут влиять на максимальное количество пользователей, однако они могут быть оперативно исправлены потому класс опасности не очень высокий. Туда же нужно отнести популярные программы не входящие в поставку — <tt>gimp</tt>, <tt>inkscape</tt>, <tt>audacity</tt>, <tt>vlc</tt>, <tt>kdenive</tt>, <tt>opera</tt>, <tt>chromium-browser</tt>, <tt>skype</tt>.<br />
;5: Обновление прочих пользовательских пакетов. Они затронут только тех, у кого эти программы стоят.<br />
;6: Обновление пакетов, необходимых только для сборки дистрибутива или работы с abf. Почти никому кроме нас они не интересны, потому класс опасности самый низкий.<br />
<br />
==== Задача ====<br />
* Главная задача QA — поиск регрессий, то есть таких изменений в дистрибутиве, которые уменьшают его функциональность по сравнению с предыдущим состоянием.<br />
* Также задачей QA является внесение в багзиллу всех найденных в процессе тестирования ошибок, не относящихся к регрессиям.<br />
<br />
==== Общие положения ====<br />
* Запрос на обновление пишется в багзилле <br />
* Все сообщения пишутся на английском языке.<br />
* Порядок принятие запросов на тестирование командой QA в общем случае — в порядке возрастания номеров багов, возможны исключения, связанные со срочностью или трудностями в тестировании определенных пакетов.<br />
* Список запросов на обновление можно открыть по ссылке http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=qa_verified%3F&o1=substring&list_id=38774<br />
<br />
==== Срок тестирования ====<br />
* Срок тестирования пакета — '''одна неделя''', за это время служба QA должня проверить пакет и вынести заключение. Срок тестирования может быть увеличен при необходимости тестирования внешними тестерами на отсутствующих у службы QA аппаратно-программных конфигурациях, в этом случае в запросе на обновление задержка должна быть обоснована службой QA.<br />
* Для пакета, который нужно проверить очень срочно, сборщик должен установить приоритет <tt>Highest Critical</tt>, чтобы он выделялся красным цветом в списке. Такие пакеты рассматриваются в течение '''48 часов''' рабочего времени.<br />
* Норма выработки на одного тестера QA - 20 одобренных запросов в неделю, обычно ошибки содержат 10-20% запросов, так что тестер QA в среднем обрабатывает 5 запросов в день.<br />
<br />
=== Процедура тестирования ===<br />
<br />
==== Требования к запросу на обновление ====<br />
# QA Team тестирует пакеты-кандидаты на добавление в репозитории <tt>main/updates, non-free/updates и restricted/updates</tt>.<br />
# Пакет должен быть собран в общедоступном репозитории (не <tt>_personal</tt>).<br />
# Для архитектурно-зависимых пакетов должны быть представлены все поддерживаемые архитектуры (<tt>i586</tt> и <tt>x64</tt>).<br />
# Описание обновления должно содержать все изменения, которые нужно протестировать.<br />
При несоответствии запроса на обновление этим требованиям необходимо сообщить об этом инициатору запроса с помощью комментария.<br />
В случае, если до пятницы запрос не исправлен согласно требованиям, он отклоняется.<br />
<br />
==== Тестирование установки пакетов ====<br />
# Система перед тестовым обновлением должна соответствовать стандартным репозиториям, с подключенными тестингами. Это можно проверить запуском <tt>urpm-reposync</tt> из пакета <tt>urpm-tools</tt><br />
# Пакеты для тестирования устанавливаются и в графическом, и в текстовом режиме.<br />
## Репозиторий подключается как репозиторий с обновлениями.<br />
## Запускается стандартная процедура обновления.<br />
# Для пакетов, установленных в системе по-умолчанию, проверяется их обновление.<br />
# Для пакетов, не установленных в системе, проверяется как их обновление, так и первоначальная установка при подключенных тестовых контейнерах.<br />
# Установка пакетов проверяется для обеих архитектур. Так как ошибки установки не обычно не зависят от архитектуры, обычно достаточно проверить на одной архитектуре установку в графическом режиме, а на другой — обновление в текстовом, или наоборот.<br />
<br />
При ошибках установки или обновления пакета необходимо сообщить об этом инициатору запроса с помощью комментария. В случае, если до пятницы ошибка установки не исправлена, запрос отклоняется.<br />
<br />
==== Тестирование на функционирование и устойчивость системы после обновления ====<br />
При тестировании системы проверяется:<br />
# Стабильность и внешний вид обновленной системы после перезагрузки.<br />
# Стабильность и внешний вид обновленной системы после пробуждения из спящего режима. Тестирование стабильности и производительности может проводиться, например, с помощью теста Unigine Valley под wine и тестом браузера https://webglsamples.org/aquarium/aquarium.html<br />
# Ошибки загрузки демонов, например, с помощью <tt>systemctl | grep failed</tt>.<br />
# Ошибки непрерывного роста файла <tt>.xsession-errors</tt>.<br />
# Журнал ошибок, командами '''journalctl -b |grep fail''' и '''journalctl -b |grep error''' (не должно быть новых ошибок, если они появились - нужно найти связанное с ошибкой обновление и написать инициатору)<br />
# Работа URPMI — дальнейшее обновление пакетов.<br />
# Установка и удаление dkms-модулей (например, установкой проприетарных драйверов с последующим откатом на свободные)<br />
# Сохранением загрузчиком определения других операционных систем, установленных на тестовом компьютере<br />
# Сохранение даты-времени на тестируемой машине после перезагрузки и пробуждения из спящего режима<br />
# Работа системы поиска по содержимому офисных файлов<br />
<br />
При ошибках функционирования или устойчивости системы, связанной с обновлением, необходимо сообщить об этом инициатору запроса с помощью комментария. <br />
В случае, если до пятницы ошибка не исправлена, запрос отклоняется.<br />
<br />
==== Тестирование запуска и работы связанных с обновлением приложений ====<br />
Проверяются:<br />
# Тестирование запуска и простейших операций со связанными с тестируемым пакетом программами, рекомендуется контроль сообщений при запуске программы из консоли.<br />
# Связанные с библиотеками из проверяемого пакета программы легче всего установить, попробовав удалить пакет с помощью <tt>urpme</tt> (для установленных в системе программ) или <tt>urpmq --whatrequires</tt> (для всех программ из подключенных репозиториев).<br />
# Изменения в интерфейсах обновляемых библиотек и, соответственно, необходимость перекомпиляции связанных пакетов с помощью сервиса https://abi-laboratory.pro/tracker/<br />
# Для пакетов, предоставляющих библиотеки, проверяются использующие эти библиотеки приложения из main, их можно определить командой <tt>urpmq --whatrequires <названиепакета></tt><br />
# Регрессии в локализации графического интерфейса и страниц справки.<br />
# Для тестирования браузеров в дополнение к https://webglsamples.org/aquarium/aquarium.html применяются.<br />
## Тест html5 https://html5test.com/ (сравнить результат до и после обновления, не должно быть регресса)<br />
## Почтовые онлайновые сервисы http://mail.yandex.ru http://mail.google.com<br />
## Яндекс и гугл-карты https://yandex.ru/maps/-/CVTQITy0 https://www.google.ru/maps/@52.2609339,104.3096872,15z?hl=ru<br />
## xml|xsl трансляцию и кодировки на http://base.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=160129;div=LAW;rnd=0.4700782325977544 и<br />
## Воспроизведение видео http://techslides.com/sample-webm-ogg-and-mp4-video-files-for-html5/ <br />
## Воспроизведение [http://youtu.be/37l7P5V1eXU видео с youtube]<br />
## Работа флэша на примере игры [http://vseigru.net/igry-zombi/2541-igra-zombi-protiv-rastenij.html Растения против зомби] и [http://kino.sputnik.ru/films/ivan+vasilyevich+menyayet+professiyu+1973]<br />
## Уязвимости SSL с помощью https://www.ssllabs.com/ssltest/viewMyClient.html<br />
## Тестирование печати<br />
## Тестирование установки браузера по-умолчанию из настроек<br />
<br />
В случае:<br />
# нахождения регрессии функционала или локализации, о них сообщается инициатору запроса в комментариях к запросу на обновление. <br />
# отсутствия до пятницы исправления регрессии или обоснования его невозможности - запрос отклоняется.<br />
# нахождения ошибок (не регрессий!) - заводится новый баг, его номер указывается в запросе на обновление.<br />
<br />
==== Тестирование изменений ====<br />
* Применяется при тестировании обновлений, изменяющих внешний вид или поведение системы.<br />
<br />
Включает себя<br />
# Воспроизведение особенностей внешнего вида или поведения системы ДО исправления.<br />
# Воспроизведение измененных обновлений особенностей по их описанию.<br />
<br />
Например, если в advisory сказано, что «вышла новая версия программы» при тестировании изменений нужно, как минимум, убедиться что версия изменилась.<br />
<br />
В случае если не все описанные изменения действительно присутствуют в тестируемом пакете, пакет принимается и в итоговый отчет (Advisory), вносятся только реально проведенные изменения.<br />
В случае значительного отклонения запрошенных и полученных изменений пакет может быть отклонен.<br />
<br />
==== Расширенное тестирование ====<br />
# Расширенное тестирование проводится добровольцами с помощью репозиториев testing, соответствующих основным репозиториям. <br />
# В течение недели (понедельник-четверг) все проверяемые QA обновления, кроме срочных, отправляются в тестинг, при этом в багзилле ставится статус verified и пишется The update is sent to expanded testing<br />
# В пятницу, руководитель QA:<br />
## Еще раз контролирует, все ли пакеты направлены в тестинг-репозитории, при помощи отключения источников-контейнеров и выполнения программы '''urpm-reposync''' с включенными тестингами. Результатом выполнения команды должно быть отсутствие пакетов на синхронизацию<br />
## Проверяет, дошли ли обновления до зеркал<br />
## Контролирует возможность обновления до тестингов с момента предыдущего релиза платформы путем установки релизного образа и его обновления с подключенными тестингами <br />
## Обновляет до тестингов системы на всех доступных тестовых стендах и проверяет их на устойчивость<br />
## На форуме и в сообществе вконтакте объявляет "пятничное тестирование", к нему выпускает бюллетень с полным списком обновлений и методикой их тестирования.<br />
# В понедельник руководитель QA читает отзывы пользователей и по их итогам, а также по итогам эксплуатации тестовых стендов в выходные дни, обрабатывает запросы на обновление и передает их на публикацию (или отклоняет)<br />
<br />
=== Завершение тестирования ===<br />
<br />
==== Положительный результат тестирования ====<br />
# По окончании тестирования при его успехе ставится индикатор успешного тестирования QA «+» и пишется отчет (Advisory), содержащий:<br />
## Название пакета с исходниками (src.rpm).<br />
## Версию пакета.<br />
## Отчет о тестировании (advisory).<br />
## Надпись «QA verified».<br />
# Если пакет содержит изменения, связанные с секретностью или же собран не сотрудником Росы — посылается запрос Secure team (взводится флажок secteam_verified «?»).<br />
# Если тестирование secure не нужно, пакет передается на публикацию (взводится соответствующий published «?»).<br />
# В случае успешного тестирования пакет может быть оставлен в системе. В случае ошибок систему нужно привести к первоначальному виду с помощью деинсталляции пакета или утилиты <tt>urpm-reposync</tt> из <tt>urpm-repotools</tt>.<br />
<br />
==== Отрицательный результат тестирования ====<br />
# При отклонении пакета ставится индикатор отклонения QA «-»,<br />
# В комментариях пишется причина отклонения запроса и в конце комментария добавляется «QA Denied».<br />
# При отрицательном результате тестирования сборщик может выложить исправленные контейнеры в тот же запрос и снова установить «?» в «qa_requested».</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F&diff=18635
Регламент тестирования
2020-04-29T09:39:56Z
<p>Vladimir.potapov: /* Срок тестирования */</p>
<hr />
<div>[[Category:Регламенты ROSA]]<br />
<br />
=== Политика ===<br />
QA отвечает за стабильность установленного у пользователей дистрибутива при его обновлениях.<br />
<br />
До установки обновлений дистрибутив работает. Любое обновление — риск его обрушить.<br />
Поэтому политика QA обязана быть консервативной и даже несколько параноидальной — при малейших сомнениях должны назначаться дополнительные проверки, пакеты должны отклоняться, направляться на пересборку.<br />
<br />
Политика QA вступает в конфликт с интересами сборщиков пакетов, желающих быстрее увидеть в репозиториях исправленную версию — конфликт этот должен быть конструктивным, приводящим к непрерывному повышению функциональности и стабильности дистрибутива.<br />
<br />
==== Классификация обновлений по степени опасности ====<br />
<blockquote><br />
Меня не интересуют их намерения, меня интересуют их возможности — © Отто Фон Бисмарк<br />
</blockquote><br />
<br />
Классификация исходит из максимально возможного урона (полный отказ функционирования компонента), который может нанести устанавливаемое обновление. Чем выше степень опасности, тем более тщательным должно быть тестирование.<br />
<br />
;0: Критические обновления. Ядро, файловая система, система прав доступа, скрипты загрузки, <tt>systemd</tt>, <tt>glibc</tt>, <tt>dracut</tt>, <tt>grub</tt>, <tt>bash</tt> и прочие основные вещи, если удалить которые система не загрузится даже в консоли.<br />
;1: Обновления драйверов устройств, т.е. те же критические обновления, но актуальные не для всех пользователей. <br />
;2: Обновления сетевых компонентов: NetworkManager, сетевых скриптов, системы сетевой инициализации и системы обновлений (curl, urpmi). Они опасны тем, что если сеть упадет, пользователю без сети будет затруднительно получить исправленный пакет, когда мы его выпустим и установить обновление. <br />
;3: Обновления графических компонент и скриптов — X-ов, менеджера входа, графических библиотек, драйверов, '''perl, python''' — то, без чего невозможен вход в систему в графическом режиме. Т.к. обновление системы, при наличии сети, возможно и не в графике - класс опасности обновлений не самый высокий<br />
;4: Обновление пользовательских пакетов, установленных по-умолчанию в системе. Эти пакеты стоят практически у всех и их ошибки будут влиять на максимальное количество пользователей, однако они могут быть оперативно исправлены потому класс опасности не очень высокий. Туда же нужно отнести популярные программы не входящие в поставку — <tt>gimp</tt>, <tt>inkscape</tt>, <tt>audacity</tt>, <tt>vlc</tt>, <tt>kdenive</tt>, <tt>opera</tt>, <tt>chromium-browser</tt>, <tt>skype</tt>.<br />
;5: Обновление прочих пользовательских пакетов. Они затронут только тех, у кого эти программы стоят.<br />
;6: Обновление пакетов, необходимых только для сборки дистрибутива или работы с abf. Почти никому кроме нас они не интересны, потому класс опасности самый низкий.<br />
<br />
==== Задача ====<br />
* Главная задача QA — поиск регрессий, то есть таких изменений в дистрибутиве, которые уменьшают его функциональность по сравнению с предыдущим состоянием.<br />
* Также задачей QA является внесение в багзиллу всех найденных в процессе тестирования ошибок, не относящихся к регрессиям.<br />
<br />
==== Общие положения ====<br />
* Запрос на обновление пишется в багзилле <br />
* Все сообщения пишутся на английском языке.<br />
* Порядок принятие запросов на тестирование командой QA в общем случае — в порядке возрастания номеров багов, возможны исключения, связанные со срочностью или трудностями в тестировании определенных пакетов.<br />
* Список запросов на обновление можно открыть по ссылке http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=qa_verified%3F&o1=substring&list_id=38774<br />
<br />
==== Срок тестирования ====<br />
* Срок тестирования пакета — '''одна неделя''', за это время служба QA должня проверить пакет и вынести заключение. Срок тестирования может быть увеличен при необходимости тестирования внешними тестерами на отсутствующих у службы QA аппаратно-программных конфигурациях, в этом случае в запросе на обновление задержка должна быть обоснована службой QA.<br />
* Для пакета, который нужно проверить очень срочно, сборщик должен установить приоритет <tt>Highest Critical</tt>, чтобы он выделялся красным цветом в списке. Такие пакеты рассматриваются в течение '''48 часов''' рабочего времени.<br />
* Норма выработки на одного тестера QA - 20 одобренных запросов в неделю, обычно ошибки содержат 10-20% запросов, так что тестер QA в среднем обрабатывает 5 запросов в день.<br />
<br />
=== Процедура тестирования ===<br />
<br />
==== Требования к запросу на обновление ====<br />
# QA Team тестирует пакеты-кандидаты на добавление в репозитории <tt>main/updates, non-free/updates и restricted/updates</tt>.<br />
# Пакет должен быть собран в общедоступном репозитории (не <tt>_personal</tt>).<br />
# Для архитектурно-зависимых пакетов должны быть представлены все поддерживаемые архитектуры (<tt>i586</tt> и <tt>x64</tt>).<br />
# Описание обновления должно содержать все изменения, которые нужно протестировать.<br />
При несоответствии запроса на обновление этим требованиям необходимо сообщить об этом инициатору запроса с помощью комментария.<br />
В случае, если до пятницы запрос не исправлен согласно требованиям, он отклоняется.<br />
<br />
==== Тестирование установки пакетов ====<br />
# Система перед тестовым обновлением должна соответствовать стандартным репозиториям, с подключенными тестингами. Это можно проверить запуском <tt>urpm-reposync</tt> из пакета <tt>urpm-tools</tt><br />
# Пакеты для тестирования устанавливаются и в графическом, и в текстовом режиме.<br />
## Репозиторий подключается как репозиторий с обновлениями.<br />
## Запускается стандартная процедура обновления.<br />
# Для пакетов, установленных в системе по-умолчанию, проверяется их обновление.<br />
# Для пакетов, не установленных в системе, проверяется как их обновление, так и первоначальная установка при подключенных тестовых контейнерах.<br />
# Установка пакетов проверяется для обеих архитектур. Так как ошибки установки не обычно не зависят от архитектуры, обычно достаточно проверить на одной архитектуре установку в графическом режиме, а на другой — обновление в текстовом, или наоборот.<br />
<br />
При ошибках установки или обновления пакета необходимо сообщить об этом инициатору запроса с помощью комментария. В случае, если до пятницы ошибка установки не исправлена, запрос отклоняется.<br />
<br />
==== Тестирование на функционирование и устойчивость системы после обновления ====<br />
При тестировании системы проверяется:<br />
# Стабильность и внешний вид обновленной системы после перезагрузки.<br />
# Стабильность и внешний вид обновленной системы после пробуждения из спящего режима. Тестирование стабильности и производительности может проводиться, например, с помощью теста Unigine Valley под wine и тестом браузера https://webglsamples.org/aquarium/aquarium.html<br />
# Ошибки загрузки демонов, например, с помощью <tt>systemctl | grep failed</tt>.<br />
# Ошибки непрерывного роста файла <tt>.xsession-errors</tt>.<br />
# Журнал ошибок, командами '''journalctl -b |grep fail''' и '''journalctl -b |grep error''' (не должно быть новых ошибок, если они появились - нужно найти связанное с ошибкой обновление и написать инициатору)<br />
# Работа URPMI — дальнейшее обновление пакетов.<br />
# Установка и удаление dkms-модулей (например, установкой проприетарных драйверов с последующим откатом на свободные)<br />
# Сохранением загрузчиком определения других операционных систем, установленных на тестовом компьютере<br />
# Сохранение даты-времени на тестируемой машине после перезагрузки и пробуждения из спящего режима<br />
# Работа системы поиска по содержимому офисных файлов<br />
<br />
При ошибках функционирования или устойчивости системы, связанной с обновлением, необходимо сообщить об этом инициатору запроса с помощью комментария. <br />
В случае, если до пятницы ошибка не исправлена, запрос отклоняется.<br />
<br />
==== Тестирование запуска и работы связанных с обновлением приложений ====<br />
Проверяются:<br />
# Тестирование запуска и простейших операций со связанными с тестируемым пакетом программами, рекомендуется контроль сообщений при запуске программы из консоли.<br />
# Связанные с библиотеками из проверяемого пакета программы легче всего установить, попробовав удалить пакет с помощью <tt>urpme</tt> (для установленных в системе программ) или <tt>urpmq --whatrequires</tt> (для всех программ из подключенных репозиториев).<br />
# Изменения в интерфейсах обновляемых библиотек и, соответственно, необходимость перекомпиляции связанных пакетов с помощью сервиса https://abi-laboratory.pro/tracker/<br />
# Для пакетов, предоставляющих библиотеки, проверяются использующие эти библиотеки приложения из main, их можно определить командой <tt>urpmq --whatrequires <названиепакета></tt><br />
# Регрессии в локализации графического интерфейса и страниц справки.<br />
# Для тестирования браузеров в дополнение к https://webglsamples.org/aquarium/aquarium.html применяются.<br />
## Тест html5 https://html5test.com/ (сравнить результат до и после обновления, не должно быть регресса)<br />
## Почтовые онлайновые сервисы http://mail.yandex.ru http://mail.google.com<br />
## Яндекс и гугл-карты https://yandex.ru/maps/-/CVTQITy0 https://www.google.ru/maps/@52.2609339,104.3096872,15z?hl=ru<br />
## xml|xsl трансляцию и кодировки на http://base.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=160129;div=LAW;rnd=0.4700782325977544 и<br />
## Воспроизведение видео http://techslides.com/sample-webm-ogg-and-mp4-video-files-for-html5/ <br />
## Воспроизведение [http://youtu.be/37l7P5V1eXU видео с youtube]<br />
## Работа флэша на примере игры [http://vseigru.net/igry-zombi/2541-igra-zombi-protiv-rastenij.html Растения против зомби] и [http://kino.sputnik.ru/films/ivan+vasilyevich+menyayet+professiyu+1973]<br />
## Уязвимости SSL с помощью https://www.ssllabs.com/ssltest/viewMyClient.html<br />
## Тестирование печати<br />
## Тестирование установки браузера по-умолчанию из настроек<br />
<br />
В случае:<br />
# нахождения регрессии функционала или локализации, о них сообщается инициатору запроса в комментариях к запросу на обновление <br />
# нахождения ошибок (не регрессий!) - заводится новый баг, его номер указывается в запросе на обновление.<br />
<br />
==== Тестирование изменений ====<br />
* Применяется при тестировании обновлений, изменяющих внешний вид или поведение системы.<br />
<br />
Включает себя<br />
# Воспроизведение особенностей внешнего вида или поведения системы ДО исправления.<br />
# Воспроизведение измененных обновлений особенностей по их описанию.<br />
<br />
Например, если в advisory сказано, что «вышла новая версия программы» при тестировании изменений нужно, как минимум, убедиться что версия изменилась.<br />
<br />
В случае если не все описанные изменения действительно присутствуют в тестируемом пакете, пакет принимается и в итоговый отчет (Advisory), вносятся только реально проведенные изменения.<br />
В случае значительного отклонения запрошенных и полученных изменений пакет может быть отклонен.<br />
<br />
==== Расширенное тестирование ====<br />
# Расширенное тестирование проводится добровольцами с помощью репозиториев testing, соответствующих основным репозиториям. <br />
# В течение недели (понедельник-четверг) все проверяемые QA обновления, кроме срочных, отправляются в тестинг, при этом в багзилле ставится статус verified и пишется The update is sent to expanded testing<br />
# В пятницу, руководитель QA:<br />
## Еще раз контролирует, все ли пакеты направлены в тестинг-репозитории, при помощи отключения источников-контейнеров и выполнения программы '''urpm-reposync''' с включенными тестингами. Результатом выполнения команды должно быть отсутствие пакетов на синхронизацию<br />
## Проверяет, дошли ли обновления до зеркал<br />
## Контролирует возможность обновления до тестингов с момента предыдущего релиза платформы путем установки релизного образа и его обновления с подключенными тестингами <br />
## Обновляет до тестингов системы на всех доступных тестовых стендах и проверяет их на устойчивость<br />
## На форуме и в сообществе вконтакте объявляет "пятничное тестирование", к нему выпускает бюллетень с полным списком обновлений и методикой их тестирования.<br />
# В понедельник руководитель QA читает отзывы пользователей и по их итогам, а также по итогам эксплуатации тестовых стендов в выходные дни, обрабатывает запросы на обновление и передает их на публикацию (или отклоняет)<br />
<br />
=== Завершение тестирования ===<br />
<br />
==== Положительный результат тестирования ====<br />
# По окончании тестирования при его успехе ставится индикатор успешного тестирования QA «+» и пишется отчет (Advisory), содержащий:<br />
## Название пакета с исходниками (src.rpm).<br />
## Версию пакета.<br />
## Отчет о тестировании (advisory).<br />
## Надпись «QA verified».<br />
# Если пакет содержит изменения, связанные с секретностью или же собран не сотрудником Росы — посылается запрос Secure team (взводится флажок secteam_verified «?»).<br />
# Если тестирование secure не нужно, пакет передается на публикацию (взводится соответствующий published «?»).<br />
# В случае успешного тестирования пакет может быть оставлен в системе. В случае ошибок систему нужно привести к первоначальному виду с помощью деинсталляции пакета или утилиты <tt>urpm-reposync</tt> из <tt>urpm-repotools</tt>.<br />
<br />
==== Отрицательный результат тестирования ====<br />
# При отклонении пакета ставится индикатор отклонения QA «-»,<br />
# В комментариях пишется причина отклонения запроса и в конце комментария добавляется «QA Denied».<br />
# При отрицательном результате тестирования сборщик может выложить исправленные контейнеры в тот же запрос и снова установить «?» в «qa_requested».</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F&diff=18634
Регламент тестирования
2020-04-29T09:38:45Z
<p>Vladimir.potapov: /* Задача */</p>
<hr />
<div>[[Category:Регламенты ROSA]]<br />
<br />
=== Политика ===<br />
QA отвечает за стабильность установленного у пользователей дистрибутива при его обновлениях.<br />
<br />
До установки обновлений дистрибутив работает. Любое обновление — риск его обрушить.<br />
Поэтому политика QA обязана быть консервативной и даже несколько параноидальной — при малейших сомнениях должны назначаться дополнительные проверки, пакеты должны отклоняться, направляться на пересборку.<br />
<br />
Политика QA вступает в конфликт с интересами сборщиков пакетов, желающих быстрее увидеть в репозиториях исправленную версию — конфликт этот должен быть конструктивным, приводящим к непрерывному повышению функциональности и стабильности дистрибутива.<br />
<br />
==== Классификация обновлений по степени опасности ====<br />
<blockquote><br />
Меня не интересуют их намерения, меня интересуют их возможности — © Отто Фон Бисмарк<br />
</blockquote><br />
<br />
Классификация исходит из максимально возможного урона (полный отказ функционирования компонента), который может нанести устанавливаемое обновление. Чем выше степень опасности, тем более тщательным должно быть тестирование.<br />
<br />
;0: Критические обновления. Ядро, файловая система, система прав доступа, скрипты загрузки, <tt>systemd</tt>, <tt>glibc</tt>, <tt>dracut</tt>, <tt>grub</tt>, <tt>bash</tt> и прочие основные вещи, если удалить которые система не загрузится даже в консоли.<br />
;1: Обновления драйверов устройств, т.е. те же критические обновления, но актуальные не для всех пользователей. <br />
;2: Обновления сетевых компонентов: NetworkManager, сетевых скриптов, системы сетевой инициализации и системы обновлений (curl, urpmi). Они опасны тем, что если сеть упадет, пользователю без сети будет затруднительно получить исправленный пакет, когда мы его выпустим и установить обновление. <br />
;3: Обновления графических компонент и скриптов — X-ов, менеджера входа, графических библиотек, драйверов, '''perl, python''' — то, без чего невозможен вход в систему в графическом режиме. Т.к. обновление системы, при наличии сети, возможно и не в графике - класс опасности обновлений не самый высокий<br />
;4: Обновление пользовательских пакетов, установленных по-умолчанию в системе. Эти пакеты стоят практически у всех и их ошибки будут влиять на максимальное количество пользователей, однако они могут быть оперативно исправлены потому класс опасности не очень высокий. Туда же нужно отнести популярные программы не входящие в поставку — <tt>gimp</tt>, <tt>inkscape</tt>, <tt>audacity</tt>, <tt>vlc</tt>, <tt>kdenive</tt>, <tt>opera</tt>, <tt>chromium-browser</tt>, <tt>skype</tt>.<br />
;5: Обновление прочих пользовательских пакетов. Они затронут только тех, у кого эти программы стоят.<br />
;6: Обновление пакетов, необходимых только для сборки дистрибутива или работы с abf. Почти никому кроме нас они не интересны, потому класс опасности самый низкий.<br />
<br />
==== Задача ====<br />
* Главная задача QA — поиск регрессий, то есть таких изменений в дистрибутиве, которые уменьшают его функциональность по сравнению с предыдущим состоянием.<br />
* Также задачей QA является внесение в багзиллу всех найденных в процессе тестирования ошибок, не относящихся к регрессиям.<br />
<br />
==== Общие положения ====<br />
* Запрос на обновление пишется в багзилле <br />
* Все сообщения пишутся на английском языке.<br />
* Порядок принятие запросов на тестирование командой QA в общем случае — в порядке возрастания номеров багов, возможны исключения, связанные со срочностью или трудностями в тестировании определенных пакетов.<br />
* Список запросов на обновление можно открыть по ссылке http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=qa_verified%3F&o1=substring&list_id=38774<br />
<br />
==== Срок тестирования ====<br />
* Срок тестирования пакета — '''одна неделя''', за это время служба QA должня проверить пакет и вынести заключение. Срок тестирования может быть увеличен при необходимости тестирования внешними тестерами на отсутствующих у службы QA аппаратно-программных конфигурациях, в этом случае в запросе на обновление задержка должна быть обоснована службой QA.<br />
* Для пакета, который нужно проверить очень срочно, сборщик должен установить приоритет <tt>Highest Critical</tt>, чтобы он выделялся красным цветом в списке. Такие пакеты рассматриваются в течение '''48 часов''' рабочего времени.<br />
* Норма выработки на одного тестера QA - 20 одобренных запросов в неделю, обычно отклоняется 10-20% запросов, так что тестер QA в среднем обрабатывает 5 запросов в день.<br />
<br />
=== Процедура тестирования ===<br />
<br />
==== Требования к запросу на обновление ====<br />
# QA Team тестирует пакеты-кандидаты на добавление в репозитории <tt>main/updates, non-free/updates и restricted/updates</tt>.<br />
# Пакет должен быть собран в общедоступном репозитории (не <tt>_personal</tt>).<br />
# Для архитектурно-зависимых пакетов должны быть представлены все поддерживаемые архитектуры (<tt>i586</tt> и <tt>x64</tt>).<br />
# Описание обновления должно содержать все изменения, которые нужно протестировать.<br />
При несоответствии запроса на обновление этим требованиям необходимо сообщить об этом инициатору запроса с помощью комментария.<br />
В случае, если до пятницы запрос не исправлен согласно требованиям, он отклоняется.<br />
<br />
==== Тестирование установки пакетов ====<br />
# Система перед тестовым обновлением должна соответствовать стандартным репозиториям, с подключенными тестингами. Это можно проверить запуском <tt>urpm-reposync</tt> из пакета <tt>urpm-tools</tt><br />
# Пакеты для тестирования устанавливаются и в графическом, и в текстовом режиме.<br />
## Репозиторий подключается как репозиторий с обновлениями.<br />
## Запускается стандартная процедура обновления.<br />
# Для пакетов, установленных в системе по-умолчанию, проверяется их обновление.<br />
# Для пакетов, не установленных в системе, проверяется как их обновление, так и первоначальная установка при подключенных тестовых контейнерах.<br />
# Установка пакетов проверяется для обеих архитектур. Так как ошибки установки не обычно не зависят от архитектуры, обычно достаточно проверить на одной архитектуре установку в графическом режиме, а на другой — обновление в текстовом, или наоборот.<br />
<br />
При ошибках установки или обновления пакета необходимо сообщить об этом инициатору запроса с помощью комментария. В случае, если до пятницы ошибка установки не исправлена, запрос отклоняется.<br />
<br />
==== Тестирование на функционирование и устойчивость системы после обновления ====<br />
При тестировании системы проверяется:<br />
# Стабильность и внешний вид обновленной системы после перезагрузки.<br />
# Стабильность и внешний вид обновленной системы после пробуждения из спящего режима. Тестирование стабильности и производительности может проводиться, например, с помощью теста Unigine Valley под wine и тестом браузера https://webglsamples.org/aquarium/aquarium.html<br />
# Ошибки загрузки демонов, например, с помощью <tt>systemctl | grep failed</tt>.<br />
# Ошибки непрерывного роста файла <tt>.xsession-errors</tt>.<br />
# Журнал ошибок, командами '''journalctl -b |grep fail''' и '''journalctl -b |grep error''' (не должно быть новых ошибок, если они появились - нужно найти связанное с ошибкой обновление и написать инициатору)<br />
# Работа URPMI — дальнейшее обновление пакетов.<br />
# Установка и удаление dkms-модулей (например, установкой проприетарных драйверов с последующим откатом на свободные)<br />
# Сохранением загрузчиком определения других операционных систем, установленных на тестовом компьютере<br />
# Сохранение даты-времени на тестируемой машине после перезагрузки и пробуждения из спящего режима<br />
# Работа системы поиска по содержимому офисных файлов<br />
<br />
При ошибках функционирования или устойчивости системы, связанной с обновлением, необходимо сообщить об этом инициатору запроса с помощью комментария. <br />
В случае, если до пятницы ошибка не исправлена, запрос отклоняется.<br />
<br />
==== Тестирование запуска и работы связанных с обновлением приложений ====<br />
Проверяются:<br />
# Тестирование запуска и простейших операций со связанными с тестируемым пакетом программами, рекомендуется контроль сообщений при запуске программы из консоли.<br />
# Связанные с библиотеками из проверяемого пакета программы легче всего установить, попробовав удалить пакет с помощью <tt>urpme</tt> (для установленных в системе программ) или <tt>urpmq --whatrequires</tt> (для всех программ из подключенных репозиториев).<br />
# Изменения в интерфейсах обновляемых библиотек и, соответственно, необходимость перекомпиляции связанных пакетов с помощью сервиса https://abi-laboratory.pro/tracker/<br />
# Для пакетов, предоставляющих библиотеки, проверяются использующие эти библиотеки приложения из main, их можно определить командой <tt>urpmq --whatrequires <названиепакета></tt><br />
# Регрессии в локализации графического интерфейса и страниц справки.<br />
# Для тестирования браузеров в дополнение к https://webglsamples.org/aquarium/aquarium.html применяются.<br />
## Тест html5 https://html5test.com/ (сравнить результат до и после обновления, не должно быть регресса)<br />
## Почтовые онлайновые сервисы http://mail.yandex.ru http://mail.google.com<br />
## Яндекс и гугл-карты https://yandex.ru/maps/-/CVTQITy0 https://www.google.ru/maps/@52.2609339,104.3096872,15z?hl=ru<br />
## xml|xsl трансляцию и кодировки на http://base.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=160129;div=LAW;rnd=0.4700782325977544 и<br />
## Воспроизведение видео http://techslides.com/sample-webm-ogg-and-mp4-video-files-for-html5/ <br />
## Воспроизведение [http://youtu.be/37l7P5V1eXU видео с youtube]<br />
## Работа флэша на примере игры [http://vseigru.net/igry-zombi/2541-igra-zombi-protiv-rastenij.html Растения против зомби] и [http://kino.sputnik.ru/films/ivan+vasilyevich+menyayet+professiyu+1973]<br />
## Уязвимости SSL с помощью https://www.ssllabs.com/ssltest/viewMyClient.html<br />
## Тестирование печати<br />
## Тестирование установки браузера по-умолчанию из настроек<br />
<br />
В случае:<br />
# нахождения регрессии функционала или локализации, о них сообщается инициатору запроса в комментариях к запросу на обновление <br />
# нахождения ошибок (не регрессий!) - заводится новый баг, его номер указывается в запросе на обновление.<br />
<br />
==== Тестирование изменений ====<br />
* Применяется при тестировании обновлений, изменяющих внешний вид или поведение системы.<br />
<br />
Включает себя<br />
# Воспроизведение особенностей внешнего вида или поведения системы ДО исправления.<br />
# Воспроизведение измененных обновлений особенностей по их описанию.<br />
<br />
Например, если в advisory сказано, что «вышла новая версия программы» при тестировании изменений нужно, как минимум, убедиться что версия изменилась.<br />
<br />
В случае если не все описанные изменения действительно присутствуют в тестируемом пакете, пакет принимается и в итоговый отчет (Advisory), вносятся только реально проведенные изменения.<br />
В случае значительного отклонения запрошенных и полученных изменений пакет может быть отклонен.<br />
<br />
==== Расширенное тестирование ====<br />
# Расширенное тестирование проводится добровольцами с помощью репозиториев testing, соответствующих основным репозиториям. <br />
# В течение недели (понедельник-четверг) все проверяемые QA обновления, кроме срочных, отправляются в тестинг, при этом в багзилле ставится статус verified и пишется The update is sent to expanded testing<br />
# В пятницу, руководитель QA:<br />
## Еще раз контролирует, все ли пакеты направлены в тестинг-репозитории, при помощи отключения источников-контейнеров и выполнения программы '''urpm-reposync''' с включенными тестингами. Результатом выполнения команды должно быть отсутствие пакетов на синхронизацию<br />
## Проверяет, дошли ли обновления до зеркал<br />
## Контролирует возможность обновления до тестингов с момента предыдущего релиза платформы путем установки релизного образа и его обновления с подключенными тестингами <br />
## Обновляет до тестингов системы на всех доступных тестовых стендах и проверяет их на устойчивость<br />
## На форуме и в сообществе вконтакте объявляет "пятничное тестирование", к нему выпускает бюллетень с полным списком обновлений и методикой их тестирования.<br />
# В понедельник руководитель QA читает отзывы пользователей и по их итогам, а также по итогам эксплуатации тестовых стендов в выходные дни, обрабатывает запросы на обновление и передает их на публикацию (или отклоняет)<br />
<br />
=== Завершение тестирования ===<br />
<br />
==== Положительный результат тестирования ====<br />
# По окончании тестирования при его успехе ставится индикатор успешного тестирования QA «+» и пишется отчет (Advisory), содержащий:<br />
## Название пакета с исходниками (src.rpm).<br />
## Версию пакета.<br />
## Отчет о тестировании (advisory).<br />
## Надпись «QA verified».<br />
# Если пакет содержит изменения, связанные с секретностью или же собран не сотрудником Росы — посылается запрос Secure team (взводится флажок secteam_verified «?»).<br />
# Если тестирование secure не нужно, пакет передается на публикацию (взводится соответствующий published «?»).<br />
# В случае успешного тестирования пакет может быть оставлен в системе. В случае ошибок систему нужно привести к первоначальному виду с помощью деинсталляции пакета или утилиты <tt>urpm-reposync</tt> из <tt>urpm-repotools</tt>.<br />
<br />
==== Отрицательный результат тестирования ====<br />
# При отклонении пакета ставится индикатор отклонения QA «-»,<br />
# В комментариях пишется причина отклонения запроса и в конце комментария добавляется «QA Denied».<br />
# При отрицательном результате тестирования сборщик может выложить исправленные контейнеры в тот же запрос и снова установить «?» в «qa_requested».</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F&diff=18633
Регламент тестирования
2020-04-29T09:37:53Z
<p>Vladimir.potapov: /* Классификация обновлений по степени опасности */</p>
<hr />
<div>[[Category:Регламенты ROSA]]<br />
<br />
=== Политика ===<br />
QA отвечает за стабильность установленного у пользователей дистрибутива при его обновлениях.<br />
<br />
До установки обновлений дистрибутив работает. Любое обновление — риск его обрушить.<br />
Поэтому политика QA обязана быть консервативной и даже несколько параноидальной — при малейших сомнениях должны назначаться дополнительные проверки, пакеты должны отклоняться, направляться на пересборку.<br />
<br />
Политика QA вступает в конфликт с интересами сборщиков пакетов, желающих быстрее увидеть в репозиториях исправленную версию — конфликт этот должен быть конструктивным, приводящим к непрерывному повышению функциональности и стабильности дистрибутива.<br />
<br />
==== Классификация обновлений по степени опасности ====<br />
<blockquote><br />
Меня не интересуют их намерения, меня интересуют их возможности — © Отто Фон Бисмарк<br />
</blockquote><br />
<br />
Классификация исходит из максимально возможного урона (полный отказ функционирования компонента), который может нанести устанавливаемое обновление. Чем выше степень опасности, тем более тщательным должно быть тестирование.<br />
<br />
;0: Критические обновления. Ядро, файловая система, система прав доступа, скрипты загрузки, <tt>systemd</tt>, <tt>glibc</tt>, <tt>dracut</tt>, <tt>grub</tt>, <tt>bash</tt> и прочие основные вещи, если удалить которые система не загрузится даже в консоли.<br />
;1: Обновления драйверов устройств, т.е. те же критические обновления, но актуальные не для всех пользователей. <br />
;2: Обновления сетевых компонентов: NetworkManager, сетевых скриптов, системы сетевой инициализации и системы обновлений (curl, urpmi). Они опасны тем, что если сеть упадет, пользователю без сети будет затруднительно получить исправленный пакет, когда мы его выпустим и установить обновление. <br />
;3: Обновления графических компонент и скриптов — X-ов, менеджера входа, графических библиотек, драйверов, '''perl, python''' — то, без чего невозможен вход в систему в графическом режиме. Т.к. обновление системы, при наличии сети, возможно и не в графике - класс опасности обновлений не самый высокий<br />
;4: Обновление пользовательских пакетов, установленных по-умолчанию в системе. Эти пакеты стоят практически у всех и их ошибки будут влиять на максимальное количество пользователей, однако они могут быть оперативно исправлены потому класс опасности не очень высокий. Туда же нужно отнести популярные программы не входящие в поставку — <tt>gimp</tt>, <tt>inkscape</tt>, <tt>audacity</tt>, <tt>vlc</tt>, <tt>kdenive</tt>, <tt>opera</tt>, <tt>chromium-browser</tt>, <tt>skype</tt>.<br />
;5: Обновление прочих пользовательских пакетов. Они затронут только тех, у кого эти программы стоят.<br />
;6: Обновление пакетов, необходимых только для сборки дистрибутива или работы с abf. Почти никому кроме нас они не интересны, потому класс опасности самый низкий.<br />
<br />
==== Задача ====<br />
* Главная задача QA — поиск регрессий, то есть таких изменений в дистрибутиве, которые уменьшают его функциональность по сравнению с предыдущим состоянием.<br />
* Также задачей QA является внесение в багзиллу всех ошибок, найденных в процессе тестирования и не относящихся к регрессиям.<br />
<br />
==== Общие положения ====<br />
* Запрос на обновление пишется в багзилле <br />
* Все сообщения пишутся на английском языке.<br />
* Порядок принятие запросов на тестирование командой QA в общем случае — в порядке возрастания номеров багов, возможны исключения, связанные со срочностью или трудностями в тестировании определенных пакетов.<br />
* Список запросов на обновление можно открыть по ссылке http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=qa_verified%3F&o1=substring&list_id=38774<br />
<br />
==== Срок тестирования ====<br />
* Срок тестирования пакета — '''одна неделя''', за это время служба QA должня проверить пакет и вынести заключение. Срок тестирования может быть увеличен при необходимости тестирования внешними тестерами на отсутствующих у службы QA аппаратно-программных конфигурациях, в этом случае в запросе на обновление задержка должна быть обоснована службой QA.<br />
* Для пакета, который нужно проверить очень срочно, сборщик должен установить приоритет <tt>Highest Critical</tt>, чтобы он выделялся красным цветом в списке. Такие пакеты рассматриваются в течение '''48 часов''' рабочего времени.<br />
* Норма выработки на одного тестера QA - 20 одобренных запросов в неделю, обычно отклоняется 10-20% запросов, так что тестер QA в среднем обрабатывает 5 запросов в день.<br />
<br />
=== Процедура тестирования ===<br />
<br />
==== Требования к запросу на обновление ====<br />
# QA Team тестирует пакеты-кандидаты на добавление в репозитории <tt>main/updates, non-free/updates и restricted/updates</tt>.<br />
# Пакет должен быть собран в общедоступном репозитории (не <tt>_personal</tt>).<br />
# Для архитектурно-зависимых пакетов должны быть представлены все поддерживаемые архитектуры (<tt>i586</tt> и <tt>x64</tt>).<br />
# Описание обновления должно содержать все изменения, которые нужно протестировать.<br />
При несоответствии запроса на обновление этим требованиям необходимо сообщить об этом инициатору запроса с помощью комментария.<br />
В случае, если до пятницы запрос не исправлен согласно требованиям, он отклоняется.<br />
<br />
==== Тестирование установки пакетов ====<br />
# Система перед тестовым обновлением должна соответствовать стандартным репозиториям, с подключенными тестингами. Это можно проверить запуском <tt>urpm-reposync</tt> из пакета <tt>urpm-tools</tt><br />
# Пакеты для тестирования устанавливаются и в графическом, и в текстовом режиме.<br />
## Репозиторий подключается как репозиторий с обновлениями.<br />
## Запускается стандартная процедура обновления.<br />
# Для пакетов, установленных в системе по-умолчанию, проверяется их обновление.<br />
# Для пакетов, не установленных в системе, проверяется как их обновление, так и первоначальная установка при подключенных тестовых контейнерах.<br />
# Установка пакетов проверяется для обеих архитектур. Так как ошибки установки не обычно не зависят от архитектуры, обычно достаточно проверить на одной архитектуре установку в графическом режиме, а на другой — обновление в текстовом, или наоборот.<br />
<br />
При ошибках установки или обновления пакета необходимо сообщить об этом инициатору запроса с помощью комментария. В случае, если до пятницы ошибка установки не исправлена, запрос отклоняется.<br />
<br />
==== Тестирование на функционирование и устойчивость системы после обновления ====<br />
При тестировании системы проверяется:<br />
# Стабильность и внешний вид обновленной системы после перезагрузки.<br />
# Стабильность и внешний вид обновленной системы после пробуждения из спящего режима. Тестирование стабильности и производительности может проводиться, например, с помощью теста Unigine Valley под wine и тестом браузера https://webglsamples.org/aquarium/aquarium.html<br />
# Ошибки загрузки демонов, например, с помощью <tt>systemctl | grep failed</tt>.<br />
# Ошибки непрерывного роста файла <tt>.xsession-errors</tt>.<br />
# Журнал ошибок, командами '''journalctl -b |grep fail''' и '''journalctl -b |grep error''' (не должно быть новых ошибок, если они появились - нужно найти связанное с ошибкой обновление и написать инициатору)<br />
# Работа URPMI — дальнейшее обновление пакетов.<br />
# Установка и удаление dkms-модулей (например, установкой проприетарных драйверов с последующим откатом на свободные)<br />
# Сохранением загрузчиком определения других операционных систем, установленных на тестовом компьютере<br />
# Сохранение даты-времени на тестируемой машине после перезагрузки и пробуждения из спящего режима<br />
# Работа системы поиска по содержимому офисных файлов<br />
<br />
При ошибках функционирования или устойчивости системы, связанной с обновлением, необходимо сообщить об этом инициатору запроса с помощью комментария. <br />
В случае, если до пятницы ошибка не исправлена, запрос отклоняется.<br />
<br />
==== Тестирование запуска и работы связанных с обновлением приложений ====<br />
Проверяются:<br />
# Тестирование запуска и простейших операций со связанными с тестируемым пакетом программами, рекомендуется контроль сообщений при запуске программы из консоли.<br />
# Связанные с библиотеками из проверяемого пакета программы легче всего установить, попробовав удалить пакет с помощью <tt>urpme</tt> (для установленных в системе программ) или <tt>urpmq --whatrequires</tt> (для всех программ из подключенных репозиториев).<br />
# Изменения в интерфейсах обновляемых библиотек и, соответственно, необходимость перекомпиляции связанных пакетов с помощью сервиса https://abi-laboratory.pro/tracker/<br />
# Для пакетов, предоставляющих библиотеки, проверяются использующие эти библиотеки приложения из main, их можно определить командой <tt>urpmq --whatrequires <названиепакета></tt><br />
# Регрессии в локализации графического интерфейса и страниц справки.<br />
# Для тестирования браузеров в дополнение к https://webglsamples.org/aquarium/aquarium.html применяются.<br />
## Тест html5 https://html5test.com/ (сравнить результат до и после обновления, не должно быть регресса)<br />
## Почтовые онлайновые сервисы http://mail.yandex.ru http://mail.google.com<br />
## Яндекс и гугл-карты https://yandex.ru/maps/-/CVTQITy0 https://www.google.ru/maps/@52.2609339,104.3096872,15z?hl=ru<br />
## xml|xsl трансляцию и кодировки на http://base.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=160129;div=LAW;rnd=0.4700782325977544 и<br />
## Воспроизведение видео http://techslides.com/sample-webm-ogg-and-mp4-video-files-for-html5/ <br />
## Воспроизведение [http://youtu.be/37l7P5V1eXU видео с youtube]<br />
## Работа флэша на примере игры [http://vseigru.net/igry-zombi/2541-igra-zombi-protiv-rastenij.html Растения против зомби] и [http://kino.sputnik.ru/films/ivan+vasilyevich+menyayet+professiyu+1973]<br />
## Уязвимости SSL с помощью https://www.ssllabs.com/ssltest/viewMyClient.html<br />
## Тестирование печати<br />
## Тестирование установки браузера по-умолчанию из настроек<br />
<br />
В случае:<br />
# нахождения регрессии функционала или локализации, о них сообщается инициатору запроса в комментариях к запросу на обновление <br />
# нахождения ошибок (не регрессий!) - заводится новый баг, его номер указывается в запросе на обновление.<br />
<br />
==== Тестирование изменений ====<br />
* Применяется при тестировании обновлений, изменяющих внешний вид или поведение системы.<br />
<br />
Включает себя<br />
# Воспроизведение особенностей внешнего вида или поведения системы ДО исправления.<br />
# Воспроизведение измененных обновлений особенностей по их описанию.<br />
<br />
Например, если в advisory сказано, что «вышла новая версия программы» при тестировании изменений нужно, как минимум, убедиться что версия изменилась.<br />
<br />
В случае если не все описанные изменения действительно присутствуют в тестируемом пакете, пакет принимается и в итоговый отчет (Advisory), вносятся только реально проведенные изменения.<br />
В случае значительного отклонения запрошенных и полученных изменений пакет может быть отклонен.<br />
<br />
==== Расширенное тестирование ====<br />
# Расширенное тестирование проводится добровольцами с помощью репозиториев testing, соответствующих основным репозиториям. <br />
# В течение недели (понедельник-четверг) все проверяемые QA обновления, кроме срочных, отправляются в тестинг, при этом в багзилле ставится статус verified и пишется The update is sent to expanded testing<br />
# В пятницу, руководитель QA:<br />
## Еще раз контролирует, все ли пакеты направлены в тестинг-репозитории, при помощи отключения источников-контейнеров и выполнения программы '''urpm-reposync''' с включенными тестингами. Результатом выполнения команды должно быть отсутствие пакетов на синхронизацию<br />
## Проверяет, дошли ли обновления до зеркал<br />
## Контролирует возможность обновления до тестингов с момента предыдущего релиза платформы путем установки релизного образа и его обновления с подключенными тестингами <br />
## Обновляет до тестингов системы на всех доступных тестовых стендах и проверяет их на устойчивость<br />
## На форуме и в сообществе вконтакте объявляет "пятничное тестирование", к нему выпускает бюллетень с полным списком обновлений и методикой их тестирования.<br />
# В понедельник руководитель QA читает отзывы пользователей и по их итогам, а также по итогам эксплуатации тестовых стендов в выходные дни, обрабатывает запросы на обновление и передает их на публикацию (или отклоняет)<br />
<br />
=== Завершение тестирования ===<br />
<br />
==== Положительный результат тестирования ====<br />
# По окончании тестирования при его успехе ставится индикатор успешного тестирования QA «+» и пишется отчет (Advisory), содержащий:<br />
## Название пакета с исходниками (src.rpm).<br />
## Версию пакета.<br />
## Отчет о тестировании (advisory).<br />
## Надпись «QA verified».<br />
# Если пакет содержит изменения, связанные с секретностью или же собран не сотрудником Росы — посылается запрос Secure team (взводится флажок secteam_verified «?»).<br />
# Если тестирование secure не нужно, пакет передается на публикацию (взводится соответствующий published «?»).<br />
# В случае успешного тестирования пакет может быть оставлен в системе. В случае ошибок систему нужно привести к первоначальному виду с помощью деинсталляции пакета или утилиты <tt>urpm-reposync</tt> из <tt>urpm-repotools</tt>.<br />
<br />
==== Отрицательный результат тестирования ====<br />
# При отклонении пакета ставится индикатор отклонения QA «-»,<br />
# В комментариях пишется причина отклонения запроса и в конце комментария добавляется «QA Denied».<br />
# При отрицательном результате тестирования сборщик может выложить исправленные контейнеры в тот же запрос и снова установить «?» в «qa_requested».</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F&diff=18632
Регламент тестирования
2020-04-29T09:35:28Z
<p>Vladimir.potapov: /* Тестирование на функционирование и устойчивость системы после обновления */</p>
<hr />
<div>[[Category:Регламенты ROSA]]<br />
<br />
=== Политика ===<br />
QA отвечает за стабильность установленного у пользователей дистрибутива при его обновлениях.<br />
<br />
До установки обновлений дистрибутив работает. Любое обновление — риск его обрушить.<br />
Поэтому политика QA обязана быть консервативной и даже несколько параноидальной — при малейших сомнениях должны назначаться дополнительные проверки, пакеты должны отклоняться, направляться на пересборку.<br />
<br />
Политика QA вступает в конфликт с интересами сборщиков пакетов, желающих быстрее увидеть в репозиториях исправленную версию — конфликт этот должен быть конструктивным, приводящим к непрерывному повышению функциональности и стабильности дистрибутива.<br />
<br />
==== Классификация обновлений по степени опасности ====<br />
<blockquote><br />
Меня не интересуют их намерения, меня интересуют их возможности — © Отто Фон Бисмарк<br />
</blockquote><br />
<br />
Классификация исходит из максимально возможного урона (полный отказ функционирования компонента), который может нанести устанавливаемое обновление.<br />
<br />
;0: Критические обновления. Ядро, файловая система, система прав доступа, скрипты загрузки, <tt>systemd</tt>, <tt>glibc</tt>, <tt>dracut</tt>, <tt>grub</tt>, <tt>bash</tt> и прочие основные вещи, если удалить которые система не загрузится даже в консоли.<br />
;1: Обновления драйверов устройств, т.е. те же критические обновления, но актуальные не для всех пользователей. <br />
;2: Обновления сетевых компонентов: NetworkManager, сетевых скриптов, системы сетевой инициализации и системы обновлений (curl, urpmi). Они опасны тем, что если сеть упадет, пользователю без сети будет затруднительно получить исправленный пакет, когда мы его выпустим и установить обновление. <br />
;3: Обновления графических компонент и скриптов — X-ов, менеджера входа, графических библиотек, драйверов, '''perl, python''' — то, без чего невозможен вход в систему в графическом режиме. Т.к. обновление системы, при наличии сети, возможно и не в графике - класс опасности обновлений не самый высокий<br />
;4: Обновление пользовательских пакетов, установленных по-умолчанию в системе. Эти пакеты стоят практически у всех и их ошибки будут влиять на максимальное количество пользователей, однако они могут быть оперативно исправлены потому класс опасности не очень высокий. Туда же нужно отнести популярные программы не входящие в поставку — <tt>gimp</tt>, <tt>inkscape</tt>, <tt>audacity</tt>, <tt>vlc</tt>, <tt>kdenive</tt>, <tt>opera</tt>, <tt>chromium-browser</tt>, <tt>skype</tt>.<br />
;5: Обновление прочих пользовательских пакетов. Они затронут только тех, у кого эти программы стоят.<br />
;6: Обновление пакетов, необходимых только для сборки дистрибутива или работы с abf. Почти никому кроме нас они не интересны, потому класс опасности самый низкий.<br />
<br />
==== Задача ====<br />
* Главная задача QA — поиск регрессий, то есть таких изменений в дистрибутиве, которые уменьшают его функциональность по сравнению с предыдущим состоянием.<br />
* Также задачей QA является внесение в багзиллу всех ошибок, найденных в процессе тестирования и не относящихся к регрессиям.<br />
<br />
==== Общие положения ====<br />
* Запрос на обновление пишется в багзилле <br />
* Все сообщения пишутся на английском языке.<br />
* Порядок принятие запросов на тестирование командой QA в общем случае — в порядке возрастания номеров багов, возможны исключения, связанные со срочностью или трудностями в тестировании определенных пакетов.<br />
* Список запросов на обновление можно открыть по ссылке http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=qa_verified%3F&o1=substring&list_id=38774<br />
<br />
==== Срок тестирования ====<br />
* Срок тестирования пакета — '''одна неделя''', за это время служба QA должня проверить пакет и вынести заключение. Срок тестирования может быть увеличен при необходимости тестирования внешними тестерами на отсутствующих у службы QA аппаратно-программных конфигурациях, в этом случае в запросе на обновление задержка должна быть обоснована службой QA.<br />
* Для пакета, который нужно проверить очень срочно, сборщик должен установить приоритет <tt>Highest Critical</tt>, чтобы он выделялся красным цветом в списке. Такие пакеты рассматриваются в течение '''48 часов''' рабочего времени.<br />
* Норма выработки на одного тестера QA - 20 одобренных запросов в неделю, обычно отклоняется 10-20% запросов, так что тестер QA в среднем обрабатывает 5 запросов в день.<br />
<br />
=== Процедура тестирования ===<br />
<br />
==== Требования к запросу на обновление ====<br />
# QA Team тестирует пакеты-кандидаты на добавление в репозитории <tt>main/updates, non-free/updates и restricted/updates</tt>.<br />
# Пакет должен быть собран в общедоступном репозитории (не <tt>_personal</tt>).<br />
# Для архитектурно-зависимых пакетов должны быть представлены все поддерживаемые архитектуры (<tt>i586</tt> и <tt>x64</tt>).<br />
# Описание обновления должно содержать все изменения, которые нужно протестировать.<br />
При несоответствии запроса на обновление этим требованиям необходимо сообщить об этом инициатору запроса с помощью комментария.<br />
В случае, если до пятницы запрос не исправлен согласно требованиям, он отклоняется.<br />
<br />
==== Тестирование установки пакетов ====<br />
# Система перед тестовым обновлением должна соответствовать стандартным репозиториям, с подключенными тестингами. Это можно проверить запуском <tt>urpm-reposync</tt> из пакета <tt>urpm-tools</tt><br />
# Пакеты для тестирования устанавливаются и в графическом, и в текстовом режиме.<br />
## Репозиторий подключается как репозиторий с обновлениями.<br />
## Запускается стандартная процедура обновления.<br />
# Для пакетов, установленных в системе по-умолчанию, проверяется их обновление.<br />
# Для пакетов, не установленных в системе, проверяется как их обновление, так и первоначальная установка при подключенных тестовых контейнерах.<br />
# Установка пакетов проверяется для обеих архитектур. Так как ошибки установки не обычно не зависят от архитектуры, обычно достаточно проверить на одной архитектуре установку в графическом режиме, а на другой — обновление в текстовом, или наоборот.<br />
<br />
При ошибках установки или обновления пакета необходимо сообщить об этом инициатору запроса с помощью комментария. В случае, если до пятницы ошибка установки не исправлена, запрос отклоняется.<br />
<br />
==== Тестирование на функционирование и устойчивость системы после обновления ====<br />
При тестировании системы проверяется:<br />
# Стабильность и внешний вид обновленной системы после перезагрузки.<br />
# Стабильность и внешний вид обновленной системы после пробуждения из спящего режима. Тестирование стабильности и производительности может проводиться, например, с помощью теста Unigine Valley под wine и тестом браузера https://webglsamples.org/aquarium/aquarium.html<br />
# Ошибки загрузки демонов, например, с помощью <tt>systemctl | grep failed</tt>.<br />
# Ошибки непрерывного роста файла <tt>.xsession-errors</tt>.<br />
# Журнал ошибок, командами '''journalctl -b |grep fail''' и '''journalctl -b |grep error''' (не должно быть новых ошибок, если они появились - нужно найти связанное с ошибкой обновление и написать инициатору)<br />
# Работа URPMI — дальнейшее обновление пакетов.<br />
# Установка и удаление dkms-модулей (например, установкой проприетарных драйверов с последующим откатом на свободные)<br />
# Сохранением загрузчиком определения других операционных систем, установленных на тестовом компьютере<br />
# Сохранение даты-времени на тестируемой машине после перезагрузки и пробуждения из спящего режима<br />
# Работа системы поиска по содержимому офисных файлов<br />
<br />
При ошибках функционирования или устойчивости системы, связанной с обновлением, необходимо сообщить об этом инициатору запроса с помощью комментария. <br />
В случае, если до пятницы ошибка не исправлена, запрос отклоняется.<br />
<br />
==== Тестирование запуска и работы связанных с обновлением приложений ====<br />
Проверяются:<br />
# Тестирование запуска и простейших операций со связанными с тестируемым пакетом программами, рекомендуется контроль сообщений при запуске программы из консоли.<br />
# Связанные с библиотеками из проверяемого пакета программы легче всего установить, попробовав удалить пакет с помощью <tt>urpme</tt> (для установленных в системе программ) или <tt>urpmq --whatrequires</tt> (для всех программ из подключенных репозиториев).<br />
# Изменения в интерфейсах обновляемых библиотек и, соответственно, необходимость перекомпиляции связанных пакетов с помощью сервиса https://abi-laboratory.pro/tracker/<br />
# Для пакетов, предоставляющих библиотеки, проверяются использующие эти библиотеки приложения из main, их можно определить командой <tt>urpmq --whatrequires <названиепакета></tt><br />
# Регрессии в локализации графического интерфейса и страниц справки.<br />
# Для тестирования браузеров в дополнение к https://webglsamples.org/aquarium/aquarium.html применяются.<br />
## Тест html5 https://html5test.com/ (сравнить результат до и после обновления, не должно быть регресса)<br />
## Почтовые онлайновые сервисы http://mail.yandex.ru http://mail.google.com<br />
## Яндекс и гугл-карты https://yandex.ru/maps/-/CVTQITy0 https://www.google.ru/maps/@52.2609339,104.3096872,15z?hl=ru<br />
## xml|xsl трансляцию и кодировки на http://base.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=160129;div=LAW;rnd=0.4700782325977544 и<br />
## Воспроизведение видео http://techslides.com/sample-webm-ogg-and-mp4-video-files-for-html5/ <br />
## Воспроизведение [http://youtu.be/37l7P5V1eXU видео с youtube]<br />
## Работа флэша на примере игры [http://vseigru.net/igry-zombi/2541-igra-zombi-protiv-rastenij.html Растения против зомби] и [http://kino.sputnik.ru/films/ivan+vasilyevich+menyayet+professiyu+1973]<br />
## Уязвимости SSL с помощью https://www.ssllabs.com/ssltest/viewMyClient.html<br />
## Тестирование печати<br />
## Тестирование установки браузера по-умолчанию из настроек<br />
<br />
В случае:<br />
# нахождения регрессии функционала или локализации, о них сообщается инициатору запроса в комментариях к запросу на обновление <br />
# нахождения ошибок (не регрессий!) - заводится новый баг, его номер указывается в запросе на обновление.<br />
<br />
==== Тестирование изменений ====<br />
* Применяется при тестировании обновлений, изменяющих внешний вид или поведение системы.<br />
<br />
Включает себя<br />
# Воспроизведение особенностей внешнего вида или поведения системы ДО исправления.<br />
# Воспроизведение измененных обновлений особенностей по их описанию.<br />
<br />
Например, если в advisory сказано, что «вышла новая версия программы» при тестировании изменений нужно, как минимум, убедиться что версия изменилась.<br />
<br />
В случае если не все описанные изменения действительно присутствуют в тестируемом пакете, пакет принимается и в итоговый отчет (Advisory), вносятся только реально проведенные изменения.<br />
В случае значительного отклонения запрошенных и полученных изменений пакет может быть отклонен.<br />
<br />
==== Расширенное тестирование ====<br />
# Расширенное тестирование проводится добровольцами с помощью репозиториев testing, соответствующих основным репозиториям. <br />
# В течение недели (понедельник-четверг) все проверяемые QA обновления, кроме срочных, отправляются в тестинг, при этом в багзилле ставится статус verified и пишется The update is sent to expanded testing<br />
# В пятницу, руководитель QA:<br />
## Еще раз контролирует, все ли пакеты направлены в тестинг-репозитории, при помощи отключения источников-контейнеров и выполнения программы '''urpm-reposync''' с включенными тестингами. Результатом выполнения команды должно быть отсутствие пакетов на синхронизацию<br />
## Проверяет, дошли ли обновления до зеркал<br />
## Контролирует возможность обновления до тестингов с момента предыдущего релиза платформы путем установки релизного образа и его обновления с подключенными тестингами <br />
## Обновляет до тестингов системы на всех доступных тестовых стендах и проверяет их на устойчивость<br />
## На форуме и в сообществе вконтакте объявляет "пятничное тестирование", к нему выпускает бюллетень с полным списком обновлений и методикой их тестирования.<br />
# В понедельник руководитель QA читает отзывы пользователей и по их итогам, а также по итогам эксплуатации тестовых стендов в выходные дни, обрабатывает запросы на обновление и передает их на публикацию (или отклоняет)<br />
<br />
=== Завершение тестирования ===<br />
<br />
==== Положительный результат тестирования ====<br />
# По окончании тестирования при его успехе ставится индикатор успешного тестирования QA «+» и пишется отчет (Advisory), содержащий:<br />
## Название пакета с исходниками (src.rpm).<br />
## Версию пакета.<br />
## Отчет о тестировании (advisory).<br />
## Надпись «QA verified».<br />
# Если пакет содержит изменения, связанные с секретностью или же собран не сотрудником Росы — посылается запрос Secure team (взводится флажок secteam_verified «?»).<br />
# Если тестирование secure не нужно, пакет передается на публикацию (взводится соответствующий published «?»).<br />
# В случае успешного тестирования пакет может быть оставлен в системе. В случае ошибок систему нужно привести к первоначальному виду с помощью деинсталляции пакета или утилиты <tt>urpm-reposync</tt> из <tt>urpm-repotools</tt>.<br />
<br />
==== Отрицательный результат тестирования ====<br />
# При отклонении пакета ставится индикатор отклонения QA «-»,<br />
# В комментариях пишется причина отклонения запроса и в конце комментария добавляется «QA Denied».<br />
# При отрицательном результате тестирования сборщик может выложить исправленные контейнеры в тот же запрос и снова установить «?» в «qa_requested».</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F&diff=18631
Регламент тестирования
2020-04-29T09:34:02Z
<p>Vladimir.potapov: /* Тестирование на функционирование и устойчивость системы после обновления */</p>
<hr />
<div>[[Category:Регламенты ROSA]]<br />
<br />
=== Политика ===<br />
QA отвечает за стабильность установленного у пользователей дистрибутива при его обновлениях.<br />
<br />
До установки обновлений дистрибутив работает. Любое обновление — риск его обрушить.<br />
Поэтому политика QA обязана быть консервативной и даже несколько параноидальной — при малейших сомнениях должны назначаться дополнительные проверки, пакеты должны отклоняться, направляться на пересборку.<br />
<br />
Политика QA вступает в конфликт с интересами сборщиков пакетов, желающих быстрее увидеть в репозиториях исправленную версию — конфликт этот должен быть конструктивным, приводящим к непрерывному повышению функциональности и стабильности дистрибутива.<br />
<br />
==== Классификация обновлений по степени опасности ====<br />
<blockquote><br />
Меня не интересуют их намерения, меня интересуют их возможности — © Отто Фон Бисмарк<br />
</blockquote><br />
<br />
Классификация исходит из максимально возможного урона (полный отказ функционирования компонента), который может нанести устанавливаемое обновление.<br />
<br />
;0: Критические обновления. Ядро, файловая система, система прав доступа, скрипты загрузки, <tt>systemd</tt>, <tt>glibc</tt>, <tt>dracut</tt>, <tt>grub</tt>, <tt>bash</tt> и прочие основные вещи, если удалить которые система не загрузится даже в консоли.<br />
;1: Обновления драйверов устройств, т.е. те же критические обновления, но актуальные не для всех пользователей. <br />
;2: Обновления сетевых компонентов: NetworkManager, сетевых скриптов, системы сетевой инициализации и системы обновлений (curl, urpmi). Они опасны тем, что если сеть упадет, пользователю без сети будет затруднительно получить исправленный пакет, когда мы его выпустим и установить обновление. <br />
;3: Обновления графических компонент и скриптов — X-ов, менеджера входа, графических библиотек, драйверов, '''perl, python''' — то, без чего невозможен вход в систему в графическом режиме. Т.к. обновление системы, при наличии сети, возможно и не в графике - класс опасности обновлений не самый высокий<br />
;4: Обновление пользовательских пакетов, установленных по-умолчанию в системе. Эти пакеты стоят практически у всех и их ошибки будут влиять на максимальное количество пользователей, однако они могут быть оперативно исправлены потому класс опасности не очень высокий. Туда же нужно отнести популярные программы не входящие в поставку — <tt>gimp</tt>, <tt>inkscape</tt>, <tt>audacity</tt>, <tt>vlc</tt>, <tt>kdenive</tt>, <tt>opera</tt>, <tt>chromium-browser</tt>, <tt>skype</tt>.<br />
;5: Обновление прочих пользовательских пакетов. Они затронут только тех, у кого эти программы стоят.<br />
;6: Обновление пакетов, необходимых только для сборки дистрибутива или работы с abf. Почти никому кроме нас они не интересны, потому класс опасности самый низкий.<br />
<br />
==== Задача ====<br />
* Главная задача QA — поиск регрессий, то есть таких изменений в дистрибутиве, которые уменьшают его функциональность по сравнению с предыдущим состоянием.<br />
* Также задачей QA является внесение в багзиллу всех ошибок, найденных в процессе тестирования и не относящихся к регрессиям.<br />
<br />
==== Общие положения ====<br />
* Запрос на обновление пишется в багзилле <br />
* Все сообщения пишутся на английском языке.<br />
* Порядок принятие запросов на тестирование командой QA в общем случае — в порядке возрастания номеров багов, возможны исключения, связанные со срочностью или трудностями в тестировании определенных пакетов.<br />
* Список запросов на обновление можно открыть по ссылке http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=qa_verified%3F&o1=substring&list_id=38774<br />
<br />
==== Срок тестирования ====<br />
* Срок тестирования пакета — '''одна неделя''', за это время служба QA должня проверить пакет и вынести заключение. Срок тестирования может быть увеличен при необходимости тестирования внешними тестерами на отсутствующих у службы QA аппаратно-программных конфигурациях, в этом случае в запросе на обновление задержка должна быть обоснована службой QA.<br />
* Для пакета, который нужно проверить очень срочно, сборщик должен установить приоритет <tt>Highest Critical</tt>, чтобы он выделялся красным цветом в списке. Такие пакеты рассматриваются в течение '''48 часов''' рабочего времени.<br />
* Норма выработки на одного тестера QA - 20 одобренных запросов в неделю, обычно отклоняется 10-20% запросов, так что тестер QA в среднем обрабатывает 5 запросов в день.<br />
<br />
=== Процедура тестирования ===<br />
<br />
==== Требования к запросу на обновление ====<br />
# QA Team тестирует пакеты-кандидаты на добавление в репозитории <tt>main/updates, non-free/updates и restricted/updates</tt>.<br />
# Пакет должен быть собран в общедоступном репозитории (не <tt>_personal</tt>).<br />
# Для архитектурно-зависимых пакетов должны быть представлены все поддерживаемые архитектуры (<tt>i586</tt> и <tt>x64</tt>).<br />
# Описание обновления должно содержать все изменения, которые нужно протестировать.<br />
При несоответствии запроса на обновление этим требованиям необходимо сообщить об этом инициатору запроса с помощью комментария.<br />
В случае, если до пятницы запрос не исправлен согласно требованиям, он отклоняется.<br />
<br />
==== Тестирование установки пакетов ====<br />
# Система перед тестовым обновлением должна соответствовать стандартным репозиториям, с подключенными тестингами. Это можно проверить запуском <tt>urpm-reposync</tt> из пакета <tt>urpm-tools</tt><br />
# Пакеты для тестирования устанавливаются и в графическом, и в текстовом режиме.<br />
## Репозиторий подключается как репозиторий с обновлениями.<br />
## Запускается стандартная процедура обновления.<br />
# Для пакетов, установленных в системе по-умолчанию, проверяется их обновление.<br />
# Для пакетов, не установленных в системе, проверяется как их обновление, так и первоначальная установка при подключенных тестовых контейнерах.<br />
# Установка пакетов проверяется для обеих архитектур. Так как ошибки установки не обычно не зависят от архитектуры, обычно достаточно проверить на одной архитектуре установку в графическом режиме, а на другой — обновление в текстовом, или наоборот.<br />
<br />
При ошибках установки или обновления пакета необходимо сообщить об этом инициатору запроса с помощью комментария. В случае, если до пятницы ошибка установки не исправлена, запрос отклоняется.<br />
<br />
==== Тестирование на функционирование и устойчивость системы после обновления ====<br />
При тестировании системы проверяется:<br />
# Стабильность и внешний вид обновленной системы после перезагрузки.<br />
# Стабильность и внешний вид обновленной системы после пробуждения из спящего режима. Тестирование стабильности и производительности может проводиться, например, с помощью теста Unigine Valley под wine и тестом браузера https://webglsamples.org/aquarium/aquarium.html<br />
# Ошибки загрузки демонов, например, с помощью <tt>systemctl | grep failed</tt>.<br />
# Ошибки непрерывного роста файла <tt>.xsession-errors</tt>.<br />
# Журнал ошибок, командами '''journalctl -b |grep fail''' и '''journalctl -b |grep error''' (не должно быть новых ошибок, если они появились - нужно найти связанное с ошибкой обновление и написать инициатору)<br />
# Работа URPMI — дальнейшее обновление пакетов.<br />
# Установка и удаление dkms-модулей (например, установкой проприетарных драйверов с последующим откатом на свободные)<br />
# Сохранением загрузчиком определения других операционных систем, установленных на тестовом компьютере<br />
# Сохранение даты-времени на тестируемой машине после перезагрузки и пробуждения из спящего режима<br />
# Работа системы поиска по содержимому офисных файлов<br />
<br />
==== Тестирование запуска и работы связанных с обновлением приложений ====<br />
Проверяются:<br />
# Тестирование запуска и простейших операций со связанными с тестируемым пакетом программами, рекомендуется контроль сообщений при запуске программы из консоли.<br />
# Связанные с библиотеками из проверяемого пакета программы легче всего установить, попробовав удалить пакет с помощью <tt>urpme</tt> (для установленных в системе программ) или <tt>urpmq --whatrequires</tt> (для всех программ из подключенных репозиториев).<br />
# Изменения в интерфейсах обновляемых библиотек и, соответственно, необходимость перекомпиляции связанных пакетов с помощью сервиса https://abi-laboratory.pro/tracker/<br />
# Для пакетов, предоставляющих библиотеки, проверяются использующие эти библиотеки приложения из main, их можно определить командой <tt>urpmq --whatrequires <названиепакета></tt><br />
# Регрессии в локализации графического интерфейса и страниц справки.<br />
# Для тестирования браузеров в дополнение к https://webglsamples.org/aquarium/aquarium.html применяются.<br />
## Тест html5 https://html5test.com/ (сравнить результат до и после обновления, не должно быть регресса)<br />
## Почтовые онлайновые сервисы http://mail.yandex.ru http://mail.google.com<br />
## Яндекс и гугл-карты https://yandex.ru/maps/-/CVTQITy0 https://www.google.ru/maps/@52.2609339,104.3096872,15z?hl=ru<br />
## xml|xsl трансляцию и кодировки на http://base.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=160129;div=LAW;rnd=0.4700782325977544 и<br />
## Воспроизведение видео http://techslides.com/sample-webm-ogg-and-mp4-video-files-for-html5/ <br />
## Воспроизведение [http://youtu.be/37l7P5V1eXU видео с youtube]<br />
## Работа флэша на примере игры [http://vseigru.net/igry-zombi/2541-igra-zombi-protiv-rastenij.html Растения против зомби] и [http://kino.sputnik.ru/films/ivan+vasilyevich+menyayet+professiyu+1973]<br />
## Уязвимости SSL с помощью https://www.ssllabs.com/ssltest/viewMyClient.html<br />
## Тестирование печати<br />
## Тестирование установки браузера по-умолчанию из настроек<br />
<br />
В случае:<br />
# нахождения регрессии функционала или локализации, о них сообщается инициатору запроса в комментариях к запросу на обновление <br />
# нахождения ошибок (не регрессий!) - заводится новый баг, его номер указывается в запросе на обновление.<br />
<br />
==== Тестирование изменений ====<br />
* Применяется при тестировании обновлений, изменяющих внешний вид или поведение системы.<br />
<br />
Включает себя<br />
# Воспроизведение особенностей внешнего вида или поведения системы ДО исправления.<br />
# Воспроизведение измененных обновлений особенностей по их описанию.<br />
<br />
Например, если в advisory сказано, что «вышла новая версия программы» при тестировании изменений нужно, как минимум, убедиться что версия изменилась.<br />
<br />
В случае если не все описанные изменения действительно присутствуют в тестируемом пакете, пакет принимается и в итоговый отчет (Advisory), вносятся только реально проведенные изменения.<br />
В случае значительного отклонения запрошенных и полученных изменений пакет может быть отклонен.<br />
<br />
==== Расширенное тестирование ====<br />
# Расширенное тестирование проводится добровольцами с помощью репозиториев testing, соответствующих основным репозиториям. <br />
# В течение недели (понедельник-четверг) все проверяемые QA обновления, кроме срочных, отправляются в тестинг, при этом в багзилле ставится статус verified и пишется The update is sent to expanded testing<br />
# В пятницу, руководитель QA:<br />
## Еще раз контролирует, все ли пакеты направлены в тестинг-репозитории, при помощи отключения источников-контейнеров и выполнения программы '''urpm-reposync''' с включенными тестингами. Результатом выполнения команды должно быть отсутствие пакетов на синхронизацию<br />
## Проверяет, дошли ли обновления до зеркал<br />
## Контролирует возможность обновления до тестингов с момента предыдущего релиза платформы путем установки релизного образа и его обновления с подключенными тестингами <br />
## Обновляет до тестингов системы на всех доступных тестовых стендах и проверяет их на устойчивость<br />
## На форуме и в сообществе вконтакте объявляет "пятничное тестирование", к нему выпускает бюллетень с полным списком обновлений и методикой их тестирования.<br />
# В понедельник руководитель QA читает отзывы пользователей и по их итогам, а также по итогам эксплуатации тестовых стендов в выходные дни, обрабатывает запросы на обновление и передает их на публикацию (или отклоняет)<br />
<br />
=== Завершение тестирования ===<br />
<br />
==== Положительный результат тестирования ====<br />
# По окончании тестирования при его успехе ставится индикатор успешного тестирования QA «+» и пишется отчет (Advisory), содержащий:<br />
## Название пакета с исходниками (src.rpm).<br />
## Версию пакета.<br />
## Отчет о тестировании (advisory).<br />
## Надпись «QA verified».<br />
# Если пакет содержит изменения, связанные с секретностью или же собран не сотрудником Росы — посылается запрос Secure team (взводится флажок secteam_verified «?»).<br />
# Если тестирование secure не нужно, пакет передается на публикацию (взводится соответствующий published «?»).<br />
# В случае успешного тестирования пакет может быть оставлен в системе. В случае ошибок систему нужно привести к первоначальному виду с помощью деинсталляции пакета или утилиты <tt>urpm-reposync</tt> из <tt>urpm-repotools</tt>.<br />
<br />
==== Отрицательный результат тестирования ====<br />
# При отклонении пакета ставится индикатор отклонения QA «-»,<br />
# В комментариях пишется причина отклонения запроса и в конце комментария добавляется «QA Denied».<br />
# При отрицательном результате тестирования сборщик может выложить исправленные контейнеры в тот же запрос и снова установить «?» в «qa_requested».</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F&diff=18630
Регламент тестирования
2020-04-29T09:33:44Z
<p>Vladimir.potapov: /* Тестирование на устойчивость системы */</p>
<hr />
<div>[[Category:Регламенты ROSA]]<br />
<br />
=== Политика ===<br />
QA отвечает за стабильность установленного у пользователей дистрибутива при его обновлениях.<br />
<br />
До установки обновлений дистрибутив работает. Любое обновление — риск его обрушить.<br />
Поэтому политика QA обязана быть консервативной и даже несколько параноидальной — при малейших сомнениях должны назначаться дополнительные проверки, пакеты должны отклоняться, направляться на пересборку.<br />
<br />
Политика QA вступает в конфликт с интересами сборщиков пакетов, желающих быстрее увидеть в репозиториях исправленную версию — конфликт этот должен быть конструктивным, приводящим к непрерывному повышению функциональности и стабильности дистрибутива.<br />
<br />
==== Классификация обновлений по степени опасности ====<br />
<blockquote><br />
Меня не интересуют их намерения, меня интересуют их возможности — © Отто Фон Бисмарк<br />
</blockquote><br />
<br />
Классификация исходит из максимально возможного урона (полный отказ функционирования компонента), который может нанести устанавливаемое обновление.<br />
<br />
;0: Критические обновления. Ядро, файловая система, система прав доступа, скрипты загрузки, <tt>systemd</tt>, <tt>glibc</tt>, <tt>dracut</tt>, <tt>grub</tt>, <tt>bash</tt> и прочие основные вещи, если удалить которые система не загрузится даже в консоли.<br />
;1: Обновления драйверов устройств, т.е. те же критические обновления, но актуальные не для всех пользователей. <br />
;2: Обновления сетевых компонентов: NetworkManager, сетевых скриптов, системы сетевой инициализации и системы обновлений (curl, urpmi). Они опасны тем, что если сеть упадет, пользователю без сети будет затруднительно получить исправленный пакет, когда мы его выпустим и установить обновление. <br />
;3: Обновления графических компонент и скриптов — X-ов, менеджера входа, графических библиотек, драйверов, '''perl, python''' — то, без чего невозможен вход в систему в графическом режиме. Т.к. обновление системы, при наличии сети, возможно и не в графике - класс опасности обновлений не самый высокий<br />
;4: Обновление пользовательских пакетов, установленных по-умолчанию в системе. Эти пакеты стоят практически у всех и их ошибки будут влиять на максимальное количество пользователей, однако они могут быть оперативно исправлены потому класс опасности не очень высокий. Туда же нужно отнести популярные программы не входящие в поставку — <tt>gimp</tt>, <tt>inkscape</tt>, <tt>audacity</tt>, <tt>vlc</tt>, <tt>kdenive</tt>, <tt>opera</tt>, <tt>chromium-browser</tt>, <tt>skype</tt>.<br />
;5: Обновление прочих пользовательских пакетов. Они затронут только тех, у кого эти программы стоят.<br />
;6: Обновление пакетов, необходимых только для сборки дистрибутива или работы с abf. Почти никому кроме нас они не интересны, потому класс опасности самый низкий.<br />
<br />
==== Задача ====<br />
* Главная задача QA — поиск регрессий, то есть таких изменений в дистрибутиве, которые уменьшают его функциональность по сравнению с предыдущим состоянием.<br />
* Также задачей QA является внесение в багзиллу всех ошибок, найденных в процессе тестирования и не относящихся к регрессиям.<br />
<br />
==== Общие положения ====<br />
* Запрос на обновление пишется в багзилле <br />
* Все сообщения пишутся на английском языке.<br />
* Порядок принятие запросов на тестирование командой QA в общем случае — в порядке возрастания номеров багов, возможны исключения, связанные со срочностью или трудностями в тестировании определенных пакетов.<br />
* Список запросов на обновление можно открыть по ссылке http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=qa_verified%3F&o1=substring&list_id=38774<br />
<br />
==== Срок тестирования ====<br />
* Срок тестирования пакета — '''одна неделя''', за это время служба QA должня проверить пакет и вынести заключение. Срок тестирования может быть увеличен при необходимости тестирования внешними тестерами на отсутствующих у службы QA аппаратно-программных конфигурациях, в этом случае в запросе на обновление задержка должна быть обоснована службой QA.<br />
* Для пакета, который нужно проверить очень срочно, сборщик должен установить приоритет <tt>Highest Critical</tt>, чтобы он выделялся красным цветом в списке. Такие пакеты рассматриваются в течение '''48 часов''' рабочего времени.<br />
* Норма выработки на одного тестера QA - 20 одобренных запросов в неделю, обычно отклоняется 10-20% запросов, так что тестер QA в среднем обрабатывает 5 запросов в день.<br />
<br />
=== Процедура тестирования ===<br />
<br />
==== Требования к запросу на обновление ====<br />
# QA Team тестирует пакеты-кандидаты на добавление в репозитории <tt>main/updates, non-free/updates и restricted/updates</tt>.<br />
# Пакет должен быть собран в общедоступном репозитории (не <tt>_personal</tt>).<br />
# Для архитектурно-зависимых пакетов должны быть представлены все поддерживаемые архитектуры (<tt>i586</tt> и <tt>x64</tt>).<br />
# Описание обновления должно содержать все изменения, которые нужно протестировать.<br />
При несоответствии запроса на обновление этим требованиям необходимо сообщить об этом инициатору запроса с помощью комментария.<br />
В случае, если до пятницы запрос не исправлен согласно требованиям, он отклоняется.<br />
<br />
==== Тестирование установки пакетов ====<br />
# Система перед тестовым обновлением должна соответствовать стандартным репозиториям, с подключенными тестингами. Это можно проверить запуском <tt>urpm-reposync</tt> из пакета <tt>urpm-tools</tt><br />
# Пакеты для тестирования устанавливаются и в графическом, и в текстовом режиме.<br />
## Репозиторий подключается как репозиторий с обновлениями.<br />
## Запускается стандартная процедура обновления.<br />
# Для пакетов, установленных в системе по-умолчанию, проверяется их обновление.<br />
# Для пакетов, не установленных в системе, проверяется как их обновление, так и первоначальная установка при подключенных тестовых контейнерах.<br />
# Установка пакетов проверяется для обеих архитектур. Так как ошибки установки не обычно не зависят от архитектуры, обычно достаточно проверить на одной архитектуре установку в графическом режиме, а на другой — обновление в текстовом, или наоборот.<br />
<br />
При ошибках установки или обновления пакета необходимо сообщить об этом инициатору запроса с помощью комментария. В случае, если до пятницы ошибка установки не исправлена, запрос отклоняется.<br />
<br />
==== Тестирование на функционирование и устойчивость системы после обновления ====<br />
При тестировании системы на устойчивость проверяется:<br />
# Стабильность и внешний вид обновленной системы после перезагрузки.<br />
# Стабильность и внешний вид обновленной системы после пробуждения из спящего режима. Тестирование стабильности и производительности может проводиться, например, с помощью теста Unigine Valley под wine и тестом браузера https://webglsamples.org/aquarium/aquarium.html<br />
# Ошибки загрузки демонов, например, с помощью <tt>systemctl | grep failed</tt>.<br />
# Ошибки непрерывного роста файла <tt>.xsession-errors</tt>.<br />
# Журнал ошибок, командами '''journalctl -b |grep fail''' и '''journalctl -b |grep error''' (не должно быть новых ошибок, если они появились - нужно найти связанное с ошибкой обновление и написать инициатору)<br />
# Работа URPMI — дальнейшее обновление пакетов.<br />
# Установка и удаление dkms-модулей (например, установкой проприетарных драйверов с последующим откатом на свободные)<br />
# Сохранением загрузчиком определения других операционных систем, установленных на тестовом компьютере<br />
# Сохранение даты-времени на тестируемой машине после перезагрузки и пробуждения из спящего режима<br />
# Работа системы поиска по содержимому офисных файлов<br />
<br />
==== Тестирование запуска и работы связанных с обновлением приложений ====<br />
Проверяются:<br />
# Тестирование запуска и простейших операций со связанными с тестируемым пакетом программами, рекомендуется контроль сообщений при запуске программы из консоли.<br />
# Связанные с библиотеками из проверяемого пакета программы легче всего установить, попробовав удалить пакет с помощью <tt>urpme</tt> (для установленных в системе программ) или <tt>urpmq --whatrequires</tt> (для всех программ из подключенных репозиториев).<br />
# Изменения в интерфейсах обновляемых библиотек и, соответственно, необходимость перекомпиляции связанных пакетов с помощью сервиса https://abi-laboratory.pro/tracker/<br />
# Для пакетов, предоставляющих библиотеки, проверяются использующие эти библиотеки приложения из main, их можно определить командой <tt>urpmq --whatrequires <названиепакета></tt><br />
# Регрессии в локализации графического интерфейса и страниц справки.<br />
# Для тестирования браузеров в дополнение к https://webglsamples.org/aquarium/aquarium.html применяются.<br />
## Тест html5 https://html5test.com/ (сравнить результат до и после обновления, не должно быть регресса)<br />
## Почтовые онлайновые сервисы http://mail.yandex.ru http://mail.google.com<br />
## Яндекс и гугл-карты https://yandex.ru/maps/-/CVTQITy0 https://www.google.ru/maps/@52.2609339,104.3096872,15z?hl=ru<br />
## xml|xsl трансляцию и кодировки на http://base.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=160129;div=LAW;rnd=0.4700782325977544 и<br />
## Воспроизведение видео http://techslides.com/sample-webm-ogg-and-mp4-video-files-for-html5/ <br />
## Воспроизведение [http://youtu.be/37l7P5V1eXU видео с youtube]<br />
## Работа флэша на примере игры [http://vseigru.net/igry-zombi/2541-igra-zombi-protiv-rastenij.html Растения против зомби] и [http://kino.sputnik.ru/films/ivan+vasilyevich+menyayet+professiyu+1973]<br />
## Уязвимости SSL с помощью https://www.ssllabs.com/ssltest/viewMyClient.html<br />
## Тестирование печати<br />
## Тестирование установки браузера по-умолчанию из настроек<br />
<br />
В случае:<br />
# нахождения регрессии функционала или локализации, о них сообщается инициатору запроса в комментариях к запросу на обновление <br />
# нахождения ошибок (не регрессий!) - заводится новый баг, его номер указывается в запросе на обновление.<br />
<br />
==== Тестирование изменений ====<br />
* Применяется при тестировании обновлений, изменяющих внешний вид или поведение системы.<br />
<br />
Включает себя<br />
# Воспроизведение особенностей внешнего вида или поведения системы ДО исправления.<br />
# Воспроизведение измененных обновлений особенностей по их описанию.<br />
<br />
Например, если в advisory сказано, что «вышла новая версия программы» при тестировании изменений нужно, как минимум, убедиться что версия изменилась.<br />
<br />
В случае если не все описанные изменения действительно присутствуют в тестируемом пакете, пакет принимается и в итоговый отчет (Advisory), вносятся только реально проведенные изменения.<br />
В случае значительного отклонения запрошенных и полученных изменений пакет может быть отклонен.<br />
<br />
==== Расширенное тестирование ====<br />
# Расширенное тестирование проводится добровольцами с помощью репозиториев testing, соответствующих основным репозиториям. <br />
# В течение недели (понедельник-четверг) все проверяемые QA обновления, кроме срочных, отправляются в тестинг, при этом в багзилле ставится статус verified и пишется The update is sent to expanded testing<br />
# В пятницу, руководитель QA:<br />
## Еще раз контролирует, все ли пакеты направлены в тестинг-репозитории, при помощи отключения источников-контейнеров и выполнения программы '''urpm-reposync''' с включенными тестингами. Результатом выполнения команды должно быть отсутствие пакетов на синхронизацию<br />
## Проверяет, дошли ли обновления до зеркал<br />
## Контролирует возможность обновления до тестингов с момента предыдущего релиза платформы путем установки релизного образа и его обновления с подключенными тестингами <br />
## Обновляет до тестингов системы на всех доступных тестовых стендах и проверяет их на устойчивость<br />
## На форуме и в сообществе вконтакте объявляет "пятничное тестирование", к нему выпускает бюллетень с полным списком обновлений и методикой их тестирования.<br />
# В понедельник руководитель QA читает отзывы пользователей и по их итогам, а также по итогам эксплуатации тестовых стендов в выходные дни, обрабатывает запросы на обновление и передает их на публикацию (или отклоняет)<br />
<br />
=== Завершение тестирования ===<br />
<br />
==== Положительный результат тестирования ====<br />
# По окончании тестирования при его успехе ставится индикатор успешного тестирования QA «+» и пишется отчет (Advisory), содержащий:<br />
## Название пакета с исходниками (src.rpm).<br />
## Версию пакета.<br />
## Отчет о тестировании (advisory).<br />
## Надпись «QA verified».<br />
# Если пакет содержит изменения, связанные с секретностью или же собран не сотрудником Росы — посылается запрос Secure team (взводится флажок secteam_verified «?»).<br />
# Если тестирование secure не нужно, пакет передается на публикацию (взводится соответствующий published «?»).<br />
# В случае успешного тестирования пакет может быть оставлен в системе. В случае ошибок систему нужно привести к первоначальному виду с помощью деинсталляции пакета или утилиты <tt>urpm-reposync</tt> из <tt>urpm-repotools</tt>.<br />
<br />
==== Отрицательный результат тестирования ====<br />
# При отклонении пакета ставится индикатор отклонения QA «-»,<br />
# В комментариях пишется причина отклонения запроса и в конце комментария добавляется «QA Denied».<br />
# При отрицательном результате тестирования сборщик может выложить исправленные контейнеры в тот же запрос и снова установить «?» в «qa_requested».</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F&diff=18629
Регламент тестирования
2020-04-29T09:32:30Z
<p>Vladimir.potapov: /* Тестирование установки пакетов */</p>
<hr />
<div>[[Category:Регламенты ROSA]]<br />
<br />
=== Политика ===<br />
QA отвечает за стабильность установленного у пользователей дистрибутива при его обновлениях.<br />
<br />
До установки обновлений дистрибутив работает. Любое обновление — риск его обрушить.<br />
Поэтому политика QA обязана быть консервативной и даже несколько параноидальной — при малейших сомнениях должны назначаться дополнительные проверки, пакеты должны отклоняться, направляться на пересборку.<br />
<br />
Политика QA вступает в конфликт с интересами сборщиков пакетов, желающих быстрее увидеть в репозиториях исправленную версию — конфликт этот должен быть конструктивным, приводящим к непрерывному повышению функциональности и стабильности дистрибутива.<br />
<br />
==== Классификация обновлений по степени опасности ====<br />
<blockquote><br />
Меня не интересуют их намерения, меня интересуют их возможности — © Отто Фон Бисмарк<br />
</blockquote><br />
<br />
Классификация исходит из максимально возможного урона (полный отказ функционирования компонента), который может нанести устанавливаемое обновление.<br />
<br />
;0: Критические обновления. Ядро, файловая система, система прав доступа, скрипты загрузки, <tt>systemd</tt>, <tt>glibc</tt>, <tt>dracut</tt>, <tt>grub</tt>, <tt>bash</tt> и прочие основные вещи, если удалить которые система не загрузится даже в консоли.<br />
;1: Обновления драйверов устройств, т.е. те же критические обновления, но актуальные не для всех пользователей. <br />
;2: Обновления сетевых компонентов: NetworkManager, сетевых скриптов, системы сетевой инициализации и системы обновлений (curl, urpmi). Они опасны тем, что если сеть упадет, пользователю без сети будет затруднительно получить исправленный пакет, когда мы его выпустим и установить обновление. <br />
;3: Обновления графических компонент и скриптов — X-ов, менеджера входа, графических библиотек, драйверов, '''perl, python''' — то, без чего невозможен вход в систему в графическом режиме. Т.к. обновление системы, при наличии сети, возможно и не в графике - класс опасности обновлений не самый высокий<br />
;4: Обновление пользовательских пакетов, установленных по-умолчанию в системе. Эти пакеты стоят практически у всех и их ошибки будут влиять на максимальное количество пользователей, однако они могут быть оперативно исправлены потому класс опасности не очень высокий. Туда же нужно отнести популярные программы не входящие в поставку — <tt>gimp</tt>, <tt>inkscape</tt>, <tt>audacity</tt>, <tt>vlc</tt>, <tt>kdenive</tt>, <tt>opera</tt>, <tt>chromium-browser</tt>, <tt>skype</tt>.<br />
;5: Обновление прочих пользовательских пакетов. Они затронут только тех, у кого эти программы стоят.<br />
;6: Обновление пакетов, необходимых только для сборки дистрибутива или работы с abf. Почти никому кроме нас они не интересны, потому класс опасности самый низкий.<br />
<br />
==== Задача ====<br />
* Главная задача QA — поиск регрессий, то есть таких изменений в дистрибутиве, которые уменьшают его функциональность по сравнению с предыдущим состоянием.<br />
* Также задачей QA является внесение в багзиллу всех ошибок, найденных в процессе тестирования и не относящихся к регрессиям.<br />
<br />
==== Общие положения ====<br />
* Запрос на обновление пишется в багзилле <br />
* Все сообщения пишутся на английском языке.<br />
* Порядок принятие запросов на тестирование командой QA в общем случае — в порядке возрастания номеров багов, возможны исключения, связанные со срочностью или трудностями в тестировании определенных пакетов.<br />
* Список запросов на обновление можно открыть по ссылке http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=qa_verified%3F&o1=substring&list_id=38774<br />
<br />
==== Срок тестирования ====<br />
* Срок тестирования пакета — '''одна неделя''', за это время служба QA должня проверить пакет и вынести заключение. Срок тестирования может быть увеличен при необходимости тестирования внешними тестерами на отсутствующих у службы QA аппаратно-программных конфигурациях, в этом случае в запросе на обновление задержка должна быть обоснована службой QA.<br />
* Для пакета, который нужно проверить очень срочно, сборщик должен установить приоритет <tt>Highest Critical</tt>, чтобы он выделялся красным цветом в списке. Такие пакеты рассматриваются в течение '''48 часов''' рабочего времени.<br />
* Норма выработки на одного тестера QA - 20 одобренных запросов в неделю, обычно отклоняется 10-20% запросов, так что тестер QA в среднем обрабатывает 5 запросов в день.<br />
<br />
=== Процедура тестирования ===<br />
<br />
==== Требования к запросу на обновление ====<br />
# QA Team тестирует пакеты-кандидаты на добавление в репозитории <tt>main/updates, non-free/updates и restricted/updates</tt>.<br />
# Пакет должен быть собран в общедоступном репозитории (не <tt>_personal</tt>).<br />
# Для архитектурно-зависимых пакетов должны быть представлены все поддерживаемые архитектуры (<tt>i586</tt> и <tt>x64</tt>).<br />
# Описание обновления должно содержать все изменения, которые нужно протестировать.<br />
При несоответствии запроса на обновление этим требованиям необходимо сообщить об этом инициатору запроса с помощью комментария.<br />
В случае, если до пятницы запрос не исправлен согласно требованиям, он отклоняется.<br />
<br />
==== Тестирование установки пакетов ====<br />
# Система перед тестовым обновлением должна соответствовать стандартным репозиториям, с подключенными тестингами. Это можно проверить запуском <tt>urpm-reposync</tt> из пакета <tt>urpm-tools</tt><br />
# Пакеты для тестирования устанавливаются и в графическом, и в текстовом режиме.<br />
## Репозиторий подключается как репозиторий с обновлениями.<br />
## Запускается стандартная процедура обновления.<br />
# Для пакетов, установленных в системе по-умолчанию, проверяется их обновление.<br />
# Для пакетов, не установленных в системе, проверяется как их обновление, так и первоначальная установка при подключенных тестовых контейнерах.<br />
# Установка пакетов проверяется для обеих архитектур. Так как ошибки установки не обычно не зависят от архитектуры, обычно достаточно проверить на одной архитектуре установку в графическом режиме, а на другой — обновление в текстовом, или наоборот.<br />
<br />
При ошибках установки или обновления пакета необходимо сообщить об этом инициатору запроса с помощью комментария. В случае, если до пятницы ошибка установки не исправлена, запрос отклоняется.<br />
<br />
==== Тестирование на устойчивость системы ====<br />
При тестировании системы на устойчивость проверяется:<br />
# Стабильность и внешний вид обновленной системы после перезагрузки.<br />
# Стабильность и внешний вид обновленной системы после пробуждения из спящего режима. Тестирование стабильности и производительности может проводиться, например, с помощью теста Unigine Valley под wine и тестом браузера https://webglsamples.org/aquarium/aquarium.html<br />
# Ошибки загрузки демонов, например, с помощью <tt>systemctl | grep failed</tt>.<br />
# Ошибки непрерывного роста файла <tt>.xsession-errors</tt>.<br />
# Журнал ошибок, командами '''journalctl -b |grep fail''' и '''journalctl -b |grep error''' (не должно быть новых ошибок, если они появились - нужно найти связанное с ошибкой обновление и написать инициатору)<br />
# Работа URPMI — дальнейшее обновление пакетов.<br />
# Установка и удаление dkms-модулей (например, установкой проприетарных драйверов с последующим откатом на свободные)<br />
# Сохранением загрузчиком определения других операционных систем, установленных на тестовом компьютере<br />
# Сохранение даты-времени на тестируемой машине после перезагрузки и пробуждения из спящего режима<br />
# Работа системы поиска по содержимому офисных файлов<br />
<br />
==== Тестирование запуска и работы связанных с обновлением приложений ====<br />
Проверяются:<br />
# Тестирование запуска и простейших операций со связанными с тестируемым пакетом программами, рекомендуется контроль сообщений при запуске программы из консоли.<br />
# Связанные с библиотеками из проверяемого пакета программы легче всего установить, попробовав удалить пакет с помощью <tt>urpme</tt> (для установленных в системе программ) или <tt>urpmq --whatrequires</tt> (для всех программ из подключенных репозиториев).<br />
# Изменения в интерфейсах обновляемых библиотек и, соответственно, необходимость перекомпиляции связанных пакетов с помощью сервиса https://abi-laboratory.pro/tracker/<br />
# Для пакетов, предоставляющих библиотеки, проверяются использующие эти библиотеки приложения из main, их можно определить командой <tt>urpmq --whatrequires <названиепакета></tt><br />
# Регрессии в локализации графического интерфейса и страниц справки.<br />
# Для тестирования браузеров в дополнение к https://webglsamples.org/aquarium/aquarium.html применяются.<br />
## Тест html5 https://html5test.com/ (сравнить результат до и после обновления, не должно быть регресса)<br />
## Почтовые онлайновые сервисы http://mail.yandex.ru http://mail.google.com<br />
## Яндекс и гугл-карты https://yandex.ru/maps/-/CVTQITy0 https://www.google.ru/maps/@52.2609339,104.3096872,15z?hl=ru<br />
## xml|xsl трансляцию и кодировки на http://base.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=160129;div=LAW;rnd=0.4700782325977544 и<br />
## Воспроизведение видео http://techslides.com/sample-webm-ogg-and-mp4-video-files-for-html5/ <br />
## Воспроизведение [http://youtu.be/37l7P5V1eXU видео с youtube]<br />
## Работа флэша на примере игры [http://vseigru.net/igry-zombi/2541-igra-zombi-protiv-rastenij.html Растения против зомби] и [http://kino.sputnik.ru/films/ivan+vasilyevich+menyayet+professiyu+1973]<br />
## Уязвимости SSL с помощью https://www.ssllabs.com/ssltest/viewMyClient.html<br />
## Тестирование печати<br />
## Тестирование установки браузера по-умолчанию из настроек<br />
<br />
В случае:<br />
# нахождения регрессии функционала или локализации, о них сообщается инициатору запроса в комментариях к запросу на обновление <br />
# нахождения ошибок (не регрессий!) - заводится новый баг, его номер указывается в запросе на обновление.<br />
<br />
==== Тестирование изменений ====<br />
* Применяется при тестировании обновлений, изменяющих внешний вид или поведение системы.<br />
<br />
Включает себя<br />
# Воспроизведение особенностей внешнего вида или поведения системы ДО исправления.<br />
# Воспроизведение измененных обновлений особенностей по их описанию.<br />
<br />
Например, если в advisory сказано, что «вышла новая версия программы» при тестировании изменений нужно, как минимум, убедиться что версия изменилась.<br />
<br />
В случае если не все описанные изменения действительно присутствуют в тестируемом пакете, пакет принимается и в итоговый отчет (Advisory), вносятся только реально проведенные изменения.<br />
В случае значительного отклонения запрошенных и полученных изменений пакет может быть отклонен.<br />
<br />
==== Расширенное тестирование ====<br />
# Расширенное тестирование проводится добровольцами с помощью репозиториев testing, соответствующих основным репозиториям. <br />
# В течение недели (понедельник-четверг) все проверяемые QA обновления, кроме срочных, отправляются в тестинг, при этом в багзилле ставится статус verified и пишется The update is sent to expanded testing<br />
# В пятницу, руководитель QA:<br />
## Еще раз контролирует, все ли пакеты направлены в тестинг-репозитории, при помощи отключения источников-контейнеров и выполнения программы '''urpm-reposync''' с включенными тестингами. Результатом выполнения команды должно быть отсутствие пакетов на синхронизацию<br />
## Проверяет, дошли ли обновления до зеркал<br />
## Контролирует возможность обновления до тестингов с момента предыдущего релиза платформы путем установки релизного образа и его обновления с подключенными тестингами <br />
## Обновляет до тестингов системы на всех доступных тестовых стендах и проверяет их на устойчивость<br />
## На форуме и в сообществе вконтакте объявляет "пятничное тестирование", к нему выпускает бюллетень с полным списком обновлений и методикой их тестирования.<br />
# В понедельник руководитель QA читает отзывы пользователей и по их итогам, а также по итогам эксплуатации тестовых стендов в выходные дни, обрабатывает запросы на обновление и передает их на публикацию (или отклоняет)<br />
<br />
=== Завершение тестирования ===<br />
<br />
==== Положительный результат тестирования ====<br />
# По окончании тестирования при его успехе ставится индикатор успешного тестирования QA «+» и пишется отчет (Advisory), содержащий:<br />
## Название пакета с исходниками (src.rpm).<br />
## Версию пакета.<br />
## Отчет о тестировании (advisory).<br />
## Надпись «QA verified».<br />
# Если пакет содержит изменения, связанные с секретностью или же собран не сотрудником Росы — посылается запрос Secure team (взводится флажок secteam_verified «?»).<br />
# Если тестирование secure не нужно, пакет передается на публикацию (взводится соответствующий published «?»).<br />
# В случае успешного тестирования пакет может быть оставлен в системе. В случае ошибок систему нужно привести к первоначальному виду с помощью деинсталляции пакета или утилиты <tt>urpm-reposync</tt> из <tt>urpm-repotools</tt>.<br />
<br />
==== Отрицательный результат тестирования ====<br />
# При отклонении пакета ставится индикатор отклонения QA «-»,<br />
# В комментариях пишется причина отклонения запроса и в конце комментария добавляется «QA Denied».<br />
# При отрицательном результате тестирования сборщик может выложить исправленные контейнеры в тот же запрос и снова установить «?» в «qa_requested».</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F&diff=18628
Регламент тестирования
2020-04-29T09:31:10Z
<p>Vladimir.potapov: /* Требования к запросу на обновление */</p>
<hr />
<div>[[Category:Регламенты ROSA]]<br />
<br />
=== Политика ===<br />
QA отвечает за стабильность установленного у пользователей дистрибутива при его обновлениях.<br />
<br />
До установки обновлений дистрибутив работает. Любое обновление — риск его обрушить.<br />
Поэтому политика QA обязана быть консервативной и даже несколько параноидальной — при малейших сомнениях должны назначаться дополнительные проверки, пакеты должны отклоняться, направляться на пересборку.<br />
<br />
Политика QA вступает в конфликт с интересами сборщиков пакетов, желающих быстрее увидеть в репозиториях исправленную версию — конфликт этот должен быть конструктивным, приводящим к непрерывному повышению функциональности и стабильности дистрибутива.<br />
<br />
==== Классификация обновлений по степени опасности ====<br />
<blockquote><br />
Меня не интересуют их намерения, меня интересуют их возможности — © Отто Фон Бисмарк<br />
</blockquote><br />
<br />
Классификация исходит из максимально возможного урона (полный отказ функционирования компонента), который может нанести устанавливаемое обновление.<br />
<br />
;0: Критические обновления. Ядро, файловая система, система прав доступа, скрипты загрузки, <tt>systemd</tt>, <tt>glibc</tt>, <tt>dracut</tt>, <tt>grub</tt>, <tt>bash</tt> и прочие основные вещи, если удалить которые система не загрузится даже в консоли.<br />
;1: Обновления драйверов устройств, т.е. те же критические обновления, но актуальные не для всех пользователей. <br />
;2: Обновления сетевых компонентов: NetworkManager, сетевых скриптов, системы сетевой инициализации и системы обновлений (curl, urpmi). Они опасны тем, что если сеть упадет, пользователю без сети будет затруднительно получить исправленный пакет, когда мы его выпустим и установить обновление. <br />
;3: Обновления графических компонент и скриптов — X-ов, менеджера входа, графических библиотек, драйверов, '''perl, python''' — то, без чего невозможен вход в систему в графическом режиме. Т.к. обновление системы, при наличии сети, возможно и не в графике - класс опасности обновлений не самый высокий<br />
;4: Обновление пользовательских пакетов, установленных по-умолчанию в системе. Эти пакеты стоят практически у всех и их ошибки будут влиять на максимальное количество пользователей, однако они могут быть оперативно исправлены потому класс опасности не очень высокий. Туда же нужно отнести популярные программы не входящие в поставку — <tt>gimp</tt>, <tt>inkscape</tt>, <tt>audacity</tt>, <tt>vlc</tt>, <tt>kdenive</tt>, <tt>opera</tt>, <tt>chromium-browser</tt>, <tt>skype</tt>.<br />
;5: Обновление прочих пользовательских пакетов. Они затронут только тех, у кого эти программы стоят.<br />
;6: Обновление пакетов, необходимых только для сборки дистрибутива или работы с abf. Почти никому кроме нас они не интересны, потому класс опасности самый низкий.<br />
<br />
==== Задача ====<br />
* Главная задача QA — поиск регрессий, то есть таких изменений в дистрибутиве, которые уменьшают его функциональность по сравнению с предыдущим состоянием.<br />
* Также задачей QA является внесение в багзиллу всех ошибок, найденных в процессе тестирования и не относящихся к регрессиям.<br />
<br />
==== Общие положения ====<br />
* Запрос на обновление пишется в багзилле <br />
* Все сообщения пишутся на английском языке.<br />
* Порядок принятие запросов на тестирование командой QA в общем случае — в порядке возрастания номеров багов, возможны исключения, связанные со срочностью или трудностями в тестировании определенных пакетов.<br />
* Список запросов на обновление можно открыть по ссылке http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=qa_verified%3F&o1=substring&list_id=38774<br />
<br />
==== Срок тестирования ====<br />
* Срок тестирования пакета — '''одна неделя''', за это время служба QA должня проверить пакет и вынести заключение. Срок тестирования может быть увеличен при необходимости тестирования внешними тестерами на отсутствующих у службы QA аппаратно-программных конфигурациях, в этом случае в запросе на обновление задержка должна быть обоснована службой QA.<br />
* Для пакета, который нужно проверить очень срочно, сборщик должен установить приоритет <tt>Highest Critical</tt>, чтобы он выделялся красным цветом в списке. Такие пакеты рассматриваются в течение '''48 часов''' рабочего времени.<br />
* Норма выработки на одного тестера QA - 20 одобренных запросов в неделю, обычно отклоняется 10-20% запросов, так что тестер QA в среднем обрабатывает 5 запросов в день.<br />
<br />
=== Процедура тестирования ===<br />
<br />
==== Требования к запросу на обновление ====<br />
# QA Team тестирует пакеты-кандидаты на добавление в репозитории <tt>main/updates, non-free/updates и restricted/updates</tt>.<br />
# Пакет должен быть собран в общедоступном репозитории (не <tt>_personal</tt>).<br />
# Для архитектурно-зависимых пакетов должны быть представлены все поддерживаемые архитектуры (<tt>i586</tt> и <tt>x64</tt>).<br />
# Описание обновления должно содержать все изменения, которые нужно протестировать.<br />
При несоответствии запроса на обновление этим требованиям необходимо сообщить об этом инициатору запроса с помощью комментария.<br />
В случае, если до пятницы запрос не исправлен согласно требованиям, он отклоняется.<br />
<br />
==== Тестирование установки пакетов ====<br />
# Система перед тестовым обновлением должна соответствовать стандартным репозиториям, с подключенными тестингами. Это можно проверить запуском <tt>urpm-reposync</tt> из пакета <tt>urpm-tools</tt><br />
# Пакеты для тестирования устанавливаются и в графическом, и в текстовом режиме.<br />
## Репозиторий подключается как репозиторий с обновлениями.<br />
## Запускается стандартная процедура обновления.<br />
# Для пакетов, установленных в системе по-умолчанию, проверяется их обновление.<br />
# Для пакетов, не установленных в системе, проверяется как их обновление, так и первоначальная установка при подключенных тестовых контейнерах.<br />
# Установка пакетов проверяется для обеих архитектур. Так как ошибки установки не обычно не зависят от архитектуры, обычно достаточно проверить на одной архитектуре установку в графическом режиме, а на другой — обновление в текстовом, или наоборот.<br />
<br />
==== Тестирование на устойчивость системы ====<br />
При тестировании системы на устойчивость проверяется:<br />
# Стабильность и внешний вид обновленной системы после перезагрузки.<br />
# Стабильность и внешний вид обновленной системы после пробуждения из спящего режима. Тестирование стабильности и производительности может проводиться, например, с помощью теста Unigine Valley под wine и тестом браузера https://webglsamples.org/aquarium/aquarium.html<br />
# Ошибки загрузки демонов, например, с помощью <tt>systemctl | grep failed</tt>.<br />
# Ошибки непрерывного роста файла <tt>.xsession-errors</tt>.<br />
# Журнал ошибок, командами '''journalctl -b |grep fail''' и '''journalctl -b |grep error''' (не должно быть новых ошибок, если они появились - нужно найти связанное с ошибкой обновление и написать инициатору)<br />
# Работа URPMI — дальнейшее обновление пакетов.<br />
# Установка и удаление dkms-модулей (например, установкой проприетарных драйверов с последующим откатом на свободные)<br />
# Сохранением загрузчиком определения других операционных систем, установленных на тестовом компьютере<br />
# Сохранение даты-времени на тестируемой машине после перезагрузки и пробуждения из спящего режима<br />
# Работа системы поиска по содержимому офисных файлов<br />
<br />
==== Тестирование запуска и работы связанных с обновлением приложений ====<br />
Проверяются:<br />
# Тестирование запуска и простейших операций со связанными с тестируемым пакетом программами, рекомендуется контроль сообщений при запуске программы из консоли.<br />
# Связанные с библиотеками из проверяемого пакета программы легче всего установить, попробовав удалить пакет с помощью <tt>urpme</tt> (для установленных в системе программ) или <tt>urpmq --whatrequires</tt> (для всех программ из подключенных репозиториев).<br />
# Изменения в интерфейсах обновляемых библиотек и, соответственно, необходимость перекомпиляции связанных пакетов с помощью сервиса https://abi-laboratory.pro/tracker/<br />
# Для пакетов, предоставляющих библиотеки, проверяются использующие эти библиотеки приложения из main, их можно определить командой <tt>urpmq --whatrequires <названиепакета></tt><br />
# Регрессии в локализации графического интерфейса и страниц справки.<br />
# Для тестирования браузеров в дополнение к https://webglsamples.org/aquarium/aquarium.html применяются.<br />
## Тест html5 https://html5test.com/ (сравнить результат до и после обновления, не должно быть регресса)<br />
## Почтовые онлайновые сервисы http://mail.yandex.ru http://mail.google.com<br />
## Яндекс и гугл-карты https://yandex.ru/maps/-/CVTQITy0 https://www.google.ru/maps/@52.2609339,104.3096872,15z?hl=ru<br />
## xml|xsl трансляцию и кодировки на http://base.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=160129;div=LAW;rnd=0.4700782325977544 и<br />
## Воспроизведение видео http://techslides.com/sample-webm-ogg-and-mp4-video-files-for-html5/ <br />
## Воспроизведение [http://youtu.be/37l7P5V1eXU видео с youtube]<br />
## Работа флэша на примере игры [http://vseigru.net/igry-zombi/2541-igra-zombi-protiv-rastenij.html Растения против зомби] и [http://kino.sputnik.ru/films/ivan+vasilyevich+menyayet+professiyu+1973]<br />
## Уязвимости SSL с помощью https://www.ssllabs.com/ssltest/viewMyClient.html<br />
## Тестирование печати<br />
## Тестирование установки браузера по-умолчанию из настроек<br />
<br />
В случае:<br />
# нахождения регрессии функционала или локализации, о них сообщается инициатору запроса в комментариях к запросу на обновление <br />
# нахождения ошибок (не регрессий!) - заводится новый баг, его номер указывается в запросе на обновление.<br />
<br />
==== Тестирование изменений ====<br />
* Применяется при тестировании обновлений, изменяющих внешний вид или поведение системы.<br />
<br />
Включает себя<br />
# Воспроизведение особенностей внешнего вида или поведения системы ДО исправления.<br />
# Воспроизведение измененных обновлений особенностей по их описанию.<br />
<br />
Например, если в advisory сказано, что «вышла новая версия программы» при тестировании изменений нужно, как минимум, убедиться что версия изменилась.<br />
<br />
В случае если не все описанные изменения действительно присутствуют в тестируемом пакете, пакет принимается и в итоговый отчет (Advisory), вносятся только реально проведенные изменения.<br />
В случае значительного отклонения запрошенных и полученных изменений пакет может быть отклонен.<br />
<br />
==== Расширенное тестирование ====<br />
# Расширенное тестирование проводится добровольцами с помощью репозиториев testing, соответствующих основным репозиториям. <br />
# В течение недели (понедельник-четверг) все проверяемые QA обновления, кроме срочных, отправляются в тестинг, при этом в багзилле ставится статус verified и пишется The update is sent to expanded testing<br />
# В пятницу, руководитель QA:<br />
## Еще раз контролирует, все ли пакеты направлены в тестинг-репозитории, при помощи отключения источников-контейнеров и выполнения программы '''urpm-reposync''' с включенными тестингами. Результатом выполнения команды должно быть отсутствие пакетов на синхронизацию<br />
## Проверяет, дошли ли обновления до зеркал<br />
## Контролирует возможность обновления до тестингов с момента предыдущего релиза платформы путем установки релизного образа и его обновления с подключенными тестингами <br />
## Обновляет до тестингов системы на всех доступных тестовых стендах и проверяет их на устойчивость<br />
## На форуме и в сообществе вконтакте объявляет "пятничное тестирование", к нему выпускает бюллетень с полным списком обновлений и методикой их тестирования.<br />
# В понедельник руководитель QA читает отзывы пользователей и по их итогам, а также по итогам эксплуатации тестовых стендов в выходные дни, обрабатывает запросы на обновление и передает их на публикацию (или отклоняет)<br />
<br />
=== Завершение тестирования ===<br />
<br />
==== Положительный результат тестирования ====<br />
# По окончании тестирования при его успехе ставится индикатор успешного тестирования QA «+» и пишется отчет (Advisory), содержащий:<br />
## Название пакета с исходниками (src.rpm).<br />
## Версию пакета.<br />
## Отчет о тестировании (advisory).<br />
## Надпись «QA verified».<br />
# Если пакет содержит изменения, связанные с секретностью или же собран не сотрудником Росы — посылается запрос Secure team (взводится флажок secteam_verified «?»).<br />
# Если тестирование secure не нужно, пакет передается на публикацию (взводится соответствующий published «?»).<br />
# В случае успешного тестирования пакет может быть оставлен в системе. В случае ошибок систему нужно привести к первоначальному виду с помощью деинсталляции пакета или утилиты <tt>urpm-reposync</tt> из <tt>urpm-repotools</tt>.<br />
<br />
==== Отрицательный результат тестирования ====<br />
# При отклонении пакета ставится индикатор отклонения QA «-»,<br />
# В комментариях пишется причина отклонения запроса и в конце комментария добавляется «QA Denied».<br />
# При отрицательном результате тестирования сборщик может выложить исправленные контейнеры в тот же запрос и снова установить «?» в «qa_requested».</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F&diff=18627
Регламент тестирования
2020-04-29T09:27:15Z
<p>Vladimir.potapov: /* Тестирование запуска и работы связанных с обновлением приложений */</p>
<hr />
<div>[[Category:Регламенты ROSA]]<br />
<br />
=== Политика ===<br />
QA отвечает за стабильность установленного у пользователей дистрибутива при его обновлениях.<br />
<br />
До установки обновлений дистрибутив работает. Любое обновление — риск его обрушить.<br />
Поэтому политика QA обязана быть консервативной и даже несколько параноидальной — при малейших сомнениях должны назначаться дополнительные проверки, пакеты должны отклоняться, направляться на пересборку.<br />
<br />
Политика QA вступает в конфликт с интересами сборщиков пакетов, желающих быстрее увидеть в репозиториях исправленную версию — конфликт этот должен быть конструктивным, приводящим к непрерывному повышению функциональности и стабильности дистрибутива.<br />
<br />
==== Классификация обновлений по степени опасности ====<br />
<blockquote><br />
Меня не интересуют их намерения, меня интересуют их возможности — © Отто Фон Бисмарк<br />
</blockquote><br />
<br />
Классификация исходит из максимально возможного урона (полный отказ функционирования компонента), который может нанести устанавливаемое обновление.<br />
<br />
;0: Критические обновления. Ядро, файловая система, система прав доступа, скрипты загрузки, <tt>systemd</tt>, <tt>glibc</tt>, <tt>dracut</tt>, <tt>grub</tt>, <tt>bash</tt> и прочие основные вещи, если удалить которые система не загрузится даже в консоли.<br />
;1: Обновления драйверов устройств, т.е. те же критические обновления, но актуальные не для всех пользователей. <br />
;2: Обновления сетевых компонентов: NetworkManager, сетевых скриптов, системы сетевой инициализации и системы обновлений (curl, urpmi). Они опасны тем, что если сеть упадет, пользователю без сети будет затруднительно получить исправленный пакет, когда мы его выпустим и установить обновление. <br />
;3: Обновления графических компонент и скриптов — X-ов, менеджера входа, графических библиотек, драйверов, '''perl, python''' — то, без чего невозможен вход в систему в графическом режиме. Т.к. обновление системы, при наличии сети, возможно и не в графике - класс опасности обновлений не самый высокий<br />
;4: Обновление пользовательских пакетов, установленных по-умолчанию в системе. Эти пакеты стоят практически у всех и их ошибки будут влиять на максимальное количество пользователей, однако они могут быть оперативно исправлены потому класс опасности не очень высокий. Туда же нужно отнести популярные программы не входящие в поставку — <tt>gimp</tt>, <tt>inkscape</tt>, <tt>audacity</tt>, <tt>vlc</tt>, <tt>kdenive</tt>, <tt>opera</tt>, <tt>chromium-browser</tt>, <tt>skype</tt>.<br />
;5: Обновление прочих пользовательских пакетов. Они затронут только тех, у кого эти программы стоят.<br />
;6: Обновление пакетов, необходимых только для сборки дистрибутива или работы с abf. Почти никому кроме нас они не интересны, потому класс опасности самый низкий.<br />
<br />
==== Задача ====<br />
* Главная задача QA — поиск регрессий, то есть таких изменений в дистрибутиве, которые уменьшают его функциональность по сравнению с предыдущим состоянием.<br />
* Также задачей QA является внесение в багзиллу всех ошибок, найденных в процессе тестирования и не относящихся к регрессиям.<br />
<br />
==== Общие положения ====<br />
* Запрос на обновление пишется в багзилле <br />
* Все сообщения пишутся на английском языке.<br />
* Порядок принятие запросов на тестирование командой QA в общем случае — в порядке возрастания номеров багов, возможны исключения, связанные со срочностью или трудностями в тестировании определенных пакетов.<br />
* Список запросов на обновление можно открыть по ссылке http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=qa_verified%3F&o1=substring&list_id=38774<br />
<br />
==== Срок тестирования ====<br />
* Срок тестирования пакета — '''одна неделя''', за это время служба QA должня проверить пакет и вынести заключение. Срок тестирования может быть увеличен при необходимости тестирования внешними тестерами на отсутствующих у службы QA аппаратно-программных конфигурациях, в этом случае в запросе на обновление задержка должна быть обоснована службой QA.<br />
* Для пакета, который нужно проверить очень срочно, сборщик должен установить приоритет <tt>Highest Critical</tt>, чтобы он выделялся красным цветом в списке. Такие пакеты рассматриваются в течение '''48 часов''' рабочего времени.<br />
* Норма выработки на одного тестера QA - 20 одобренных запросов в неделю, обычно отклоняется 10-20% запросов, так что тестер QA в среднем обрабатывает 5 запросов в день.<br />
<br />
=== Процедура тестирования ===<br />
<br />
==== Требования к запросу на обновление ====<br />
# QA Team тестирует пакеты-кандидаты на добавление в репозитории <tt>main/updates, non-free/updates и restricted/updates</tt>.<br />
# Пакет должен быть собран в общедоступном репозитории (не <tt>_personal</tt>).<br />
# Для архитектурно-зависимых пакетов должны быть представлены все поддерживаемые архитектуры (<tt>i586</tt> и <tt>x64</tt>).<br />
# Описание обновления должно содержать все изменения, которые нужно протестировать.<br />
При несоответствии запроса на обновление этим требованиям запрос отклоняется.<br />
<br />
==== Тестирование установки пакетов ====<br />
# Система перед тестовым обновлением должна соответствовать стандартным репозиториям, с подключенными тестингами. Это можно проверить запуском <tt>urpm-reposync</tt> из пакета <tt>urpm-tools</tt><br />
# Пакеты для тестирования устанавливаются и в графическом, и в текстовом режиме.<br />
## Репозиторий подключается как репозиторий с обновлениями.<br />
## Запускается стандартная процедура обновления.<br />
# Для пакетов, установленных в системе по-умолчанию, проверяется их обновление.<br />
# Для пакетов, не установленных в системе, проверяется как их обновление, так и первоначальная установка при подключенных тестовых контейнерах.<br />
# Установка пакетов проверяется для обеих архитектур. Так как ошибки установки не обычно не зависят от архитектуры, обычно достаточно проверить на одной архитектуре установку в графическом режиме, а на другой — обновление в текстовом, или наоборот.<br />
<br />
==== Тестирование на устойчивость системы ====<br />
При тестировании системы на устойчивость проверяется:<br />
# Стабильность и внешний вид обновленной системы после перезагрузки.<br />
# Стабильность и внешний вид обновленной системы после пробуждения из спящего режима. Тестирование стабильности и производительности может проводиться, например, с помощью теста Unigine Valley под wine и тестом браузера https://webglsamples.org/aquarium/aquarium.html<br />
# Ошибки загрузки демонов, например, с помощью <tt>systemctl | grep failed</tt>.<br />
# Ошибки непрерывного роста файла <tt>.xsession-errors</tt>.<br />
# Журнал ошибок, командами '''journalctl -b |grep fail''' и '''journalctl -b |grep error''' (не должно быть новых ошибок, если они появились - нужно найти связанное с ошибкой обновление и написать инициатору)<br />
# Работа URPMI — дальнейшее обновление пакетов.<br />
# Установка и удаление dkms-модулей (например, установкой проприетарных драйверов с последующим откатом на свободные)<br />
# Сохранением загрузчиком определения других операционных систем, установленных на тестовом компьютере<br />
# Сохранение даты-времени на тестируемой машине после перезагрузки и пробуждения из спящего режима<br />
# Работа системы поиска по содержимому офисных файлов<br />
<br />
==== Тестирование запуска и работы связанных с обновлением приложений ====<br />
Проверяются:<br />
# Тестирование запуска и простейших операций со связанными с тестируемым пакетом программами, рекомендуется контроль сообщений при запуске программы из консоли.<br />
# Связанные с библиотеками из проверяемого пакета программы легче всего установить, попробовав удалить пакет с помощью <tt>urpme</tt> (для установленных в системе программ) или <tt>urpmq --whatrequires</tt> (для всех программ из подключенных репозиториев).<br />
# Изменения в интерфейсах обновляемых библиотек и, соответственно, необходимость перекомпиляции связанных пакетов с помощью сервиса https://abi-laboratory.pro/tracker/<br />
# Для пакетов, предоставляющих библиотеки, проверяются использующие эти библиотеки приложения из main, их можно определить командой <tt>urpmq --whatrequires <названиепакета></tt><br />
# Регрессии в локализации графического интерфейса и страниц справки.<br />
# Для тестирования браузеров в дополнение к https://webglsamples.org/aquarium/aquarium.html применяются.<br />
## Тест html5 https://html5test.com/ (сравнить результат до и после обновления, не должно быть регресса)<br />
## Почтовые онлайновые сервисы http://mail.yandex.ru http://mail.google.com<br />
## Яндекс и гугл-карты https://yandex.ru/maps/-/CVTQITy0 https://www.google.ru/maps/@52.2609339,104.3096872,15z?hl=ru<br />
## xml|xsl трансляцию и кодировки на http://base.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=160129;div=LAW;rnd=0.4700782325977544 и<br />
## Воспроизведение видео http://techslides.com/sample-webm-ogg-and-mp4-video-files-for-html5/ <br />
## Воспроизведение [http://youtu.be/37l7P5V1eXU видео с youtube]<br />
## Работа флэша на примере игры [http://vseigru.net/igry-zombi/2541-igra-zombi-protiv-rastenij.html Растения против зомби] и [http://kino.sputnik.ru/films/ivan+vasilyevich+menyayet+professiyu+1973]<br />
## Уязвимости SSL с помощью https://www.ssllabs.com/ssltest/viewMyClient.html<br />
## Тестирование печати<br />
## Тестирование установки браузера по-умолчанию из настроек<br />
<br />
В случае:<br />
# нахождения регрессии функционала или локализации, о них сообщается инициатору запроса в комментариях к запросу на обновление <br />
# нахождения ошибок (не регрессий!) - заводится новый баг, его номер указывается в запросе на обновление.<br />
<br />
==== Тестирование изменений ====<br />
* Применяется при тестировании обновлений, изменяющих внешний вид или поведение системы.<br />
<br />
Включает себя<br />
# Воспроизведение особенностей внешнего вида или поведения системы ДО исправления.<br />
# Воспроизведение измененных обновлений особенностей по их описанию.<br />
<br />
Например, если в advisory сказано, что «вышла новая версия программы» при тестировании изменений нужно, как минимум, убедиться что версия изменилась.<br />
<br />
В случае если не все описанные изменения действительно присутствуют в тестируемом пакете, пакет принимается и в итоговый отчет (Advisory), вносятся только реально проведенные изменения.<br />
В случае значительного отклонения запрошенных и полученных изменений пакет может быть отклонен.<br />
<br />
==== Расширенное тестирование ====<br />
# Расширенное тестирование проводится добровольцами с помощью репозиториев testing, соответствующих основным репозиториям. <br />
# В течение недели (понедельник-четверг) все проверяемые QA обновления, кроме срочных, отправляются в тестинг, при этом в багзилле ставится статус verified и пишется The update is sent to expanded testing<br />
# В пятницу, руководитель QA:<br />
## Еще раз контролирует, все ли пакеты направлены в тестинг-репозитории, при помощи отключения источников-контейнеров и выполнения программы '''urpm-reposync''' с включенными тестингами. Результатом выполнения команды должно быть отсутствие пакетов на синхронизацию<br />
## Проверяет, дошли ли обновления до зеркал<br />
## Контролирует возможность обновления до тестингов с момента предыдущего релиза платформы путем установки релизного образа и его обновления с подключенными тестингами <br />
## Обновляет до тестингов системы на всех доступных тестовых стендах и проверяет их на устойчивость<br />
## На форуме и в сообществе вконтакте объявляет "пятничное тестирование", к нему выпускает бюллетень с полным списком обновлений и методикой их тестирования.<br />
# В понедельник руководитель QA читает отзывы пользователей и по их итогам, а также по итогам эксплуатации тестовых стендов в выходные дни, обрабатывает запросы на обновление и передает их на публикацию (или отклоняет)<br />
<br />
=== Завершение тестирования ===<br />
<br />
==== Положительный результат тестирования ====<br />
# По окончании тестирования при его успехе ставится индикатор успешного тестирования QA «+» и пишется отчет (Advisory), содержащий:<br />
## Название пакета с исходниками (src.rpm).<br />
## Версию пакета.<br />
## Отчет о тестировании (advisory).<br />
## Надпись «QA verified».<br />
# Если пакет содержит изменения, связанные с секретностью или же собран не сотрудником Росы — посылается запрос Secure team (взводится флажок secteam_verified «?»).<br />
# Если тестирование secure не нужно, пакет передается на публикацию (взводится соответствующий published «?»).<br />
# В случае успешного тестирования пакет может быть оставлен в системе. В случае ошибок систему нужно привести к первоначальному виду с помощью деинсталляции пакета или утилиты <tt>urpm-reposync</tt> из <tt>urpm-repotools</tt>.<br />
<br />
==== Отрицательный результат тестирования ====<br />
# При отклонении пакета ставится индикатор отклонения QA «-»,<br />
# В комментариях пишется причина отклонения запроса и в конце комментария добавляется «QA Denied».<br />
# При отрицательном результате тестирования сборщик может выложить исправленные контейнеры в тот же запрос и снова установить «?» в «qa_requested».</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F&diff=18626
Регламент тестирования
2020-04-29T09:20:18Z
<p>Vladimir.potapov: /* Тестирование запуска и работы связанных с обновлением приложений */</p>
<hr />
<div>[[Category:Регламенты ROSA]]<br />
<br />
=== Политика ===<br />
QA отвечает за стабильность установленного у пользователей дистрибутива при его обновлениях.<br />
<br />
До установки обновлений дистрибутив работает. Любое обновление — риск его обрушить.<br />
Поэтому политика QA обязана быть консервативной и даже несколько параноидальной — при малейших сомнениях должны назначаться дополнительные проверки, пакеты должны отклоняться, направляться на пересборку.<br />
<br />
Политика QA вступает в конфликт с интересами сборщиков пакетов, желающих быстрее увидеть в репозиториях исправленную версию — конфликт этот должен быть конструктивным, приводящим к непрерывному повышению функциональности и стабильности дистрибутива.<br />
<br />
==== Классификация обновлений по степени опасности ====<br />
<blockquote><br />
Меня не интересуют их намерения, меня интересуют их возможности — © Отто Фон Бисмарк<br />
</blockquote><br />
<br />
Классификация исходит из максимально возможного урона (полный отказ функционирования компонента), который может нанести устанавливаемое обновление.<br />
<br />
;0: Критические обновления. Ядро, файловая система, система прав доступа, скрипты загрузки, <tt>systemd</tt>, <tt>glibc</tt>, <tt>dracut</tt>, <tt>grub</tt>, <tt>bash</tt> и прочие основные вещи, если удалить которые система не загрузится даже в консоли.<br />
;1: Обновления драйверов устройств, т.е. те же критические обновления, но актуальные не для всех пользователей. <br />
;2: Обновления сетевых компонентов: NetworkManager, сетевых скриптов, системы сетевой инициализации и системы обновлений (curl, urpmi). Они опасны тем, что если сеть упадет, пользователю без сети будет затруднительно получить исправленный пакет, когда мы его выпустим и установить обновление. <br />
;3: Обновления графических компонент и скриптов — X-ов, менеджера входа, графических библиотек, драйверов, '''perl, python''' — то, без чего невозможен вход в систему в графическом режиме. Т.к. обновление системы, при наличии сети, возможно и не в графике - класс опасности обновлений не самый высокий<br />
;4: Обновление пользовательских пакетов, установленных по-умолчанию в системе. Эти пакеты стоят практически у всех и их ошибки будут влиять на максимальное количество пользователей, однако они могут быть оперативно исправлены потому класс опасности не очень высокий. Туда же нужно отнести популярные программы не входящие в поставку — <tt>gimp</tt>, <tt>inkscape</tt>, <tt>audacity</tt>, <tt>vlc</tt>, <tt>kdenive</tt>, <tt>opera</tt>, <tt>chromium-browser</tt>, <tt>skype</tt>.<br />
;5: Обновление прочих пользовательских пакетов. Они затронут только тех, у кого эти программы стоят.<br />
;6: Обновление пакетов, необходимых только для сборки дистрибутива или работы с abf. Почти никому кроме нас они не интересны, потому класс опасности самый низкий.<br />
<br />
==== Задача ====<br />
* Главная задача QA — поиск регрессий, то есть таких изменений в дистрибутиве, которые уменьшают его функциональность по сравнению с предыдущим состоянием.<br />
* Также задачей QA является внесение в багзиллу всех ошибок, найденных в процессе тестирования и не относящихся к регрессиям.<br />
<br />
==== Общие положения ====<br />
* Запрос на обновление пишется в багзилле <br />
* Все сообщения пишутся на английском языке.<br />
* Порядок принятие запросов на тестирование командой QA в общем случае — в порядке возрастания номеров багов, возможны исключения, связанные со срочностью или трудностями в тестировании определенных пакетов.<br />
* Список запросов на обновление можно открыть по ссылке http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=qa_verified%3F&o1=substring&list_id=38774<br />
<br />
==== Срок тестирования ====<br />
* Срок тестирования пакета — '''одна неделя''', за это время служба QA должня проверить пакет и вынести заключение. Срок тестирования может быть увеличен при необходимости тестирования внешними тестерами на отсутствующих у службы QA аппаратно-программных конфигурациях, в этом случае в запросе на обновление задержка должна быть обоснована службой QA.<br />
* Для пакета, который нужно проверить очень срочно, сборщик должен установить приоритет <tt>Highest Critical</tt>, чтобы он выделялся красным цветом в списке. Такие пакеты рассматриваются в течение '''48 часов''' рабочего времени.<br />
* Норма выработки на одного тестера QA - 20 одобренных запросов в неделю, обычно отклоняется 10-20% запросов, так что тестер QA в среднем обрабатывает 5 запросов в день.<br />
<br />
=== Процедура тестирования ===<br />
<br />
==== Требования к запросу на обновление ====<br />
# QA Team тестирует пакеты-кандидаты на добавление в репозитории <tt>main/updates, non-free/updates и restricted/updates</tt>.<br />
# Пакет должен быть собран в общедоступном репозитории (не <tt>_personal</tt>).<br />
# Для архитектурно-зависимых пакетов должны быть представлены все поддерживаемые архитектуры (<tt>i586</tt> и <tt>x64</tt>).<br />
# Описание обновления должно содержать все изменения, которые нужно протестировать.<br />
При несоответствии запроса на обновление этим требованиям запрос отклоняется.<br />
<br />
==== Тестирование установки пакетов ====<br />
# Система перед тестовым обновлением должна соответствовать стандартным репозиториям, с подключенными тестингами. Это можно проверить запуском <tt>urpm-reposync</tt> из пакета <tt>urpm-tools</tt><br />
# Пакеты для тестирования устанавливаются и в графическом, и в текстовом режиме.<br />
## Репозиторий подключается как репозиторий с обновлениями.<br />
## Запускается стандартная процедура обновления.<br />
# Для пакетов, установленных в системе по-умолчанию, проверяется их обновление.<br />
# Для пакетов, не установленных в системе, проверяется как их обновление, так и первоначальная установка при подключенных тестовых контейнерах.<br />
# Установка пакетов проверяется для обеих архитектур. Так как ошибки установки не обычно не зависят от архитектуры, обычно достаточно проверить на одной архитектуре установку в графическом режиме, а на другой — обновление в текстовом, или наоборот.<br />
<br />
==== Тестирование на устойчивость системы ====<br />
При тестировании системы на устойчивость проверяется:<br />
# Стабильность и внешний вид обновленной системы после перезагрузки.<br />
# Стабильность и внешний вид обновленной системы после пробуждения из спящего режима. Тестирование стабильности и производительности может проводиться, например, с помощью теста Unigine Valley под wine и тестом браузера https://webglsamples.org/aquarium/aquarium.html<br />
# Ошибки загрузки демонов, например, с помощью <tt>systemctl | grep failed</tt>.<br />
# Ошибки непрерывного роста файла <tt>.xsession-errors</tt>.<br />
# Журнал ошибок, командами '''journalctl -b |grep fail''' и '''journalctl -b |grep error''' (не должно быть новых ошибок, если они появились - нужно найти связанное с ошибкой обновление и написать инициатору)<br />
# Работа URPMI — дальнейшее обновление пакетов.<br />
# Установка и удаление dkms-модулей (например, установкой проприетарных драйверов с последующим откатом на свободные)<br />
# Сохранением загрузчиком определения других операционных систем, установленных на тестовом компьютере<br />
# Сохранение даты-времени на тестируемой машине после перезагрузки и пробуждения из спящего режима<br />
# Работа системы поиска по содержимому офисных файлов<br />
<br />
==== Тестирование запуска и работы связанных с обновлением приложений ====<br />
Проверяются:<br />
# Тестирование запуска и простейших операций со связанными с тестируемым пакетом программами, рекомендуется контроль сообщений при запуске программы из консоли.<br />
# Связанные с библиотеками из проверяемого пакета программы легче всего установить, попробовав удалить пакет с помощью <tt>urpme</tt> (для установленных в системе программ) или <tt>urpmq --whatrequires</tt> (для всех программ из подключенных репозиториев).<br />
# Изменения в интерфейсах обновляемых библиотек и, соответственно, необходимость перекомпиляции связанных пакетов с помощью сервиса https://abi-laboratory.pro/tracker/<br />
# Для пакетов, предоставляющих библиотеки, проверяются использующие эти библиотеки приложения из main, их можно определить командой <tt>urpmq --whatrequires <названиепакета></tt><br />
# Регрессии в локализации графического интерфейса и страниц справки.<br />
# Для тестирования браузеров в дополнение к https://webglsamples.org/aquarium/aquarium.html применяются.<br />
## Тест html5 https://html5test.com/ (сравнить результат до и после обновления, не должно быть регресса)<br />
## Почтовые онлайновые сервисы http://mail.yandex.ru http://mail.google.com<br />
## Яндекс и гугл-карты https://yandex.ru/maps/-/CVTQITy0 https://www.google.ru/maps/@52.2609339,104.3096872,15z?hl=ru<br />
## xml|xsl трансляцию и кодировки на http://base.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=160129;div=LAW;rnd=0.4700782325977544 и<br />
## Воспроизведение видео http://techslides.com/sample-webm-ogg-and-mp4-video-files-for-html5/ <br />
## Воспроизведение [http://youtu.be/37l7P5V1eXU видео с youtube]<br />
## Работа флэша на примере игры [http://vseigru.net/igry-zombi/2541-igra-zombi-protiv-rastenij.html Растения против зомби] и [http://kino.sputnik.ru/films/ivan+vasilyevich+menyayet+professiyu+1973]<br />
## Уязвимости SSL с помощью https://www.ssllabs.com/ssltest/viewMyClient.html<br />
## Тестирование печати<br />
## Тестирование установки браузера по-умолчанию из настроек<br />
<br />
При найденных на этапе тестирования устройчивости системы или запуска и работы пакета регрессиях запрос на тестирование отклоняется.<br />
<br />
==== Тестирование изменений ====<br />
* Применяется при тестировании обновлений, изменяющих внешний вид или поведение системы.<br />
<br />
Включает себя<br />
# Воспроизведение особенностей внешнего вида или поведения системы ДО исправления.<br />
# Воспроизведение измененных обновлений особенностей по их описанию.<br />
<br />
Например, если в advisory сказано, что «вышла новая версия программы» при тестировании изменений нужно, как минимум, убедиться что версия изменилась.<br />
<br />
В случае если не все описанные изменения действительно присутствуют в тестируемом пакете, пакет принимается и в итоговый отчет (Advisory), вносятся только реально проведенные изменения.<br />
В случае значительного отклонения запрошенных и полученных изменений пакет может быть отклонен.<br />
<br />
==== Расширенное тестирование ====<br />
# Расширенное тестирование проводится добровольцами с помощью репозиториев testing, соответствующих основным репозиториям. <br />
# В течение недели (понедельник-четверг) все проверяемые QA обновления, кроме срочных, отправляются в тестинг, при этом в багзилле ставится статус verified и пишется The update is sent to expanded testing<br />
# В пятницу, руководитель QA:<br />
## Еще раз контролирует, все ли пакеты направлены в тестинг-репозитории, при помощи отключения источников-контейнеров и выполнения программы '''urpm-reposync''' с включенными тестингами. Результатом выполнения команды должно быть отсутствие пакетов на синхронизацию<br />
## Проверяет, дошли ли обновления до зеркал<br />
## Контролирует возможность обновления до тестингов с момента предыдущего релиза платформы путем установки релизного образа и его обновления с подключенными тестингами <br />
## Обновляет до тестингов системы на всех доступных тестовых стендах и проверяет их на устойчивость<br />
## На форуме и в сообществе вконтакте объявляет "пятничное тестирование", к нему выпускает бюллетень с полным списком обновлений и методикой их тестирования.<br />
# В понедельник руководитель QA читает отзывы пользователей и по их итогам, а также по итогам эксплуатации тестовых стендов в выходные дни, обрабатывает запросы на обновление и передает их на публикацию (или отклоняет)<br />
<br />
=== Завершение тестирования ===<br />
<br />
==== Положительный результат тестирования ====<br />
# По окончании тестирования при его успехе ставится индикатор успешного тестирования QA «+» и пишется отчет (Advisory), содержащий:<br />
## Название пакета с исходниками (src.rpm).<br />
## Версию пакета.<br />
## Отчет о тестировании (advisory).<br />
## Надпись «QA verified».<br />
# Если пакет содержит изменения, связанные с секретностью или же собран не сотрудником Росы — посылается запрос Secure team (взводится флажок secteam_verified «?»).<br />
# Если тестирование secure не нужно, пакет передается на публикацию (взводится соответствующий published «?»).<br />
# В случае успешного тестирования пакет может быть оставлен в системе. В случае ошибок систему нужно привести к первоначальному виду с помощью деинсталляции пакета или утилиты <tt>urpm-reposync</tt> из <tt>urpm-repotools</tt>.<br />
<br />
==== Отрицательный результат тестирования ====<br />
# При отклонении пакета ставится индикатор отклонения QA «-»,<br />
# В комментариях пишется причина отклонения запроса и в конце комментария добавляется «QA Denied».<br />
# При отрицательном результате тестирования сборщик может выложить исправленные контейнеры в тот же запрос и снова установить «?» в «qa_requested».</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F&diff=18625
Регламент тестирования
2020-04-29T09:19:57Z
<p>Vladimir.potapov: /* Тестирование установки пакетов */</p>
<hr />
<div>[[Category:Регламенты ROSA]]<br />
<br />
=== Политика ===<br />
QA отвечает за стабильность установленного у пользователей дистрибутива при его обновлениях.<br />
<br />
До установки обновлений дистрибутив работает. Любое обновление — риск его обрушить.<br />
Поэтому политика QA обязана быть консервативной и даже несколько параноидальной — при малейших сомнениях должны назначаться дополнительные проверки, пакеты должны отклоняться, направляться на пересборку.<br />
<br />
Политика QA вступает в конфликт с интересами сборщиков пакетов, желающих быстрее увидеть в репозиториях исправленную версию — конфликт этот должен быть конструктивным, приводящим к непрерывному повышению функциональности и стабильности дистрибутива.<br />
<br />
==== Классификация обновлений по степени опасности ====<br />
<blockquote><br />
Меня не интересуют их намерения, меня интересуют их возможности — © Отто Фон Бисмарк<br />
</blockquote><br />
<br />
Классификация исходит из максимально возможного урона (полный отказ функционирования компонента), который может нанести устанавливаемое обновление.<br />
<br />
;0: Критические обновления. Ядро, файловая система, система прав доступа, скрипты загрузки, <tt>systemd</tt>, <tt>glibc</tt>, <tt>dracut</tt>, <tt>grub</tt>, <tt>bash</tt> и прочие основные вещи, если удалить которые система не загрузится даже в консоли.<br />
;1: Обновления драйверов устройств, т.е. те же критические обновления, но актуальные не для всех пользователей. <br />
;2: Обновления сетевых компонентов: NetworkManager, сетевых скриптов, системы сетевой инициализации и системы обновлений (curl, urpmi). Они опасны тем, что если сеть упадет, пользователю без сети будет затруднительно получить исправленный пакет, когда мы его выпустим и установить обновление. <br />
;3: Обновления графических компонент и скриптов — X-ов, менеджера входа, графических библиотек, драйверов, '''perl, python''' — то, без чего невозможен вход в систему в графическом режиме. Т.к. обновление системы, при наличии сети, возможно и не в графике - класс опасности обновлений не самый высокий<br />
;4: Обновление пользовательских пакетов, установленных по-умолчанию в системе. Эти пакеты стоят практически у всех и их ошибки будут влиять на максимальное количество пользователей, однако они могут быть оперативно исправлены потому класс опасности не очень высокий. Туда же нужно отнести популярные программы не входящие в поставку — <tt>gimp</tt>, <tt>inkscape</tt>, <tt>audacity</tt>, <tt>vlc</tt>, <tt>kdenive</tt>, <tt>opera</tt>, <tt>chromium-browser</tt>, <tt>skype</tt>.<br />
;5: Обновление прочих пользовательских пакетов. Они затронут только тех, у кого эти программы стоят.<br />
;6: Обновление пакетов, необходимых только для сборки дистрибутива или работы с abf. Почти никому кроме нас они не интересны, потому класс опасности самый низкий.<br />
<br />
==== Задача ====<br />
* Главная задача QA — поиск регрессий, то есть таких изменений в дистрибутиве, которые уменьшают его функциональность по сравнению с предыдущим состоянием.<br />
* Также задачей QA является внесение в багзиллу всех ошибок, найденных в процессе тестирования и не относящихся к регрессиям.<br />
<br />
==== Общие положения ====<br />
* Запрос на обновление пишется в багзилле <br />
* Все сообщения пишутся на английском языке.<br />
* Порядок принятие запросов на тестирование командой QA в общем случае — в порядке возрастания номеров багов, возможны исключения, связанные со срочностью или трудностями в тестировании определенных пакетов.<br />
* Список запросов на обновление можно открыть по ссылке http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=qa_verified%3F&o1=substring&list_id=38774<br />
<br />
==== Срок тестирования ====<br />
* Срок тестирования пакета — '''одна неделя''', за это время служба QA должня проверить пакет и вынести заключение. Срок тестирования может быть увеличен при необходимости тестирования внешними тестерами на отсутствующих у службы QA аппаратно-программных конфигурациях, в этом случае в запросе на обновление задержка должна быть обоснована службой QA.<br />
* Для пакета, который нужно проверить очень срочно, сборщик должен установить приоритет <tt>Highest Critical</tt>, чтобы он выделялся красным цветом в списке. Такие пакеты рассматриваются в течение '''48 часов''' рабочего времени.<br />
* Норма выработки на одного тестера QA - 20 одобренных запросов в неделю, обычно отклоняется 10-20% запросов, так что тестер QA в среднем обрабатывает 5 запросов в день.<br />
<br />
=== Процедура тестирования ===<br />
<br />
==== Требования к запросу на обновление ====<br />
# QA Team тестирует пакеты-кандидаты на добавление в репозитории <tt>main/updates, non-free/updates и restricted/updates</tt>.<br />
# Пакет должен быть собран в общедоступном репозитории (не <tt>_personal</tt>).<br />
# Для архитектурно-зависимых пакетов должны быть представлены все поддерживаемые архитектуры (<tt>i586</tt> и <tt>x64</tt>).<br />
# Описание обновления должно содержать все изменения, которые нужно протестировать.<br />
При несоответствии запроса на обновление этим требованиям запрос отклоняется.<br />
<br />
==== Тестирование установки пакетов ====<br />
# Система перед тестовым обновлением должна соответствовать стандартным репозиториям, с подключенными тестингами. Это можно проверить запуском <tt>urpm-reposync</tt> из пакета <tt>urpm-tools</tt><br />
# Пакеты для тестирования устанавливаются и в графическом, и в текстовом режиме.<br />
## Репозиторий подключается как репозиторий с обновлениями.<br />
## Запускается стандартная процедура обновления.<br />
# Для пакетов, установленных в системе по-умолчанию, проверяется их обновление.<br />
# Для пакетов, не установленных в системе, проверяется как их обновление, так и первоначальная установка при подключенных тестовых контейнерах.<br />
# Установка пакетов проверяется для обеих архитектур. Так как ошибки установки не обычно не зависят от архитектуры, обычно достаточно проверить на одной архитектуре установку в графическом режиме, а на другой — обновление в текстовом, или наоборот.<br />
<br />
==== Тестирование на устойчивость системы ====<br />
При тестировании системы на устойчивость проверяется:<br />
# Стабильность и внешний вид обновленной системы после перезагрузки.<br />
# Стабильность и внешний вид обновленной системы после пробуждения из спящего режима. Тестирование стабильности и производительности может проводиться, например, с помощью теста Unigine Valley под wine и тестом браузера https://webglsamples.org/aquarium/aquarium.html<br />
# Ошибки загрузки демонов, например, с помощью <tt>systemctl | grep failed</tt>.<br />
# Ошибки непрерывного роста файла <tt>.xsession-errors</tt>.<br />
# Журнал ошибок, командами '''journalctl -b |grep fail''' и '''journalctl -b |grep error''' (не должно быть новых ошибок, если они появились - нужно найти связанное с ошибкой обновление и написать инициатору)<br />
# Работа URPMI — дальнейшее обновление пакетов.<br />
# Установка и удаление dkms-модулей (например, установкой проприетарных драйверов с последующим откатом на свободные)<br />
# Сохранением загрузчиком определения других операционных систем, установленных на тестовом компьютере<br />
# Сохранение даты-времени на тестируемой машине после перезагрузки и пробуждения из спящего режима<br />
# Работа системы поиска по содержимому офисных файлов<br />
<br />
==== Тестирование запуска и работы связанных с обновлением приложений ====<br />
Проверяются:<br />
# Тестирование запуска и простейших операций со связанными с тестируемым пакетом программами, рекомендуется контроль сообщений при запуске программы из консоли.<br />
# Связанные с библиотеками из проверяемого пакета программы легче всего установить, попробовав удалить пакет с помощью <tt>urpme</tt> (для установленных в системе программ) или <tt>urpmq --whatrequires</tt> (для всех программ из подключенных репозиториев).<br />
# Изменения в интерфейсах обновляемых библиотек и, соответственно, необходимость перекомпиляции связанных пакетов с помощью сервиса https://abi-laboratory.pro/tracker/<br />
# Для пакетов, предоставляющих библиотеки, проверяются использующие эти библиотеки приложения из main, их можно определить командой <tt>urpmq --whatrequires <названиепакета></tt><br />
# Регрессии в локализации графического интерфейса и страниц справки.<br />
# Для тестирования браузеров в дополнение к https://webglsamples.org/aquarium/aquarium.html применяются.<br />
## Тест html5 https://html5test.com/ (сравнить результат до и после обновления, не должно быть регресса)<br />
## Почтовые онлайновые сервисы http://mail.yandex.ru http://mail.google.com<br />
## Яндекс и гугл-карты https://yandex.ru/maps/-/CVTQITy0 https://www.google.ru/maps/@52.2609339,104.3096872,15z?hl=ru<br />
## xml|xsl трансляцию и кодировки на http://base.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=160129;div=LAW;rnd=0.4700782325977544 и<br />
## Воспроизведение видео http://techslides.com/sample-webm-ogg-and-mp4-video-files-for-html5/ <br />
## Воспроизведение [http://youtu.be/37l7P5V1eXU видео с youtube]<br />
## Работа флэша на примере игры [http://vseigru.net/igry-zombi/2541-igra-zombi-protiv-rastenij.html Растения против зомби] и [http://kino.sputnik.ru/films/ivan+vasilyevich+menyayet+professiyu+1973]<br />
## Работу java с помощью <tt>icedtea-web</tt> и демок пакета <tt>java-1.8-openjdk-demo</tt><br />
## Уязвимости SSL с помощью https://www.ssllabs.com/ssltest/viewMyClient.html<br />
## Тестирование печати<br />
## Тестирование установки браузера по-умолчанию из настроек<br />
<br />
При найденных на этапе тестирования устройчивости системы или запуска и работы пакета регрессиях запрос на тестирование отклоняется.<br />
<br />
==== Тестирование изменений ====<br />
* Применяется при тестировании обновлений, изменяющих внешний вид или поведение системы.<br />
<br />
Включает себя<br />
# Воспроизведение особенностей внешнего вида или поведения системы ДО исправления.<br />
# Воспроизведение измененных обновлений особенностей по их описанию.<br />
<br />
Например, если в advisory сказано, что «вышла новая версия программы» при тестировании изменений нужно, как минимум, убедиться что версия изменилась.<br />
<br />
В случае если не все описанные изменения действительно присутствуют в тестируемом пакете, пакет принимается и в итоговый отчет (Advisory), вносятся только реально проведенные изменения.<br />
В случае значительного отклонения запрошенных и полученных изменений пакет может быть отклонен.<br />
<br />
==== Расширенное тестирование ====<br />
# Расширенное тестирование проводится добровольцами с помощью репозиториев testing, соответствующих основным репозиториям. <br />
# В течение недели (понедельник-четверг) все проверяемые QA обновления, кроме срочных, отправляются в тестинг, при этом в багзилле ставится статус verified и пишется The update is sent to expanded testing<br />
# В пятницу, руководитель QA:<br />
## Еще раз контролирует, все ли пакеты направлены в тестинг-репозитории, при помощи отключения источников-контейнеров и выполнения программы '''urpm-reposync''' с включенными тестингами. Результатом выполнения команды должно быть отсутствие пакетов на синхронизацию<br />
## Проверяет, дошли ли обновления до зеркал<br />
## Контролирует возможность обновления до тестингов с момента предыдущего релиза платформы путем установки релизного образа и его обновления с подключенными тестингами <br />
## Обновляет до тестингов системы на всех доступных тестовых стендах и проверяет их на устойчивость<br />
## На форуме и в сообществе вконтакте объявляет "пятничное тестирование", к нему выпускает бюллетень с полным списком обновлений и методикой их тестирования.<br />
# В понедельник руководитель QA читает отзывы пользователей и по их итогам, а также по итогам эксплуатации тестовых стендов в выходные дни, обрабатывает запросы на обновление и передает их на публикацию (или отклоняет)<br />
<br />
=== Завершение тестирования ===<br />
<br />
==== Положительный результат тестирования ====<br />
# По окончании тестирования при его успехе ставится индикатор успешного тестирования QA «+» и пишется отчет (Advisory), содержащий:<br />
## Название пакета с исходниками (src.rpm).<br />
## Версию пакета.<br />
## Отчет о тестировании (advisory).<br />
## Надпись «QA verified».<br />
# Если пакет содержит изменения, связанные с секретностью или же собран не сотрудником Росы — посылается запрос Secure team (взводится флажок secteam_verified «?»).<br />
# Если тестирование secure не нужно, пакет передается на публикацию (взводится соответствующий published «?»).<br />
# В случае успешного тестирования пакет может быть оставлен в системе. В случае ошибок систему нужно привести к первоначальному виду с помощью деинсталляции пакета или утилиты <tt>urpm-reposync</tt> из <tt>urpm-repotools</tt>.<br />
<br />
==== Отрицательный результат тестирования ====<br />
# При отклонении пакета ставится индикатор отклонения QA «-»,<br />
# В комментариях пишется причина отклонения запроса и в конце комментария добавляется «QA Denied».<br />
# При отрицательном результате тестирования сборщик может выложить исправленные контейнеры в тот же запрос и снова установить «?» в «qa_requested».</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F&diff=18624
Регламент тестирования
2020-04-29T09:18:06Z
<p>Vladimir.potapov: /* Тестирование на устойчивость системы */</p>
<hr />
<div>[[Category:Регламенты ROSA]]<br />
<br />
=== Политика ===<br />
QA отвечает за стабильность установленного у пользователей дистрибутива при его обновлениях.<br />
<br />
До установки обновлений дистрибутив работает. Любое обновление — риск его обрушить.<br />
Поэтому политика QA обязана быть консервативной и даже несколько параноидальной — при малейших сомнениях должны назначаться дополнительные проверки, пакеты должны отклоняться, направляться на пересборку.<br />
<br />
Политика QA вступает в конфликт с интересами сборщиков пакетов, желающих быстрее увидеть в репозиториях исправленную версию — конфликт этот должен быть конструктивным, приводящим к непрерывному повышению функциональности и стабильности дистрибутива.<br />
<br />
==== Классификация обновлений по степени опасности ====<br />
<blockquote><br />
Меня не интересуют их намерения, меня интересуют их возможности — © Отто Фон Бисмарк<br />
</blockquote><br />
<br />
Классификация исходит из максимально возможного урона (полный отказ функционирования компонента), который может нанести устанавливаемое обновление.<br />
<br />
;0: Критические обновления. Ядро, файловая система, система прав доступа, скрипты загрузки, <tt>systemd</tt>, <tt>glibc</tt>, <tt>dracut</tt>, <tt>grub</tt>, <tt>bash</tt> и прочие основные вещи, если удалить которые система не загрузится даже в консоли.<br />
;1: Обновления драйверов устройств, т.е. те же критические обновления, но актуальные не для всех пользователей. <br />
;2: Обновления сетевых компонентов: NetworkManager, сетевых скриптов, системы сетевой инициализации и системы обновлений (curl, urpmi). Они опасны тем, что если сеть упадет, пользователю без сети будет затруднительно получить исправленный пакет, когда мы его выпустим и установить обновление. <br />
;3: Обновления графических компонент и скриптов — X-ов, менеджера входа, графических библиотек, драйверов, '''perl, python''' — то, без чего невозможен вход в систему в графическом режиме. Т.к. обновление системы, при наличии сети, возможно и не в графике - класс опасности обновлений не самый высокий<br />
;4: Обновление пользовательских пакетов, установленных по-умолчанию в системе. Эти пакеты стоят практически у всех и их ошибки будут влиять на максимальное количество пользователей, однако они могут быть оперативно исправлены потому класс опасности не очень высокий. Туда же нужно отнести популярные программы не входящие в поставку — <tt>gimp</tt>, <tt>inkscape</tt>, <tt>audacity</tt>, <tt>vlc</tt>, <tt>kdenive</tt>, <tt>opera</tt>, <tt>chromium-browser</tt>, <tt>skype</tt>.<br />
;5: Обновление прочих пользовательских пакетов. Они затронут только тех, у кого эти программы стоят.<br />
;6: Обновление пакетов, необходимых только для сборки дистрибутива или работы с abf. Почти никому кроме нас они не интересны, потому класс опасности самый низкий.<br />
<br />
==== Задача ====<br />
* Главная задача QA — поиск регрессий, то есть таких изменений в дистрибутиве, которые уменьшают его функциональность по сравнению с предыдущим состоянием.<br />
* Также задачей QA является внесение в багзиллу всех ошибок, найденных в процессе тестирования и не относящихся к регрессиям.<br />
<br />
==== Общие положения ====<br />
* Запрос на обновление пишется в багзилле <br />
* Все сообщения пишутся на английском языке.<br />
* Порядок принятие запросов на тестирование командой QA в общем случае — в порядке возрастания номеров багов, возможны исключения, связанные со срочностью или трудностями в тестировании определенных пакетов.<br />
* Список запросов на обновление можно открыть по ссылке http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=qa_verified%3F&o1=substring&list_id=38774<br />
<br />
==== Срок тестирования ====<br />
* Срок тестирования пакета — '''одна неделя''', за это время служба QA должня проверить пакет и вынести заключение. Срок тестирования может быть увеличен при необходимости тестирования внешними тестерами на отсутствующих у службы QA аппаратно-программных конфигурациях, в этом случае в запросе на обновление задержка должна быть обоснована службой QA.<br />
* Для пакета, который нужно проверить очень срочно, сборщик должен установить приоритет <tt>Highest Critical</tt>, чтобы он выделялся красным цветом в списке. Такие пакеты рассматриваются в течение '''48 часов''' рабочего времени.<br />
* Норма выработки на одного тестера QA - 20 одобренных запросов в неделю, обычно отклоняется 10-20% запросов, так что тестер QA в среднем обрабатывает 5 запросов в день.<br />
<br />
=== Процедура тестирования ===<br />
<br />
==== Требования к запросу на обновление ====<br />
# QA Team тестирует пакеты-кандидаты на добавление в репозитории <tt>main/updates, non-free/updates и restricted/updates</tt>.<br />
# Пакет должен быть собран в общедоступном репозитории (не <tt>_personal</tt>).<br />
# Для архитектурно-зависимых пакетов должны быть представлены все поддерживаемые архитектуры (<tt>i586</tt> и <tt>x64</tt>).<br />
# Описание обновления должно содержать все изменения, которые нужно протестировать.<br />
При несоответствии запроса на обновление этим требованиям запрос отклоняется.<br />
<br />
==== Тестирование установки пакетов ====<br />
# Система перед тестовым обновлением должна соответствовать стандартным репозиториям, с подключенными тестингами. Это можно проверить запуском <tt>urpm-reposync</tt> из пакета <tt>urpm-tools</tt><br />
# Пакеты для тестирования устанавливаются и в графическом, и в текстовом режиме.<br />
## Репозиторий подключается как репозиторий с обновлениями.<br />
## Запускается стандартная процедура обновления.<br />
# Для пакетов, установленных в системе по-умолчанию, проверяется их обновление.<br />
# Для пакетов, не установленных в системе, проверяется как их обновление, так и первоначальная установка при подключенных тестовых контейнерах.<br />
# Установка пакетов проверяется для обеих архитектур. Так как ошибки установки не обычно не зависят от архитектуры, обычно достаточно проверить на одной архитектуре установку в графическом режиме, а на другой — обновление в текстовом, или наоборот.<br />
<br />
При ошибке установки в запрос пишется сообщение об ошибке, если до пятницы он не исправляется инициатором запроса, то такой запрос отклоняется.<br />
<br />
==== Тестирование на устойчивость системы ====<br />
При тестировании системы на устойчивость проверяется:<br />
# Стабильность и внешний вид обновленной системы после перезагрузки.<br />
# Стабильность и внешний вид обновленной системы после пробуждения из спящего режима. Тестирование стабильности и производительности может проводиться, например, с помощью теста Unigine Valley под wine и тестом браузера https://webglsamples.org/aquarium/aquarium.html<br />
# Ошибки загрузки демонов, например, с помощью <tt>systemctl | grep failed</tt>.<br />
# Ошибки непрерывного роста файла <tt>.xsession-errors</tt>.<br />
# Журнал ошибок, командами '''journalctl -b |grep fail''' и '''journalctl -b |grep error''' (не должно быть новых ошибок, если они появились - нужно найти связанное с ошибкой обновление и написать инициатору)<br />
# Работа URPMI — дальнейшее обновление пакетов.<br />
# Установка и удаление dkms-модулей (например, установкой проприетарных драйверов с последующим откатом на свободные)<br />
# Сохранением загрузчиком определения других операционных систем, установленных на тестовом компьютере<br />
# Сохранение даты-времени на тестируемой машине после перезагрузки и пробуждения из спящего режима<br />
# Работа системы поиска по содержимому офисных файлов<br />
<br />
==== Тестирование запуска и работы связанных с обновлением приложений ====<br />
Проверяются:<br />
# Тестирование запуска и простейших операций со связанными с тестируемым пакетом программами, рекомендуется контроль сообщений при запуске программы из консоли.<br />
# Связанные с библиотеками из проверяемого пакета программы легче всего установить, попробовав удалить пакет с помощью <tt>urpme</tt> (для установленных в системе программ) или <tt>urpmq --whatrequires</tt> (для всех программ из подключенных репозиториев).<br />
# Изменения в интерфейсах обновляемых библиотек и, соответственно, необходимость перекомпиляции связанных пакетов с помощью сервиса https://abi-laboratory.pro/tracker/<br />
# Для пакетов, предоставляющих библиотеки, проверяются использующие эти библиотеки приложения из main, их можно определить командой <tt>urpmq --whatrequires <названиепакета></tt><br />
# Регрессии в локализации графического интерфейса и страниц справки.<br />
# Для тестирования браузеров в дополнение к https://webglsamples.org/aquarium/aquarium.html применяются.<br />
## Тест html5 https://html5test.com/ (сравнить результат до и после обновления, не должно быть регресса)<br />
## Почтовые онлайновые сервисы http://mail.yandex.ru http://mail.google.com<br />
## Яндекс и гугл-карты https://yandex.ru/maps/-/CVTQITy0 https://www.google.ru/maps/@52.2609339,104.3096872,15z?hl=ru<br />
## xml|xsl трансляцию и кодировки на http://base.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=160129;div=LAW;rnd=0.4700782325977544 и<br />
## Воспроизведение видео http://techslides.com/sample-webm-ogg-and-mp4-video-files-for-html5/ <br />
## Воспроизведение [http://youtu.be/37l7P5V1eXU видео с youtube]<br />
## Работа флэша на примере игры [http://vseigru.net/igry-zombi/2541-igra-zombi-protiv-rastenij.html Растения против зомби] и [http://kino.sputnik.ru/films/ivan+vasilyevich+menyayet+professiyu+1973]<br />
## Работу java с помощью <tt>icedtea-web</tt> и демок пакета <tt>java-1.8-openjdk-demo</tt><br />
## Уязвимости SSL с помощью https://www.ssllabs.com/ssltest/viewMyClient.html<br />
## Тестирование печати<br />
## Тестирование установки браузера по-умолчанию из настроек<br />
<br />
При найденных на этапе тестирования устройчивости системы или запуска и работы пакета регрессиях запрос на тестирование отклоняется.<br />
<br />
==== Тестирование изменений ====<br />
* Применяется при тестировании обновлений, изменяющих внешний вид или поведение системы.<br />
<br />
Включает себя<br />
# Воспроизведение особенностей внешнего вида или поведения системы ДО исправления.<br />
# Воспроизведение измененных обновлений особенностей по их описанию.<br />
<br />
Например, если в advisory сказано, что «вышла новая версия программы» при тестировании изменений нужно, как минимум, убедиться что версия изменилась.<br />
<br />
В случае если не все описанные изменения действительно присутствуют в тестируемом пакете, пакет принимается и в итоговый отчет (Advisory), вносятся только реально проведенные изменения.<br />
В случае значительного отклонения запрошенных и полученных изменений пакет может быть отклонен.<br />
<br />
==== Расширенное тестирование ====<br />
# Расширенное тестирование проводится добровольцами с помощью репозиториев testing, соответствующих основным репозиториям. <br />
# В течение недели (понедельник-четверг) все проверяемые QA обновления, кроме срочных, отправляются в тестинг, при этом в багзилле ставится статус verified и пишется The update is sent to expanded testing<br />
# В пятницу, руководитель QA:<br />
## Еще раз контролирует, все ли пакеты направлены в тестинг-репозитории, при помощи отключения источников-контейнеров и выполнения программы '''urpm-reposync''' с включенными тестингами. Результатом выполнения команды должно быть отсутствие пакетов на синхронизацию<br />
## Проверяет, дошли ли обновления до зеркал<br />
## Контролирует возможность обновления до тестингов с момента предыдущего релиза платформы путем установки релизного образа и его обновления с подключенными тестингами <br />
## Обновляет до тестингов системы на всех доступных тестовых стендах и проверяет их на устойчивость<br />
## На форуме и в сообществе вконтакте объявляет "пятничное тестирование", к нему выпускает бюллетень с полным списком обновлений и методикой их тестирования.<br />
# В понедельник руководитель QA читает отзывы пользователей и по их итогам, а также по итогам эксплуатации тестовых стендов в выходные дни, обрабатывает запросы на обновление и передает их на публикацию (или отклоняет)<br />
<br />
=== Завершение тестирования ===<br />
<br />
==== Положительный результат тестирования ====<br />
# По окончании тестирования при его успехе ставится индикатор успешного тестирования QA «+» и пишется отчет (Advisory), содержащий:<br />
## Название пакета с исходниками (src.rpm).<br />
## Версию пакета.<br />
## Отчет о тестировании (advisory).<br />
## Надпись «QA verified».<br />
# Если пакет содержит изменения, связанные с секретностью или же собран не сотрудником Росы — посылается запрос Secure team (взводится флажок secteam_verified «?»).<br />
# Если тестирование secure не нужно, пакет передается на публикацию (взводится соответствующий published «?»).<br />
# В случае успешного тестирования пакет может быть оставлен в системе. В случае ошибок систему нужно привести к первоначальному виду с помощью деинсталляции пакета или утилиты <tt>urpm-reposync</tt> из <tt>urpm-repotools</tt>.<br />
<br />
==== Отрицательный результат тестирования ====<br />
# При отклонении пакета ставится индикатор отклонения QA «-»,<br />
# В комментариях пишется причина отклонения запроса и в конце комментария добавляется «QA Denied».<br />
# При отрицательном результате тестирования сборщик может выложить исправленные контейнеры в тот же запрос и снова установить «?» в «qa_requested».</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F&diff=18623
Регламент тестирования
2020-04-29T09:10:44Z
<p>Vladimir.potapov: /* Тестирование установки пакетов */</p>
<hr />
<div>[[Category:Регламенты ROSA]]<br />
<br />
=== Политика ===<br />
QA отвечает за стабильность установленного у пользователей дистрибутива при его обновлениях.<br />
<br />
До установки обновлений дистрибутив работает. Любое обновление — риск его обрушить.<br />
Поэтому политика QA обязана быть консервативной и даже несколько параноидальной — при малейших сомнениях должны назначаться дополнительные проверки, пакеты должны отклоняться, направляться на пересборку.<br />
<br />
Политика QA вступает в конфликт с интересами сборщиков пакетов, желающих быстрее увидеть в репозиториях исправленную версию — конфликт этот должен быть конструктивным, приводящим к непрерывному повышению функциональности и стабильности дистрибутива.<br />
<br />
==== Классификация обновлений по степени опасности ====<br />
<blockquote><br />
Меня не интересуют их намерения, меня интересуют их возможности — © Отто Фон Бисмарк<br />
</blockquote><br />
<br />
Классификация исходит из максимально возможного урона (полный отказ функционирования компонента), который может нанести устанавливаемое обновление.<br />
<br />
;0: Критические обновления. Ядро, файловая система, система прав доступа, скрипты загрузки, <tt>systemd</tt>, <tt>glibc</tt>, <tt>dracut</tt>, <tt>grub</tt>, <tt>bash</tt> и прочие основные вещи, если удалить которые система не загрузится даже в консоли.<br />
;1: Обновления драйверов устройств, т.е. те же критические обновления, но актуальные не для всех пользователей. <br />
;2: Обновления сетевых компонентов: NetworkManager, сетевых скриптов, системы сетевой инициализации и системы обновлений (curl, urpmi). Они опасны тем, что если сеть упадет, пользователю без сети будет затруднительно получить исправленный пакет, когда мы его выпустим и установить обновление. <br />
;3: Обновления графических компонент и скриптов — X-ов, менеджера входа, графических библиотек, драйверов, '''perl, python''' — то, без чего невозможен вход в систему в графическом режиме. Т.к. обновление системы, при наличии сети, возможно и не в графике - класс опасности обновлений не самый высокий<br />
;4: Обновление пользовательских пакетов, установленных по-умолчанию в системе. Эти пакеты стоят практически у всех и их ошибки будут влиять на максимальное количество пользователей, однако они могут быть оперативно исправлены потому класс опасности не очень высокий. Туда же нужно отнести популярные программы не входящие в поставку — <tt>gimp</tt>, <tt>inkscape</tt>, <tt>audacity</tt>, <tt>vlc</tt>, <tt>kdenive</tt>, <tt>opera</tt>, <tt>chromium-browser</tt>, <tt>skype</tt>.<br />
;5: Обновление прочих пользовательских пакетов. Они затронут только тех, у кого эти программы стоят.<br />
;6: Обновление пакетов, необходимых только для сборки дистрибутива или работы с abf. Почти никому кроме нас они не интересны, потому класс опасности самый низкий.<br />
<br />
==== Задача ====<br />
* Главная задача QA — поиск регрессий, то есть таких изменений в дистрибутиве, которые уменьшают его функциональность по сравнению с предыдущим состоянием.<br />
* Также задачей QA является внесение в багзиллу всех ошибок, найденных в процессе тестирования и не относящихся к регрессиям.<br />
<br />
==== Общие положения ====<br />
* Запрос на обновление пишется в багзилле <br />
* Все сообщения пишутся на английском языке.<br />
* Порядок принятие запросов на тестирование командой QA в общем случае — в порядке возрастания номеров багов, возможны исключения, связанные со срочностью или трудностями в тестировании определенных пакетов.<br />
* Список запросов на обновление можно открыть по ссылке http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=qa_verified%3F&o1=substring&list_id=38774<br />
<br />
==== Срок тестирования ====<br />
* Срок тестирования пакета — '''одна неделя''', за это время служба QA должня проверить пакет и вынести заключение. Срок тестирования может быть увеличен при необходимости тестирования внешними тестерами на отсутствующих у службы QA аппаратно-программных конфигурациях, в этом случае в запросе на обновление задержка должна быть обоснована службой QA.<br />
* Для пакета, который нужно проверить очень срочно, сборщик должен установить приоритет <tt>Highest Critical</tt>, чтобы он выделялся красным цветом в списке. Такие пакеты рассматриваются в течение '''48 часов''' рабочего времени.<br />
* Норма выработки на одного тестера QA - 20 одобренных запросов в неделю, обычно отклоняется 10-20% запросов, так что тестер QA в среднем обрабатывает 5 запросов в день.<br />
<br />
=== Процедура тестирования ===<br />
<br />
==== Требования к запросу на обновление ====<br />
# QA Team тестирует пакеты-кандидаты на добавление в репозитории <tt>main/updates, non-free/updates и restricted/updates</tt>.<br />
# Пакет должен быть собран в общедоступном репозитории (не <tt>_personal</tt>).<br />
# Для архитектурно-зависимых пакетов должны быть представлены все поддерживаемые архитектуры (<tt>i586</tt> и <tt>x64</tt>).<br />
# Описание обновления должно содержать все изменения, которые нужно протестировать.<br />
При несоответствии запроса на обновление этим требованиям запрос отклоняется.<br />
<br />
==== Тестирование установки пакетов ====<br />
# Система перед тестовым обновлением должна соответствовать стандартным репозиториям, с подключенными тестингами. Это можно проверить запуском <tt>urpm-reposync</tt> из пакета <tt>urpm-tools</tt><br />
# Пакеты для тестирования устанавливаются и в графическом, и в текстовом режиме.<br />
## Репозиторий подключается как репозиторий с обновлениями.<br />
## Запускается стандартная процедура обновления.<br />
# Для пакетов, установленных в системе по-умолчанию, проверяется их обновление.<br />
# Для пакетов, не установленных в системе, проверяется как их обновление, так и первоначальная установка при подключенных тестовых контейнерах.<br />
# Установка пакетов проверяется для обеих архитектур. Так как ошибки установки не обычно не зависят от архитектуры, обычно достаточно проверить на одной архитектуре установку в графическом режиме, а на другой — обновление в текстовом, или наоборот.<br />
<br />
При ошибке установки в запрос пишется сообщение об ошибке, если до пятницы он не исправляется инициатором запроса, то такой запрос отклоняется.<br />
<br />
==== Тестирование на устойчивость системы ====<br />
* Применяется при пересборках библиотек или пакетов без внесения изменений, или для изменений связанных с безопасностью.<br />
* Для экономии времени может выполняться для окончательного тестирования последовательности обновлений перед публикацией их в репозитории<br />
<br />
При тестировании системы на устойчивость проверяется<br />
# Стабильность и внешний вид обновленной системы после перезагрузки.<br />
# Стабильность и внешний вид обновленной системы после пробуждения из спящего режима. Тестирование стабильности и производительности может проводиться, например, с помощью теста Unigine Valley под wine и тестом браузера https://webglsamples.org/aquarium/aquarium.html<br />
# Ошибки загрузки демонов, например, с помощью <tt>systemctl | grep failed</tt>.<br />
# Ошибки непрерывного роста файла <tt>.xsession-errors</tt>.<br />
# Работа URPMI — дальнейшее обновление пакетов.<br />
# Установка и удаление dkms-модулей.<br />
# Сохранение даты-времени на тестируемой машине после перезагрузки и пробуждения из спящего режима.<br />
<br />
==== Тестирование запуска и работы связанных с обновлением приложений ====<br />
Проверяются:<br />
# Тестирование запуска и простейших операций со связанными с тестируемым пакетом программами, рекомендуется контроль сообщений при запуске программы из консоли.<br />
# Связанные с библиотеками из проверяемого пакета программы легче всего установить, попробовав удалить пакет с помощью <tt>urpme</tt> (для установленных в системе программ) или <tt>urpmq --whatrequires</tt> (для всех программ из подключенных репозиториев).<br />
# Изменения в интерфейсах обновляемых библиотек и, соответственно, необходимость перекомпиляции связанных пакетов с помощью сервиса https://abi-laboratory.pro/tracker/<br />
# Для пакетов, предоставляющих библиотеки, проверяются использующие эти библиотеки приложения из main, их можно определить командой <tt>urpmq --whatrequires <названиепакета></tt><br />
# Регрессии в локализации графического интерфейса и страниц справки.<br />
# Для тестирования браузеров в дополнение к https://webglsamples.org/aquarium/aquarium.html применяются.<br />
## Тест html5 https://html5test.com/ (сравнить результат до и после обновления, не должно быть регресса)<br />
## Почтовые онлайновые сервисы http://mail.yandex.ru http://mail.google.com<br />
## Яндекс и гугл-карты https://yandex.ru/maps/-/CVTQITy0 https://www.google.ru/maps/@52.2609339,104.3096872,15z?hl=ru<br />
## xml|xsl трансляцию и кодировки на http://base.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=160129;div=LAW;rnd=0.4700782325977544 и<br />
## Воспроизведение видео http://techslides.com/sample-webm-ogg-and-mp4-video-files-for-html5/ <br />
## Воспроизведение [http://youtu.be/37l7P5V1eXU видео с youtube]<br />
## Работа флэша на примере игры [http://vseigru.net/igry-zombi/2541-igra-zombi-protiv-rastenij.html Растения против зомби] и [http://kino.sputnik.ru/films/ivan+vasilyevich+menyayet+professiyu+1973]<br />
## Работу java с помощью <tt>icedtea-web</tt> и демок пакета <tt>java-1.8-openjdk-demo</tt><br />
## Уязвимости SSL с помощью https://www.ssllabs.com/ssltest/viewMyClient.html<br />
## Тестирование печати<br />
## Тестирование установки браузера по-умолчанию из настроек<br />
<br />
При найденных на этапе тестирования устройчивости системы или запуска и работы пакета регрессиях запрос на тестирование отклоняется.<br />
<br />
==== Тестирование изменений ====<br />
* Применяется при тестировании обновлений, изменяющих внешний вид или поведение системы.<br />
<br />
Включает себя<br />
# Воспроизведение особенностей внешнего вида или поведения системы ДО исправления.<br />
# Воспроизведение измененных обновлений особенностей по их описанию.<br />
<br />
Например, если в advisory сказано, что «вышла новая версия программы» при тестировании изменений нужно, как минимум, убедиться что версия изменилась.<br />
<br />
В случае если не все описанные изменения действительно присутствуют в тестируемом пакете, пакет принимается и в итоговый отчет (Advisory), вносятся только реально проведенные изменения.<br />
В случае значительного отклонения запрошенных и полученных изменений пакет может быть отклонен.<br />
<br />
==== Расширенное тестирование ====<br />
# Расширенное тестирование проводится добровольцами с помощью репозиториев testing, соответствующих основным репозиториям. <br />
# В течение недели (понедельник-четверг) все проверяемые QA обновления, кроме срочных, отправляются в тестинг, при этом в багзилле ставится статус verified и пишется The update is sent to expanded testing<br />
# В пятницу, руководитель QA:<br />
## Еще раз контролирует, все ли пакеты направлены в тестинг-репозитории, при помощи отключения источников-контейнеров и выполнения программы '''urpm-reposync''' с включенными тестингами. Результатом выполнения команды должно быть отсутствие пакетов на синхронизацию<br />
## Проверяет, дошли ли обновления до зеркал<br />
## Контролирует возможность обновления до тестингов с момента предыдущего релиза платформы путем установки релизного образа и его обновления с подключенными тестингами <br />
## Обновляет до тестингов системы на всех доступных тестовых стендах и проверяет их на устойчивость<br />
## На форуме и в сообществе вконтакте объявляет "пятничное тестирование", к нему выпускает бюллетень с полным списком обновлений и методикой их тестирования.<br />
# В понедельник руководитель QA читает отзывы пользователей и по их итогам, а также по итогам эксплуатации тестовых стендов в выходные дни, обрабатывает запросы на обновление и передает их на публикацию (или отклоняет)<br />
<br />
=== Завершение тестирования ===<br />
<br />
==== Положительный результат тестирования ====<br />
# По окончании тестирования при его успехе ставится индикатор успешного тестирования QA «+» и пишется отчет (Advisory), содержащий:<br />
## Название пакета с исходниками (src.rpm).<br />
## Версию пакета.<br />
## Отчет о тестировании (advisory).<br />
## Надпись «QA verified».<br />
# Если пакет содержит изменения, связанные с секретностью или же собран не сотрудником Росы — посылается запрос Secure team (взводится флажок secteam_verified «?»).<br />
# Если тестирование secure не нужно, пакет передается на публикацию (взводится соответствующий published «?»).<br />
# В случае успешного тестирования пакет может быть оставлен в системе. В случае ошибок систему нужно привести к первоначальному виду с помощью деинсталляции пакета или утилиты <tt>urpm-reposync</tt> из <tt>urpm-repotools</tt>.<br />
<br />
==== Отрицательный результат тестирования ====<br />
# При отклонении пакета ставится индикатор отклонения QA «-»,<br />
# В комментариях пишется причина отклонения запроса и в конце комментария добавляется «QA Denied».<br />
# При отрицательном результате тестирования сборщик может выложить исправленные контейнеры в тот же запрос и снова установить «?» в «qa_requested».</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F&diff=18622
Регламент тестирования
2020-04-29T09:07:49Z
<p>Vladimir.potapov: /* Срок тестирования */</p>
<hr />
<div>[[Category:Регламенты ROSA]]<br />
<br />
=== Политика ===<br />
QA отвечает за стабильность установленного у пользователей дистрибутива при его обновлениях.<br />
<br />
До установки обновлений дистрибутив работает. Любое обновление — риск его обрушить.<br />
Поэтому политика QA обязана быть консервативной и даже несколько параноидальной — при малейших сомнениях должны назначаться дополнительные проверки, пакеты должны отклоняться, направляться на пересборку.<br />
<br />
Политика QA вступает в конфликт с интересами сборщиков пакетов, желающих быстрее увидеть в репозиториях исправленную версию — конфликт этот должен быть конструктивным, приводящим к непрерывному повышению функциональности и стабильности дистрибутива.<br />
<br />
==== Классификация обновлений по степени опасности ====<br />
<blockquote><br />
Меня не интересуют их намерения, меня интересуют их возможности — © Отто Фон Бисмарк<br />
</blockquote><br />
<br />
Классификация исходит из максимально возможного урона (полный отказ функционирования компонента), который может нанести устанавливаемое обновление.<br />
<br />
;0: Критические обновления. Ядро, файловая система, система прав доступа, скрипты загрузки, <tt>systemd</tt>, <tt>glibc</tt>, <tt>dracut</tt>, <tt>grub</tt>, <tt>bash</tt> и прочие основные вещи, если удалить которые система не загрузится даже в консоли.<br />
;1: Обновления драйверов устройств, т.е. те же критические обновления, но актуальные не для всех пользователей. <br />
;2: Обновления сетевых компонентов: NetworkManager, сетевых скриптов, системы сетевой инициализации и системы обновлений (curl, urpmi). Они опасны тем, что если сеть упадет, пользователю без сети будет затруднительно получить исправленный пакет, когда мы его выпустим и установить обновление. <br />
;3: Обновления графических компонент и скриптов — X-ов, менеджера входа, графических библиотек, драйверов, '''perl, python''' — то, без чего невозможен вход в систему в графическом режиме. Т.к. обновление системы, при наличии сети, возможно и не в графике - класс опасности обновлений не самый высокий<br />
;4: Обновление пользовательских пакетов, установленных по-умолчанию в системе. Эти пакеты стоят практически у всех и их ошибки будут влиять на максимальное количество пользователей, однако они могут быть оперативно исправлены потому класс опасности не очень высокий. Туда же нужно отнести популярные программы не входящие в поставку — <tt>gimp</tt>, <tt>inkscape</tt>, <tt>audacity</tt>, <tt>vlc</tt>, <tt>kdenive</tt>, <tt>opera</tt>, <tt>chromium-browser</tt>, <tt>skype</tt>.<br />
;5: Обновление прочих пользовательских пакетов. Они затронут только тех, у кого эти программы стоят.<br />
;6: Обновление пакетов, необходимых только для сборки дистрибутива или работы с abf. Почти никому кроме нас они не интересны, потому класс опасности самый низкий.<br />
<br />
==== Задача ====<br />
* Главная задача QA — поиск регрессий, то есть таких изменений в дистрибутиве, которые уменьшают его функциональность по сравнению с предыдущим состоянием.<br />
* Также задачей QA является внесение в багзиллу всех ошибок, найденных в процессе тестирования и не относящихся к регрессиям.<br />
<br />
==== Общие положения ====<br />
* Запрос на обновление пишется в багзилле <br />
* Все сообщения пишутся на английском языке.<br />
* Порядок принятие запросов на тестирование командой QA в общем случае — в порядке возрастания номеров багов, возможны исключения, связанные со срочностью или трудностями в тестировании определенных пакетов.<br />
* Список запросов на обновление можно открыть по ссылке http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=qa_verified%3F&o1=substring&list_id=38774<br />
<br />
==== Срок тестирования ====<br />
* Срок тестирования пакета — '''одна неделя''', за это время служба QA должня проверить пакет и вынести заключение. Срок тестирования может быть увеличен при необходимости тестирования внешними тестерами на отсутствующих у службы QA аппаратно-программных конфигурациях, в этом случае в запросе на обновление задержка должна быть обоснована службой QA.<br />
* Для пакета, который нужно проверить очень срочно, сборщик должен установить приоритет <tt>Highest Critical</tt>, чтобы он выделялся красным цветом в списке. Такие пакеты рассматриваются в течение '''48 часов''' рабочего времени.<br />
* Норма выработки на одного тестера QA - 20 одобренных запросов в неделю, обычно отклоняется 10-20% запросов, так что тестер QA в среднем обрабатывает 5 запросов в день.<br />
<br />
=== Процедура тестирования ===<br />
<br />
==== Требования к запросу на обновление ====<br />
# QA Team тестирует пакеты-кандидаты на добавление в репозитории <tt>main/updates, non-free/updates и restricted/updates</tt>.<br />
# Пакет должен быть собран в общедоступном репозитории (не <tt>_personal</tt>).<br />
# Для архитектурно-зависимых пакетов должны быть представлены все поддерживаемые архитектуры (<tt>i586</tt> и <tt>x64</tt>).<br />
# Описание обновления должно содержать все изменения, которые нужно протестировать.<br />
При несоответствии запроса на обновление этим требованиям запрос отклоняется.<br />
<br />
==== Тестирование установки пакетов ====<br />
# Система перед тестовым обновлением должна соответствовать стандартным репозиториям. Это можно проверить запуском <tt>urpm-reposync</tt> из пакета <tt>urpm-tools</tt><br />
# Пакеты для тестирования устанавливаются и в графическом, и в текстовом режиме.<br />
## Репозиторий подключается как репозиторий с обновлениями.<br />
## Из графического режима запускается стандартная процедура обновления.<br />
# Для пакетов, установленных в системе по-умолчанию, проверяется их обновление.<br />
# Для пакетов, не установленных в системе, проверяется как их обновление, так и первоначальная установка при подключенных тестовых контейнерах.<br />
# Установка пакетов проверяется для обеих архитектур. Так как ошибки установки не обычно не зависят от архитектуры, обычно достаточно проверить на одной архитектуре установку в графическом режиме, а на другой — обновление в текстовом, или наоборот.<br />
<br />
При ошибке установки запрос на тестирование отклоняется.<br />
<br />
==== Тестирование на устойчивость системы ====<br />
* Применяется при пересборках библиотек или пакетов без внесения изменений, или для изменений связанных с безопасностью.<br />
* Для экономии времени может выполняться для окончательного тестирования последовательности обновлений перед публикацией их в репозитории<br />
<br />
При тестировании системы на устойчивость проверяется<br />
# Стабильность и внешний вид обновленной системы после перезагрузки.<br />
# Стабильность и внешний вид обновленной системы после пробуждения из спящего режима. Тестирование стабильности и производительности может проводиться, например, с помощью теста Unigine Valley под wine и тестом браузера https://webglsamples.org/aquarium/aquarium.html<br />
# Ошибки загрузки демонов, например, с помощью <tt>systemctl | grep failed</tt>.<br />
# Ошибки непрерывного роста файла <tt>.xsession-errors</tt>.<br />
# Работа URPMI — дальнейшее обновление пакетов.<br />
# Установка и удаление dkms-модулей.<br />
# Сохранение даты-времени на тестируемой машине после перезагрузки и пробуждения из спящего режима.<br />
<br />
==== Тестирование запуска и работы связанных с обновлением приложений ====<br />
Проверяются:<br />
# Тестирование запуска и простейших операций со связанными с тестируемым пакетом программами, рекомендуется контроль сообщений при запуске программы из консоли.<br />
# Связанные с библиотеками из проверяемого пакета программы легче всего установить, попробовав удалить пакет с помощью <tt>urpme</tt> (для установленных в системе программ) или <tt>urpmq --whatrequires</tt> (для всех программ из подключенных репозиториев).<br />
# Изменения в интерфейсах обновляемых библиотек и, соответственно, необходимость перекомпиляции связанных пакетов с помощью сервиса https://abi-laboratory.pro/tracker/<br />
# Для пакетов, предоставляющих библиотеки, проверяются использующие эти библиотеки приложения из main, их можно определить командой <tt>urpmq --whatrequires <названиепакета></tt><br />
# Регрессии в локализации графического интерфейса и страниц справки.<br />
# Для тестирования браузеров в дополнение к https://webglsamples.org/aquarium/aquarium.html применяются.<br />
## Тест html5 https://html5test.com/ (сравнить результат до и после обновления, не должно быть регресса)<br />
## Почтовые онлайновые сервисы http://mail.yandex.ru http://mail.google.com<br />
## Яндекс и гугл-карты https://yandex.ru/maps/-/CVTQITy0 https://www.google.ru/maps/@52.2609339,104.3096872,15z?hl=ru<br />
## xml|xsl трансляцию и кодировки на http://base.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=160129;div=LAW;rnd=0.4700782325977544 и<br />
## Воспроизведение видео http://techslides.com/sample-webm-ogg-and-mp4-video-files-for-html5/ <br />
## Воспроизведение [http://youtu.be/37l7P5V1eXU видео с youtube]<br />
## Работа флэша на примере игры [http://vseigru.net/igry-zombi/2541-igra-zombi-protiv-rastenij.html Растения против зомби] и [http://kino.sputnik.ru/films/ivan+vasilyevich+menyayet+professiyu+1973]<br />
## Работу java с помощью <tt>icedtea-web</tt> и демок пакета <tt>java-1.8-openjdk-demo</tt><br />
## Уязвимости SSL с помощью https://www.ssllabs.com/ssltest/viewMyClient.html<br />
## Тестирование печати<br />
## Тестирование установки браузера по-умолчанию из настроек<br />
<br />
При найденных на этапе тестирования устройчивости системы или запуска и работы пакета регрессиях запрос на тестирование отклоняется.<br />
<br />
==== Тестирование изменений ====<br />
* Применяется при тестировании обновлений, изменяющих внешний вид или поведение системы.<br />
<br />
Включает себя<br />
# Воспроизведение особенностей внешнего вида или поведения системы ДО исправления.<br />
# Воспроизведение измененных обновлений особенностей по их описанию.<br />
<br />
Например, если в advisory сказано, что «вышла новая версия программы» при тестировании изменений нужно, как минимум, убедиться что версия изменилась.<br />
<br />
В случае если не все описанные изменения действительно присутствуют в тестируемом пакете, пакет принимается и в итоговый отчет (Advisory), вносятся только реально проведенные изменения.<br />
В случае значительного отклонения запрошенных и полученных изменений пакет может быть отклонен.<br />
<br />
==== Расширенное тестирование ====<br />
# Расширенное тестирование проводится добровольцами с помощью репозиториев testing, соответствующих основным репозиториям. <br />
# В течение недели (понедельник-четверг) все проверяемые QA обновления, кроме срочных, отправляются в тестинг, при этом в багзилле ставится статус verified и пишется The update is sent to expanded testing<br />
# В пятницу, руководитель QA:<br />
## Еще раз контролирует, все ли пакеты направлены в тестинг-репозитории, при помощи отключения источников-контейнеров и выполнения программы '''urpm-reposync''' с включенными тестингами. Результатом выполнения команды должно быть отсутствие пакетов на синхронизацию<br />
## Проверяет, дошли ли обновления до зеркал<br />
## Контролирует возможность обновления до тестингов с момента предыдущего релиза платформы путем установки релизного образа и его обновления с подключенными тестингами <br />
## Обновляет до тестингов системы на всех доступных тестовых стендах и проверяет их на устойчивость<br />
## На форуме и в сообществе вконтакте объявляет "пятничное тестирование", к нему выпускает бюллетень с полным списком обновлений и методикой их тестирования.<br />
# В понедельник руководитель QA читает отзывы пользователей и по их итогам, а также по итогам эксплуатации тестовых стендов в выходные дни, обрабатывает запросы на обновление и передает их на публикацию (или отклоняет)<br />
<br />
=== Завершение тестирования ===<br />
<br />
==== Положительный результат тестирования ====<br />
# По окончании тестирования при его успехе ставится индикатор успешного тестирования QA «+» и пишется отчет (Advisory), содержащий:<br />
## Название пакета с исходниками (src.rpm).<br />
## Версию пакета.<br />
## Отчет о тестировании (advisory).<br />
## Надпись «QA verified».<br />
# Если пакет содержит изменения, связанные с секретностью или же собран не сотрудником Росы — посылается запрос Secure team (взводится флажок secteam_verified «?»).<br />
# Если тестирование secure не нужно, пакет передается на публикацию (взводится соответствующий published «?»).<br />
# В случае успешного тестирования пакет может быть оставлен в системе. В случае ошибок систему нужно привести к первоначальному виду с помощью деинсталляции пакета или утилиты <tt>urpm-reposync</tt> из <tt>urpm-repotools</tt>.<br />
<br />
==== Отрицательный результат тестирования ====<br />
# При отклонении пакета ставится индикатор отклонения QA «-»,<br />
# В комментариях пишется причина отклонения запроса и в конце комментария добавляется «QA Denied».<br />
# При отрицательном результате тестирования сборщик может выложить исправленные контейнеры в тот же запрос и снова установить «?» в «qa_requested».</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F&diff=18621
Регламент тестирования
2020-04-29T09:00:35Z
<p>Vladimir.potapov: /* Положительный результат тестирования */</p>
<hr />
<div>[[Category:Регламенты ROSA]]<br />
<br />
=== Политика ===<br />
QA отвечает за стабильность установленного у пользователей дистрибутива при его обновлениях.<br />
<br />
До установки обновлений дистрибутив работает. Любое обновление — риск его обрушить.<br />
Поэтому политика QA обязана быть консервативной и даже несколько параноидальной — при малейших сомнениях должны назначаться дополнительные проверки, пакеты должны отклоняться, направляться на пересборку.<br />
<br />
Политика QA вступает в конфликт с интересами сборщиков пакетов, желающих быстрее увидеть в репозиториях исправленную версию — конфликт этот должен быть конструктивным, приводящим к непрерывному повышению функциональности и стабильности дистрибутива.<br />
<br />
==== Классификация обновлений по степени опасности ====<br />
<blockquote><br />
Меня не интересуют их намерения, меня интересуют их возможности — © Отто Фон Бисмарк<br />
</blockquote><br />
<br />
Классификация исходит из максимально возможного урона (полный отказ функционирования компонента), который может нанести устанавливаемое обновление.<br />
<br />
;0: Критические обновления. Ядро, файловая система, система прав доступа, скрипты загрузки, <tt>systemd</tt>, <tt>glibc</tt>, <tt>dracut</tt>, <tt>grub</tt>, <tt>bash</tt> и прочие основные вещи, если удалить которые система не загрузится даже в консоли.<br />
;1: Обновления драйверов устройств, т.е. те же критические обновления, но актуальные не для всех пользователей. <br />
;2: Обновления сетевых компонентов: NetworkManager, сетевых скриптов, системы сетевой инициализации и системы обновлений (curl, urpmi). Они опасны тем, что если сеть упадет, пользователю без сети будет затруднительно получить исправленный пакет, когда мы его выпустим и установить обновление. <br />
;3: Обновления графических компонент и скриптов — X-ов, менеджера входа, графических библиотек, драйверов, '''perl, python''' — то, без чего невозможен вход в систему в графическом режиме. Т.к. обновление системы, при наличии сети, возможно и не в графике - класс опасности обновлений не самый высокий<br />
;4: Обновление пользовательских пакетов, установленных по-умолчанию в системе. Эти пакеты стоят практически у всех и их ошибки будут влиять на максимальное количество пользователей, однако они могут быть оперативно исправлены потому класс опасности не очень высокий. Туда же нужно отнести популярные программы не входящие в поставку — <tt>gimp</tt>, <tt>inkscape</tt>, <tt>audacity</tt>, <tt>vlc</tt>, <tt>kdenive</tt>, <tt>opera</tt>, <tt>chromium-browser</tt>, <tt>skype</tt>.<br />
;5: Обновление прочих пользовательских пакетов. Они затронут только тех, у кого эти программы стоят.<br />
;6: Обновление пакетов, необходимых только для сборки дистрибутива или работы с abf. Почти никому кроме нас они не интересны, потому класс опасности самый низкий.<br />
<br />
==== Задача ====<br />
* Главная задача QA — поиск регрессий, то есть таких изменений в дистрибутиве, которые уменьшают его функциональность по сравнению с предыдущим состоянием.<br />
* Также задачей QA является внесение в багзиллу всех ошибок, найденных в процессе тестирования и не относящихся к регрессиям.<br />
<br />
==== Общие положения ====<br />
* Запрос на обновление пишется в багзилле <br />
* Все сообщения пишутся на английском языке.<br />
* Порядок принятие запросов на тестирование командой QA в общем случае — в порядке возрастания номеров багов, возможны исключения, связанные со срочностью или трудностями в тестировании определенных пакетов.<br />
* Список запросов на обновление можно открыть по ссылке http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=qa_verified%3F&o1=substring&list_id=38774<br />
<br />
==== Срок тестирования ====<br />
* Срок тестирования пакета — '''одна неделя''', для сложных пакетов, отправляемых на дополнительное тестирование, срок тестирования зависит от срока дополнительного тестирования.<br />
* Для пакета, который нужно проверить очень срочно, сборщик должен установить приоритет <tt>Highest Critical</tt>, чтобы он выделялся красным цветом в списке. Такие пакеты рассматриваются в течение '''48 часов'''.<br />
<br />
=== Процедура тестирования ===<br />
<br />
==== Требования к запросу на обновление ====<br />
# QA Team тестирует пакеты-кандидаты на добавление в репозитории <tt>main/updates, non-free/updates и restricted/updates</tt>.<br />
# Пакет должен быть собран в общедоступном репозитории (не <tt>_personal</tt>).<br />
# Для архитектурно-зависимых пакетов должны быть представлены все поддерживаемые архитектуры (<tt>i586</tt> и <tt>x64</tt>).<br />
# Описание обновления должно содержать все изменения, которые нужно протестировать.<br />
При несоответствии запроса на обновление этим требованиям запрос отклоняется.<br />
<br />
==== Тестирование установки пакетов ====<br />
# Система перед тестовым обновлением должна соответствовать стандартным репозиториям. Это можно проверить запуском <tt>urpm-reposync</tt> из пакета <tt>urpm-tools</tt><br />
# Пакеты для тестирования устанавливаются и в графическом, и в текстовом режиме.<br />
## Репозиторий подключается как репозиторий с обновлениями.<br />
## Из графического режима запускается стандартная процедура обновления.<br />
# Для пакетов, установленных в системе по-умолчанию, проверяется их обновление.<br />
# Для пакетов, не установленных в системе, проверяется как их обновление, так и первоначальная установка при подключенных тестовых контейнерах.<br />
# Установка пакетов проверяется для обеих архитектур. Так как ошибки установки не обычно не зависят от архитектуры, обычно достаточно проверить на одной архитектуре установку в графическом режиме, а на другой — обновление в текстовом, или наоборот.<br />
<br />
При ошибке установки запрос на тестирование отклоняется.<br />
<br />
==== Тестирование на устойчивость системы ====<br />
* Применяется при пересборках библиотек или пакетов без внесения изменений, или для изменений связанных с безопасностью.<br />
* Для экономии времени может выполняться для окончательного тестирования последовательности обновлений перед публикацией их в репозитории<br />
<br />
При тестировании системы на устойчивость проверяется<br />
# Стабильность и внешний вид обновленной системы после перезагрузки.<br />
# Стабильность и внешний вид обновленной системы после пробуждения из спящего режима. Тестирование стабильности и производительности может проводиться, например, с помощью теста Unigine Valley под wine и тестом браузера https://webglsamples.org/aquarium/aquarium.html<br />
# Ошибки загрузки демонов, например, с помощью <tt>systemctl | grep failed</tt>.<br />
# Ошибки непрерывного роста файла <tt>.xsession-errors</tt>.<br />
# Работа URPMI — дальнейшее обновление пакетов.<br />
# Установка и удаление dkms-модулей.<br />
# Сохранение даты-времени на тестируемой машине после перезагрузки и пробуждения из спящего режима.<br />
<br />
==== Тестирование запуска и работы связанных с обновлением приложений ====<br />
Проверяются:<br />
# Тестирование запуска и простейших операций со связанными с тестируемым пакетом программами, рекомендуется контроль сообщений при запуске программы из консоли.<br />
# Связанные с библиотеками из проверяемого пакета программы легче всего установить, попробовав удалить пакет с помощью <tt>urpme</tt> (для установленных в системе программ) или <tt>urpmq --whatrequires</tt> (для всех программ из подключенных репозиториев).<br />
# Изменения в интерфейсах обновляемых библиотек и, соответственно, необходимость перекомпиляции связанных пакетов с помощью сервиса https://abi-laboratory.pro/tracker/<br />
# Для пакетов, предоставляющих библиотеки, проверяются использующие эти библиотеки приложения из main, их можно определить командой <tt>urpmq --whatrequires <названиепакета></tt><br />
# Регрессии в локализации графического интерфейса и страниц справки.<br />
# Для тестирования браузеров в дополнение к https://webglsamples.org/aquarium/aquarium.html применяются.<br />
## Тест html5 https://html5test.com/ (сравнить результат до и после обновления, не должно быть регресса)<br />
## Почтовые онлайновые сервисы http://mail.yandex.ru http://mail.google.com<br />
## Яндекс и гугл-карты https://yandex.ru/maps/-/CVTQITy0 https://www.google.ru/maps/@52.2609339,104.3096872,15z?hl=ru<br />
## xml|xsl трансляцию и кодировки на http://base.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=160129;div=LAW;rnd=0.4700782325977544 и<br />
## Воспроизведение видео http://techslides.com/sample-webm-ogg-and-mp4-video-files-for-html5/ <br />
## Воспроизведение [http://youtu.be/37l7P5V1eXU видео с youtube]<br />
## Работа флэша на примере игры [http://vseigru.net/igry-zombi/2541-igra-zombi-protiv-rastenij.html Растения против зомби] и [http://kino.sputnik.ru/films/ivan+vasilyevich+menyayet+professiyu+1973]<br />
## Работу java с помощью <tt>icedtea-web</tt> и демок пакета <tt>java-1.8-openjdk-demo</tt><br />
## Уязвимости SSL с помощью https://www.ssllabs.com/ssltest/viewMyClient.html<br />
## Тестирование печати<br />
## Тестирование установки браузера по-умолчанию из настроек<br />
<br />
При найденных на этапе тестирования устройчивости системы или запуска и работы пакета регрессиях запрос на тестирование отклоняется.<br />
<br />
==== Тестирование изменений ====<br />
* Применяется при тестировании обновлений, изменяющих внешний вид или поведение системы.<br />
<br />
Включает себя<br />
# Воспроизведение особенностей внешнего вида или поведения системы ДО исправления.<br />
# Воспроизведение измененных обновлений особенностей по их описанию.<br />
<br />
Например, если в advisory сказано, что «вышла новая версия программы» при тестировании изменений нужно, как минимум, убедиться что версия изменилась.<br />
<br />
В случае если не все описанные изменения действительно присутствуют в тестируемом пакете, пакет принимается и в итоговый отчет (Advisory), вносятся только реально проведенные изменения.<br />
В случае значительного отклонения запрошенных и полученных изменений пакет может быть отклонен.<br />
<br />
==== Расширенное тестирование ====<br />
# Расширенное тестирование проводится добровольцами с помощью репозиториев testing, соответствующих основным репозиториям. <br />
# В течение недели (понедельник-четверг) все проверяемые QA обновления, кроме срочных, отправляются в тестинг, при этом в багзилле ставится статус verified и пишется The update is sent to expanded testing<br />
# В пятницу, руководитель QA:<br />
## Еще раз контролирует, все ли пакеты направлены в тестинг-репозитории, при помощи отключения источников-контейнеров и выполнения программы '''urpm-reposync''' с включенными тестингами. Результатом выполнения команды должно быть отсутствие пакетов на синхронизацию<br />
## Проверяет, дошли ли обновления до зеркал<br />
## Контролирует возможность обновления до тестингов с момента предыдущего релиза платформы путем установки релизного образа и его обновления с подключенными тестингами <br />
## Обновляет до тестингов системы на всех доступных тестовых стендах и проверяет их на устойчивость<br />
## На форуме и в сообществе вконтакте объявляет "пятничное тестирование", к нему выпускает бюллетень с полным списком обновлений и методикой их тестирования.<br />
# В понедельник руководитель QA читает отзывы пользователей и по их итогам, а также по итогам эксплуатации тестовых стендов в выходные дни, обрабатывает запросы на обновление и передает их на публикацию (или отклоняет)<br />
<br />
=== Завершение тестирования ===<br />
<br />
==== Положительный результат тестирования ====<br />
# По окончании тестирования при его успехе ставится индикатор успешного тестирования QA «+» и пишется отчет (Advisory), содержащий:<br />
## Название пакета с исходниками (src.rpm).<br />
## Версию пакета.<br />
## Отчет о тестировании (advisory).<br />
## Надпись «QA verified».<br />
# Если пакет содержит изменения, связанные с секретностью или же собран не сотрудником Росы — посылается запрос Secure team (взводится флажок secteam_verified «?»).<br />
# Если тестирование secure не нужно, пакет передается на публикацию (взводится соответствующий published «?»).<br />
# В случае успешного тестирования пакет может быть оставлен в системе. В случае ошибок систему нужно привести к первоначальному виду с помощью деинсталляции пакета или утилиты <tt>urpm-reposync</tt> из <tt>urpm-repotools</tt>.<br />
<br />
==== Отрицательный результат тестирования ====<br />
# При отклонении пакета ставится индикатор отклонения QA «-»,<br />
# В комментариях пишется причина отклонения запроса и в конце комментария добавляется «QA Denied».<br />
# При отрицательном результате тестирования сборщик может выложить исправленные контейнеры в тот же запрос и снова установить «?» в «qa_requested».</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F&diff=18620
Регламент тестирования
2020-04-29T09:00:18Z
<p>Vladimir.potapov: /* Расширенное тестирование */</p>
<hr />
<div>[[Category:Регламенты ROSA]]<br />
<br />
=== Политика ===<br />
QA отвечает за стабильность установленного у пользователей дистрибутива при его обновлениях.<br />
<br />
До установки обновлений дистрибутив работает. Любое обновление — риск его обрушить.<br />
Поэтому политика QA обязана быть консервативной и даже несколько параноидальной — при малейших сомнениях должны назначаться дополнительные проверки, пакеты должны отклоняться, направляться на пересборку.<br />
<br />
Политика QA вступает в конфликт с интересами сборщиков пакетов, желающих быстрее увидеть в репозиториях исправленную версию — конфликт этот должен быть конструктивным, приводящим к непрерывному повышению функциональности и стабильности дистрибутива.<br />
<br />
==== Классификация обновлений по степени опасности ====<br />
<blockquote><br />
Меня не интересуют их намерения, меня интересуют их возможности — © Отто Фон Бисмарк<br />
</blockquote><br />
<br />
Классификация исходит из максимально возможного урона (полный отказ функционирования компонента), который может нанести устанавливаемое обновление.<br />
<br />
;0: Критические обновления. Ядро, файловая система, система прав доступа, скрипты загрузки, <tt>systemd</tt>, <tt>glibc</tt>, <tt>dracut</tt>, <tt>grub</tt>, <tt>bash</tt> и прочие основные вещи, если удалить которые система не загрузится даже в консоли.<br />
;1: Обновления драйверов устройств, т.е. те же критические обновления, но актуальные не для всех пользователей. <br />
;2: Обновления сетевых компонентов: NetworkManager, сетевых скриптов, системы сетевой инициализации и системы обновлений (curl, urpmi). Они опасны тем, что если сеть упадет, пользователю без сети будет затруднительно получить исправленный пакет, когда мы его выпустим и установить обновление. <br />
;3: Обновления графических компонент и скриптов — X-ов, менеджера входа, графических библиотек, драйверов, '''perl, python''' — то, без чего невозможен вход в систему в графическом режиме. Т.к. обновление системы, при наличии сети, возможно и не в графике - класс опасности обновлений не самый высокий<br />
;4: Обновление пользовательских пакетов, установленных по-умолчанию в системе. Эти пакеты стоят практически у всех и их ошибки будут влиять на максимальное количество пользователей, однако они могут быть оперативно исправлены потому класс опасности не очень высокий. Туда же нужно отнести популярные программы не входящие в поставку — <tt>gimp</tt>, <tt>inkscape</tt>, <tt>audacity</tt>, <tt>vlc</tt>, <tt>kdenive</tt>, <tt>opera</tt>, <tt>chromium-browser</tt>, <tt>skype</tt>.<br />
;5: Обновление прочих пользовательских пакетов. Они затронут только тех, у кого эти программы стоят.<br />
;6: Обновление пакетов, необходимых только для сборки дистрибутива или работы с abf. Почти никому кроме нас они не интересны, потому класс опасности самый низкий.<br />
<br />
==== Задача ====<br />
* Главная задача QA — поиск регрессий, то есть таких изменений в дистрибутиве, которые уменьшают его функциональность по сравнению с предыдущим состоянием.<br />
* Также задачей QA является внесение в багзиллу всех ошибок, найденных в процессе тестирования и не относящихся к регрессиям.<br />
<br />
==== Общие положения ====<br />
* Запрос на обновление пишется в багзилле <br />
* Все сообщения пишутся на английском языке.<br />
* Порядок принятие запросов на тестирование командой QA в общем случае — в порядке возрастания номеров багов, возможны исключения, связанные со срочностью или трудностями в тестировании определенных пакетов.<br />
* Список запросов на обновление можно открыть по ссылке http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=qa_verified%3F&o1=substring&list_id=38774<br />
<br />
==== Срок тестирования ====<br />
* Срок тестирования пакета — '''одна неделя''', для сложных пакетов, отправляемых на дополнительное тестирование, срок тестирования зависит от срока дополнительного тестирования.<br />
* Для пакета, который нужно проверить очень срочно, сборщик должен установить приоритет <tt>Highest Critical</tt>, чтобы он выделялся красным цветом в списке. Такие пакеты рассматриваются в течение '''48 часов'''.<br />
<br />
=== Процедура тестирования ===<br />
<br />
==== Требования к запросу на обновление ====<br />
# QA Team тестирует пакеты-кандидаты на добавление в репозитории <tt>main/updates, non-free/updates и restricted/updates</tt>.<br />
# Пакет должен быть собран в общедоступном репозитории (не <tt>_personal</tt>).<br />
# Для архитектурно-зависимых пакетов должны быть представлены все поддерживаемые архитектуры (<tt>i586</tt> и <tt>x64</tt>).<br />
# Описание обновления должно содержать все изменения, которые нужно протестировать.<br />
При несоответствии запроса на обновление этим требованиям запрос отклоняется.<br />
<br />
==== Тестирование установки пакетов ====<br />
# Система перед тестовым обновлением должна соответствовать стандартным репозиториям. Это можно проверить запуском <tt>urpm-reposync</tt> из пакета <tt>urpm-tools</tt><br />
# Пакеты для тестирования устанавливаются и в графическом, и в текстовом режиме.<br />
## Репозиторий подключается как репозиторий с обновлениями.<br />
## Из графического режима запускается стандартная процедура обновления.<br />
# Для пакетов, установленных в системе по-умолчанию, проверяется их обновление.<br />
# Для пакетов, не установленных в системе, проверяется как их обновление, так и первоначальная установка при подключенных тестовых контейнерах.<br />
# Установка пакетов проверяется для обеих архитектур. Так как ошибки установки не обычно не зависят от архитектуры, обычно достаточно проверить на одной архитектуре установку в графическом режиме, а на другой — обновление в текстовом, или наоборот.<br />
<br />
При ошибке установки запрос на тестирование отклоняется.<br />
<br />
==== Тестирование на устойчивость системы ====<br />
* Применяется при пересборках библиотек или пакетов без внесения изменений, или для изменений связанных с безопасностью.<br />
* Для экономии времени может выполняться для окончательного тестирования последовательности обновлений перед публикацией их в репозитории<br />
<br />
При тестировании системы на устойчивость проверяется<br />
# Стабильность и внешний вид обновленной системы после перезагрузки.<br />
# Стабильность и внешний вид обновленной системы после пробуждения из спящего режима. Тестирование стабильности и производительности может проводиться, например, с помощью теста Unigine Valley под wine и тестом браузера https://webglsamples.org/aquarium/aquarium.html<br />
# Ошибки загрузки демонов, например, с помощью <tt>systemctl | grep failed</tt>.<br />
# Ошибки непрерывного роста файла <tt>.xsession-errors</tt>.<br />
# Работа URPMI — дальнейшее обновление пакетов.<br />
# Установка и удаление dkms-модулей.<br />
# Сохранение даты-времени на тестируемой машине после перезагрузки и пробуждения из спящего режима.<br />
<br />
==== Тестирование запуска и работы связанных с обновлением приложений ====<br />
Проверяются:<br />
# Тестирование запуска и простейших операций со связанными с тестируемым пакетом программами, рекомендуется контроль сообщений при запуске программы из консоли.<br />
# Связанные с библиотеками из проверяемого пакета программы легче всего установить, попробовав удалить пакет с помощью <tt>urpme</tt> (для установленных в системе программ) или <tt>urpmq --whatrequires</tt> (для всех программ из подключенных репозиториев).<br />
# Изменения в интерфейсах обновляемых библиотек и, соответственно, необходимость перекомпиляции связанных пакетов с помощью сервиса https://abi-laboratory.pro/tracker/<br />
# Для пакетов, предоставляющих библиотеки, проверяются использующие эти библиотеки приложения из main, их можно определить командой <tt>urpmq --whatrequires <названиепакета></tt><br />
# Регрессии в локализации графического интерфейса и страниц справки.<br />
# Для тестирования браузеров в дополнение к https://webglsamples.org/aquarium/aquarium.html применяются.<br />
## Тест html5 https://html5test.com/ (сравнить результат до и после обновления, не должно быть регресса)<br />
## Почтовые онлайновые сервисы http://mail.yandex.ru http://mail.google.com<br />
## Яндекс и гугл-карты https://yandex.ru/maps/-/CVTQITy0 https://www.google.ru/maps/@52.2609339,104.3096872,15z?hl=ru<br />
## xml|xsl трансляцию и кодировки на http://base.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=160129;div=LAW;rnd=0.4700782325977544 и<br />
## Воспроизведение видео http://techslides.com/sample-webm-ogg-and-mp4-video-files-for-html5/ <br />
## Воспроизведение [http://youtu.be/37l7P5V1eXU видео с youtube]<br />
## Работа флэша на примере игры [http://vseigru.net/igry-zombi/2541-igra-zombi-protiv-rastenij.html Растения против зомби] и [http://kino.sputnik.ru/films/ivan+vasilyevich+menyayet+professiyu+1973]<br />
## Работу java с помощью <tt>icedtea-web</tt> и демок пакета <tt>java-1.8-openjdk-demo</tt><br />
## Уязвимости SSL с помощью https://www.ssllabs.com/ssltest/viewMyClient.html<br />
## Тестирование печати<br />
## Тестирование установки браузера по-умолчанию из настроек<br />
<br />
При найденных на этапе тестирования устройчивости системы или запуска и работы пакета регрессиях запрос на тестирование отклоняется.<br />
<br />
==== Тестирование изменений ====<br />
* Применяется при тестировании обновлений, изменяющих внешний вид или поведение системы.<br />
<br />
Включает себя<br />
# Воспроизведение особенностей внешнего вида или поведения системы ДО исправления.<br />
# Воспроизведение измененных обновлений особенностей по их описанию.<br />
<br />
Например, если в advisory сказано, что «вышла новая версия программы» при тестировании изменений нужно, как минимум, убедиться что версия изменилась.<br />
<br />
В случае если не все описанные изменения действительно присутствуют в тестируемом пакете, пакет принимается и в итоговый отчет (Advisory), вносятся только реально проведенные изменения.<br />
В случае значительного отклонения запрошенных и полученных изменений пакет может быть отклонен.<br />
<br />
==== Расширенное тестирование ====<br />
# Расширенное тестирование проводится добровольцами с помощью репозиториев testing, соответствующих основным репозиториям. <br />
# В течение недели (понедельник-четверг) все проверяемые QA обновления, кроме срочных, отправляются в тестинг, при этом в багзилле ставится статус verified и пишется The update is sent to expanded testing<br />
# В пятницу, руководитель QA:<br />
## Еще раз контролирует, все ли пакеты направлены в тестинг-репозитории, при помощи отключения источников-контейнеров и выполнения программы '''urpm-reposync''' с включенными тестингами. Результатом выполнения команды должно быть отсутствие пакетов на синхронизацию<br />
## Проверяет, дошли ли обновления до зеркал<br />
## Контролирует возможность обновления до тестингов с момента предыдущего релиза платформы путем установки релизного образа и его обновления с подключенными тестингами <br />
## Обновляет до тестингов системы на всех доступных тестовых стендах и проверяет их на устойчивость<br />
## На форуме и в сообществе вконтакте объявляет "пятничное тестирование", к нему выпускает бюллетень с полным списком обновлений и методикой их тестирования.<br />
# В понедельник руководитель QA читает отзывы пользователей и по их итогам, а также по итогам эксплуатации тестовых стендов в выходные дни, обрабатывает запросы на обновление и передает их на публикацию (или отклоняет)<br />
<br />
=== Завершение тестирования ===<br />
<br />
==== Положительный результат тестирования ====<br />
# По окончании теситрования при его успехе ставится индикатор успешного тестирования QA «+» и пишется отчет (Advisory), содержащий:<br />
## Название пакета с исходниками (src.rpm).<br />
## Версию пакета.<br />
## Отчет о тестировании (advisory).<br />
## Надпись «QA verified».<br />
# Если пакет содержит изменения, связанные с секретностью или же собран не сотрудником Росы — посылается запрос Secure team (взводится флажок secteam_verified «?»).<br />
# Если тестирование secure не нужно, пакет передается на публикацию (взводится соответствующий published «?»).<br />
# В случае успешного тестирования пакет может быть оставлен в системе. В случае ошибок систему нужно привести к первоначальному виду с помощью деинсталляции пакета или утилиты <tt>urpm-reposync</tt> из <tt>urpm-repotools</tt>.<br />
<br />
==== Отрицательный результат тестирования ====<br />
# При отклонении пакета ставится индикатор отклонения QA «-»,<br />
# В комментариях пишется причина отклонения запроса и в конце комментария добавляется «QA Denied».<br />
# При отрицательном результате тестирования сборщик может выложить исправленные контейнеры в тот же запрос и снова установить «?» в «qa_requested».</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_%D0%B2_%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%BD%D1%8B%D1%85_%D1%80%D0%B5%D0%BF%D0%BE%D0%B7%D0%B8%D1%82%D0%BE%D1%80%D0%B8%D1%8F%D1%85_ROSA_Linux&diff=18619
Регламент обновления пакетов в основных репозиториях ROSA Linux
2020-04-29T08:47:41Z
<p>Vladimir.potapov: /* Применимость */</p>
<hr />
<div>=== Применимость ===<br />
Настоящий регламент описывает порядок добавления и исправления пакетов в дистрибутивах ROSA Linux Fresh при взаимодействии пяти команд:<br />
# Команды репортеров, сообщающих об ошибках и уязвимостях в пакетной базе и выступающих с предложениями обновления пакетов<br />
# Команды сборщиков (мейнтейнеров), собирающих пакеты с новыми версиями программ и исправлениями ошибок и уязвимостей<br />
# Команды контроля качества (QA), контролирующих работоспособность исправленных пакетов и всей системы в целом после обновления<br />
# Команда контроля уязвимостей (SecTeam), отслеживающих текущие уязвимости дистрибутива и корректность исправления этих уязвимостей сборщиками<br />
# Публикатора, задачи которого - доступность исправленных пакетов на зеркалах дистрибутива, контроль целостности/замкнутости репозиториев после публикации, а также качества сборки самих пакетов (соответствие политикам сборки, принятым в дистрибутиве и т.п.)<br />
<br />
Данный порядок относится к работе с основными репозиториями ROSA Linux, за исключением репозитория сообщества ROSA Fresh (contrib) где контроль качества не производится.<br />
<br />
=== Общий порядок обновления ===<br />
# Общий порядок адресации каждого запроса на обновление - <br />
Репортеры (в т.ч. из SecTeam) -> Cборщики -> QA & SecTeam -> Публикатор<br />
# Допустимо совмещение ролей "репортер", "сборщик" и "публикатор", но недопустима ситуация, когда человек проверяет результаты своей сборки и публикует их. <br />
# Репортер-сборщик, отслеживающий обновления необходимого ему пакета и самостоятельно собирающий его, называется сопровождающим (мейнтейнером) и прописывается на abf.<br />
# Вся работа по обновлению пакетов происходит с помощью специально созданных в багзилле ROSA Linux багов - запросов на обновление<br />
<br />
=== Репортеры ===<br />
# Репортеры заводят в багзилле баги, обосновывающие необходимость исправления или добавления, с описанием ошибки, кодом уязвимости или необходимым им новым функционалом.<br />
# Альтернативным путем создания запроса на изменение пакетов в репозиториях для репортеров является пул-реквест в системе сборки ABF.<br />
# Репортеры являются заказчиками исправления, т.е. контролируют весь его процесс до попадания в репозитории.<br />
<br />
=== Сборщики ===<br />
# Сборщики получают информацию о багах от репортеров через почтовую рассылку багзиллы<br />
# Пакеты обновляются на основании заведенного в [http://bugs.rosalinux.ru багзилле] бага с заголовком [UPDATE REQUEST <платформа>] называемого запросом на обновление<br />
# В комментариях к запросу на обновления указываются ссылки на контейнеры с собранным для указанной платформы обновлением пакета и advisory - написанное по-английски обоснование обновления (например выход новой версии, исправление уязвимости)<br />
# После того, как закончено формирование запроса на обновление, он отправляется на контроль качества команде QA установкой флажка qa_verified в знак вопроса "?"<br />
<br />
=== Команда контроля качества (QA) ===<br />
# Команда QA получает запросы с установленным сборщиками флажком qa_verified<br />
# Команда QA проводит тестирование пакетов, используя [[Регламент тестирования]]<br />
# Если обновление содержит исправления уязвимостей, устанавливается флажок sectime_verified в "?" для параллельной проверки корректности исправления уязвимостей командой SecTeam<br />
# После проверки отсутствия регрессий функциональности у собранного пакета команда QA ставит флаг QA_verified "+" при успешной проверке и "-" при неуспешной.<br />
# При отсутствии регрессий и, при необходимости, после получения одобрения запроса от команды SecTeam (флажок sectime_verified меняется на "+") запрос отправляется на публикацию установкой флажка publishied в "?"<br />
# QA каждую пятницу публикует бюллетень с перечнем исправленных багов за истекшую неделю<br />
<br />
=== Команда поиска и устранения уязвимостей (SecTeam) ===<br />
# Подробности поиска уязвимостей описаны в документе [[Регламент по устранению уязвимостей]]<br />
# Список уязвимостей ведется на странице вики [http://wiki.rosalab.ru/ru/index.php/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:Security_Advisories Список уязвимостей] командой SecTeam.<br />
# Для каждой уязвимости из списка команда SecTeam выступает репортером и заводит баг<br />
# После того, как сборщики соберут исправленные пакеты и QA установить флажок secteam_verified в "?", SecTeam проверяет исправление уязвимости<br />
# Дополнительно могут проверяться и запросы с исправлениями уязвимостей, сделанные и не участниками команды SecTeam<br />
# При успешной проверке secteam_verified устанавливается в "+"<br />
<br />
=== Публикатор ===<br />
# Публикатор получает запрос на обновление после его одобрения командами QA и (если он содержит исправления уязвимостей) SecTeam<br />
# Публикатор обеспечивает появление пакетов обновлений в репозиториях и непротиворечивость репозиториев после публикации.<br />
# После успешной публикации флажок "publishied" устанавливается в "+" и запрос на обновление считается полностью закрытым.<br />
<br />
[[Категория:Регламенты ROSA]]</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F&diff=18618
Регламент тестирования
2020-04-29T08:46:43Z
<p>Vladimir.potapov: /* Положительный результат тестирования */</p>
<hr />
<div>[[Category:Регламенты ROSA]]<br />
<br />
=== Политика ===<br />
QA отвечает за стабильность установленного у пользователей дистрибутива при его обновлениях.<br />
<br />
До установки обновлений дистрибутив работает. Любое обновление — риск его обрушить.<br />
Поэтому политика QA обязана быть консервативной и даже несколько параноидальной — при малейших сомнениях должны назначаться дополнительные проверки, пакеты должны отклоняться, направляться на пересборку.<br />
<br />
Политика QA вступает в конфликт с интересами сборщиков пакетов, желающих быстрее увидеть в репозиториях исправленную версию — конфликт этот должен быть конструктивным, приводящим к непрерывному повышению функциональности и стабильности дистрибутива.<br />
<br />
==== Классификация обновлений по степени опасности ====<br />
<blockquote><br />
Меня не интересуют их намерения, меня интересуют их возможности — © Отто Фон Бисмарк<br />
</blockquote><br />
<br />
Классификация исходит из максимально возможного урона (полный отказ функционирования компонента), который может нанести устанавливаемое обновление.<br />
<br />
;0: Критические обновления. Ядро, файловая система, система прав доступа, скрипты загрузки, <tt>systemd</tt>, <tt>glibc</tt>, <tt>dracut</tt>, <tt>grub</tt>, <tt>bash</tt> и прочие основные вещи, если удалить которые система не загрузится даже в консоли.<br />
;1: Обновления драйверов устройств, т.е. те же критические обновления, но актуальные не для всех пользователей. <br />
;2: Обновления сетевых компонентов: NetworkManager, сетевых скриптов, системы сетевой инициализации и системы обновлений (curl, urpmi). Они опасны тем, что если сеть упадет, пользователю без сети будет затруднительно получить исправленный пакет, когда мы его выпустим и установить обновление. <br />
;3: Обновления графических компонент и скриптов — X-ов, менеджера входа, графических библиотек, драйверов, '''perl, python''' — то, без чего невозможен вход в систему в графическом режиме. Т.к. обновление системы, при наличии сети, возможно и не в графике - класс опасности обновлений не самый высокий<br />
;4: Обновление пользовательских пакетов, установленных по-умолчанию в системе. Эти пакеты стоят практически у всех и их ошибки будут влиять на максимальное количество пользователей, однако они могут быть оперативно исправлены потому класс опасности не очень высокий. Туда же нужно отнести популярные программы не входящие в поставку — <tt>gimp</tt>, <tt>inkscape</tt>, <tt>audacity</tt>, <tt>vlc</tt>, <tt>kdenive</tt>, <tt>opera</tt>, <tt>chromium-browser</tt>, <tt>skype</tt>.<br />
;5: Обновление прочих пользовательских пакетов. Они затронут только тех, у кого эти программы стоят.<br />
;6: Обновление пакетов, необходимых только для сборки дистрибутива или работы с abf. Почти никому кроме нас они не интересны, потому класс опасности самый низкий.<br />
<br />
==== Задача ====<br />
* Главная задача QA — поиск регрессий, то есть таких изменений в дистрибутиве, которые уменьшают его функциональность по сравнению с предыдущим состоянием.<br />
* Также задачей QA является внесение в багзиллу всех ошибок, найденных в процессе тестирования и не относящихся к регрессиям.<br />
<br />
==== Общие положения ====<br />
* Запрос на обновление пишется в багзилле <br />
* Все сообщения пишутся на английском языке.<br />
* Порядок принятие запросов на тестирование командой QA в общем случае — в порядке возрастания номеров багов, возможны исключения, связанные со срочностью или трудностями в тестировании определенных пакетов.<br />
* Список запросов на обновление можно открыть по ссылке http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=qa_verified%3F&o1=substring&list_id=38774<br />
<br />
==== Срок тестирования ====<br />
* Срок тестирования пакета — '''одна неделя''', для сложных пакетов, отправляемых на дополнительное тестирование, срок тестирования зависит от срока дополнительного тестирования.<br />
* Для пакета, который нужно проверить очень срочно, сборщик должен установить приоритет <tt>Highest Critical</tt>, чтобы он выделялся красным цветом в списке. Такие пакеты рассматриваются в течение '''48 часов'''.<br />
<br />
=== Процедура тестирования ===<br />
<br />
==== Требования к запросу на обновление ====<br />
# QA Team тестирует пакеты-кандидаты на добавление в репозитории <tt>main/updates, non-free/updates и restricted/updates</tt>.<br />
# Пакет должен быть собран в общедоступном репозитории (не <tt>_personal</tt>).<br />
# Для архитектурно-зависимых пакетов должны быть представлены все поддерживаемые архитектуры (<tt>i586</tt> и <tt>x64</tt>).<br />
# Описание обновления должно содержать все изменения, которые нужно протестировать.<br />
При несоответствии запроса на обновление этим требованиям запрос отклоняется.<br />
<br />
==== Тестирование установки пакетов ====<br />
# Система перед тестовым обновлением должна соответствовать стандартным репозиториям. Это можно проверить запуском <tt>urpm-reposync</tt> из пакета <tt>urpm-tools</tt><br />
# Пакеты для тестирования устанавливаются и в графическом, и в текстовом режиме.<br />
## Репозиторий подключается как репозиторий с обновлениями.<br />
## Из графического режима запускается стандартная процедура обновления.<br />
# Для пакетов, установленных в системе по-умолчанию, проверяется их обновление.<br />
# Для пакетов, не установленных в системе, проверяется как их обновление, так и первоначальная установка при подключенных тестовых контейнерах.<br />
# Установка пакетов проверяется для обеих архитектур. Так как ошибки установки не обычно не зависят от архитектуры, обычно достаточно проверить на одной архитектуре установку в графическом режиме, а на другой — обновление в текстовом, или наоборот.<br />
<br />
При ошибке установки запрос на тестирование отклоняется.<br />
<br />
==== Тестирование на устойчивость системы ====<br />
* Применяется при пересборках библиотек или пакетов без внесения изменений, или для изменений связанных с безопасностью.<br />
* Для экономии времени может выполняться для окончательного тестирования последовательности обновлений перед публикацией их в репозитории<br />
<br />
При тестировании системы на устойчивость проверяется<br />
# Стабильность и внешний вид обновленной системы после перезагрузки.<br />
# Стабильность и внешний вид обновленной системы после пробуждения из спящего режима. Тестирование стабильности и производительности может проводиться, например, с помощью теста Unigine Valley под wine и тестом браузера https://webglsamples.org/aquarium/aquarium.html<br />
# Ошибки загрузки демонов, например, с помощью <tt>systemctl | grep failed</tt>.<br />
# Ошибки непрерывного роста файла <tt>.xsession-errors</tt>.<br />
# Работа URPMI — дальнейшее обновление пакетов.<br />
# Установка и удаление dkms-модулей.<br />
# Сохранение даты-времени на тестируемой машине после перезагрузки и пробуждения из спящего режима.<br />
<br />
==== Тестирование запуска и работы связанных с обновлением приложений ====<br />
Проверяются:<br />
# Тестирование запуска и простейших операций со связанными с тестируемым пакетом программами, рекомендуется контроль сообщений при запуске программы из консоли.<br />
# Связанные с библиотеками из проверяемого пакета программы легче всего установить, попробовав удалить пакет с помощью <tt>urpme</tt> (для установленных в системе программ) или <tt>urpmq --whatrequires</tt> (для всех программ из подключенных репозиториев).<br />
# Изменения в интерфейсах обновляемых библиотек и, соответственно, необходимость перекомпиляции связанных пакетов с помощью сервиса https://abi-laboratory.pro/tracker/<br />
# Для пакетов, предоставляющих библиотеки, проверяются использующие эти библиотеки приложения из main, их можно определить командой <tt>urpmq --whatrequires <названиепакета></tt><br />
# Регрессии в локализации графического интерфейса и страниц справки.<br />
# Для тестирования браузеров в дополнение к https://webglsamples.org/aquarium/aquarium.html применяются.<br />
## Тест html5 https://html5test.com/ (сравнить результат до и после обновления, не должно быть регресса)<br />
## Почтовые онлайновые сервисы http://mail.yandex.ru http://mail.google.com<br />
## Яндекс и гугл-карты https://yandex.ru/maps/-/CVTQITy0 https://www.google.ru/maps/@52.2609339,104.3096872,15z?hl=ru<br />
## xml|xsl трансляцию и кодировки на http://base.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=160129;div=LAW;rnd=0.4700782325977544 и<br />
## Воспроизведение видео http://techslides.com/sample-webm-ogg-and-mp4-video-files-for-html5/ <br />
## Воспроизведение [http://youtu.be/37l7P5V1eXU видео с youtube]<br />
## Работа флэша на примере игры [http://vseigru.net/igry-zombi/2541-igra-zombi-protiv-rastenij.html Растения против зомби] и [http://kino.sputnik.ru/films/ivan+vasilyevich+menyayet+professiyu+1973]<br />
## Работу java с помощью <tt>icedtea-web</tt> и демок пакета <tt>java-1.8-openjdk-demo</tt><br />
## Уязвимости SSL с помощью https://www.ssllabs.com/ssltest/viewMyClient.html<br />
## Тестирование печати<br />
## Тестирование установки браузера по-умолчанию из настроек<br />
<br />
При найденных на этапе тестирования устройчивости системы или запуска и работы пакета регрессиях запрос на тестирование отклоняется.<br />
<br />
==== Тестирование изменений ====<br />
* Применяется при тестировании обновлений, изменяющих внешний вид или поведение системы.<br />
<br />
Включает себя<br />
# Воспроизведение особенностей внешнего вида или поведения системы ДО исправления.<br />
# Воспроизведение измененных обновлений особенностей по их описанию.<br />
<br />
Например, если в advisory сказано, что «вышла новая версия программы» при тестировании изменений нужно, как минимум, убедиться что версия изменилась.<br />
<br />
В случае если не все описанные изменения действительно присутствуют в тестируемом пакете, пакет принимается и в итоговый отчет (Advisory), вносятся только реально проведенные изменения.<br />
В случае значительного отклонения запрошенных и полученных изменений пакет может быть отклонен.<br />
<br />
==== Расширенное тестирование ====<br />
# Расширенное тестирование проводится добровольцами с помощью репозиториев testing, соответствующих основным репозиториям. <br />
# В течение недели все проверяемые QA обновления, кроме срочных, отправляются в тестинг, при этом в багзилле ставится статус verified и пишется The update is sent to expanded testing<br />
# В пятницу на форуме и в сообществе вконтакте объявляется "пятничное тестирование", к нему выпускается бюллетень с полным списком обновлений и методикой их тестирования.<br />
# В понедельник подводятся результаты тестирования и протестированные пакеты публикуются в репозитории<br />
<br />
=== Завершение тестирования ===<br />
<br />
==== Положительный результат тестирования ====<br />
# По окончании теситрования при его успехе ставится индикатор успешного тестирования QA «+» и пишется отчет (Advisory), содержащий:<br />
## Название пакета с исходниками (src.rpm).<br />
## Версию пакета.<br />
## Отчет о тестировании (advisory).<br />
## Надпись «QA verified».<br />
# Если пакет содержит изменения, связанные с секретностью или же собран не сотрудником Росы — посылается запрос Secure team (взводится флажок secteam_verified «?»).<br />
# Если тестирование secure не нужно, пакет передается на публикацию (взводится соответствующий published «?»).<br />
# В случае успешного тестирования пакет может быть оставлен в системе. В случае ошибок систему нужно привести к первоначальному виду с помощью деинсталляции пакета или утилиты <tt>urpm-reposync</tt> из <tt>urpm-repotools</tt>.<br />
<br />
==== Отрицательный результат тестирования ====<br />
# При отклонении пакета ставится индикатор отклонения QA «-»,<br />
# В комментариях пишется причина отклонения запроса и в конце комментария добавляется «QA Denied».<br />
# При отрицательном результате тестирования сборщик может выложить исправленные контейнеры в тот же запрос и снова установить «?» в «qa_requested».</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=%D0%A0%D0%B5%D0%B3%D0%BB%D0%B0%D0%BC%D0%B5%D0%BD%D1%82_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F&diff=18617
Регламент тестирования
2020-04-29T08:42:35Z
<p>Vladimir.potapov: </p>
<hr />
<div>[[Category:Регламенты ROSA]]<br />
<br />
=== Политика ===<br />
QA отвечает за стабильность установленного у пользователей дистрибутива при его обновлениях.<br />
<br />
До установки обновлений дистрибутив работает. Любое обновление — риск его обрушить.<br />
Поэтому политика QA обязана быть консервативной и даже несколько параноидальной — при малейших сомнениях должны назначаться дополнительные проверки, пакеты должны отклоняться, направляться на пересборку.<br />
<br />
Политика QA вступает в конфликт с интересами сборщиков пакетов, желающих быстрее увидеть в репозиториях исправленную версию — конфликт этот должен быть конструктивным, приводящим к непрерывному повышению функциональности и стабильности дистрибутива.<br />
<br />
==== Классификация обновлений по степени опасности ====<br />
<blockquote><br />
Меня не интересуют их намерения, меня интересуют их возможности — © Отто Фон Бисмарк<br />
</blockquote><br />
<br />
Классификация исходит из максимально возможного урона (полный отказ функционирования компонента), который может нанести устанавливаемое обновление.<br />
<br />
;0: Критические обновления. Ядро, файловая система, система прав доступа, скрипты загрузки, <tt>systemd</tt>, <tt>glibc</tt>, <tt>dracut</tt>, <tt>grub</tt>, <tt>bash</tt> и прочие основные вещи, если удалить которые система не загрузится даже в консоли.<br />
;1: Обновления драйверов устройств, т.е. те же критические обновления, но актуальные не для всех пользователей. <br />
;2: Обновления сетевых компонентов: NetworkManager, сетевых скриптов, системы сетевой инициализации и системы обновлений (curl, urpmi). Они опасны тем, что если сеть упадет, пользователю без сети будет затруднительно получить исправленный пакет, когда мы его выпустим и установить обновление. <br />
;3: Обновления графических компонент и скриптов — X-ов, менеджера входа, графических библиотек, драйверов, '''perl, python''' — то, без чего невозможен вход в систему в графическом режиме. Т.к. обновление системы, при наличии сети, возможно и не в графике - класс опасности обновлений не самый высокий<br />
;4: Обновление пользовательских пакетов, установленных по-умолчанию в системе. Эти пакеты стоят практически у всех и их ошибки будут влиять на максимальное количество пользователей, однако они могут быть оперативно исправлены потому класс опасности не очень высокий. Туда же нужно отнести популярные программы не входящие в поставку — <tt>gimp</tt>, <tt>inkscape</tt>, <tt>audacity</tt>, <tt>vlc</tt>, <tt>kdenive</tt>, <tt>opera</tt>, <tt>chromium-browser</tt>, <tt>skype</tt>.<br />
;5: Обновление прочих пользовательских пакетов. Они затронут только тех, у кого эти программы стоят.<br />
;6: Обновление пакетов, необходимых только для сборки дистрибутива или работы с abf. Почти никому кроме нас они не интересны, потому класс опасности самый низкий.<br />
<br />
==== Задача ====<br />
* Главная задача QA — поиск регрессий, то есть таких изменений в дистрибутиве, которые уменьшают его функциональность по сравнению с предыдущим состоянием.<br />
* Также задачей QA является внесение в багзиллу всех ошибок, найденных в процессе тестирования и не относящихся к регрессиям.<br />
<br />
==== Общие положения ====<br />
* Запрос на обновление пишется в багзилле <br />
* Все сообщения пишутся на английском языке.<br />
* Порядок принятие запросов на тестирование командой QA в общем случае — в порядке возрастания номеров багов, возможны исключения, связанные со срочностью или трудностями в тестировании определенных пакетов.<br />
* Список запросов на обновление можно открыть по ссылке http://bugs.rosalinux.ru/buglist.cgi?query_format=advanced&f1=flagtypes.name&v1=qa_verified%3F&o1=substring&list_id=38774<br />
<br />
==== Срок тестирования ====<br />
* Срок тестирования пакета — '''одна неделя''', для сложных пакетов, отправляемых на дополнительное тестирование, срок тестирования зависит от срока дополнительного тестирования.<br />
* Для пакета, который нужно проверить очень срочно, сборщик должен установить приоритет <tt>Highest Critical</tt>, чтобы он выделялся красным цветом в списке. Такие пакеты рассматриваются в течение '''48 часов'''.<br />
<br />
=== Процедура тестирования ===<br />
<br />
==== Требования к запросу на обновление ====<br />
# QA Team тестирует пакеты-кандидаты на добавление в репозитории <tt>main/updates, non-free/updates и restricted/updates</tt>.<br />
# Пакет должен быть собран в общедоступном репозитории (не <tt>_personal</tt>).<br />
# Для архитектурно-зависимых пакетов должны быть представлены все поддерживаемые архитектуры (<tt>i586</tt> и <tt>x64</tt>).<br />
# Описание обновления должно содержать все изменения, которые нужно протестировать.<br />
При несоответствии запроса на обновление этим требованиям запрос отклоняется.<br />
<br />
==== Тестирование установки пакетов ====<br />
# Система перед тестовым обновлением должна соответствовать стандартным репозиториям. Это можно проверить запуском <tt>urpm-reposync</tt> из пакета <tt>urpm-tools</tt><br />
# Пакеты для тестирования устанавливаются и в графическом, и в текстовом режиме.<br />
## Репозиторий подключается как репозиторий с обновлениями.<br />
## Из графического режима запускается стандартная процедура обновления.<br />
# Для пакетов, установленных в системе по-умолчанию, проверяется их обновление.<br />
# Для пакетов, не установленных в системе, проверяется как их обновление, так и первоначальная установка при подключенных тестовых контейнерах.<br />
# Установка пакетов проверяется для обеих архитектур. Так как ошибки установки не обычно не зависят от архитектуры, обычно достаточно проверить на одной архитектуре установку в графическом режиме, а на другой — обновление в текстовом, или наоборот.<br />
<br />
При ошибке установки запрос на тестирование отклоняется.<br />
<br />
==== Тестирование на устойчивость системы ====<br />
* Применяется при пересборках библиотек или пакетов без внесения изменений, или для изменений связанных с безопасностью.<br />
* Для экономии времени может выполняться для окончательного тестирования последовательности обновлений перед публикацией их в репозитории<br />
<br />
При тестировании системы на устойчивость проверяется<br />
# Стабильность и внешний вид обновленной системы после перезагрузки.<br />
# Стабильность и внешний вид обновленной системы после пробуждения из спящего режима. Тестирование стабильности и производительности может проводиться, например, с помощью теста Unigine Valley под wine и тестом браузера https://webglsamples.org/aquarium/aquarium.html<br />
# Ошибки загрузки демонов, например, с помощью <tt>systemctl | grep failed</tt>.<br />
# Ошибки непрерывного роста файла <tt>.xsession-errors</tt>.<br />
# Работа URPMI — дальнейшее обновление пакетов.<br />
# Установка и удаление dkms-модулей.<br />
# Сохранение даты-времени на тестируемой машине после перезагрузки и пробуждения из спящего режима.<br />
<br />
==== Тестирование запуска и работы связанных с обновлением приложений ====<br />
Проверяются:<br />
# Тестирование запуска и простейших операций со связанными с тестируемым пакетом программами, рекомендуется контроль сообщений при запуске программы из консоли.<br />
# Связанные с библиотеками из проверяемого пакета программы легче всего установить, попробовав удалить пакет с помощью <tt>urpme</tt> (для установленных в системе программ) или <tt>urpmq --whatrequires</tt> (для всех программ из подключенных репозиториев).<br />
# Изменения в интерфейсах обновляемых библиотек и, соответственно, необходимость перекомпиляции связанных пакетов с помощью сервиса https://abi-laboratory.pro/tracker/<br />
# Для пакетов, предоставляющих библиотеки, проверяются использующие эти библиотеки приложения из main, их можно определить командой <tt>urpmq --whatrequires <названиепакета></tt><br />
# Регрессии в локализации графического интерфейса и страниц справки.<br />
# Для тестирования браузеров в дополнение к https://webglsamples.org/aquarium/aquarium.html применяются.<br />
## Тест html5 https://html5test.com/ (сравнить результат до и после обновления, не должно быть регресса)<br />
## Почтовые онлайновые сервисы http://mail.yandex.ru http://mail.google.com<br />
## Яндекс и гугл-карты https://yandex.ru/maps/-/CVTQITy0 https://www.google.ru/maps/@52.2609339,104.3096872,15z?hl=ru<br />
## xml|xsl трансляцию и кодировки на http://base.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=160129;div=LAW;rnd=0.4700782325977544 и<br />
## Воспроизведение видео http://techslides.com/sample-webm-ogg-and-mp4-video-files-for-html5/ <br />
## Воспроизведение [http://youtu.be/37l7P5V1eXU видео с youtube]<br />
## Работа флэша на примере игры [http://vseigru.net/igry-zombi/2541-igra-zombi-protiv-rastenij.html Растения против зомби] и [http://kino.sputnik.ru/films/ivan+vasilyevich+menyayet+professiyu+1973]<br />
## Работу java с помощью <tt>icedtea-web</tt> и демок пакета <tt>java-1.8-openjdk-demo</tt><br />
## Уязвимости SSL с помощью https://www.ssllabs.com/ssltest/viewMyClient.html<br />
## Тестирование печати<br />
## Тестирование установки браузера по-умолчанию из настроек<br />
<br />
При найденных на этапе тестирования устройчивости системы или запуска и работы пакета регрессиях запрос на тестирование отклоняется.<br />
<br />
==== Тестирование изменений ====<br />
* Применяется при тестировании обновлений, изменяющих внешний вид или поведение системы.<br />
<br />
Включает себя<br />
# Воспроизведение особенностей внешнего вида или поведения системы ДО исправления.<br />
# Воспроизведение измененных обновлений особенностей по их описанию.<br />
<br />
Например, если в advisory сказано, что «вышла новая версия программы» при тестировании изменений нужно, как минимум, убедиться что версия изменилась.<br />
<br />
В случае если не все описанные изменения действительно присутствуют в тестируемом пакете, пакет принимается и в итоговый отчет (Advisory), вносятся только реально проведенные изменения.<br />
В случае значительного отклонения запрошенных и полученных изменений пакет может быть отклонен.<br />
<br />
==== Расширенное тестирование ====<br />
# Расширенное тестирование проводится добровольцами с помощью репозиториев testing, соответствующих основным репозиториям. <br />
# В течение недели все проверяемые QA обновления, кроме срочных, отправляются в тестинг, при этом в багзилле ставится статус verified и пишется The update is sent to expanded testing<br />
# В пятницу на форуме и в сообществе вконтакте объявляется "пятничное тестирование", к нему выпускается бюллетень с полным списком обновлений и методикой их тестирования.<br />
# В понедельник подводятся результаты тестирования и протестированные пакеты публикуются в репозитории<br />
<br />
=== Завершение тестирования ===<br />
<br />
==== Положительный результат тестирования ====<br />
# По окончании тестрования при его успехе ставится индикатор успешного тестирования QA «+» и пишется отчет (Advisory), содержащий:<br />
## Название пакета с исходниками (src.rpm).<br />
## Версию пакета.<br />
## Отчет о тестировании (advisory).<br />
## Надпись «QA verified».<br />
# Если пакет содержит изменения, связанные с секретностью или же собран не сотрудником Росы — посылается запрос Secure team (взводится соответствующий «?»).<br />
# Если тестирование secure не нужно, пакет отправляется на публикацию (взводится соответствующий «?»).<br />
# В случае успешного тестирования пакет может быть оставлен в системе. В случае ошибок систему нужно привести к первоначальному виду с помощью деинсталляции пакета или утилиты <tt>urpm-reposync</tt> из <tt>urpm-repotools</tt>.<br />
<br />
==== Отрицательный результат тестирования ====<br />
# При отклонении пакета ставится индикатор отклонения QA «-»,<br />
# В комментариях пишется причина отклонения запроса и в конце комментария добавляется «QA Denied».<br />
# При отрицательном результате тестирования сборщик может выложить исправленные контейнеры в тот же запрос и снова установить «?» в «qa_requested».</div>
Vladimir.potapov
http://wiki.rosalab.com/ru/index.php?title=ROSA_%D1%80%D0%B5%D0%BB%D0%B8%D0%B7&diff=18603
ROSA релиз
2020-04-23T10:58:10Z
<p>Vladimir.potapov: /* ROSA Desktop Fresh R11.1 KDE */</p>
<hr />
<div>='''Официальные релизы ROSA'''=<br />
<br />
== ROSA Desktop Fresh R11.1 ==<br />
<br />
* [[Примечания к релизу ROSA Desktop Fresh R11.1]]<br />
* [[Errata ROSA Desktop Fresh R11|Errata ROSA Desktop R11]]<br />
<br />
{| class="standart" border="0" cellpadding="10" cellspacing="0"<br />
|-<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
=== ROSA Desktop Fresh R11.1 KDE ===<br />
<br />
{{Версия|32 bit}} (Дата релиза: {{Источник|23-Апр-2020}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R11.1/ROSA.FRESH.KDE4.R11.1.i586.iso Download ROSA Desktop Fresh R11.1 (i586)]}}<br />
<br />
{{Версия|64 bit}} (Дата релиза: {{Источник|23-Апр-2020}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R11.1/ROSA.FRESH.KDE4.R11.1.x86_64.uefi.iso Download ROSA Desktop Fresh R11.1 (x86_64)]}}<br />
<br />
=== ROSA Desktop Fresh R11.1 PLASMA ===<br />
<br />
{{Версия|32 бит}} (Дата релиза: {{Источник|23-Апр-2020}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R11.1/ROSA.FRESH.PLASMA5.R11.1.i586.iso Download ROSA Desktop Fresh PLASMA R11.1 (i586)]}}<br />
<br />
{{Версия|64 бит}} (Дата релиза: {{Источник|23-Апр-2020}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R11.1/ROSA.FRESH.PLASMA5.R11.1.x86_64.uefi.iso Download ROSA Desktop PLASMA R11.1 (x86_64)]}}<br />
<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
<br />
=== ROSA Desktop Fresh R11.1 XFCE ===<br />
<br />
{{Версия|32 bit}} (Дата релиза: {{Источник|23-Апр-2020}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R11.1/ROSA.FRESH.XFCE.R11.1.i586.iso Download ROSA Desktop Fresh XFCE R11.1 (i586)]}}<br />
<br />
{{Версия|64 bit}} (Дата релиза: {{Источник|23-Апр-2020}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R11.1/ROSA.FRESH.XFCE.R11.1.x86_64.uefi.iso Download ROSA Desktop XFCE R11.1 (x86_64)]}}<br />
<br />
=== ROSA Desktop Fresh R11.1 LXQT ===<br />
<br />
{{Версия|32 bit}} (Дата релиза: {{Источник|23-Апр-2020}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R11.1/ROSA.FRESH.LXQT.R11.1.i586.iso Download ROSA Desktop Fresh XFCE R11 (i586)]}}<br />
<br />
{{Версия|64 bit}} (Дата релиза: {{Источник|23-Апр-2020}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R11.1/ROSA.FRESH.LXQT.R11.1.x86_64.uefi.iso Download ROSA Desktop XFCE R11 (x86_64)]}}<br />
<br />
|}<br />
==='''Торренты'''===<br />
[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R11.1/ROSA.FRESH.KDE4.R11.i586.iso.torrent ROSA.FRESH.KDE4.R11.1.i586.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R11.1/ROSA.FRESH.KDE4.R11.x86_64.iso.torrent ROSA.FRESH.KDE4.R11.1.x86_64.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R11.1/ROSA.FRESH.PLASMA5.R11.i586.uefi.iso.torrent ROSA.FRESH.PLASMA5.R11.1.i586.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R11.1/ROSA.FRESH.PLASMA5.R11.x86_64.uefi.iso.torrent ROSA.FRESH.PLASMA5.R11.1.x86_64.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R11.1/ROSA.FRESH.XFCE.R11.i586.uefi.iso.torrent ROSA.FRESH.XFCE.R11.1.i586.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R11.1/ROSA.FRESH.XFCE.R11.x86_64.uefi.iso.torrent ROSA.FRESH.XFCE.R11.1.x86_64.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R11.1/ROSA.FRESH.LXQT.R11.i586.uefi.iso.torrent ROSA.FRESH.LXQT.R11.1.i586.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R11.1/ROSA.FRESH.LXQT.R11.x86_64.uefi.iso.torrent ROSA.FRESH.LXQT.R11.1.x86_64.iso]<br/><br />
<br />
<br />
== ROSA Desktop Fresh R11 ==<br />
<br />
* [[Примечания к релизу ROSA Desktop Fresh R11]]<br />
* [[Errata ROSA Desktop Fresh R11|Errata ROSA Desktop R11]]<br />
<br />
{| class="standart" border="0" cellpadding="10" cellspacing="0"<br />
|-<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
=== ROSA Desktop Fresh R11 KDE ===<br />
<br />
{{Версия|32 bit}} (Дата релиза: {{Источник|15-Мар-2019}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R11/ROSA.FRESH.KDE4.R11.i586.iso Download ROSA Desktop Fresh R11 (i586)]}}<br />
<br />
{{Версия|64 bit}} (Дата релиза: {{Источник|15-Мар-2019}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R11/ROSA.FRESH.KDE4.R11.x86_64.iso Download ROSA Desktop Fresh R11 (x86_64)]}}<br />
<br />
=== ROSA Desktop Fresh R11 PLASMA ===<br />
<br />
{{Версия|32 бит}} (Дата релиза: {{Источник|15-Мар-2019}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R11/ROSA.FRESH.PLASMA5.R11.i586.iso Download ROSA Desktop Fresh PLASMA R11 (i586)]}}<br />
<br />
{{Версия|64 бит}} (Дата релиза: {{Источник|15-Мар-2019}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R11/ROSA.FRESH.PLASMA5.R11.x86_64.uefi.iso Download ROSA Desktop PLASMA R11 (x86_64)]}}<br />
<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
<br />
=== ROSA Desktop Fresh R11 XFCE ===<br />
<br />
{{Версия|32 bit}} (Дата релиза: {{Источник|15-Мар-2019}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R11/ROSA.FRESH.XFCE.R11.i586.iso Download ROSA Desktop Fresh XFCE R11 (i586)]}}<br />
<br />
{{Версия|64 bit}} (Дата релиза: {{Источник|15-Мар-2019}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R11/ROSA.FRESH.XFCE.R11.x86_64.uefi.iso Download ROSA Desktop XFCE R11 (x86_64)]}}<br />
<br />
=== ROSA Desktop Fresh R11 LXQT ===<br />
<br />
{{Версия|32 bit}} (Дата релиза: {{Источник|15-Мар-2019}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R11/ROSA.FRESH.LXQT.R11.i586.iso Download ROSA Desktop Fresh XFCE R11 (i586)]}}<br />
<br />
{{Версия|64 bit}} (Дата релиза: {{Источник|15-Мар-2019}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R11/ROSA.FRESH.LXQT.R11.x86_64.uefi.iso Download ROSA Desktop XFCE R11 (x86_64)]}}<br />
<br />
|}<br />
==='''Торренты'''===<br />
[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R11/ROSA.FRESH.KDE4.R11.i586.iso.torrent ROSA.FRESH.KDE4.R11.i586.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R11/ROSA.FRESH.KDE4.R11.x86_64.iso.torrent ROSA.FRESH.KDE4.R11.x86_64.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R11/ROSA.FRESH.PLASMA5.R11.i586.uefi.iso.torrent ROSA.FRESH.PLASMA5.R11.i586.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R11/ROSA.FRESH.PLASMA5.R11.x86_64.uefi.iso.torrent ROSA.FRESH.PLASMA5.R11.x86_64.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R11/ROSA.FRESH.XFCE.R11.i586.uefi.iso.torrent ROSA.FRESH.XFCE.R11.i586.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R11/ROSA.FRESH.XFCE.R11.x86_64.uefi.iso.torrent ROSA.FRESH.XFCE.R11.x86_64.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R11/ROSA.FRESH.LXQT.R11.i586.uefi.iso.torrent ROSA.FRESH.LXQT.R11.i586.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R11/ROSA.FRESH.LXQT.R11.x86_64.uefi.iso.torrent ROSA.FRESH.LXQT.R11.x86_64.iso]<br/><br />
<br />
== ROSA Desktop Fresh R10 ==<br />
<br />
* [[Примечания к релизу ROSA Desktop Fresh R10]]<br />
* [[Errata ROSA Desktop R9|Errata ROSA Desktop R10]]<br />
<br />
{| class="standart" border="0" cellpadding="10" cellspacing="0"<br />
|-<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
=== ROSA Desktop Fresh R10 KDE ===<br />
<br />
{{Версия|32 bit}} (Дата выхода: {{Источник|6-Dec-2017}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R10/ROSA.FRESH.KDE.R10.i586.iso Скачать ROSA Desktop Fresh R10 (i586)]}}<br />
<br />
{{Версия|64 bit}} (Дата выхода: {{Источник|6-Dec-2017}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R10/ROSA.FRESH.KDE.R10.x86_64.iso Скачать ROSA Desktop Fresh R10 (x86_64)]}}<br />
<br />
|<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
<br />
=== ROSA Desktop Fresh R10 PLASMA ===<br />
<br />
{{Версия|32 bit}} (Дата выхода: {{Источник|6-Dec-2017}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R10/ROSA.FRESH.PLASMA.R10.i586.iso Скачать ROSA Desktop Fresh PLASMA R10 (i586)]}}<br />
<br />
{{Версия|64 bit}} (Дата выхода: {{Источник|6-Dec-2017}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R10/ROSA.FRESH.PLASMA.R10.x86_64.uefi.iso Скачать ROSA Desktop PLASMA R10 (x86_64)]}}<br />
<br />
=== ROSA Desktop Fresh R10 LXQt ===<br />
<br />
{{Версия|32 bit}} (Дата выхода: {{Источник|25-Dec-2017}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R10/ROSA.FRESH.LXQT.R10.i586.iso Скачать ROSA Desktop Fresh LXQt R10 (i586)]}}<br />
<br />
{{Версия|64 bit}} (Дата выхода: {{Источник|25-Dec-2017}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R10/ROSA.FRESH.LXQT.R10.x86_64.uefi.iso Скачать ROSA Desktop LXQt R10 (x86_64)]}}<br />
<br />
<br />
|}<br />
<br />
<br />
==='''Torrents'''===<br />
[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R10/ROSA.FRESH.KDE.R10.i586.iso.torrent ROSA.FRESH.KDE.R10.i586.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R10/ROSA.FRESH.KDE.R10.x86_64.iso.torrent ROSA.FRESH.KDE.R10.x86_64.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R10/ROSA.FRESH.PLASMA.R10.i586.uefi.iso.torrent ROSA.FRESH.PLASMA.R10.i586.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R10/ROSA.FRESH.PLASMA.R10.x86_64.uefi.iso.torrent ROSA.FRESH.PLASMA.R10.x86_64.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R10/ROSA.FRESH.LXQT.R10.i586.uefi.iso.torrent ROSA.FRESH.LXQT.R10.i586.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R10/ROSA.FRESH.LXQT.R10.x86_64.uefi.iso.torrent ROSA.FRESH.LXQT.R10.x86_64.iso]<br/><br />
<br />
<br />
== ROSA Desktop Fresh R9 ==<br />
<br />
* [[Примечания к релизу ROSA Desktop Fresh R9]]<br />
* [[Errata ROSA Desktop R9|Errata ROSA Desktop R9]]<br />
<br />
{| class="standart" border="0" cellpadding="10" cellspacing="0"<br />
|-<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
=== ROSA Desktop Fresh R9 KDE ===<br />
<br />
{{Версия|32 bit}} (Дата выхода: {{Источник|19-Apr-2017}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R9/ROSA.FRESH.KDE.R9.i586.iso Скачать ROSA Desktop Fresh R9 (i586)]}}<br />
<br />
{{Версия|64 bit}} (Дата выхода: {{Источник|19-Apr-2017}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R9/ROSA.FRESH.KDE.R9.x86_64.iso Скачать ROSA Desktop Fresh R9 (x86_64)]}}<br />
<br />
|<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
=== ROSA Desktop Fresh R9 PLASMA ===<br />
<br />
{{Версия|32 bit}} (Дата выхода: {{Источник|19-Apr-2017}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R9/ROSA.FRESH.PLASMA.R9.i586.iso Скачать ROSA Desktop Fresh PLASMA R9 (i586)]}}<br />
<br />
{{Версия|64 bit}} (Дата выхода: {{Источник|19-Apr-2017}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R9/ROSA.FRESH.PLASMA.R9.x86_64.uefi.iso Скачать ROSA Desktop PLASMA R9 (x86_64)]}}<br />
<br />
|}<br />
<br />
{| class="standart" border="0" cellpadding="10" cellspacing="0"<br />
|-<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
=== ROSA Desktop Fresh R9 GNOME ===<br />
<br />
{{Версия|32 bit}} (Дата выхода: {{Источник|16-May-2017}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R9/ROSA.FRESH.GNOME.R9.i586.iso Скачать ROSA Desktop Fresh GNOME R9 (i586)]}}<br />
<br />
{{Версия|64 bit}} (Дата выхода: {{Источник|16-May-2017}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R9/ROSA.FRESH.GNOME.R9.x86_64.uefi.iso Скачать ROSA Desktop GNOME R9 (x86_64)]}}<br />
<br />
|<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
=== ROSA Desktop Fresh R9 LXQT ===<br />
<br />
{{Версия|32 bit}} (Дата выхода: {{Источник|7-Jun-2017}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R9/ROSA.FRESH.LXQT.R9.i586.iso Скачать ROSA Desktop Fresh LXQT R9 (i586)]}}<br />
<br />
{{Версия|64 bit}} (Дата выхода: {{Источник|7-Jun-2017}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R9/ROSA.FRESH.LXQT.R9.x86_64.uefi.iso Скачать ROSA Desktop LXQT R9 (x86_64)]}}<br />
<br />
|}<br />
<br />
==='''Torrents'''===<br />
[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R9/ROSA.FRESH.KDE.R9.i586.iso.torrent ROSA.FRESH.KDE.R9.i586.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R9/ROSA.FRESH.KDE.R9.x86_64.iso.torrent ROSA.FRESH.KDE.R9.x86_64.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R9/ROSA.FRESH.PLASMA.R9.i586.uefi.iso.torrent ROSA.FRESH.PLASMA.R9.i586.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R9/ROSA.FRESH.PLASMA.R9.x86_64.uefi.iso.torrent ROSA.FRESH.PLASMA.R9.x86_64.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R9/ROSA.FRESH.GNOME.R9.i586.uefi.iso.torrent ROSA.FRESH.GNOME.R9.i586.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R9/ROSA.FRESH.GNOME.R9.x86_64.uefi.iso.torrent ROSA.FRESH.GNOME.R9.x86_64.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R9/ROSA.FRESH.LXQT.R9.i586.uefi.iso.torrent ROSA.FRESH.LXQT.R9.i586.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2016.1/iso/ROSA.Fresh.R9/ROSA.FRESH.LXQT.R9.x86_64.uefi.iso.torrent ROSA.FRESH.LXQT.R9.x86_64.iso]<br/><br />
<br />
== ROSA Desktop Fresh R8.1 ==<br />
<br />
* [[Примечания к релизу ROSA Desktop Fresh R8.1]]<br />
* [[Errata ROSA Desktop R8.1|Errata ROSA Desktop R8.1]]<br />
<br />
{| class="standart" border="0" cellpadding="10" cellspacing="0"<br />
|-<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
=== ROSA Desktop Fresh R8.1 KDE ===<br />
<br />
{{Версия|32 bit}} (Дата выхода: {{Источник|7-Mar-2017}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R8/ROSA.Fresh.R8.1/ROSA.FRESH.KDE.R8.1.i586.iso Скачать ROSA Desktop Fresh R8.1 (i586)]}}<br />
<br />
{{Версия|64 bit}} (Дата выхода: {{Источник|7-Mar-2017}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R8/ROSA.Fresh.R8.1/ROSA.FRESH.KDE.R8.1.x86_64.uefi.iso Скачать ROSA Desktop Fresh R8.1 (x86_64)]}}<br />
|}<br />
<br />
<br />
<br />
== ROSA Desktop Fresh R8 ==<br />
<br />
* [[Примечания к релизу ROSA Desktop Fresh R8]]<br />
* [[Errata ROSA Desktop R8|Errata ROSA Desktop R8]]<br />
<br />
{| class="standart" border="0" cellpadding="10" cellspacing="0"<br />
|-<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
=== ROSA Desktop Fresh R8 KDE ===<br />
<br />
{{Версия|32 bit}} (Дата выхода: {{Источник|2-Aug-2016}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R8/ROSA.FRESH.KDE.R8.i586.iso Скачать ROSA Desktop Fresh R8 (i586)]}}<br />
<br />
{{Версия|64 bit}} (Дата выхода: {{Источник|2-Aug-2016}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R8/ROSA.FRESH.KDE.R8.x86_64.iso Скачать ROSA Desktop Fresh R8 (x86_64)]}}<br />
<br />
|<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
<br />
=== ROSA Desktop Fresh R8 GNOME ===<br />
<br />
{{Версия|32 bit}} (Дата выхода: {{Источник|2-Aug-2016}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R8/ROSA.FRESH.GNOME.R8.i586.iso Скачать ROSA Desktop Fresh GNOME R8 (i586)]}}<br />
<br />
{{Версия|64 bit}} (Дата выхода: {{Источник|2-Aug-2016}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R8/ROSA.FRESH.GNOME.R8.x86_64.uefi.iso Скачать ROSA Desktop Fresh GNOME R8 (x86_64)]}}<br />
|}<br />
<br />
{| class="standart" border="0" cellpadding="10" cellspacing="0"<br />
|-<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
<br />
=== ROSA Desktop Fresh R8 MATE ===<br />
<br />
{{Версия|32 bit}} (Дата выхода: {{Источник|2-Aug-2016}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R8/ROSA.FRESH.MATE.R8.i586.iso Скачать ROSA Desktop Fresh MATE R8 (i586)]}}<br />
<br />
{{Версия|64 bit}} (Дата выхода: {{Источник|2-Aug-2016}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R8/ROSA.FRESH.MATE.R8.x86_64.uefi.iso Скачать ROSA Desktop Fresh MATE R8 (x86_64)]}}<br />
<br />
|<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
<br />
=== ROSA Desktop Fresh R8 PLASMA ===<br />
<br />
{{Версия|32 bit}} (Дата выхода: {{Источник|2-Aug-2016}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R8/ROSA.FRESH.PLASMA.R8.i586.iso Скачать ROSA Desktop Fresh PLASMA R8 (i586)]}}<br />
<br />
{{Версия|64 bit}} (Дата выхода: {{Источник|2-Aug-2016}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R8/ROSA.FRESH.PLASMA.R8.x86_64.uefi.iso Скачать ROSA Desktop PLASMA R8 (x86_64)]}}<br />
|}<br />
<br />
==='''Torrents'''===<br />
[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R8/ROSA.FRESH.KDE.R8.i586.iso.torrent ROSA.FRESH.KDE.R8.i586.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R8/ROSA.FRESH.KDE.R8.x86_64.iso.torrent ROSA.FRESH.KDE.R8.x86_64.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R8/ROSA.FRESH.GNOME.R8.i586.uefi.iso.torrent ROSA.FRESH.GNOME.R8.i586.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R8/ROSA.FRESH.GNOME.R8.x86_64.uefi.iso.torrent ROSA.FRESH.GNOME.R8.x86_64.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R8/ROSA.FRESH.MATE.R8.i586.uefi.iso.torrent ROSA.FRESH.MATE.R8.i586.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R8/ROSA.FRESH.MATE.R8.x86_64.uefi.iso.torrent ROSA.FRESH.MATE.R8.x86_64.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R8/ROSA.FRESH.PLASMA.R8.i586.uefi.iso.torrent ROSA.FRESH.PLASMA.R8.i586.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R8/ROSA.FRESH.PLASMA.R8.x86_64.uefi.iso.torrent ROSA.FRESH.PLASMA.R8.x86_64.iso]<br/><br />
<br />
<br />
== ROSA Desktop Fresh R7 ==<br />
<br />
* [[Примечания к релизу ROSA Desktop Fresh R7]]<br />
* [[Примечания к релизу ROSA Desktop Fresh GNOME R7]]<br />
* [[Errata ROSA Desktop R7|Список проблем и решений ROSA Desktop Fresh R7]]<br />
<br />
{| class="standart" border="0" cellpadding="10" cellspacing="0"<br />
|-<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
=== ROSA Desktop Fresh R7 KDE ===<br />
<br />
{{Версия|32 bit}} (Дата выхода: {{Источник|25-Jan-2016}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R7/ROSA.FRESH.KDE.R7.i586.iso Скачать ROSA Desktop Fresh R7 (i586)]}}<br />
<br />
{{Версия|64 bit}} (Дата выхода: {{Источник|25-Jan-2016}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R7/ROSA.FRESH.KDE.R7.x86_64.iso Скачать ROSA Desktop Fresh R7 (x86_64)]}}<br />
<br />
|<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
<br />
=== ROSA Desktop Fresh R7 GNOME ===<br />
<br />
{{Версия|32 bit}} (Дата выхода: {{Источник|20-Feb-2016}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R7/ROSA.FRESH.GNOME.R7.i586.iso Скачать ROSA Desktop Fresh R7 GNOME (i586)]}}<br />
<br />
{{Версия|64 bit}} (Дата выхода: {{Источник|20-Feb-2015}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R7/ROSA.FRESH.GNOME.R7.x86_64.iso Скачать ROSA Desktop Fresh R7 GNOME (x86_64)]}}<br />
<br />
{{Версия|32 bit}} (Дата выхода: {{Источник|20-Feb-2016}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R7/ROSA.FRESH.GNOME.R7.i586.uefi.iso Скачать ROSA Desktop Fresh R7 GNOME UEFI (i586)]}}<br />
<br />
{{Версия|64 bit}} (Дата выхода: {{Источник|20-Feb-2015}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R7/ROSA.FRESH.GNOME.R7.x86_64.uefi.iso Скачать ROSA Desktop Fresh R7 GNOME UEFI (x86_64)]}}<br />
<br />
|}<br />
<br />
==='''Торренты'''===<br />
[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R7/ROSA.FRESH.KDE.R7.i586.iso.torrent ROSA.FRESH.KDE.R7.i586.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R7/ROSA.FRESH.KDE.R7.x86_64.iso.torrent ROSA.FRESH.KDE.R7.x86_64.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R7/ROSA.FRESH.GNOME.R7.i586.iso.torrent ROSA.FRESH.GNOME.R7.i586.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R7/ROSA.FRESH.GNOME.R7.x86_64.iso.torrent ROSA.FRESH.GNOME.R7.x86_64.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R7/ROSA.FRESH.GNOME.R7.i586.uefi.iso.torrent ROSA.FRESH.GNOME.R7.i586.uefi.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R7/ROSA.FRESH.GNOME.R7.x86_64.uefi.iso.torrent ROSA.FRESH.GNOME.R7.x86_64.uefi.iso]<br/><br />
<br />
== ROSA Desktop Fresh R6 ==<br />
<br />
* [[Примечания к релизу ROSA Desktop Fresh R6]]<br />
* [[Errata ROSA Desktop R6|Список проблем и решений ROSA Desktop Fresh R6]]<br />
<br />
{| class="standart" border="0" cellpadding="10" cellspacing="0"<br />
|-<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
=== ROSA Desktop Fresh R6 KDE ===<br />
<br />
{{Версия|32 bit}} (Дата выхода: {{Источник|21-Jul-2015}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R6/ROSA.FRESH.KDE.R6.i586.iso Скачать ROSA Desktop Fresh R6 (i586)]}}<br />
<br />
{{Версия|64 bit}} (Дата выхода: {{Источник|21-Jul-2015}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R6/ROSA.FRESH.KDE.R6.x86_64.iso Скачать ROSA Desktop Fresh R6 (x86_64)]}}<br />
<br />
|<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
<br />
=== ROSA Desktop Fresh R6 LXQt ===<br />
<br />
{{Версия|32 bit}} (Дата выхода: {{Источник|09-Dec-2015}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R6/ROSA.FRESH.LXQT.R6.i586.iso Скачать ROSA Desktop Fresh R6 LXQt (i586)]}}<br />
<br />
{{Версия|64 bit}} (Дата выхода: {{Источник|09-Dec-2015}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R6/ROSA.FRESH.LXQT.R6.x86_64.iso Скачать ROSA Desktop Fresh R6 LXQt (x86_64)]}}<br />
<br />
|}<br />
<br />
==='''Торренты'''===<br />
[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R6/ROSA.FRESH.KDE.R6.i586.iso.torrent ROSA.FRESH.KDE.R6.i586.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R6/ROSA.FRESH.KDE.R6.x86_64.iso.torrent ROSA.FRESH.KDE.R6.x86_64.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R6/ROSA.FRESH.LXQT.R6.i586.iso.torrent ROSA.FRESH.LXQT.R6.i586.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R6/ROSA.FRESH.LXQT.R6.x86_64.iso.torrent ROSA.FRESH.LXQT.R6.x86_64.iso]<br/><br />
<br />
<br />
== ROSA Enterprise Desktop X2 ==<br />
* [[ROSA Enterprise Desktop X2|Примечания к релизу ROSA Enterprise Desktop X2]]<br />
* [[Errata RED X2|Список проблем и решений ROSA Enterprise Desktop X2]]<br />
<br />
Если вы хотите приобрести данную систему или получить ее установочный образ для внутреннего тестирования, вам необходимо связаться с нашим отделом продаж. Детали можно найти на [http://www.rosalab.ru/products/desktop_lts/download нашем сайте].<br />
<br />
== ROSA Desktop Fresh R5 ==<br />
<br />
* [[Примечания к релизу ROSA Desktop.Fresh R5]]<br />
* [[Errata ROSA Desktop R5|Список проблем и решений ROSA Desktop Fresh R5]]<br />
<br />
{| class="standart" border="0" cellpadding="10" cellspacing="0"<br />
|-<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
=== ROSA Desktop Fresh R5 KDE ===<br />
<br />
{{Версия|32 bit}} (Дата выхода: {{Источник|25-Dec-2014}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R5/ROSA.FRESH.KDE.R5.i586.iso Скачать ROSA Desktop Fresh R5 (i586)]}}<br />
<br />
{{Версия|64 bit}} (Дата выхода: {{Источник|25-Dec-2014}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R5/ROSA.FRESH.KDE.R5.x86_64.iso Скачать ROSA Desktop Fresh R5 (x86_64)]}}<br />
<br />
|<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
<br />
=== ROSA Desktop Fresh R5 LXDE ===<br />
<br />
{{Версия|32 bit}} (Дата выхода: {{Источник|03-February-2015}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R5/ROSA.FRESH.LXDE.R5.i586.iso Скачать ROSA Desktop Fresh R5 LXDE (i586)]}}<br />
<br />
{{Версия|64 bit}} (Дата выхода: {{Источник|03-February-2015}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R5/ROSA.FRESH.LXDE.R5.x86_64.iso Скачать ROSA Desktop Fresh R5 LXDE (x86_64)]}}<br />
<br />
|-<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
<br />
=== ROSA Desktop Fresh R5 GNOME ===<br />
<br />
{{Версия|32 bit}} (Дата выхода: {{Источник|11-March-2015}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R5/ROSA.FRESH.GNOME.R5.i586.iso Скачать ROSA Desktop Fresh GNOME R5 (i586)]}}<br />
<br />
{{Версия|64 bit}} (Дата выхода: {{Источник|11-March-2015}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R5/ROSA.FRESH.GNOME.R5.x86_64.iso Скачать ROSA Desktop Fresh GNOME R5 (x86_64)]}}<br />
<br />
|}<br />
<br />
==='''Торренты'''===<br />
[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R5/ROSA.FRESH.KDE.R5.i586.iso.torrent ROSA.FRESH.KDE.R5.i586.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R5/ROSA.FRESH.KDE.R5.x86_64.iso.torrent ROSA.FRESH.KDE.R5.x86_64.iso]<br/><br />
<br />
[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R5/ROSA.FRESH.LXDE.R5.i586.iso.torrent ROSA.FRESH.R5.LXDE.i586.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R5/ROSA.FRESH.LXDE.R5.x86_64.iso.torrent ROSA.FRESH.R5.LXDE.x86_64.iso]<br/><br />
<br />
[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R5/ROSA.FRESH.GNOME.R5.i586.iso.torrent ROSA.FRESH.GNOME.R5.i586.iso.torrent]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R5/ROSA.FRESH.GNOME.R5.x86_64.iso.torrent ROSA.FRESH.GNOME.R5.x86_64.iso.torrent]<br/><br />
<br />
== ROSA Desktop Fresh R4 ==<br />
<br />
* [[Примечания к релизу ROSA Desktop.Fresh R4]]<br />
* [[Errata_ROSA_Desktop_R4|Список проблем и решений ROSA Desktop Fresh R4]]<br />
* [[Миграция с ROSA Desktop Fresh R3 на R4]]<br />
<br />
{| class="standart" border="0" cellpadding="10" cellspacing="0"<br />
|-<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
=== ROSA Desktop Fresh R4 KDE ===<br />
<br />
{{Версия|32 bit}} (Дата выхода: {{Источник|08-Oct-2014}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R4/ROSA.FRESH.KDE.R4.i586.iso Скачать ROSA Desktop Fresh R4 (i586)]}}<br />
<br />
{{Версия|64 bit}} (Дата выхода: {{Источник|08-Oct-2014}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R4/ROSA.FRESH.KDE.R4.x86_64.iso Скачать ROSA Desktop Fresh R4 (x86_64)]}}<br />
<br />
|<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
<br />
=== ROSA Desktop Fresh R4 LXDE ===<br />
<br />
{{Версия|32 bit}} (Дата выхода: {{Источник|27-October-2014}})<br />
<br />
{{Скачать|[http://mirror.rosalinux.com/rosa/rosa2014.1/iso/ROSA.Fresh.R4/ROSA.FRESH.LXDE.R4.i586.iso Скачать ROSA Desktop Fresh R4 LXDE (i586)]}}<br />
<br />
{{Версия|64 bit}} (Дата выхода: {{Источник|27-October-2014}})<br />
<br />
{{Скачать|[http://mirror.rosalinux.com/rosa/rosa2014.1/iso/ROSA.Fresh.R4/ROSA.FRESH.LXDE.R4.x86_64.iso Скачать ROSA Desktop Fresh R4 LXDE (x86_64)]}}<br />
<br />
|}<br />
<br />
==='''Торренты'''===<br />
[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R4/ROSA.FRESH.KDE.R4.i586.iso.torrent ROSA.FRESH.KDE.R4.i586.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R4/ROSA.FRESH.KDE.R4.x86_64.iso.torrent ROSA.FRESH.KDE.R4.x86_64.iso]<br/><br />
<br />
[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R4/ROSA.FRESH.LXDE.R4.i586.iso.torrent ROSA.FRESH.LXDE.R4.i586.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2014.1/iso/ROSA.Fresh.R4/ROSA.FRESH.LXDE.R4.x86_64.iso.torrent ROSA.FRESH.LXDE.R4.x86_64.iso]<br/><br />
<br />
== ROSA Desktop Fresh R3 ==<br />
<br />
* [[Примечания к релизу ROSA Desktop.Fresh R3]]<br />
* [[Errata_ROSA_Desktop_R3|Список проблем и решений ROSA Desktop Fresh R3]]<br />
* [[Проблемы и решения при миграции с ROSA Desktop Fresh R2 на R3]]<br />
<br />
{| class="standart" border="0" cellpadding="10" cellspacing="0"<br />
|-<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
=== ROSA Desktop Fresh R3 KDE ===<br />
<br />
{{Версия|32 bit}} (Дата выхода: {{Источник|29-Apr-2014}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2012.1/iso/ROSA.Fresh.R3/ROSA.FRESH.KDE.R3.i586.iso Скачать ROSA Desktop Fresh R3 (i586)]}}<br />
<br />
{{Версия|64 bit}} (Дата выхода: {{Источник|29-Apr-2014}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2012.1/iso/ROSA.Fresh.R3/ROSA.FRESH.KDE.R3.x86_64.iso Скачать ROSA Desktop Fresh R3 (x86_64)]}}<br />
<br />
|-<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
=== ROSA Desktop Fresh R3 GNOME ===<br />
<br />
{{Версия|32 bit}} (Дата выхода: {{Источник|01-Sep-2014}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2012.1/iso/ROSA.Fresh.R3.GNOME/ROSA.FRESH.GNOME.R3.i586.iso Скачать ROSA Desktop Fresh GNOME R3 (i586)]}}<br />
<br />
{{Версия|64 bit}} (Дата выхода: {{Источник|01-Sep-2014}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2012.1/iso/ROSA.Fresh.R3.GNOME/ROSA.FRESH.GNOME.R3.x86_64.iso Скачать ROSA Desktop Fresh GNOME R3 (x86_64)]}}<br />
<br />
|}<br />
<br />
==='''Торренты'''===<br />
[http://mirror.rosalab.ru/rosa/rosa2012.1/iso/ROSA.Fresh.R3/ROSA.FRESH.KDE.R3.i586.iso.torrent ROSA.FRESH.KDE.R3.i586.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2012.1/iso/ROSA.Fresh.R3/ROSA.FRESH.KDE.R3.x86_64.iso.torrent ROSA.FRESH.KDE.R3.x86_64.iso]<br/><br />
<br />
== ROSA Desktop Fresh R2 ==<br />
<br />
* [[Примечания к релизу ROSA Desktop.Fresh R2]]<br />
* [[Errata_ROSA_Desktop_R2|Список проблем и решений ROSA Desktop Fresh R2]]<br />
* [[Проблемы и решения при миграции с ROSA Desktop Fresh R1 на R2]]<br />
<br />
{| class="standart" border="0" cellpadding="10" cellspacing="0"<br />
|-<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
=== ROSA Desktop Fresh R2 KDE ===<br />
<br />
{{Версия|32 bit}} (Дата выхода: {{Источник|4-December-2013}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2012.1/iso/ROSA.Fresh.R2/ROSA.FRESH.KDE.R2.i586.iso Скачать ROSA Desktop Fresh R2(i586)]}}<br />
<br />
{{Версия|64 bit}} (Дата выхода: {{Источник|4-December-2013}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2012.1/iso/ROSA.Fresh.R2/ROSA.FRESH.KDE.R2.x86_64.iso Скачать ROSA Desktop Fresh R2 (x86_64)]}}<br />
<br />
<br />
|<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
<br />
=== ROSA Desktop Fresh R2 LXDE ===<br />
<br />
{{Версия|32 bit}} (Дата выхода: {{Источник|30-December-2013}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa2012.1/iso/ROSA.Fresh.R2.LXDE/ROSA.FRESH.R2.LXDE.i586.iso Скачать ROSA Desktop Fresh R2 LXDE (i586)]}}<br />
<br />
{{Версия|64 bit}} (Дата выхода: {{Источник|30-December-2013}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa2012.1/iso/ROSA.Fresh.R2.LXDE/ROSA.FRESH.R2.LXDE.x86_64.iso Скачать ROSA Desktop Fresh R2 LXDE (x86_64)]}}<br />
<br />
<br />
<br />
|-<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
=== ROSA Desktop Fresh R2 GNOME ===<br />
<br />
{{Версия|32 bit}} (Дата выхода: {{Источник|21-Jan-2014}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2012.1/iso/ROSA.Fresh.R2.GNOME/ROSA.FRESH.GNOME.R2.i586.iso Скачать ROSA Desktop Fresh GNOME R2 (i586)]}}<br />
<br />
{{Версия|64 bit}} (Дата выхода: {{Источник|21-Jan-2014}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa/rosa2012.1/iso/ROSA.Fresh.R2.GNOME/ROSA.FRESH.GNOME.R2.x86_64.iso Скачать ROSA Desktop Fresh GNOME R2 (x86_64)]}}<br />
<br />
|}<br />
<br />
==='''Торренты'''===<br />
[http://mirror.rosalab.ru/rosa/rosa2012.1/iso/ROSA.Fresh.R2/ROSA.FRESH.KDE.R2.i586.iso.torrent ROSA.FRESH.KDE.R2.i586.iso]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2012.1/iso/ROSA.Fresh.R2/ROSA.FRESH.KDE.R2.x86_64.iso.torrent ROSA.FRESH.KDE.R2.x86_64.iso]<br/><br />
<br />
[http://mirror.rosalab.ru/rosa2012.1/iso/ROSA.Fresh.R2.LXDE/ROSA.FRESH.R2.LXDE.i586.iso.torrent ROSA.FRESH.R2.LXDE.i586.iso]<br/><br />
[http://mirror.rosalab.ru/rosa2012.1/iso/ROSA.Fresh.R2.LXDE/ROSA.FRESH.R2.LXDE.x86_64.iso.torrent ROSA.FRESH.R2.LXDE.x86_64.iso]<br/><br />
<br />
[http://mirror.rosalab.ru/rosa/rosa2012.1/iso/ROSA.Fresh.R2.GNOME/ROSA.FRESH.GNOME.R2.i586.iso.torrent ROSA.FRESH.GNOME.R2.i586.iso.torrent]<br/><br />
[http://mirror.rosalab.ru/rosa/rosa2012.1/iso/ROSA.Fresh.R2.GNOME/ROSA.FRESH.GNOME.R2.x86_64.iso.torrent ROSA.FRESH.GNOME.R2.x86_64.iso.torrent]<br/><br />
<br />
== ROSA Desktop Fresh R1 ==<br />
<br />
* [[Примечания к релизу ROSA Desktop.Fresh R1]]<br />
* [[Errata_ROSA_Desktop_R1|Список проблем и решений ROSA Desktop Fresh R1]]<br />
* [[Проблемы и решения при миграции с ROSA Desktop Fresh 2012.1 на R1]]<br />
<br />
{| class="standart" border="0" cellpadding="10" cellspacing="0"<br />
|-<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
<br />
=== ROSA Desktop Fresh R1 KDE ===<br />
<br />
{{Версия|32 bit}} (Дата выхода: {{Источник|06-June-2013}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa2012.1/iso/ROSA.Fresh.R1/ROSA.FRESH.KDE.R1.i586.iso Скачать ROSA Desktop Fresh R1 (i586)]}}<br />
<br />
{{Версия|64 bit}} (Дата выхода: {{Источник|06-June-2013}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa2012.1/iso/ROSA.Fresh.R1/ROSA.FRESH.KDE.R1.x86_64.iso Скачать ROSA Desktop Fresh R1 (x86_64)]}}<br />
<br />
<br />
|<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
<br />
=== ROSA Desktop Fresh R1 LXDE ===<br />
<br />
{{Версия|32 bit}} (Дата выхода: {{Источник|17-July-2013}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa2012.1/iso/ROSA.FRESH.R1.LXDE/ROSA.FRESH.R1.LXDE.i586.iso Скачать ROSA Desktop Fresh R1 LXDE (i586)]}}<br />
<br />
{{Версия|64 bit}} (Дата выхода: {{Источник|17-July-2013}})<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa2012.1/iso/ROSA.FRESH.R1.LXDE/ROSA.FRESH.R1.LXDE.x86_64.iso Скачать ROSA Desktop Fresh R1 LXDE (x86_64)]}}<br />
<br />
|}<br />
<br />
<br />
==='''Торренты'''===<br />
[http://mirror.rosalab.ru/rosa2012.1/iso/ROSA.Fresh.R1/ROSA.FRESH.KDE.R1.i586.iso.torrent ROSA.FRESH.KDE.R1.i586.iso]<br/><br />
[http://mirror.rosalab.ru/rosa2012.1/iso/ROSA.Fresh.R1/ROSA.FRESH.KDE.R1.x86_64.iso.torrent ROSA.FRESH.KDE.R1.x86_64.iso]<br/><br />
<br />
[http://mirror.rosalab.ru/rosa2012.1/iso/ROSA.FRESH.R1.LXDE/ROSA.FRESH.R1.LXDE.i586.iso.torrent ROSA.FRESH.R1.LXDE.i586.iso]<br/><br />
[http://mirror.rosalab.ru/rosa2012.1/iso/ROSA.FRESH.R1.LXDE/ROSA.FRESH.R1.LXDE.x86_64.iso.torrent ROSA.FRESH.R1.LXDE.x86_64.iso]<br/><br />
<br />
<br />
== ROSA Marathon RP2 (Enterprise Desktop X1) ==<br />
* [[ROSA_Marathon_X1|Информация о релизе ROSA Marathon RP2 (Enterprise Desktop X1)]]<br />
* [[ROSA_Enterprise_Desktop_X1_(Marathon)|Обзор ROSA Marathon RP2 (Enterprise Desktop X1)]]<br />
* [[Errata_ROSA_Marathon_X1|Список проблем и решений ROSA Marathon RP2 (Enterprise Desktop X1)]]<br />
<br />
{| class="standart" border="0" cellpadding="10" cellspacing="0"<br />
|-<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
<br />
=== ROSA Marathon RP2 (Enterprise Desktop X1) ===<br />
<br />
{{Версия|32 бит}} Дата выхода: {{Источник|18-Apr-2013}}<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa2012lts/iso/ROSA.2012.MARATHON.X1/ROSA.MARATHON.X1.EE.i586.iso Скачать ROSA Marathon RP2 (Enterprise Desktop X1) (i586)]}}<br />
<br />
{{Версия|64 бит}} Дата выхода: {{Источник|18-Apr-2013}}<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/rosa2012lts/iso/ROSA.2012.MARATHON.X1/ROSA.MARATHON.X1.EE.x86_64.iso Скачать ROSA Marathon RP2 (Enterprise Desktop X1) (x86_64)]}}<br />
<br />
|<br />
|}<br />
<br />
==='''Торренты'''===<br />
[http://mirror.rosalab.ru/rosa2012lts/iso/ROSA.2012.MARATHON.X1/ROSA.MARATHON.X1.EE.i586.iso.torrent ROSA.MARATHON.X1.EE.i586.iso]<br/><br />
[http://mirror.rosalab.ru/rosa2012lts/iso/ROSA.2012.MARATHON.X1/ROSA.MARATHON.X1.EE.x86_64.iso.md5sum ROSA.MARATHON.X1.EE.x86_64.iso]<br/><br />
<br />
== ROSA Desktop Fresh 2012 ==<br />
* [[Release_notes_ROSA Desktop 2012|Информация о релизе ROSA Desktop Fresh 2012]]<br />
* [[Errata_ROSA Desktop 2012|Список проблем и решений ROSA Desktop Fresh 2012]]<br />
<br />
{| class="standart" border="0" cellpadding="10" cellspacing="0"<br />
|-<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
<br />
=== ROSA Desktop Fresh 2012 Extended Edition ===<br />
<br />
{{Версия|32 бит}} Дата выхода: {{Источник|19-Dec-2012}}<br />
<br />
{{Скачать|[http://mirror.yandex.ru/rosa/rosa2012.1/iso/ROSA.Desktop.Fresh/ROSA.Desktop.Fresh.2012.i586.iso Скачать ROSA Desktop Fresh 2012 EE (i586)]}}<br />
<br />
{{Версия|64 бит}} Дата выхода: {{Источник|19-Dec-2012}}<br />
<br />
{{Скачать|[http://mirror.yandex.ru/rosa/rosa2012.1/iso/ROSA.Desktop.Fresh/ROSA.Desktop.Fresh.2012.x86_64.iso Скачать ROSA Desktop Fresh 2012 EE (x86_64)]}}<br />
<br />
|<br />
|}<br />
<br />
=== '''Торренты''' ===<br />
[http://mirror.yandex.ru/rosa/rosa2012.1/iso/ROSA.Desktop.Fresh/ROSA.Desktop.Fresh.2012.i586.iso.torrent ROSA.Desktop.Fresh.2012.i586]<br/><br />
[http://mirror.yandex.ru/rosa/rosa2012.1/iso/ROSA.Desktop.Fresh/ROSA.Desktop.Fresh.2012.x86_64.iso.torrent ROSA.Desktop.Fresh.2012.x86_64]<br/><br />
<br />
== ROSA Marathon 2012 (LTS) ==<br />
* [[Release_notes_ROSA Marathon 2012|Информация о релизе ROSA Marathon 2012]]<br />
* [[Tour_ROSA Marathon 2012|Обзор ROSA Marathon 2012]]<br />
* [[Errata_ROSA Marathon 2012|Список проблем и решений ROSA Marathon 2012]]<br />
* [[Quickstart_guide_ROSA_Marathon_2012|Краткое руководство пользователя]]<br />
* [[Errata ROSA Marathon 2012]]<br />
<br />
{| class="standart" border="0" cellpadding="10" cellspacing="0"<br />
|-<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
<br />
=== ROSA Desktop 2012 LTS MARATHON Extended Edition ===<br />
<br />
{{Версия|32 бит}} Дата выхода: {{Источник|10-May-2012}}<br />
<br />
{{Скачать|[http://mirror.rosalinux.com/rosa/rosa2012lts/iso/ROSA.2012.MARATHON/ROSA.2012.MARATHON.EE.i586.iso Скачать ROSA Marathon 2012 LTS EE (i586)]}}<br />
<br />
{{Версия|64 бит}} Дата выхода: {{Источник|10-May-2012}}<br />
<br />
{{Скачать|[http://mirror.rosalinux.com/rosa/rosa2012lts/iso/ROSA.2012.MARATHON/ROSA.2012.MARATHON.EE.x86_64.iso Скачать ROSA Marathon 2012 LTS EE (x86_64)]}}<br />
<br />
|<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
<br />
=== ROSA 2012 LTS MARATHON Free Edition ===<br />
<br />
{{Версия|32 бит}} Дата выхода: {{Источник|10-May-2012}}<br />
<br />
{{Скачать|[http://mirror.rosalinux.com/rosa/rosa2012lts/iso/ROSA.2012.MARATHON/ROSA.2012.MARATHON.FREE.i586.iso Скачать ROSA Marathon 2012 LTS Free (i586)]}}<br />
<br />
{{Версия|64 бит}} Дата выхода: {{Источник|10-May-2012}}<br />
<br />
{{Скачать|[http://mirror.rosalinux.com/rosa/rosa2012lts/iso/ROSA.2012.MARATHON/ROSA.2012.MARATHON.FREE.x86_64.iso Скачать ROSA Marathon 2012 LTS Free (x86_64)]}}<br />
<br />
|}<br />
<br />
=== '''Торренты''' ===<br />
[http://mirror.rosalinux.com/rosa/rosa2012lts/iso/ROSA.2012.MARATHON.RP1/ROSA.2012.RP1.MARATHON.EE.i586.iso.torrent ROSA.2012.RP1.MARATHON.EE.i586]<br/><br />
[http://mirror.rosalinux.com/rosa/rosa2012lts/iso/ROSA.2012.MARATHON.RP1/ROSA.2012.RP1.MARATHON.EE.x86_64.iso.torrent ROSA.2012.RP1.MARATHON.EE.x86_64]<br/><br />
<br />
[http://mirror.rosalinux.com/rosa/rosa2012lts/iso/ROSA.2012.MARATHON.RP1/ROSA.2012.RP1.MARATHON.FREE.i586.iso.torrent ROSA.2012.RP1.MARATHON.FREE.i586]<br/><br />
[http://mirror.rosalinux.com/rosa/rosa2012lts/iso/ROSA.2012.MARATHON.RP1/ROSA.2012.RP1.MARATHON.FREE.x86_64.iso.torrent ROSA.2012.RP1.MARATHON.FREE.x86_64]<br/><br />
<br />
[http://mirror.rosalinux.com/rosa/rosa2012lts/iso/ROSA.2012.MARATHON/ROSA.2012.MARATHON.EE.i586.iso.torrent ROSA.2012.MARATHON.EE.i586]<br/><br />
[http://mirror.rosalinux.com/rosa/rosa2012lts/iso/ROSA.2012.MARATHON/ROSA.2012.MARATHON.EE.x86_64.iso.torrent ROSA.2012.MARATHON.EE.x86_64]<br/><br />
<br />
[http://mirror.rosalinux.com/rosa/rosa2012lts/iso/ROSA.2012.MARATHON/ROSA.2012.MARATHON.FREE.i586.iso ROSA.2012.MARATHON.FREE.i586]<br/><br />
[http://mirror.rosalinux.com/rosa/rosa2012lts/iso/ROSA.2012.MARATHON/ROSA.2012.MARATHON.FREE.x86_64.iso.torrent ROSA.2012.MARATHON.FREE.x86_64]<br/><br />
<br />
[http://mirror.rosalinux.com/rosa/rosa2012lts/iso/ROSA.2012.MARATHON.LXDE/ROSA.2012.LTS.LXDE.i586.iso.torrent ROSA.2012.LTS.LXDE.i586]<br/><br />
[http://mirror.rosalinux.com/rosa/rosa2012lts/iso/ROSA.2012.MARATHON.LXDE/ROSA.2012.LTS.LXDE.x86_64.iso.torrent ROSA.2012.LTS.LXDE.x86_64]<br/><br />
<br />
[http://mirror.rosalinux.com/rosa/unofficial/ROSA.2012.MARATHON.GNOME/ROSA.2012.MARATHON.GNOME.FREE.i586.iso.torrent ROSA.2012.MARATHON.GNOME.FREE.i586]<br/><br />
[http://mirror.rosalinux.com/rosa/unofficial/ROSA.2012.MARATHON.GNOME/ROSA.2012.MARATHON.GNOME.FREE.x86_64.iso.torrent ROSA.2012.MARATHON.GNOME.FREE.x86_64]<br/><br />
<br />
[http://mirror.rosalinux.com/rosa/unofficial/ROSA.2012.MARATHON.GNOME/ROSA.2012.MARATHON.GNOME.i586.iso.torrent ROSA.2012.MARATHON.GNOME.i586]<br/><br />
[http://mirror.rosalinux.com/rosa/unofficial/ROSA.2012.MARATHON.GNOME/ROSA.2012.MARATHON.GNOME.x86_64.iso.torrent ROSA.2012.MARATHON.GNOME.x86_64]<br/><br />
<br />
=='''Комьюнити-релизы ROSA Marathon'''==<br />
<br />
{|<br />
|&bull;&nbsp;[[Краткое описание ROSA LXDE 2012 LTS]]<br />
|-<br />
|&bull;&nbsp;[[Краткое описание ROSA Marathon 2012 GNOME Edition]]<br />
|}<br />
<br />
<br />
{| class="standart" border="0" cellpadding="10" cellspacing="0"<br />
|-<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
=== ROSA Marathon 2012 GNOME Community Edition (GNOME 2.32) ===<br />
<br />
Версия 32-бит Вышла: 7 августа 2012<br />
<br />
{{Скачать|[http://mirror.rosalinux.com/rosa/unofficial/ROSA.2012.MARATHON.GNOME/ROSA.2012.MARATHON.GNOME.i586.iso Скачать ROSA Marathon 2012 GNOME Edition (i586)]}}<br />
<br />
Версия 64-бит Вышла: 7 августа 2012<br />
<br />
{{Скачать|[http://mirror.rosalinux.com/rosa/unofficial/ROSA.2012.MARATHON.GNOME/ROSA.2012.MARATHON.GNOME.x86_64.iso Скачать ROSA Marathon 2012 GNOME Edition (x86_64)]}}<br />
|<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
<br />
=== ROSA Marathon 2012 LXDE Community Edition ===<br />
<br />
Версия 32-бит Вышла: 20 июня 2012<br />
<br />
{{Скачать|[http://mirror.rosalinux.com/rosa/rosa2012lts/iso/ROSA.2012.MARATHON.LXDE/ROSA.2012.LTS.LXDE.i586.iso Скачать ROSA Marathon 2012 LXDE Edition (i586)]}}<br />
<br />
Версия 64-бит Вышла: 20 июня 2012<br />
<br />
{{Скачать|[http://mirror.rosalinux.com/rosa/rosa2012lts/iso/ROSA.2012.MARATHON.LXDE/ROSA.2012.LTS.LXDE.x86_64.iso Скачать ROSA Marathon 2012 LXDE Edition (x86_64)]}}<br />
|}<br />
<br />
<hr><br />
{|<br />
|&bull;&nbsp;[[Обзор релиза ROSA Desktop 2011 Extended Edition]]<br />
|-<br />
|&bull;&nbsp;[[Обзор релиза ROSA Desktop 2011]]<br />
|-<br />
|&bull;&nbsp;[[2011.0 Errata]]<br />
|-<br />
|&bull;&nbsp;[[2011.0 Errata|Список известных проблем в ROSA Desktop 2011]]<br />
|-<br />
|&bull;&nbsp;[http://wiki.rosalab.ru/images/9/96/QuickStart_2011.pdf Руководство по быстрому старту для ROSA Desktop 2011]<br />
|-<br />
|&bull;&nbsp;[http://wiki.rosalab.ru/images/f/f5/Rosa_desktop_ug.pdf Руководство пользователя ROSA Desktop 2011 (BETA)]<br />
|}<br />
<br />
{| class="standart" border="0" cellpadding="10" cellspacing="0"<br />
|-<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
<br />
==ROSA Desktop 2011==<br />
<br />
{{Версия|32 бит}} Дата выхода: {{Источник|23-Dec-2011}}<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/iso/ROSA.Desktop/ROSA.2011/ROSA.2011.i586.2.iso Скачать ROSA Desktop 2011 (i586)]}}<br />
<br />
{{Версия|64 бит}} Дата выхода: {{Источник|23-Dec-2011}}<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/iso/ROSA.Desktop/ROSA.2011/ROSA.2011.x86_64.2.iso Скачать ROSA Desktop 2011 (x86_64)]}}<br />
<br />
{{Версия|32 бит}} Дата выхода: {{Источник|28-Aug-2011}}<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/iso/ROSA.Desktop/ROSA.2011/ROSA.2011.i586.1.iso Скачать ROSA Desktop 2011 (i586)]}}<br />
<br />
{{Версия|64 бит}} Дата выхода: {{Источник|28-Aug-2011}}<br />
<br />
{{Скачать|[http://mirror.rosalab.ru/iso/ROSA.Desktop/ROSA.2011/ROSA.2011.x86_64.1.iso Скачать ROSA Desktop 2011 (x86_64)]}}<br />
<br />
|<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
<br />
=== ROSA Desktop 2011 Extended Edition ===<br />
<br />
{{Версия|32 бит}} Дата выхода: {{Источник|18-Dec-2011}}<br />
<br />
{{Скачать|[http://mirror.yandex.ru/rosa/iso/ROSA.Desktop/ROSA.2011.EE/ROSA.2011.EE.i586.1.iso Скачать ROSA Desktop 2011 Extended Edition (i586)]}}<br />
<br />
{{Версия|64 бит}} Дата выхода: {{Источник|18-Dec-2011}}<br />
<br />
{{Скачать|[http://mirror.yandex.ru/rosa/iso/ROSA.Desktop/ROSA.2011.EE/ROSA.2011.EE.x86_64.1.iso Скачать ROSA Desktop 2011 Extended Edition (x86_64)]}}<br />
<br />
|}<br />
<br />
Совместно с образовательным проектом [http://www.edumandriva.ru EduMandriva] компания РОСА выпустила релизы ПСПО (Платформы для Свободного Программного Обеспечения). ПСПО6 является достойным продолжением линейки образовательных дистрибутивов и имеет ряд обновлений и улучшений по сравнению с ПСПО4 и ПСПО5.<br />
{|<br />
|&bull;&nbsp;[[Обзор релиза ПСПО6]]<br />
|-<br />
|&bull;&nbsp;[[PSPO6 Errata|Список известных проблем в ПСПО6]]<br />
|}<br />
<br />
<br />
{| class="standart" border="0" cellpadding="10" cellspacing="0"<br />
|-<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
==Релизы ПСПО6==<br />
<br />
{{Версия|32 бит}} Дата выхода: {{Источник|31.12.2011}}<br />
<br />
{{Скачать|[ftp://ftp.mandriva.ru/EduMandriva/iso/PSPO6/PSPO6.kde.RC2.i586.iso Скачать ПСПО6 RC2 (i586)]}}<br />
<br />
{{Версия|32 бит}} Дата выхода: {{Источник|31.01.2012}}<br />
<br />
{{Скачать|[ftp://ftp.mandriva.ru/EduMandriva/iso/PSPO6/PSPO6.kde.RC.i586.iso Скачать ПСПО6 RC1 (i586)]}}<br />
<br />
|}<br />
<br />
Релизы ROSA Desktop 2011 GE (Gnome Edition) выпускаятся '''сообществом''' пользователей РОСА.<br />
<br />
{| class="standart" border="0" cellpadding="10" cellspacing="0"<br />
|-<br />
| width="49%" valign="top" style="border-style:solid;border-width:1px;border-color:#7EB7ED;"|<br />
<br />
==ROSA Desktop 2011 GE==<br />
<br />
{{Версия|32 бит}} Дата выхода: {{Источник|30-Jan-2012}}<br />
<br />
{{Скачать|[http://mirror.yandex.ru/rosa/iso/unofficial/ROSA.Desktop.2011.GNOME.Edition.Beta/ROSA.Desktop.2011.GNOME.Edition.Beta.i586.iso Скачать ROSA Desktop 2011 GE Beta (i586)]}}<br />
<br />
{{Версия|64 бит}} Дата выхода: {{Источник|30-Jan-2012}}<br />
<br />
{{Скачать|[http://mirror.yandex.ru/rosa/iso/unofficial/ROSA.Desktop.2011.GNOME.Edition.Beta/ROSA.Desktop.2011.GNOME.Edition.Beta.x86_64.iso Скачать ROSA Desktop 2011 GE Beta (x86_64)]}}<br />
<br />
|}<br />
<br />
[[en:ROSA Release]]<br />
[[Категория:Документация]]</div>
Vladimir.potapov