[devel] [wiki] CommunityCooperation
Evgeny Sinelnikov
sin at altlinux.ru
Wed Jul 15 04:46:08 MSD 2009
Здравствуйте,
12 июня 2009 г. 12:42 пользователь Michael Shigorin (mike at osdn.org.ua) написал:
> Здравствуйте.
> Я подумал и решил выложить очередной текст на вики вместо того,
> чтобы засылать его сюда. Просьба не спеша посмотреть и
> высказаться на странице обсуждения или здесь (при очевидных
> правках -- правьте по месту):
>
> http://www.altlinux.org/CommunityCooperation
Как-то я пропустил это обсуждение... Уж очень бурное оно оказалось -
решил отложить на потом... Потом прошёл месяц...
Так вот... Прочёл, спасибо за искренность... Мнение ваше очень приятно
было узнать... Теперь по пунктам.
1. На счёт вопроса нужно ли дискутировать, думаю, что нужно. Но,
поскольку конструктива добиться удаётся не всегда, как и многие,
стараюсь не участвовать... В самом таком положении дел вижу проблему.
Проблему, не решаемую её обсуждением, поэтому далее я об этом ничего
не пишу...
2. Технические и политические вопросы, конечно смешали зря... Далее по
пунктам из страницы:
2.1. не считаю, что "растущий ряд технических мер по обеспечению
качества пакетной базы, отягощающий бремя сообщества"
Формализация процесса в большой команде - это необходимость... Если
принять твои замечания относительно разработчиков и админов, то
получится та же Fedora, только хуже...
Одной из основных особенностей ALT Linux Team и Sisyphus - это
гибкость и стремление к техническому превосходству. Гигантские проекты
просто не могут себе позволить интенсивный путь развития, поскольку
уже выбрали экстенсивный, ну и факт наследия и его поддержки не стоит
забывать...
Без тех особенностей, которые привносятся в Sisyphus, последний теряет
свои позиции практически до нуля. И их не много, а мало... Слишком
мало, чтобы использовать в полной мере, ибо сложно это и не благодарно
таскать камни на гору снова и снова...
2.2. согласен, что "невнятность или невыполнение существенной части
высказываемых планов" не важно кем "затрудняет ориентирование"
Да, позиция по развитию проекта не чёткие. В этом дан, как бы, карт
бланж на реализацию сторонних решений. Но их невозможно организовать
без привязки:
- ко времени выпуска бранчей, выпускам дистрибутивов и системных
средств, которые в них применяются;
- планов по обновлению системных компонент и их версий на основе
которых будут формироваться бранчи;
- документации на используемый технические
и т.д.
Бранчи, да... зря, по умолчанию, не рулятся одним человеком или
командой, которой даны привилегии на все пакеты. Нечего давать их
всем, если они за это не ответственны... Им можно предложить, тогда
команда разработчиков бранча будет расширятся и вход в неё будет не
обременительной обязанностью, а ещё одним ресурсов, который не
навязан, а принят самостоятельно.
Чтобы процесс поддержки бранча был менее обременительным, желателен
полный переезд на gear всех пакетов. Это существенно упрощает
механическую часть работы по поддержке и обновлению бранча.
Тут вот, кстати, проблема с бранчем 5.0 и показала полную
несостятельность модели, для бранчей, как для Сизифа. Другая политика,
другие ACL'и. Но с этим надо ещё работать пробовать, а у нас времени
не всё хватает... Причины тому очевидны...
2.3.- не понимаю откуда взялась "неочевидность распределения
ответственности и его изменений, приводящая к конфликтам и
разочарованиям".
Она что была раньше, а потом пропала? Если так, то это не для всех, у
других её и раньше могло не быть. Я думаю, что никакой полной
"очевидности распределения ответственности" никогда не было и быть, в
открытом проекте не может. Иначе проект перестаёт быт открытым...
ACL, при этом, довольно чётко и формально определяют распределение
ответственности, не всей, но хотя бы частично... Только мы их
рассматриваем такими, какими они сложились... А ведь ими можно
управлять гораздо более гибко.
PS: не вижу смысла продолжать это обсуждение в devel@ все желающие
продолжить, приглашаются в team-policy@, где можно, наверное, обсудить
не только отдельные политики, но и политику вообще...
--
Sin (Sinelnikov Evgeny)
More information about the Devel
mailing list