[docs] О литературной правке ( было: ALT packaging docs)

[Kirill Maslinsky]

Добрй вечер!

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

Пока я не знаю, как такое полиси должно выглядеть.

> Я думаю, что полиси стоит включать только в том случае, если мы вообще
> собираемся прикладывать какие-либо усилия к стандартизации процесса
> поддержки - разработки. Т.е. только полиси на python - наверно не стоит
> включать. Полиси на полиси, Полиси на пакетирование вообще и Полиси
> на python как частный случай - да, это может быть даже стоит. Хотя,
> наверно не в текущем виде.

По-моему мы их и прикладываем. Только очень разрозненно -- расширить круг 
людей, которые в курсе существования полиси, по-моему, ни в каком отношении
не вредно. Даже мне самому пригодился rpm-build-python и его документация, 
когда понадобилось собрать пакет с программой на Питоне, в котором я 
ничегошеньки не понимаю. После прочтения этой документации -- получилось. 
Но только узнал я о ней и rpm-build-python совершенно случайно, потому 
что в этот момент кто-то упомянул в devel at . 

/*Кстати, в описании rpm-build-python написано, что он нужен для сборки 
 * _модулей_ питона и ни слова о программах на питоне. А то, что это одно
 * и то же для стороннего человека не очевидно, см. ниже. */

> Но в любом случае, критерий необходимости включения - это заинтересованность
> читателя.  Чря я был немного удивлен, что такой интерес 
> всплыл: у меня было  ощущение некоей пустоты вокруг понятия полиси в ALT - 
> и питоновской, и вообще.

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

> > Или же нужно эти тексты как-то перестроить, возможно,    
> > снабдить введением? Вам, наверное, несложно сформулировать мнение по этому
> > вопросу, тем более что книжка существует во вполне конкретном виде:
> > всего-то требуется посмотреть оглавление и несколько страниц.
> 
> Где их взять?

дык alt-docs-devel это не просто слово, а название пакета в Сизифе ;)
В коробке Мастер 2.4 оно же в печатном виде под заголовком:
"ALT Linux Team и проект Sisyphus"
Занимаемся популяризацией разных соглашений о разработке в ALT и вообще 
самой идеи разработки в ALT ;) 

> > Вместе с предыдущим абзацем:
> > Список(?) зависимостей модуля или программы на языке "Python" от 
> 
> ;)) Вы уверены, что это именно список, а не кортеж или словарь? Я вот не уверен,
Не уверен, оттуда и вопросик. Подозревал, что опущено не случайно, 
хотел уточнить.

> "Зависимости модуля на языке python от других модулей ..."
> 
> > других модулей(?) можно получить автоматически. 
> 
> "...нужно..."
А почему нужно? Потому что нужно всё делать автоматически? =)
Если Вы считаете, что нужно -- так бы и писали. А то никакой модальности
не было, мне пришлось самому добавлять.

> Полноту обеспечивает сам факт наличия зависимостей, а автоматическое определение лишь снижает
> трудоемкость. Кстати, в последней версии текст вот такой (в 0.12 далеко лезть):
> 
>     Автоматическое определение зависимостей для модулей и программ на языке
>     "Python" допускает разбиение пакетов на отдельные компоненты,
>     обеспечивая возможность контроля полноты установки среды.
> 
> Что, по моему, более точно отражает мою мысль. Хотя вот так, наверно, будет
> лучше:
Отражает более точно. Формулирует -- менее. Вообще текст -- не зеркало мысли, 
ой не зеркало... это тяжёлый труд ;)

>     Автоматическое определение зависимостей для модулей и программ на языке
>     "Python" обеспечивает возможность контроля полноты установки среды,
>     что допускает разбиение пакетов на отдельные компоненты.
Зачем же Вы так упорно маскируете то, что хотите сказать: 
"автоматическое определение лишь снижает трудоёмкость"
глаголом "допускает", у которого гораздо более широкое, и даже просто
другое значение? Вы же сами сформулировали свою мысль явно, когда мне 
объясняли -- вот эту бы формулировку и в текст...

> Я не слишком согласен с каким-то странным противопоствлением модуля и программы и
А это я по незнанию. Никак не пойму, чем модуль отличается от программы,
а у Вас в тексте то модуль, то программа, то и то, и другое...

> мне не нравится ненужная детализация реализации (я про список). Разбить фразу
> на две - это мысль, которую стоит рассмотреть: смысл ощутимо изменился - 
> но остался эквивалентным.
здорово выражаетесь: у Вас смысл -- это одновременно и поверхностная форма и,
так сказать, глубинная. Поэтому он может эквивалентно изменяться :)

> > Собственно, эти вопросики отражают, где в тексте были непонятные моменты, 
> > которые пришлось додумывать.
> 
> Я откомментировал, чбы что-то такое проиллюстрировать. Наверно то,
> как редактура может случайно исказить смысл в погоне за литературностью ;),
> я немного утрировал, конечно.

А погоня была не за литературностью совсем, а за ясностью. И я специально 
поставил вопросики в тех местах, где намеренно _исказил_, вернее дополнил
смысл. Чбы спровоцировать автора меня поправить -- и сформулировать тем
самым свою мысль. И нисколько Вы не утрировали, а дали толковые пояснения к  
тексту. А если теперь Вы поправите последнюю версию по 
итогам нашего обсуждения -- выйдет и редакторскаяя правка ;)

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

> Разумеется,  непонятности в тексте нужно искать и устранять ;), только
> обычно вводят "литературного" редактора и "научного". И кто именно
> из них занимается прояснением .... я затрудняюсь сказать.

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

-- 
Kirill Maslinsky
ALT Linux Team * Documentation Project