Incoming Tests Policy: различия между версиями

Материал из ALT Linux Wiki
(init)
 
Нет описания правки
 
(не показано 8 промежуточных версий 3 участников)
Строка 1: Строка 1:
{{DraftPolicy
{{Policy|since=10.04.2011|responsible=mike@}}
|responsible=mike@
|discussion_link=http://lists.altlinux.org/pipermail/devel/2010-May/182183.html
|discussion_since=мая 2010 (как минимум)
}}
 
== Полиси добавления тестов на сборку ==
== Полиси добавления тестов на сборку ==
Этот черновик политики регламентирует процесс внесения изменений в набор тестов, производимых при сборке пакета в репозиторий ALT Linux.
Этот черновик политики регламентирует процесс внесения изменений в набор тестов, производимых при сборке пакета в репозиторий ALT Linux.


=== Обоснование ===
=== Обоснование ===
Поскольку людям свойственно ошибаться, тесты являются полезным средством отлова типичных ошибок -- но в то же время сами могут содержать ошибки либо решать неправильно поставленную задачу.
Поскольку людям свойственно ошибаться, тесты являются полезным средством отлова типичных ошибок, но в то же время сами могут содержать ошибки либо решать некорректно поставленную задачу.


=== Процесс ===
=== Процесс ===
При добавлении нового теста '''необходимо''' анонсировать его в [https://lists.altlinux.org/mailman/listinfo/devel-announce devel-announce@] вместе с результатами предварительной обкатки, если таковая была (таковая обычно включает тестовую пересборку Sisyphus).
При добавлении нового теста, претендующего на возможность блокирования сборки, '''необходимо''':
При добавлении нового теста, претендующего на возможность блокирования сборки, '''необходимо''':
* либо проведение предварительного внедрения теста с работой в режиме предупреждения в течение месяца;
* либо проведение предварительного внедрения теста с работой в режиме предупреждения в течение месяца с отсутствием непредвиденных и неисправленных ложных срабатываний;
* либо аргументированное мнение ответственного (ответственных) за сборочную инфраструктуру и репозиторий о критичности спешного развёртывания именно в потенциально блокирующем режиме.
* либо отсутствие существенных замечаний по опубликованным результатам обкатки в течение недели;
* либо аргументированное мнение ответственного (ответственных) за сборочную инфраструктуру и репозиторий о критичности срочного развёртывания именно в потенциально блокирующем режиме.


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

Текущая версия от 15:40, 10 апреля 2011

Stamp90cw.png
Действующая политика Sisyphus

Политика действует с 10.04.2011.

Ответственный за проведение политики в жизнь — mike@.


Полиси добавления тестов на сборку

Этот черновик политики регламентирует процесс внесения изменений в набор тестов, производимых при сборке пакета в репозиторий ALT Linux.

Обоснование

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

Процесс

При добавлении нового теста необходимо анонсировать его в devel-announce@ вместе с результатами предварительной обкатки, если таковая была (таковая обычно включает тестовую пересборку Sisyphus).

При добавлении нового теста, претендующего на возможность блокирования сборки, необходимо:

  • либо проведение предварительного внедрения теста с работой в режиме предупреждения в течение месяца с отсутствием непредвиденных и неисправленных ложных срабатываний;
  • либо отсутствие существенных замечаний по опубликованным результатам обкатки в течение недели;
  • либо аргументированное мнение ответственного (ответственных) за сборочную инфраструктуру и репозиторий о критичности срочного развёртывания именно в потенциально блокирующем режиме.

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