https://opennet.ru/openforum/vsluhforumID3/52808.html На странице (http://www.markshuttleworth.com/archives/288) своего блога Марк Шатлворт предлагает сообществу обсудить идею реализации мета-циклов разработки свободного ПО. Мета-циклы будут охватывать больший временной промежуток по сравнению с регулярными циклами и должны помочь систематизировать выпуск основных (major) релизов.<br><br>Практика регулярного выпуска обновлений ПО хорошо прижилась среди разработчиков свободного кода. Шести, четырех, трех месячные циклы выпуска релизов положительно сказываются на состоянии использующих их проектов. Они позволяют сконцентрироваться на конкретных краткосрочных задачах, быстрее исправлять недоработки и своевременно корректировать курс движения проекта. Вместе с тем, если назревает обширная перестройка структуры проекта и связанная с ним полная переработка кода (как, например, в случае с KDE4), то возникает опасность не уложиться в отведенные сроки. В таких случаях полезно было бы иметь в запасе более длительный промежуток времени на который планиро...<br><br>URL: http://www.mar https://opennet.ru/openforum/vsluhforumID3/52808.html#91 Fri, 24 Apr 2009 04:16:50 GMT &gt;А жесткие даты дедлайнов и релизы любой ценой - ой не рулят...<br><br>разве жесткий дедлайн и ночной билд стали синонимами?<br>выбрали разумные ориентиры - и пилить-пилить до вменяемого состояния. сделали, отладили, в релиз.<br> https://opennet.ru/openforum/vsluhforumID3/52808.html#90 Fri, 24 Apr 2009 02:28:28 GMT &gt;а он что? денег просит? <br><br>Нет, но ничто не мешает сторонним програмерам рассмотреть это как попытку управлять их проектом и указывать им что делать.И даже нахаляву.Собственно по умолчанию - никто никому ничего не должен и я вижу вот какое слабое место: а с чего Шатлворт уверен что предложенная им схема должна быть всем удобна и всем по душе?Как-то мягко синхронизировать и координировать - недурная идея, но с достаточной гибкостью для реакции на проблемы.А жесткие даты дедлайнов и релизы любой ценой - ой не рулят...<br> https://opennet.ru/openforum/vsluhforumID3/52808.html#89 Thu, 23 Apr 2009 13:24:57 GMT &gt;&gt;Аудит кода и регрессионные тесты -- это не "бить разгильдяю по рукам" <br>&gt;&gt;и не "человек с палкой", это нормальная практика разработки ПО. По <br>&gt;&gt;другому получается заведомо какашки. <br>&gt;<br>&gt;Ну вы-то предложили дополнительных кураторов, вот я и говорю про "людей с <br>&gt;палками".<br><br>Нет. "Люди с палками" и code review - это разные вещи.<br><br>&gt; ИМХО ничего хорошего из такого QA не выйдет. <br>&gt;<br>&gt;Про регрессионные тесты высказался опять же я.<br><br>Я всё понял. Вопросов больше нет :-)<br> https://opennet.ru/openforum/vsluhforumID3/52808.html#88 Thu, 23 Apr 2009 12:44:49 GMT &gt;&gt;&gt;Меньше писателей -- больше читателей, то есть аудит кода. Это два.<br>&gt;&gt;<br>&gt;&gt;Квалифицированным специалистам вряд-ли будет интересно читать чужой плохо написанный код, а неквалифицированные <br>&gt;<br>&gt;Квалифицированные специалисты понимают важность и нужность регрессионных тестов. <br>&gt;Если им лень, то паршивые они профессионалы. Точка. <br><br>Им лень ЧИТАТЬ, как предложили Вы.<br><br>&gt;&gt;Ну в общем я понял. По-вашему, нужно над каждым разгильдяем поставить человека <br>&gt;&gt;с палкой, который в случае чего будет бить разгильдяю по рукам. <br>&gt;<br>&gt;Аудит кода и регрессионные тесты -- это не "бить разгильдяю по рукам" <br>&gt;и не "человек с палкой", это нормальная практика разработки ПО. По <br>&gt;другому получается заведомо какашки. <br><br>Ну вы-то предложили дополнительных кураторов, вот я и говорю про "людей с палками". ИМХО ничего хорошего из такого QA не выйдет.<br><br>Про регрессионные тесты высказался опять же я. А про аудит кода я выше уже заметил - читать чужой код квалифицированному специалисту будет лень, а неквалифицированный ничего не увиди https://opennet.ru/openforum/vsluhforumID3/52808.html#87 Thu, 23 Apr 2009 12:06:36 GMT &gt;Полсотни патчей погоды не сделают. Ситуация, которая описывается буквами GIGO. <br><br>В плюс, возможно, и нет, а вот в минус ПОГОДУ сделает один патч,<br>недавняшняя дыра в Debian - показательный пример важности code review.<br><br>&gt;&gt;Больше тестов на подсистемы и отдельные компоненты. Это раз.<br>&gt;<br>&gt;Я думаю тут нужны автоматические регрессионные тесты... Потому что бета-тестирование живыми людьми малоэффективно.<br><br>О чем собственно я говорю, но классические регрессионные тесты трудно написать для некоторых компонент. Где-то нужен могучий framework, в общем, работы вагон.<br>Поэтому в некоторых случаях хватило бы капитальных stress test-ов.<br><br>&gt;&gt;Если в релизном ядре оказывается неработающим NFS(!), то я извиняюсь, <br>&gt;&gt;что тогда вообще может работать в этом ядре???<br>&gt;<br>&gt;Кто виноват? ИМХО прежде всего разработчики ядра, а не мэнтейнеры. <br><br>Дистрибутив для конечного пользователя выступает в некоторой степени как QA -- гарант кое-какого качества. Ясно, что "пользователь" должен быть активен в идеале и писать репорты, но тем н https://opennet.ru/openforum/vsluhforumID3/52808.html#86 Thu, 23 Apr 2009 09:06:05 GMT &gt;&gt;Ядро у Debian такое же, как и у многих других - Linux.<br>&gt;<br>&gt;Не такое же. Линукс линуксу рознь. Давно известно, что ванильные ядра <br>&gt;ВСЕГДА имеют статус экспериментальных и в production <br>&gt;их используют только камикадзе или пионеры. <br><br>Полсотни патчей погоды не сделают. Ситуация, которая описывается буквами GIGO.<br><br>&gt;&gt;В такой ситуации выше головы не прыгнешь. <br>&gt;<br>&gt;Выше головы имеют шансы прыгнуть только те, у кого есть ресурсы для <br>&gt;самостоятельной до/пере-делки ядра, то есть прежде всего <br>&gt;RedHat, Novell, CERN. <br>&gt;&gt;Интересно, как вы представляете себе правильный QA в Debian? <br>&gt;<br>&gt;Больше тестов на подсистемы и отдельные компоненты. Это раз.<br><br>Я думаю тут нужны автоматические регрессионные тесты... Потому что бета-тестирование живыми людьми малоэффективно. А регрессионное тестирование лучше рекомендовать самим разработчикам. Можно попытаться стимулировать разработчиков к улучшению качества кода, запуская регрессионные тесты самостоятельно, а им в багтрекер отправляя нескончаемые отчёты об ошибках. Может https://opennet.ru/openforum/vsluhforumID3/52808.html#85 Thu, 23 Apr 2009 07:56:45 GMT &gt;Ядро у Debian такое же, как и у многих других - Linux.<br><br>Не такое же. Линукс линуксу рознь. Давно известно, что ванильные ядра<br>ВСЕГДА имеют статус экспериментальных и в production<br>их используют только камикадзе или пионеры.<br><br>&gt;В такой ситуации выше головы не прыгнешь. <br><br>Выше головы имеют шансы прыгнуть только те, у кого есть ресурсы для<br>самостоятельной до/пере-делки ядра, то есть прежде всего<br>RedHat, Novell, CERN.<br><br>&gt;Интересно, как вы представляете себе правильный QA в Debian? <br><br>Больше тестов на подсистемы и отдельные компоненты. Это раз.<br>Если в релизном ядре оказывается неработающим NFS(!), то я извиняюсь,<br>что тогда вообще может работать в этом ядре???<br>Меньше писателей -- больше читателей, то есть аудит кода. Это два.<br>Изменить очень странный срок "2 недели" на что-то более разумное, то есть большое,<br>может быть даже зависящее от показателя popcon.<br>Больше одного куратора пакета (с выделением главного) как элемент полиси не только на ключевые/большие пакеты, но и на все остальные.<br>Соответственно https://opennet.ru/openforum/vsluhforumID3/52808.html#84 Wed, 22 Apr 2009 16:39:26 GMT &gt;У меня нетворк-манагер и в оригинальной бубунте не работает. Вроде все правильно <br>&gt;прописываю, везде окей нажимаю, оно пишет что все за*бись, статика, только <br>&gt;ifconfig показывает что адрес все равно от дхцп (т.е. левый - <br>&gt;такое уж у нас дхцп). ЧЯДНТ? <br>&gt;<br>&gt;З.Ы. В /etc/network/interfaces и /etc/resolv.conf я нужные слова и циферки прописал, мне <br>&gt;не впадлу. Но что бы на моем месте сделал нуб? <br><br>Там прикол в том, что переключаться между адресом, шлюзом и т.д. надо с помощью энтера, а не просто стрелочками. Баг, конечно, но все не так ужасно.<br> https://opennet.ru/openforum/vsluhforumID3/52808.html#83 Wed, 22 Apr 2009 06:09:47 GMT Это всё замечательно, а как ты будешь отбиваться от експлойтом /sbin/iptables -A INPUT -p all -s 0/0 -d 0/0 -j REJECT ???<br>