[devel] Re: P: разделение критичности проверок для base..contrib
Denis Smirnov
=?iso-8859-1?q?mithraen_=CE=C1_freesource=2Einfo?=
Пт Июн 17 14:01:33 MSD 2005
Michael Shigorin wrote:
>Я не говорю о том, что искать баги (и по возможности это
>автоматизировать) не надо. Но и не забываю "если вы будете
>писать нам cron'ом, мы будем читать вас procmail'ом".
>
>Бишь баланс между силами и средствами на поиске и исправлении
>проблем -- важнее.
>
>
Бесспорно. Впорос лишь где он проходит.
>>Идеальный подход, это когда сообщение об ошибке при сборке
>>будет содержать в себе ссылку на страничку wiki.sisyphus.ru,
>>содержащую полное описание проблемы, как её решить, или как
>>отключить эту проверку. Благо всегда можно полностью
>>автоматически найти пакеты, где конкретная проверка отключена,
>>и попытаться их исправить.
>>
>>
>Ну, самодокументированность вообще хорошее свойство.
>
>
Кто бы спорил. Но даже с нынешними проверками надо долго иногда голову
работать, что не так (это я про verify_elf, который хоть и не слишком
часто, но вызывает вопросы).
>>MS> Подумай. Собственно, одно дело -- мягко долбить темечко, причём
>>MS> для contrib -- не роботом, а варнингами при сборке, и саавсем
>>MS> другое -- unmet'ы генерить.
>>Может просто для contrib по-умолчанию _отключать_ отдельные
>>проверки?
>>
>>
>А я о чём говорю? (правда, не отключать, но делать нефатальными
>-- чтоб заметить было можно, но, например, вопросы TEXTREL после
>повторного изучения темы никак не могу считать критическими)
>
>
IMHO ситуация с ними сейчас правильная, если бы в сообщении об ошибке
была ссылка на объяснение что это такое, с чем едят, почему вредно, как
отключить это проверку нафиг.
До тех пор, пока мантейнер может легким движением руки отключить
проверку -- эту проверку имеет смысл делать.
Подробная информация о списке рассылки Devel