You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
Reacted by Glenn Y. Rolland, Ralph J.Mayer, Sofus Albert Høgsbro Rose, Dmytro Sirenko and lajawi
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)
Activity
MichaelMure commentedon Dec 10, 2018
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 ?
vtolstov commentedon Dec 10, 2018
Firstly i think about as backend, to minimize usage of sql database and have ability to create/update/delete issues via console interface =)
MichaelMure commentedon Mar 27, 2019
related issue: go-gitea/gitea#6454
hoijui commentedon Apr 23, 2019
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: go-gitea/gitea#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.
MichaelMure commentedon Apr 23, 2019
@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.
hoijui commentedon Apr 24, 2019
ahhh nice!
perfect explanation, thank you @MichaelMure !
bqv commentedon Mar 27, 2022
@tianyuanhao desperate to see this happen, thanks for your work in #675
nsrosenqvist commentedon Oct 20, 2023
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.
github-actions commentedon Jul 23, 2024
This bot triages untriaged issues and PRs according to the following rules:
lifecycle/stalelabel is appliedlifecycle/stalewas applied, the issue is closedTo remove the stale status, you can:
lifecycle/stalelabelGalaxySnail commentedon Jul 23, 2024
Not stale.
mattcen commentedon Aug 3, 2024
As per #349 (comment):
@sudoforge said:
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 commentedon Aug 4, 2024
@mattcen, I responded here in order to keep the conversation in one place.
github-actions commentedon Nov 3, 2024
This bot triages issues in order to help the maintainers identify what
needs attention, according to the following lifecycle rules:
lifecycle/staleis appliedlifecycle/stalewas applied,lifecycle/rottenis appliedThis bot will not automatically close stale issues.
To remove the stale status, you can:
To avoid automatic lifecycle management of this issue, add
lifecycle/frozen.mcepl commentedon Sep 24, 2026
absolutely not stale
sashil450697 commentedon Sep 24, 2026
wida5962loksin commentedon Sep 24, 2026
wisalia589qs commentedon Sep 24, 2026