On Mon, May 21, 2001 at 07:52:33PM +0300, Serge Skorokhodov wrote:
> >> > > Это тоже ведь ответ. Но, возможно, стоит все же выделить категории,
> >> > > для которых жесткость критериев различна (вариант:
> >> > > supported/maintained/justso) - с замкнутостью по зависимостям снизу
> >> > > вверх.
> >> > 
> >> > Это хорошая мысль.
> >> 
> >> Кстати, я посмотрел сейчас список пакетов и обнаружил, что Вы в большей
> >> степени, и Дмитрий в меньшей, помимо "базовых" пакетов собираете все, что
> >> не взяли остальные разработчики. Imho стоит составит список 
> 
> DVL> Уточняю: если maintainer пакета - ldv@altlinux.ru, то про такой пакет
> DVL> можно сказать, что он либо базовый, либо unmaintained.
> 
> >> "разыскивается :-) packager" и перечислить в этом списке те пакеты,
> >> которые вы соберать не хотите или не можете. Если packager'а нет, пакет
> >> попадает в justso.
> >>   Я например использую xemacs, который Вы не любите, и zsh, который мало
> >> кто использует, и еще несколько подобных пакетов - если бы они появились в
> >> подобном списке, думаю, взялся бы их собирать. Тем более в отпуск через
> >> неделю ухожу - время появится. :-)
> 
> DVL> Спасибо за идею. Постараюсь в течение недели представить список
> DVL> "unmaintaned" пакетов для желающих взять их на maintainance.
> 
> А каковы обязанности мейнтейнера?

Maintainer пакета XXX должен:
+ Регулярно пользоваться этим пакетом.
  Rationale: maintainer должен чувствовать пакет "изнутри", без этого
  нарушается цикл тестирования и пакет становится неполноценным.
+ Быть в курсе разработки софта, входящего в пакет. Это, как минимум,
  подразумевает участие в списке рассылки типа XXX-announce. Общение с
  разработчиками софта, входящего в пакет, желательно, но не обязательно.
  Участие в разработке софта, входящего в пакет, желательно, но не
  обязательно.
  Rationale: это дает возможность иметь в дистрибутиве самую свежую (но
  при этом рабочую) версию софта, а также повышает оперативность
  исправления ошибок.
+ Отслеживать bug report'ы (как в bts, так и в списках рассылки; последнее
  на порядок сложнее) и реагировать на них. Оперативность реакции на
  security holes - не более одного рабочего дня (реакция - это не
  обязательно исправление).
  Rationale: это просто очевидно.

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


Regards,
	Dmitry

+-------------------------------------------------------------------------+
Dmitry V. Levin     mailto://ldv@alt-linux.org
ALT Linux Team      http://www.altlinux.ru/
Fandra Project      http://www.fandra.org/
+-------------------------------------------------------------------------+
UNIX is user friendly. It's just very selective about who its friends are.