[docs] Re: patches

[Vitaly Ostanin]

Fr. Br. George пишет:
> On Fri, Feb 03, 2006 at 03:13:28AM +0300, Денис Смирнов wrote:
> 
>>On Thu, Feb 02, 2006 at 02:55:23PM +0300, Kirill Maslinsky wrote:
>>
>>KM> Можно сделать что угодно. Разница в том, что докмент, положенный в Кучу 
>>KM> _уже_ автоматически собирается. А собирать что-то как-то из какого-то 
>>KM> репозитория вместо стандартной процедуры -- это как раз и есть геморрой. 
>>KM> Вопрос, короче, в том, на чьей стороне будет геморрой, а это уж вопрос
>>KM> заинтересованности ;)
>>
>>Геморрой будет исключительно у собирающего робота. Честно говоря, я не
>>столь маньяк, чтобы меня волновало количество геморроя у робота. А вот у
>>людей геморроя быть не должно.
> 
> Денис, мне кажется, вы прекрасно понимаете, что любой ``геморрой''
> робота -- это ручная работа его администратора, человека. Что напрочь
> обессмысливает ваше утверждение.

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

Повторю очевидную вещь - робота ручной работой учат один раз.
Работа робота избавляет от ручной работы больше одного автора.

> Что касаемо "на чьей стороне геморрой", здесь тоже всё вполне
> однозначно. Кто-то должен писать этого робота для каждого репозитория
> каждого автора. Наверное, это автор -- кому же ещё ведомы тайны "каждого
> репозитория", который-- как автор и писатель -- вполне может не быть
> никаким программистом. Не хочется. Думается, что скрутить tarball, подложив в
> него docinfo и License, намного проще: даже если ты совсем не
> программист, всегда можно попросить кого-нибудь написать скрипт из трёх
> строк -- один раз. В этом и видится минимизация геморроя, так как со
> стороны автора требуется три строки кода, которые формализуют документ
> до степени, достаточной для робота.
> 
> Замечу, что единый репозиторий для всех документов вообще и всех авторов
> вообще с единой дисциплиной разработки, единым интерфейсом и т. п. --
> ситуация, с которой мы имели дело два года назад, когда в Сизифе было
> ровно три (!) пакета с документацией, два из которых к этому репозиторию
> не имели отношения, а третий собирался путём непрерывного шаманства из
> полдюжины неизвестно кем и неизвестно зачем наплождённых веток
> документации, состоящей из кусков непонятного авторства, в каждой
> из которых можно было найти что-то новое и что-то за 2001 год. При этом
> авторы текстов, как правило, вообще не прикладывали рук к репозиторию, а
> те, кто прикладывал, отказывались отвечать за адекватность и
> осмысленность вбитых ими туда чужих текстов.

Вы пошли путём, аналогичным тому, что было 2 года назад.

> Прошу прощения, вырвалось. Прошу не отвечать на предыдущий абзац, а то
> пойдёт по кругу. 

Классная манера вести беседу :)

> Особенно прошу не отвечать в стиле "тогда было
> неправильно, а мы знаем, как правильно". 

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

> Мы не знаем, как правильно. Мы
> "всего лишь" публикуем и организуем обратную связь, если автор не в
> состоянии сделать это сам.

Я думаю, что знаю, как правильно, и уже есть готовые реализации.

Нужен централизованный (или распределённый, но не представляю,
как это в данном случае пригодится) репозиторий с path based
доступом. К trunk может иметь доступ только Кирилл, а к branches
любой желающий (участники ALT Team - автоматически).

Этим решаются возможные проблемы Кирилла с тратой времени на
откатывание чужих патчей. Subversion это умеет.

Нужна возможность оставлять non latin1 комментарии к коммитам.
Нужна возможность переименовывать файлы. Subversion это умеет.

Нужен web-интерфейс к репозиторию с возможностью просмотра
документов, изменений версий, созданием страниц wiki со ссылками
на определённые версии документов и со ссылками на место внутри
документа. Trac это умеет.

Кстати, система плагинов Trac позволяет сделать отображение не
только исходников, но и собранных документов.

Нужна система отслеживания ошибок, позволяющая завести багрепорт
со ссылкой (с точностью до строки и версии документа) на
документ, в котором обнаружена ошибка. Нужна возможность
добавлять в багрепорты патчи. Trac это умеет.

Нужна система, в которой можно создавать справочные страницы. В
Trac есть wiki с полной интеграцией с репозиторием subversion.

Кроме того, в subversion есть механизм ссылок (svn:externals) как
внутри репозитория, так и на внешние репозитории subversion.

Я не пониманию, почему автоматически собираются только документы,
положенные в кучу. Что мешает роботу или автору класть в кучу
документы из svn ? Что мешает собирать документы из заданной
рабочей копии subversion ?

Суть предложения - сделать работу с репозиторием более
комфортной. Автор - ленивый человек, ему лень читать, как
работать с кучей.

Ему удобнее получить одну ссылку и сразу посмотреть структуру
документов и сами документы. Или там же - все изменения в
репозитории за период времени. Или не только в репозитории, а во
всей системе. И много чего ещё, но в _одном_ месте. Лично меня
ломает ходить от bugzilla к куче.

http://projects.edgewall.com/trac/

-- 
Regards, Vyt
mailto:  vyt at vzljot.ru
JID:     vyt at vzljot.ru

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://lists.altlinux.org/pipermail/docs/attachments/20060203/47a3beee/signature-0001.bin