[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