Wiki и багтрекер вместе с кодом
Бывают всякие ditz, но они как-то не очень удобные в итоге
Если поискать там еще несколько похожих проектов есть
Если поискать там еще несколько похожих проектов есть
Нашел еще bugs everywhere , git-issues и немного обсуждений .
Так вот, это все просто багтрекеры, без вики, ну и самое главное — без веб-интерфейса, так жить нельзя. Почему они его не приделали не понимаю.
Так вот, это все просто багтрекеры, без вики, ну и самое главное — без веб-интерфейса, так жить нельзя. Почему они его не приделали не понимаю.
С одной стороны почти то что надо, с другой там очень много велосипедов: своя система контроля версий, своя вики. Работать в сумме будет плохо.
И автор похоже виндузятник, поскольку считает достижением что не надо ставить посторонних пакетов.
Вот еще нарыл: http://www.ditrack.org/ и какое-то описание, по-моему без кода — http://subissue.tigris.org/
Самый главный вопрос на самом деле — "почему я не должен этого хотеть?".
Связанный вопрос — "почему нет нормального API ни у одной системы контроля версий?"
А чего хочется:
1) Хочется хранить документацию рядом с кодом, иначе в документации написано одно, в коде другое, и по документации непонятно насколько она актуальна. Не видел ни одной вики которая бы этим не страдала.
2) Хочется иметь легкий способ экспорта документации в разнообразные форматы.
3) Достаточно распространенный язык разметки.
4) Документацию можно редактировать через веб-интерфейс и как текст в системе контроля версий. Соответственно бранчить, мержить и отдавать исходные тексты тоже.
5) Баги уметь редактировать через веб-интерфейс и текстовым редактором вместе с кодом.
6) Уметь отдавать версию кода с соответствующими багами.
7) Уметь пристраивать интеграцию с почтой
8) Перекрестные ссылки между тикетами и коммитами.
Если такой штуки до сих пор нет, а всякие похожие есть, то, вероятно, "я не должен этого хотеть".
И автор похоже виндузятник, поскольку считает достижением что не надо ставить посторонних пакетов.
Вот еще нарыл: http://www.ditrack.org/ и какое-то описание, по-моему без кода — http://subissue.tigris.org/
Самый главный вопрос на самом деле — "почему я не должен этого хотеть?".
Связанный вопрос — "почему нет нормального API ни у одной системы контроля версий?"
А чего хочется:
1) Хочется хранить документацию рядом с кодом, иначе в документации написано одно, в коде другое, и по документации непонятно насколько она актуальна. Не видел ни одной вики которая бы этим не страдала.
2) Хочется иметь легкий способ экспорта документации в разнообразные форматы.
3) Достаточно распространенный язык разметки.
4) Документацию можно редактировать через веб-интерфейс и как текст в системе контроля версий. Соответственно бранчить, мержить и отдавать исходные тексты тоже.
5) Баги уметь редактировать через веб-интерфейс и текстовым редактором вместе с кодом.
6) Уметь отдавать версию кода с соответствующими багами.
7) Уметь пристраивать интеграцию с почтой
8) Перекрестные ссылки между тикетами и коммитами.
Если такой штуки до сих пор нет, а всякие похожие есть, то, вероятно, "я не должен этого хотеть".
документацию в свне - я готов понять. для такого есть глупости типа javadoc. не вики конечно, но имхо для конечных целей вполне хватает.
вот баги хранить в свне же - это труднореализуемое желание. баги редко поялвяются одновременно с коммитом кода. честные баги, а не фичебаги, появляются уже потом.
соотв они будет попадать в отдельный коммит.
соотв если баг распространяется на пачку версий, его надо будет мерджить в несколько бранчей, и потом поддерживать между этим консистентность.
соотв когда ты мерджишь код, совершенно непонятно какие из соотв багоревизий к этому коду относятся, а ведь их тоже неплохо бы замерджить.
софтовая поддержка этого требует существенной допилики существующих вцс.
вот баги хранить в свне же - это труднореализуемое желание. баги редко поялвяются одновременно с коммитом кода. честные баги, а не фичебаги, появляются уже потом.
соотв они будет попадать в отдельный коммит.
соотв если баг распространяется на пачку версий, его надо будет мерджить в несколько бранчей, и потом поддерживать между этим консистентность.
соотв когда ты мерджишь код, совершенно непонятно какие из соотв багоревизий к этому коду относятся, а ведь их тоже неплохо бы замерджить.
софтовая поддержка этого требует существенной допилики существующих вцс.
ditrack сцуко странный
Не знаю как сейчас, не следил, но год-два назад я не смог нормально его прикрутить к git
Он очень сильно заточен был под централизованные системы
По личным впечатлениям, самый приличный из того что ты упомянул — ditz. Даже пользовался им какое-то время. К нему есть уеб-интерфейс (sheila, вроде в основном дереве ditz живет, но я ей не пользовался).
Не знаю как сейчас, не следил, но год-два назад я не смог нормально его прикрутить к git
Он очень сильно заточен был под централизованные системы
Если такой штуки до сих пор нет, а всякие похожие есть, то, вероятно, "я не должен этого хотеть".Не то чтоб ты этого не должен хотеть, на мой взгляд просто народ делится на две категории - которые хотят уеб, или которые хотят править в коде. Их очень тяжело объединить вместе
По личным впечатлениям, самый приличный из того что ты упомянул — ditz. Даже пользовался им какое-то время. К нему есть уеб-интерфейс (sheila, вроде в основном дереве ditz живет, но я ей не пользовался).
Автор - основной разработчик SQLite, называть его "виндузятником" глупо, по-моему.
Из крупных проектов, которые этим пользуются - в голову приходит http://mongrel2.org/
Что же до твоих хотелок,
Короче, по-моему твои проблемы весьма надуманы.
Из крупных проектов, которые этим пользуются - в голову приходит http://mongrel2.org/
Что же до твоих хотелок,
1) Хочется хранить документацию рядом с кодом, иначе в документации написано одно, в коде другое, и по документации непонятно насколько она актуальна. Не видел ни одной вики которая бы этим не страдала.Ну так храни документацию рядом с кодом, прямо в системе контроля версий. И пусть рядом лежит скрипт длиной в одну команду rsync, который ее выгружает на сервер, при необходимости.
2) Хочется иметь легкий способ экспорта документации в разнообразные форматы.Нет препятствий патриотам! Хотя бы sphinx (http://sphinx.pocoo.org/)
3) Достаточно распространенный язык разметки.
4) Документацию можно редактировать через веб-интерфейс и как текст в системе контроля версий. Соответственно бранчить, мержить и отдавать исходные тексты тоже.Под любую VCS сейчас есть веб-морда. Полноценное редактирование, мердж и так далее через веб-интерфейс - вообще странное желание. Редактировать и мерджить должен не программист? Или программисту типа неудобно держать у себя VCS-клиента для этих операций?
5) Баги уметь редактировать через веб-интерфейс и текстовым редактором вместе с кодом.Любой приличный баг-трекер понимает почту и имеет веб-интерфейс.
7) Уметь пристраивать интеграцию с почтой
6) Уметь отдавать версию кода с соответствующими багами.Что мешает писать номера багов в коммит-месседжах и номера коммитов в багах? Все приличные баг-трекеры и веб-морды к VCS умеют автоматически разворачивать текстовые номера багов где угодно и текстовые номера коммитов где угодно в перекрестные ссылки.
8) Перекрестные ссылки между тикетами и коммитами.
Короче, по-моему твои проблемы весьма надуманы.
То ли я плохо объясняю, то ли ты плохо понял:
> Ну так храни документацию рядом с кодом, прямо в системе контроля версий.
Так и делаю.
> И пусть рядом лежит скрипт длиной в одну команду rsync, который ее выгружает на сервер, при необходимости.
Это не решает проблемы. В проекте есть не только разработчики, и редактировать документацию они тоже должны уметь.
> Нет препятствий патриотам! Хотя бы sphinx (http://sphinx.pocoo.org/)
В первом посте я уже писал слова ReST. Вся документация в нем.
> Под любую VCS сейчас есть веб-морда
... которая не решает проблемы
> Полноценное редактирование, мердж и так далее через веб-интерфейс - вообще странное желание. Редактировать и мерджить должен не программист? Или программисту типа неудобно держать у себя VCS-клиента для этих операций?
Тут некрасиво выразился. Имел в виду: "Бранчить и мержить проект целиком можно, делать это может программист". Редактировать могут все, не только программисты.
> Любой приличный баг-трекер понимает почту и имеет веб-интерфейс.
Зато не умеет ничего другого.
> Что мешает писать номера багов в коммит-месседжах и номера коммитов в багах?
Все так делают. Но вот скажем в Redmine есть associated revisions, и при появлении такой ревизии уведомления в почту не идет. Пытаюсь дописать это самостоятельно, но баги в Redmine issues REST API мешают.
В траке из коробки ревизия не становится комментом к тикету, если в ней есть ссылка на тикет.
> Короче, по-моему твои проблемы весьма надуманы.
Короче, ты ответил как консультант из анекдота. Я не хочу ничего принципиально нового, хочу удобный набор существующих уже в разном виде в разных проектах фич. Не надо мне рассказывать что такие фичи по отдельности где-то есть, я это прекрасно знаю.
> Ну так храни документацию рядом с кодом, прямо в системе контроля версий.
Так и делаю.
> И пусть рядом лежит скрипт длиной в одну команду rsync, который ее выгружает на сервер, при необходимости.
Это не решает проблемы. В проекте есть не только разработчики, и редактировать документацию они тоже должны уметь.
> Нет препятствий патриотам! Хотя бы sphinx (http://sphinx.pocoo.org/)
В первом посте я уже писал слова ReST. Вся документация в нем.
> Под любую VCS сейчас есть веб-морда
... которая не решает проблемы
> Полноценное редактирование, мердж и так далее через веб-интерфейс - вообще странное желание. Редактировать и мерджить должен не программист? Или программисту типа неудобно держать у себя VCS-клиента для этих операций?
Тут некрасиво выразился. Имел в виду: "Бранчить и мержить проект целиком можно, делать это может программист". Редактировать могут все, не только программисты.
> Любой приличный баг-трекер понимает почту и имеет веб-интерфейс.
Зато не умеет ничего другого.
> Что мешает писать номера багов в коммит-месседжах и номера коммитов в багах?
Все так делают. Но вот скажем в Redmine есть associated revisions, и при появлении такой ревизии уведомления в почту не идет. Пытаюсь дописать это самостоятельно, но баги в Redmine issues REST API мешают.
В траке из коробки ревизия не становится комментом к тикету, если в ней есть ссылка на тикет.
> Короче, по-моему твои проблемы весьма надуманы.
Короче, ты ответил как консультант из анекдота. Я не хочу ничего принципиально нового, хочу удобный набор существующих уже в разном виде в разных проектах фич. Не надо мне рассказывать что такие фичи по отдельности где-то есть, я это прекрасно знаю.
Ну тебе как бы предложили вариант, который практически все, что ты хочешь делает. Ты ж говоришь: "а хочу, чтобы все при этом работало на моих старых инструментах".
Ну тебе как бы предложили вариант, который практически все, что ты хочешь делает. Ты ж говоришь: "а хочу, чтобы все при этом работало на моих старых инструментах".Ты ditz имеешь в виду? На его страничке ничего не сказано про веб-интерфейс, теперь знаю что он есть, посмотрю.
Оставить комментарий
pilot
Когда-то я уже писал, по-моему, что непонятно зачем в Траке и ему подобных системах вики вынесена отдельно в БД, там отдельно хранится и версионируется.То же и про баги.
1) Документация к проекту и баги проекта это, на мой взгляд, его неотъемлемая часть. Если можно будет мержить доки и тикеты то собственно и проект можно делать распределенно, не только код.
2) Также непонятно зачем плодить кучу викиразметок, если есть Docutils=ReST, у которого есть конвертация в кучу разных форматов. И те же вики и баги можно править из текстового редактора (tm).
Непонятно почему нет подобных систем для разработки.
И вот нашел обсуждение этого вопроса в траке:
http://trac.edgewall.org/wiki/WhySQLite
Минусы не кажутся мне существенными.
?