new release?

[jedahan]

Anything stopping a new release from happening?

Having trouble with things like github bridge #581 , and want to use git-bug for a shared project, but feel like its a big ask for people to clone, build and install git-bug instead of using the packaged version.

[MichaelMure]

Yeah, sorry about that.

The situation is that I'm buying and refurbishing an apartment. This has kept me extremely busy in the last few months and might last a bit more.

git-bug is close to a new release, but there is still some stuff to do:

• finish/control/merge a bunch of PRs
• finish a bunch of stuff in flux, in particular regarding the data format
• make sure everything is fine
• write doc and communicate around the new data format (make your own distributed datastructure in git easily!)
• write release notes and actually release

[jedahan]

Good luck / congrats on the new apartment!

If any of those things are something we could help out on - testing, documentation, etc, lmk.

[pka]

Any chance for a new release? The GH bridge seems not working with new tokens in the latest release.

[6543]

@MichaelMure should I push this forward?

[MichaelMure]

A new release is not so much the problem, it's having the code in a releasable state. Unfortunately some very extensive changes in the core have been amde,that need to be stabilized and exercised up to a point where I/we are confident about it. This is especially important as the next release is likely to be the 1.0, which comes with some form of compatibility guarantee regarding the data stored.

[6543]

well I can check & update dep. but the hevy lifting of going throug all the code is not in my time buged atm :sweat:

[MichaelMure]

Thanks, that's already useful. On my side, the apartment refurbish should finish this month, so hopefully I finally get some free time soon-ish.

[mthuggett]

Looking for status... Do we have a sense yet on release schedule?

[MichaelMure]

Let's go back to my initial list:

• ~finish/control/merge a bunch of PRs~
• ~finish a bunch of stuff in flux, in particular regarding the data format~
• make sure everything is fine
• ~write doc and~ communicate around the new data format (make your own distributed datastructure in git easily!)
• write release notes and actually release

I think the last PR I want to have before 1.0 is https://github.com/MichaelMure/git-bug/pull/664. After that, it's "just" a question of making sure everything is ready for prime time, and in particular that git-bug is ready to commit to a data format.

[smoyer64]

write doc and

I'm trying to use the current implementation from the master branch and was trying to "make my own distributed datastructure in git". Can you point me to the above referenced document? And one of the problems that I have is that LocalStorage always writes to .git/git-bug/xxx. Thanks!

[MichaelMure]

Doc is there, let me know if something is unclear: https://github.com/MichaelMure/git-bug/blob/master/doc/model.md https://github.com/MichaelMure/git-bug/blob/master/entity/dag/example_test.go

Are you trying to run in the browser with wasm or something like that? I didn't intend for that code to support that so it's possible that things would need to be adjusted a bit. FYI @happybeing has been experimenting with that over at https://github.com/happyborg/p2p-git-portal-poc

[smoyer64]

@MichaelMure - Thanks so much for the response! I've been following the model but hadn't seen the example you referenced. Amazingly, I mostly got my Snapshot and Entity created correctly and appreciate that I can set the directory which holds the references (and that references are separated by the type of entity). Right now, I'm just creating a CLI application so I don't have an issue with running in WASM (though I have written applications that run in a browser and that's an interesting side-project).

The example actually highlights my question about how to the underlying Git repository - the two lines at https://github.com/MichaelMure/git-bug/blob/650c11dcb68bfe00e2d399c5e1d337cae9c1bfeb/entity/dag/example_test.go#L345 will result in the Lamport clocks, indices and cache files being stored at .git/git-bug. Using that one directory for all applications doesn't matter so much for the indices and cache files other than it clutters up git-bug's temporary space. Sharing that directory for the Lamport clocks has the side-effect of any update to one application's data increasing the shared clocks. This might matter as the clocks might seem to be arbitrarily advanced. The path for LocalStorage in the git repository is hard-coded in three places in this file - https://github.com/MichaelMure/git-bug/blob/650c11dcb68bfe00e2d399c5e1d337cae9c1bfeb/repository/gogit.go#L75.

I was also trying to reuse RepoCache (or parts of it) and it doesn't seem to be nearly as friendly to alternate entities. I see obvious reasons for specialization in indexing but it seems like basic caching could also be made general (I previously would have said "generic") like the the underlying storage (repository).

I see in the README that you're looking for help - at this point, I'm probably more adept with git-bug's core and CLI but could probably help with termui. Thanks again for this amazing project ... I'm a convert from bugs-everywhere and the idea of distributed bug-tracking, PRs, gist (equivalents), etc will soon be considered mainstream. Here's looking forward to the day when we stop using centralized "hubs" for with our distributed source repository. And perhaps the ultimate in distributed sharing happens using IPFS or Hyperswarm. At that point, git behaves more like Bittorrent and distributed file-sharing provides the trackers.

[MichaelMure]

The example actually highlights my question about how to the underlying Git repository - the two lines at

https://github.com/MichaelMure/git-bug/blob/650c11dcb68bfe00e2d399c5e1d337cae9c1bfeb/entity/dag/example_test.go#L345 will result in the Lamport clocks, indices and cache files being stored at .git/git-bug. Using that one directory for all applications doesn't matter so much for the indices and cache files other than it clutters up git-bug's temporary space. Sharing that directory for the Lamport clocks has the side-effect of any update to one application's data increasing the shared clocks. This might matter as the clocks might seem to be arbitrarily advanced.

This code also wasn't written with multiple app sharing that same space, but that's actually a good point now that there is a reusable data structure. Luckily that's easy-ish to change as git-bug will recreate all those temp files if they are not found after changing the path.

The path for LocalStorage in the git repository is hard-coded in three places in this file -

https://github.com/MichaelMure/git-bug/blob/650c11dcb68bfe00e2d399c5e1d337cae9c1bfeb/repository/gogit.go#L75 .

Yeah it's probably a good idea to make that configurable.

I was also trying to reuse RepoCache (or parts of it) and it doesn't seem to be nearly as friendly to alternate entities. I see obvious reasons for specialization in indexing but it seems like basic caching could also be made general (I previously would have said "generic") like the the underlying storage (repository).

It's like that because I didn't find a better way to do it (also, this generic datastructure is quite a recent thing). Maybe go generics could help here?

I see in the README that you're looking for help - at this point, I'm probably more adept with git-bug's core and CLI but could probably help with termui.

I listed the different UIs and bridges because they are self-contained and easier to grasp. If the core is what tickles you, by all mean go ahead ;)

Thanks again for this amazing project ... I'm a convert from bugs-everywhere and the idea of distributed bug-tracking, PRs, gist (equivalents), etc will soon be considered mainstream. Here's looking forward to the day when we stop using centralized "hubs" for with our distributed source repository. And perhaps the ultimate in distributed sharing happens using IPFS or Hyperswarm. At that point, git behaves more like Bittorrent and distributed file-sharing provides the trackers.

You are preaching to the choir, IPFS is my day job ;-)

[smoyer64]

IPFS is my day job

Must be nice! ... I have a couple side-projects that are focused around the non-crypto side of web3 (distributed file systems of various sorts). In addition to writing a distributed journal system (this question), I'm working on a Go implementation of the HyperSwarm protocol with the ultimate goal of bridging HyperSwarm and IPFS - it feels like there should be a way to find documents regardless of where they exist. I'm also interested in whether something like Gemini could take off as distributed publishing on top of distributed file systems.

Do you have an issue in the core you'd like me to take on? Generics might be one solution to caching any given entity type but you've managed to generalize Entity without them. It also seems like multi_repo_cache could be used for repo_cache which seems to be an aggregation of repo_cache_bug and repo_cache_identity. I'll play around with the idea of a generic repository cache a bit more.

[MichaelMure]

IPFS is my day job

Must be nice! ... I have a couple side-projects that are focused around the non-crypto side of web3 (distributed file systems of various sorts). In addition to writing a distributed journal system (this question), I'm working on a Go implementation of the HyperSwarm protocol with the ultimate goal of bridging HyperSwarm and IPFS - it feels like there should be a way to find documents regardless of where they exist. I'm also interested in whether something like Gemini could take off as distributed publishing on top of distributed file systems.

Cool stuff :+1: I'm actually hiring right now, so if you are interested to work on high scale IPFS infrastructure, shoot me a quick email at [email protected]. (perfectly optional, no biggies if not interested). Let's not pollute this thread more ;-)

Do you have an issue in the core you'd like me to take on? Generics might be one solution to caching any given entity type but you've managed to generalize Entity without them. It also seems like multi_repo_cache could be used for repo_cache which seems to be an aggregation of repo_cache_bug and repo_cache_identity. I'll play around with the idea of a generic repository cache a bit more.

I'd say scratch your own itch! The things you mentioned are good start. If you need more, there is plenty of ideas in the issues, maybe https://github.com/MichaelMure/git-bug/issues/10 ? Or straight up a new type of entities like a kanban or project settings?

[smoyer64]

@MichaelMure - I've been playing around with the idea of Kanban a bit and would like to propose that you create a "repository project" in Github that contains the backlog of issue you believe to be required for the v1.0.0 release. This would make it easier for others to help and would also provide an example for both the git-bug specific entities that would be required as well as how to alter the bridge to pull and push them.

[MichaelMure]

Rejoice! https://github.com/MichaelMure/git-bug/releases/tag/v0.8.0