Is there any ongoing work to push into github/gitlab/gogs/etc support for handling issues created git-bug ?

It would be awesome.

That's part of the "master plan". git-bug is design to be easy to pick-up for them.

However it's probably way too early for such a push. git-bug would need to have a more stable core and data model, and attract actual users.

to attract stable users whats the MVP then ? Being able to use git-bug with github ? I honestly am not sure but curious the direction you want to head.

Actually there is different groups of users and thus different levels of MVP, each being a super-set of the previous.

Here is how I see them and what is required to enable them:

1. autonomous project (no bugs submitted by non-dev) - stable data model (mainly #5)
2. usage complementary to another tracker, bugs available offline as read-only - incremental import from the main bug-tracker (probably github at first)
3. usage complementary to another tracker, bugs available offline as read/write - incremental bidirectional bridge with the main bug-tracker
4. standalone usage - webUI able to serve as a public interface to edit bugs

Michael Muré (MichaelMure) added label Non-actionable 7 years ago

Out of curiosity, is there a substantial difference between git-bug's internal storage method and NoteDB https://gerrit-review.googlesource.com/Documentation/note-db.html ?

From what I gather from this, it's generally the same idea with some differences. The slides are a bit light in details so it's more an educated guess.

Both git-bug and NoteDb store data in a (linear for git-but, not sure for NoteDb) chain of commit accessible through a ref, don't pollute the normal code workflow and rely on git for storing/transport of the data.

However, NoteDb seems to store data as key/value pairs in commit message. git-bug goes further than that and store arbitrary data in git Blob and Tree, and tie them in a chain of commits. This gives the sames guarantees but allow for a more flexible format. As an example, git-bug can store files for the embedded media in comments and have them managed by git as well. This data model also helps to implement the conflict-free merge.

I don't think that Gerrit needs to have that flexibility or merging data, so I'd say it's good enough for them.