Re: issue tracking options

[Yoni Rabkin]

Mike Kazantsev <mk.fraggod@gmail.com> writes:

> 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).

git-bug looks interesting. I don't know of any project that uses it
though so I have no experience.

>> 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.

As far as decentralization goes, I don't see that Emms currently has a
problem. Anyone's git repo can be used to clone to any service. I
certainly don't have a problem with people mirroring, forking, and
developing Emms everywhere (as long as the service in question is
decent.)

I was hoping that the FSF would publish a more modern forge by now. But
there is little point in waiting until that happens. The reason Emms is
on Savannah at the moment is because that is where GNU ELPA is
configured to synchronize from at the moment.

-- 
   "Cut your own wood and it will warm you twice"