= Сизиф-на-Куче = * [:Docs/TZ/HeapCatalogue: Веб-интерфейс, позволяющий ориентироваться в документах Кучи] = Сборочные технологии проекта ALT Docs = * [:Docs/Build/CurrentWorkflow: Текущая реализация сборочной технологии] '''Общая идея:''' '''Публикатор''': поступающие в Кучу документы должны проходить сборочную процедуру (сборка в HTML и унификация) и публиковаться в собранном виде в Сети ''без участия человека'' ('''короткий цикл'''). Кроме этого предусматривается публикация документов во внешних репозиториях (sisyphus), при минимальном участии человека в тривиальных процедурах (пересборка обновлённого документа) -- это '''длинный цикл'''. Текущая реализация сборочной процедуры (не описано тут), даёт только частичную автоматизацию. Предлагаемая реализация сборочной процедуры ('''которкий цикл'''): 1. Преобразование Кучи в набор git-репозиториев (по одному на каждый документ) 1. Импорт существующих документов в git [:Docs/TZ/GitHeapimport: утилита git-heapimport] 1. Структура git-Кучи: права доступа, структура каталогов, полиси. формат тегов, запрашивающих пересборку. 1. Сборочная процедура: 1. [:Docs/TZ/HeapRobot: Робот] по наступлению события (cron) определяет список модулей к сборке 1. Он же запускает gear, передавая необходимые сборочные параметры (Timestamp, Archive, Comitter) 1. gear получает тарболл из git-репозитория и запускает скрипт-обвязку, который [:Docs/TZ/GenSpec: генерирует спек] и выполняет сборку в hasher 1. собранный rpm-пакет устанавливается в общий chroot с другими подобными (тоже hasher) 1. часть chroot, содержащая html-файлы модулей, отображается на web = Реорганизация структуры выпуска = См. [:Docs/TZ/Issue: техзадание] Предложение по структуре выпуска. * ''`Базовый_каталог`'' -- каталог с документацией (`/usr/share/docs/alt-docs`) * `modules/` -- каталог с установленными модулями * ''`Модуль_1/`'' -- некоторый модуль * `head.html` -- стандартная шапка модуля (вариант: генерируется при установке модуля) * `foot.html` -- стандартный подвал модуля (вариант: генерируется при установке модуля) * `doconfo.html`, `License.html` и пр. -- файлы ALD policy * `doc/` -- подкаталог с файлами модуля (содержит `index.html`, в который внедрены `head.html` и `foot.html` в виде `iFrame`-ов * ''`Модуль_2/`'' -- некоторый модуль * `. . .` -- другие модули * `index.html` -- сводный список (обновляется при установке нового модуля) * ''`Выпуск_1/`'' -- каталог с некоторым выпуском, собранным из модулей * `modules/` -- каталог со ссылками на модули * ''`Модуль_1/`'' -- каталог со ссылкой на ''Модуль_1'' * `head.html` -- модифицированная шапка модуля (генерируется при установке либо при сборке выпуска) * `foot.html` -- модифицированный подвал модуля (генерируется при установке либо при сборке выпуска) * `doc` -- символьная ссылка на подкаталог `doc` ''Модуля_1'' (`-> ../../../modules/`''`Модуль_1/`''`/doc`) * `. . .` -- символьные ссылки на файлы ALD policy * ''`Модуль_2/`'' -- некоторый модуль * `. . .` -- другие модули и левые файлы выпуска, если таковые понадобятся (например, список модулей в выпуске по аналогии с `modules/index.html`, может генерироваться той же программой) * `index.html` и пр. -- оглавление и другие файлы выпуска, не входящие в модули Требуется реорганизовать структуру HTML-модуля. Обоснование: не помещать в `index.html` ''модуля'' информацию, зависящую от названия этого модуля (сейчас роль `head.html` и `foot.html` играют символьные ссылки вида ''`Модуль_1`''`.next` и т. п.). Не устраивать каши в `modules/`. [http://phobos.cs.msu.su/~george/drafts/doc-stand Пример структуры] = Развитие сайта ALT Docs = Мелкие: * наладить всё-таки доставку почтовых уведомлений об измениях на wiki-страницах Покрупнее: * возможность offline-обновления страниц (подкладывания готовых в формате moin), чтобы такие обновления отслеживались движком и отображались в истории изменений. См. также [:Docs/TZ/HeapCatalogue: веб-интерфейс к Куче] = Развитие сайта ALT Linux = * [:Docs/TZ/ALTLinuxSite: Проект информационной структуры сайта ALT Linux]