Great to see such project, what do you think - how integrate such thing into gitea to store issues inside git?
gitea integration
Labels: lifecycle/stale
Timeline
That would be great. Are you talking about gitea to use git-bug as a backend or about a bridge to import/export bugs between gitea and git-bug ?
Firstly i think about as backend, to minimize usage of sql database and have ability to create/update/delete issues via console interface =)
related issue: https://github.com/go-gitea/gitea/issues/6454
I would also prefer it that way; that gitea is the interface. why do you prefer the bridge way, @MichaelMure ? ... i would like the interface way very much! I think it would be great for both of the projects. distributed-ness is the thing for conscious, freedom loving people, and that tends to be an important thing in the open source community, and especially among the people using gitea or this project, I would imagine. It is the perfect marriage.
also related issue: https://github.com/go-gitea/gitea/issues/6519
PS: I am investigating possibilities to recommend in an open hardware standard we are developing, and we are lacking a solution for (git) distributed issues that is viable for a broader audience. If it worked with the same web interface without any additional work, that would be it.
@hoijui I would very much welcome gitea to use git-bug as a backend for bugs (and even code review eventually!).
I would consider first the bridge solution, simply because it's by far the easiest and doesn't require heavy changes in gitea. Also note that if the bridge solution is done well enough, you get most of the benefits you would have if gitea used natively git-bug as its backend.
ahhh nice! perfect explanation, thank you @MichaelMure !
@tianyuanhao desperate to see this happen, thanks for your work in #675
Would love this too, also note that Forgejo is another popular for of gitea/gogs, and I think a bridge would be able to provide support for more than just gitea without much issue.
This bot triages untriaged issues and PRs according to the following rules:
- After 90 days of inactivity, the
lifecycle/stalelabel is applied - After 30 days of inactivity since
lifecycle/stalewas applied, the issue is closed
To remove the stale status, you can:
- Remove the
lifecycle/stalelabel - Comment on this issue
Not stale.
As per https://github.com/MichaelMure/git-bug/issues/349#issuecomment-2267075506: @sudoforge said:
I'm hestitant to add new bridges at all given that it adds to the maintenance burden. […] I'm much more in favor of maintaining a common bridge interface and supporting a "plugin system", allowing the community to maintain specific bridges outside of
git-bug.
Do you have ideas or the beginnings of a plan for this? Is it the sort of thing that's likely to get any more traction than the current approach? My concern is that while I agree that this will improve separation and reduce maintenance burden on git-bug core, it would likely involve a significant interface/API design and reimplementation of the 4-5 existing bridges, which is a lot of initial up-front work that could take significant effort (especially on volunteer time).
(EDIT: To be clear, I'm in favour of the approach in general, aside from its potential effort/timeline)
sudoforge commented
@mattcen, I responded here in order to keep the conversation in one place.
This bot triages issues in order to help the maintainers identify what needs attention, according to the following lifecycle rules:
- After 90 days of inactivity,
lifecycle/staleis applied - After 90 days of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied
This bot will not automatically close stale issues.
To remove the stale status, you can:
- Remove the stale label from this issue
- Comment on this issue
- Close this issue
- Offer to help out with triaging
To avoid automatic lifecycle management of this issue, add
lifecycle/frozen.