Что: bd94115b066472316ea03e85d611f732785f8b7c Когда: 2024-01-11 15:26:56+03:00 ------------------------------------------------------------------------ Темы: git mail 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". В итоге и вышел этот "швабрак", где ещё и "швабра" и "брак". ------------------------------------------------------------------------ оставить комментарий: mailto:comment@blog.stargrave.org?subject=Re:%20schwabrak%20--%20%D0%BF%D1%80%D0%BE%D1%81%D1%82%D0%BE%D0%B9%20issue%20tracker%20%28bd94115b066472316ea03e85d611f732785f8b7c%29 ------------------------------------------------------------------------ Сгенерирован: SGBlog 0.34.0