Что: bd94115b066472316ea03e85d611f732785f8b7c
Когда: 2024-01-11 15:26:56+03:00
Темы: git mail python tcl zsh
schwabrak -- простой issue tracker
http://www.git.stargrave.org/?p=schwabrak.git;a=blob;f=README
https://github.com/driusan/PoormanIssueTracker
Чем заняться после новогодних каникул? Работой. Но для этого надо
завести задачу. А это значит идти в броузер и пользоваться чем-то,
что не будет доступно в offline, что нельзя просто так склонировать
локально. Само собой я всю профессиональную жизнь работал за разными
issue tracker-ами: Trac (моим любимым был, администрировал его),
Redmine, да вот собственно и всё. Где-то был проприетарный закрытый не
работающий без JavaScript YouTrack -- но от него, благо, удалось
держаться подальше. ivi, слышал, переходил на Jira, и там коллега писал
TUI инструменты к нему.
А есть ли чего попроще? Ну чтобы пять минут потратить и иметь простую
штуку, которую хотя бы клонировать локально бы было легко. Trac вроде бы
мог с SQLite3 БД жить например, но... он на Python, что сейчас уже
неприемлемо для меня выглядит. Redmine довольно здоровое полноценный
такой Ruby+СУБД сервер. Против Ruby я меньше против чего имею, хотя я
очень давно с ним и не сталкивался. Но точно помню что поднимать Redmine
это не два клика.
Fossil попробовал -- очень понравилась штука, особенно после того, как я
с Tcl всё же уже поимел знакомства положительного. Один бинарь, один
файл SQLite3 и в нём и issue/bug tracker полностью имеется, работающий
без JavaScript. Но Tcl запросто будет других отталкивать так же, как
меня Python.
А можно ли ещё как попроще? Что такое issue/bug tracker? По сути же это
просто какие-то текстовые задачки, к которым нехитрая метаинформация
прикрепляется, где ещё можно зачастую добавлять комментарии с файлами.
Не, ещё 100500 других фич можно понапридумывать конечно же, ибо даже в
Fossil имеется ещё и кроме встроенной Wiki -- чат, что уж точно
совершенное излишество опциональное.
Одной из крайностей issue tracker-а является просто текстовый файл, куда
записываются все задачи и их состояния. Его можно/нужно коммитить в DVCS
и вот появляется возможность простого удобного клонирования и
возможности обновления в offline-е асинхронно. Но автоматизировать
какие-либо действия с ним уже проблематично. Ибо уже нужно делать его
машиночитаемым, превращать в более строгий формат. Как-то на работе
начальник пробовал использовать Org-mode закоммиченный файл, но только
он, с Emacs-ом, мог с ним работать как-то более сложно, чем просто
смотреть и редактировать.
Можно вообще было бы коммитить SQL-dump базы данных со всеми этими
задачами. SQL же в общем-то никто не запрещает использовать без
дополнительного инструментария. SELECT-ить задачи по статусу, датам и
всё такое прочее. Но выглядит не то чтобы очень уж удобно.
А что если один файл с кучей pure-plain-text-only задач разбить на
поддиректории (по директории на задачу?), внутри которых будут текстовые
файлы? По сути у каждой задачи, есть как минимум два поля на практике:
описание и итог/решение/чем закончилась задача. Плюс метаинформация в
виде enumeration значений: по сути просто прикреплённые чётко заданные
метки/тэги. Туда же можно приложить и любые дополнительные файлы, хоть
бинарные. А если это всё положить в Git, то автоматом появляется история
всех изменений связанных с задачей, просто делая "git log -p dir". Там
же можно точно так же хранить комментарии, где вместе с коммитом
автоматом будет добавляться метаинформация кто и когда его добавил.
В suckless рассылке когда-то было обсуждение suckless трэкеров, но кроме
просто текстового файла для очень простых случаев (у меня тоже в каждом
личном проекте по TODO файлу лежит, как правило не добавленному в
репозиторий), они так ни до чего и не дошли. Многим нравилась идея
взаимодействия с bug трэкером через почту, где номер баги в теме письма
идентифицирует задачу, а дальше все сообщения для баги просто хранятся в
одном mbox/maildir файле. Так устроена работа в Debian. mbox-ы можно
скачать и локально, просто натравив MUA, смотреть всё общение в рамках
задачи. Но для этого нужен вменяемый MUA, плюс это не то чтобы легко
автоматизировать можно (работать из командной строки с MIME сообщениями
то ещё удовольствие) и оно всё же именно про bug tracking, когда
анонимные люди могут взаимодействовать, а не чётко заданные разработчики
у которых есть взаимосвязи между задачами, сроки, всякие там возможно
строящиеся диаграммы Ганта и тому подобное. Всё же bug tracker и issue
tracker ощутимо отличаются. И для bug tracker я бы тоже наверное смотрел
в сторону почтовых сообщений и каких-то hook-ов на стороне принимающего
сервера. Возможно debbugs вполне себе не так сложен для администрирования.
Но это всё для bug tracking, а для issue tracking излишне.
Git выглядит как сразу готовая распределённая СУБД где "git log -p"
покажет всю историю изменений связанную с задачей. После всего этого я
нашёл PoormanIssueTracker предложение, даже с презентацией онного на
какой-то конференции. Где все идеи полностью схожи и с тем до чего я
дошёл.
Ну а для упрощения работы с этой простой иерархией задач написал
несколько zsh-скриптов (почему zsh? потому что в нём проще работать не
заботясь об экранировании и подобных штуках, хотелось по быстрому
написать что-то работающее) в schwabrak репозитории. Попытаюсь
поработать в таком духе. Никаких там генераторов отчётов, сводных таблиц
или чего-то подобного -- когда понадобятся, то за пару часов можно всё
что угодно будет написать. Если же zsh нет, то всё настолько тривиально,
что можно и просто руками возиться с файлами. Ведь всё это по сути
просто договорённость об именовании нескольких файлов и директорий,
ничего более. Но зато с этим куда проще проводить автоматизацию и вообще
машинно обрабатывать всё. Всё описано в README.
В отличии от PoormanIssueTracker у меня есть "поддержка" иерархических
проектов, а не просто одного большого списка задач. Конечно, название
проекта может просто входить в часть названия. У меня это часть
поддиректории. Задачи могут зависеть от других. Всякие статусы,
приоритеты, assignment-ы и подобное -- считаю что просто может являться
частью enumeration-ов, которые можно сгруппировать по части названия
("status:open", "status:done", "severity:high", "assigned:stargrave"
(всё равно список людей на которые можно повесить задачу -- относительно
небольшое множество), и т.д.). Комментарии добавляются коммитом меняющим
"comment" файл, поэтому их все можно проглядеть просто сделав "git log"
на него, увидев и даты, и авторов, и добавленные/изменённые связанные
файлы. В ivi например всё рецензирование кода делалось через комментарии
к задаче, никаких отдельных Gerrit или Phabricator. Пробовали, но не
понравилось. С Gerrit я дело имел годами, и так и остался при своём
мнении что не нужен он, комментарии с рецензированием кода более чем
достаточны. Так же как и Gitlab. Просто надо иметь утилиту для удобного
комментирования кода (как я когда-то написал CodeComm и GerrVim). Так
что и тема с рецензированием/review тоже закрывается.
Откуда такое имя? Искал как будет по немецки bug, жук, таракан
(Schwabe). Добавлял "trac", "trak". В итоге и вышел этот "швабрак",
где ещё и "швабра" и "брак".
Сгенерирован: SGBlog 0.34.0