From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on sa.int.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_OPENWHOIS,SPF_PASS autolearn=no version=3.2.5 Date: Fri, 1 Apr 2011 12:30:06 +0300 From: Igor Vlasenko To: devel@lists.altlinux.org Message-ID: <20110401093006.GA22567@dad.imath.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.20 (2009-08-17) Subject: [devel] www.altlinux.org/Incoming_Tests_Policy X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 09:30:11 -0000 Archived-At: List-Archive: List-Post: Уважаемые коллеги, обнаружил, что у нас более года лежит в статусе драфта написанное Михаилом Шигориным Incoming Tests Policy. хоть текст написан и год назад, актуальным и злободневным остается и сейчас. Если нет возражений, давайте примем как полиси. ============================================================= Incoming Tests Policy Черновик политики Sisyphus Автор(ы) mike@ Обсуждение в devel@ Обсуждается с 18.05.2010 * Полиси добавления тестов на сборку Этот черновик политики регламентирует процесс внесения изменений в набор тестов, производимых при сборке пакета в репозиторий ALT Linux. * Обоснование Поскольку людям свойственно ошибаться, тесты являются полезным средством отлова типичных ошибок но в то же время сами могут содержать ошибки либо решать некорректно поставленную задачу. * Процесс При добавлении нового теста необходимо анонсировать его в devel@ вместе с результатами предварительной обкатки, если таковая была (таковая обычно включает пересборку Sisyphus). При добавлении нового теста, претендующего на возможность блокирования сборки, необходимо: * либо проведение предварительного внедрения теста с работой в режиме предупреждения в течение месяца с отсутствием непредвиденных и неисправленных ложных срабатываний; * либо отсутствие существенных замечаний по опубликованным результатам обкатки в течение недели; * либо аргументированное мнение ответственного (ответственных) за сборочную инфраструктуру и репозиторий о критичности срочного развёртывания именно в потенциально блокирующем режиме. Разработчикам потенциально блокирующих тестов желательно также воспользоваться таким пилотным периодом с тем, чтобы оценить непредвиденные обстоятельства и иметь возможность помочь коллегам с исправлением тех из обнаруженных проблем, которые сочтены автором теста заслуживающими исправления, но не могут быть исправлены в разумное время майнтейнером пакета. -- Dr. Igor Vlasenko -------------------- Topology Department Institute of Math Kiev, Ukraine