Re: issue tracking options

[Mike Kazantsev]

On Mon, 21 Nov 2022 17:33:18 -0500
Yoni Rabkin <yoni@rabkins.net> wrote:

> I think that we can manage with a git repo which contains an issue list
> as a text file: bullet-proof, fast, doesn't require a web browser,
> decentralized, in-line with the way Emms itself is being developed.
> 
> My current options are different flavors of kludge:
> 
> I. Manage the issue list in its own separate branch "issues", which will
> have an "issues" directory with stuff in it. This way, people who just
> pull a version of Emms don't need to see it if they don't want to.

I've recently looked at this tool, and was thinking that maybe it's a
good option for keeping track of issues in git itself:

  https://github.com/MichaelMure/git-bug

It seem to be quite like git-notes (built-in git feature), where
non-file objects get linked into commits (on a separate trees/refs,
I think?), are used to store the issues, and can be merged/edited
separately, with cli similar to git-notes, but also localhost WebUI
and TUI, add in same binary.

(with latter, it looks quite like fossil scm too, which also has
similar UIs running on-demand from its all-in-on binary, and manages
issues/wikis/etc as separate type of artefacts in its repo)

Haven't used it myself, but maybe a bit fancier than txt list,
and might be simple enough internally with json lists
(or probably easier to export/import via bridges there too).


> II. Manage the issue list as a file in the "doc" directory in the main
> branch, similar to the developer-release.txt file.
> 
> III. Open a project on sourcehut to manage the list.
> 
> (I) and (II) have the upside of other developers having immediate access
> to the list. (III) has the upside of keeping the code clean.
> 
> What do people think?

https://codeberg.org/ might be another reasonably-libre alternative
to sourcehut, I think, and has more conventional github-like interface,
which might be easier for most people to use.


My approach with personal projects is to have multiple url= lines under
"remote origin" and push to multiple online hosting places like that,
for a bit of extra redundancy and more accessibility for folks who e.g.
only/already have account on one of these places.
(for example - https://github.com/mk-fg/emacs-setup - with other
web-places stored as links in the README there)

It probably doesn't work as well for larger project like EMMS, where
multiple people have commit access, but maybe still well enough, 
if it's not too much trouble to sometimes merge stuff or ask comitters
to also add a multi-url remote to avoid needing that or when having
occasional conflicts.

Seem to be closer to a decentralized spirit of git itself than picking
just one place, and more redundant in case one of these free hosters go
bad, which is no big deal with such approach.


-- 
Mike Kazantsev // fraggod.net