[devel] ALT packaging docs (was: О сборке программ на GTK / GNOME)

[Andrey Orlov]

On Friday 12 November 2004 13:50, Kirill Maslinsky wrote:
> > Ну так займитесь. Исходники документации открыты. Поймите меня правильно - дело вовсе не в спортивной 
> > правоте, работа по поддержке пакетов дело сугубо добровольное и я действительно не имею возможности
> > поддерживать доку в докбук. Я один раз попробовал - на документации к Zope - и в общем-то этого напряга не выдержал.

> Надеюсь что Вам, как автору, будет несложно обновлять свою документацию ещё в одном месте (это можно даже автоматизировать).

Чего уж проще: rpm -Uvh rpm-build-python;  cvs commit; 
:)

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

Хорошо. Как я уже писал - в принципе я согласен.

> Если Вы согласитесь на такой способ взаимодействия -- я готов немедленно
> заняться организацией такого репозитория. Думаю, дальнейшее обсуждение этого 
> вопроса стоит перенести в docs@, Вы подписаны на эту рассылку?

Да, я подписан на рассылку, и когда-то даже у меня был доступ в CVS. Я попробую проверить жив ли еще этот
доступ и помню ли я пароли.

> Предложения и замечания по организации ``репозитория исходных текстов документации'' необходимы и будут очень кстати в рассылке docs на . 

Я пока предложений высказывать не буду, хочу только получить ответы на неск. вопросов, часть из которых навеяна прошлым опытом:

1. Если у нас уже какая-либо практика ведения в док буке именно ПОЛИСИ на пакетирование? Вопрос задан потому,
что есть несколько характерных особенностей, которые я заметил по крайней мере на своей практике, и мне бы хотелось понять,
как это будет решаться.

2. Будут ли документы полиси опубликованы где-л. в общедоступном месте? Особенност вопроса в том, что многие документы
постоянно обновляются, и их обновление должно незамедлительно публиковаться. На тьекущий момент - все доки сбраны в одном месте,
в пакете rpm-build-python - все решается просто. Если в инет будет выкладыватся версия полугодовой давности - вреда будет больше чем пользы.
Вопрос даже не в том, что информация может перестать быть валидной - это для полиси не характерно - вопрос в том, что полиси не содержащая
последние (наиболее актуальные) изменения будет создавать потребителю ложную видимость знакомства с полиси.

3. Как будут решаться вопросы с литературной правкой? Чгря даже на случае с Zope у меня были некоторые проблемы, а то была все-таки
более менее старательно написанная документация, тогда как в случае с полиси литературность я однозначно приношу в жертву оперативности
обновления и однозначности текста. 

4. Python-полиси содержит явные и неявные ссылки на другую аналогичную документацию, в частности из пакета rpm/rpm-build. Будет ли
эта документация поддерживаться там же (может быть, уже поддерживается)?

5. Как будет решаться вопрос с версиями, а самое главное - с паралельными ветвями полиси? Сейчас версия полиси лежит в пакете rpm-build-python
и возможность установки и использования этого пакета примерно совпадает с границами применимости полиси, это, может быть, не совсем
удобно, зато  управляемо, объяснимо и воспроизводимо.

В любом случае, я прошу, до тех пор, пока эта технология не будет обкатана, что бы на видном месте 
стояло следующие замечание: "это неофициальная версия полиси, которая, возможно, искажена или устарела. 
Официальная версия содержится в пакете rpm-build-python"
 
-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray на neural.ru, jid: cray на altlinux.org ---
----------------------------------------