[devel] Re: мысли о 3.0, dev cycles и "кому что надо"

[Michael Shigorin <mike@osdn.org.ua>]

[-- Attachment #1: Type: text/plain, Size: 7888 bytes --]

PreScriptum:
> > > Я что-то хотел сказать про стабильность сизифа.
> > Это тупик.
> Да.  Рассматриваются варианты выхода из тупика.
> Но по существу, а не хорошая мина при плохой игре.

Вот, пытаюсь обдумать, обрисовать фреймворк, в котором участники
могли бы заниматься интересным/полезным для себя делом с общим
вектором и результатами по мере делания.

Пока напоминает разговор с зеркалом -- в том плане, что мы с
тобой вряд ли скажем много нового друг другу по этому вопросу.



PreScriptum:
> > С ещё одной стороны, дистрибутив -- это элементная база для
> > суппорта.  Если у тебя сгорел МП42Б и заменить его нечем --
> > всё, приплыли, надо было сразу думать про китайские.
> В этой дискуссии действительно всё смешалось, в том числе уже и
> жалость к суппорту (и даже германевые транзисторы
> отечественного производства).

Да, и это плохо.  Но узел действительно весьма сложный,
и у меня опять рвёт крышу от очередной попытки его
проанализировать и порубать.

Впрочем, не думаю, что многие добрались до этого места треда...




On Mon, Apr 04, 2005 at 10:53:31PM +0400, Alexey Tourbin wrote:
> То есть я не верю в неоднородность технологического процесса

И тем не менее она есть.  И определяется в т.ч. сезоном года и
летне-осенней разницей в той же (извиняюсь) деловой активности.

Это влияет и на волонтеров, и на участников по более ощутимым
поводам, и на core team.

> и выражаю скептическое отношение к "стабилизации" и
> "стабильности".  По меньшей мере применительно к текущей
> ситуации в ALT (не верю ли вообще -- это более сложный вопрос).

Вот это и есть проблемой.  Поскольку опыт всё тех же linux kernel
и mozilla показывает, что при управлении развитием проекта,
доходя до уровня "принимаем ли мы конкретно это изменение
сейчас?" и не чувствуя этого вот периода "развалили/собрали" --
качество хромает на обе ноги.

Вот, пока гуглил статью про то, как товарищи из mozilla project
искали оптимум по своему циклу -- нашёл старую (2000) статью.
Подпишусь отнюдь не под каждым словом, но много здравых мыслей
есть: http://www.welchco.com/02/14/01/60/00/10/3101.HTM

 But many OSS projects fail because of friction within the teams
 [...] As a rule, OSS projects do best when one person is the
 clear leader of a team and makes the big decisions (design
 changes, release dates, and so on).
 
 
 Let's state it plainly: Alpha is not Beta. Beta is not Release.
 Repeat that several times until it sticks. [...] What we need is
 a commitment to release software in a more regularized way - the
 users need this information to plan for deployments and future
 upgrades.

В частности, не согласен вот с этим:

 The first rule is to avoid placing blame (even on yourself!)

Столько говорить об ответственности и закончить
безответственностью -- эт круто. :)  По крайней мере
_свои_ ошибки действительно важно уметь признать.

> > Что интересно, BE тоже входит в платформу -- с hasher в ALM2.4
> > появился дешёвый штатный метод собираться на нём автономно.
> Да.  Тогда надо только автоматизировать изготовление обновлений
> до такой степени, чтобы "глаза мои не глядели". :)  Предлагаю
> подумать, как это может внешне выглядеть.
> $ patch_rpm -m 'fixed buffer overflow (CAN-2006-007)' \
> 	-p ~/RPM/SOURCES/$package-$version-deb-CAN-2006-007.patch \
> 	~sisyphus/SRPMS.classic/$package-$version-alt1.src.rpm
> Например так.  И дальше в хэшер.  Чего не хватает, чтобы
> написать такой скрипт?  Не хватает алгоритма изменения релиза.
> Если его записать, то дело в шляпе.

Ну где-то так по части засовывания -- тут действительно есть
элемент рутины.

> (Ещё бы нужно подумать над скриптом, который автоматически
> извлекает дебиановские патчи :))

...а также подтачивает, если отваливаются или перехлёстываются с
уже накладываемыми? :)

> Что я хочу сказать в связи с этим.  Обновление можно выпускать
> формально, только чтобы отчитаться по закрытой дырке (тогда
> невыпуск некоторых обновлений можно рассматривать как
> безответственность).  Но такой формальный подход вступает в
> противоречие с энтузиазмом и пр.

Зато не вступает в противоречие с ответственностью фирмы за
продукт, а также (чтоб не размахивать этой красной тряпкой,
достаю зелёную) чтобы суппорт не корячился с патчами -- или
не дрожал, что щас жахнут.

Боюсь, это _энтузиазм_ может противоречить необходимости, но 
это значит ровно то, что не надо полагаться на энтузиастов
здесь.  А или на фултаймеров, или на тех, кому оно действительно
*надо*.

> В противоположность формальному подходу имманентный подход

Proactive security approach?  Да ладно, больше того, что делает
Дима -- вряд ли получится в обозримом будущем без опять же
реально заинтересованных.

> К тому же многие пользователи очень хотят новые версии софта
> (особенно это касатеся KDE:)).  В связи с чем встает вопрос о
> нише дистрибутивов ALT вообще.

О!

> Если ALM24 не тянет на enterprise уровнь (что для меня вполне
> очевидно)

Именно.

> то это дает повод задуматься об альтернативном технологическом
> процессе, который исключает этап стабилизации (и подразумевает
> некую "текущую" стабильность).

Это даёт повод задуматься о том, чтобы спросить себя и других --
зачем вообще этот проект и чем именно он интересен.

И исходя из ответов делать выводы.

Для меня проект интересен тем, что собралось хорошее сообщество
как разработчиков, так и пользователей (это само по себе ценно)
и тем, что его "материальный" результат -- дистрибутивы --
получалось улучшать (при том, что степень их готовности к работе
после развёртывания была весьма и весьма).

Плохо то, что девелоперы, даже лучшие, но предоставленные самим
себе -- без сколь-нибудь ясного видения _общего_ пути и такой
банальности, как пинание время от времени (внешний организующий
фактор, когда не хватает самоорганизации и координации в группе)
-- они пролетают.  Особенно когда склонность изобретать колесо,
не глядя по сторонам (бо мы ж самые крутые) и так есть.

> Здесь обычно встает вопрос о трафике: неужели для обновления
> KDE придётся скачивать и обновлять ещё пол-систетемы.  Но это
> вопрос о бедных и обездоленных, которые хотят, чтобы к ним
> проявили жалось.

Ну так это-то решено -- активные из обездоленных идут в backports
и делают, что надо.  Опять же Зерг Мороз (сорри! :) вон подарки
им принёс, как раз KDE под 2.4. :)

> > Если серьёзно -- см. выше.  Фундаментальной разработки
> > линуксов как науки с грантами и приемлемостью _такого_ уровня
> > разгильдяйства -- в xSU не наблюдаю.
> Это какие ещё гранты?  По которым бумажки пишут?
> А при чем здесь фундаментальная разработка линуксов? :)

Вот и я говорю -- ни при чём.

> > Чтобы жить, оно должно пользу приносить.  А для этого --
> > стоять в производстве, точка.
> Может и так.  Тогда оно в этом смысле пока нежизнеспособно.

Местами способно, но только если Слишком Много Знать.
Что неприемлемо.

> > > Ох.  Я говорю про проект Sisyphus, который некоммерческий и
> > Так он никому всерьёз не нужен без коммерческой нотки в финале.
> Да??? :)

Всерьёз -- да.

> > Ну я рад за тебя, но тогда искренне не понимаю предыдущей
> > переписки.  Может, просто её забыть?
> Я "передумал".  Стал более хладнокровным, что ли.

Понимаю.

> > Второй в нём смысл -- как в платформе.
> В каком смысле "платформа"?

То, на чём можно строить.  Не пески зыбучие.

> > > Во-первых, это не так: бизнеса на дистрибутивах не сделаешь
> > С другой стороны, он вроде и не убыточен.
> С другой стороны, какие имеются достаточные основания?

Прибыльность субпроекта может быть достаточным основанием.

> Потому что все так делают?  То, что делают все, заведомо плохо. :)

Но не заведомо полностью и на корню.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]