[Tartarus] Предложение на изменения планов на релизы Tartarus

Вс Мар 8 00:14:10 MSK 2009

7 марта 2009 г. 18:02 пользователь Vitaly Lipatov <lav на etersoft.ru> написал:
> В сообщении от 7 марта 2009 Dmitriy M. Maslennikov написал(a):
>> 7 марта 2009 г. 14:27 пользователь Vitaly Lipatov <lav на etersoft.ru> написал:
>> > Я уже давно умоляю выпустить нечто, минимально работающее, но по
>> > различным причинам публикация всё откладывается и откладывается.
>>
>> Видимо, очень тихо. Лично я догадывался о том, что надо что-то
>> выпустить, поскольку это всегда надо и чем раньше, тем лучше. Открытым
>> текстом такое услышал только месяц назад.
> Ну функции репродуктора исполнял Женя.
>

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

>> > 3446  P4  Выпуск релиза 0.8.2 Tartarus на Etersoft - Альфа 3  -23 (13 Feb
>> > 09)
>>
>> Он видимо станет нашим первым релизом, так как вполне работоспособен.
> Тогда надо скорректировать дату, я так понимаю, запаздывание будет на
> месяц-полтора.
>

Кроме даты нужно уточнить форму утверждения релиза... Сейчас я это
делаю некоторым набором ручных действий на двух виртуальных машинах,
заменяющих мне стенд. Хотелось бы завершать процесс выпуска доп.
тестами. Чтобы исключить применения разработчиками недокументированных
возможностей, это стоит делать отдельно...

> ...
>> >> По моему мнению нам не хватает для стабильного релиза:
>> >> - Внедрения новойреализации nss_tartarus - старая течет
>> >
>> > Это не критично.
>>
>> Ок, перенесем.
> Я имел в виду, что ориентация на функционал подразумевает, что все детские
> болезни - тормоза, большой объём, утечки памяти, баги, лёгкая
> нестабильность - не критичны для релиза.
> Релизы надо делать чаще, просто наладить их выпуск поавтоматичнее.
> Разработку же "в стол" никто не оценит/
>

Это всё ясно... Поскольку я всё-таки опакетил всё необходимое в сизиф
и портировал на бранч 4.1, то всё что мы сейчас делаем в рамках 0.8.x
- это отлаживаем среду, создаём задел в виде клиентских утилит и
параллельно готовимся начать использовать политики... Это в точности
соответствует плану:
http://www.tartarus.ru/wiki/tartarus/Plans

>> >> - Некоторых небольших доработок в DHCP - иначе все будут плеваться,
>> >> когда будут его использовать
>> >> - Утилиту для управления DNS - она не сложная - много времени занять не
>> >> должна
>> >
>> > Альтернативы утилите есть?
>>
>> Нет. Но она действительно очень простая. За день напишу.
> Хотелось бы, чтобы понимать, о чём речь, почитать некую спецификацию к ней
> (требования).
>

Ну, "за день" это то, что она заработает, а не то, что ты её отдашь и
мы забудем её обновлять на долгое время....

>> >> - Консольную утилиту для создания, просмотра и удаления
>> >> пользователей - тоже очень просто
>> >
>> > Нельзя ли для просмотра использовать getent passwd,
>>
>> Нет. Вычитывать всех пользователей вредно, так как их может быть очень
>> много. Поэтому наш nss-модуль отдает пустой список (winbind, например,
>> так тоже умеет).
> Мне кажется, это стоит сделать настраиваемым. Почему windbind умеет, а у нас
> по-умолчанию? Очень медленно отдаём пользователей.
> Я только к тому, что getent passwd - это привычное средство отладки.

getent passwd у нас работает, для этого нет необходимости перебирать
всех пользователей. Перечисления действительно обычно не требуется
поэтому, по умолчанию, в winbind оно тоже отключено...

>
>> > а для создания и удаления - passwd?
>>
>> passwd может только менять пароль. Нужны useradd, userdel, usermod.
> Да, я оговорился, конечно я имел в виду весь этот набор.
>> При том, что вся эта кухня в POSIX не модульная, так что придется
>> написать. По дню на утилиту, плюс два дня на возможные сложности.
> Убедительная просьба найти по возможности популярный аналог и сделать
> интерфейс как можно более приближенным к нему.
>

Да, стоит посмотреть на pw от FreeBSD и избавить его от архаизмов... В
рамках управления системой я думаю, нужно смотреть в сторону сервисов,
управляемых через DBus для управления локальными ресурсами и Ice - для
управления сетевыми...

>> >> - Упорядочить сборку/установку
>> >
>> > Я не смог найти на сайте перечень репозиториев, в которым лежат те, или
>> > иные компоненты.
>> > Например, пытаясь, найти коммит, упомянутый в
>> > http://tartarus.ru/issues/show/127#change-279
>> > не преуспел.
>> > Возможно есть какие-то проблемы с публикацией репозиториев, или искать
>> > надо не в
>> > http://git.etersoft.ru/people/rlz/packages/Tartarus-core.git
>> > ?
>>
>> Просто такого центрального места нет, поскольку используется girar от
>> ALTLinux, а они не делают центральных репозиториев. Сейчас каждый
>> коммитит к себе и время от времени мержится с соседями. Кроме того,
>> есть еще репозитории у нас на сервере в Саратове, так что, возможно, я
>> не выложил самый свежий на сервер. Будет полиси по этому поводу -
>> будем придерживаться.
> Мне кажется полиси тут очевидно. Дискуссию по поводу целесообразности
> раздельных репозиториев в случае совместной работы мы проведём отдельно,
> здесь я хотел бы сказать две вещи:
>
> 1. запускаемый перед уходом с работы скрипт, публикующий во все нужные
> публичные репозитории - элементарен.

Я тоже не вижу в этом проблемы... это можно решить разными способами...

> 2. трудности центрального места преувеличены, у нас есть достаточный опыт
> использования http://git.etersoft.ru/projects/, где репозиторий доступен на
> запись всем состоящим в группе разработчиков конкретного проекта.
>

Подход, когда робот публикует результаты сборки разных людей в одном
репозитории мне кажется более подходящим для git, на workflow же
технические детали реализации общего репозитория влияют не много...

>> > Не смог найти, где разрабатывается SysDB:
>> > http://git.etersoft.ru/people/iv/packages/
>>
>> Возможно, что он не выкладывал свои наработки в общедоступный
>> репозиторий...
> По датам обновления репозиториев это очевидно, но мне бы хотелось понять,
> каких таких административных средств не хватает для того, чтобы работа над
> проектом велась открыто и с возможностью соучастия.
>

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

Следующая эволюционная веха проекта - это дерево объектов и
политики... без них остаётся придумывать эти самые политики и этим,
действительно стоит заняться...

-- 
Sin (Sinelnikov Evgeny)