Gitea hosted Gitea #390

Open
opened 2025-11-02 03:21:15 -06:00 by GiteaMirror · 99 comments
Owner

Originally created by @lunny on GitHub (Feb 23, 2017).

For the first big stage, we would like Gitea's development could be based on a Gitea hosted and github will only a mirror. This will maybe completed in v1.x. So that this issue will list all the features needed to be implemented before v1.x. And of course please discuss them and change my post.

  • Squash merge (#712 #3188)
  • Complete Protected branch (#32 #339)
  • Complete API support (#64)
  • API Documents (#194)
  • Webhooks implementation (#2418)
  • Better CI Integration ( (PR #1332)) Drone PR: (#2017)
  • Comment on commit and PR (#124 #2583 #3748 )
  • Approvals system (#2794 #3748 )
  • Approvals limitations (#5251)
  • Migrate a throughout github repository to gitea (#6290, #7293, #6200, #7410)
  • Dump/restore github/gitlab repository data to a local directory and restore to gitea #12244

Migrating Progress Updated:

Originally created by @lunny on GitHub (Feb 23, 2017). For the first big stage, we would like Gitea's development could be based on a Gitea hosted and github will only a mirror. This will maybe completed in v1.x. So that this issue will list all the features needed to be implemented before v1.x. And of course please discuss them and change my post. - [x] ~Squash merge (#712 #3188)~ - [x] ~Complete Protected branch (#32 #339)~ - [x] ~Complete API support (#64)~ - [x] ~API Documents (#194)~ - [x] ~Webhooks implementation (#2418)~ - [x] ~Better CI Integration ( (PR #1332~)) ~Drone PR: (#2017)~ - [x] ~Comment on commit and PR (#124 ~#2583~ #3748 )~ - [x] ~Approvals system (#2794 #3748 )~ - [x] ~Approvals limitations (#5251)~ - [x] ~Migrate a throughout github repository to gitea (#6290, #7293, #6200, #7410)~ - [x] ~Dump/restore github/gitlab repository data to a local directory and restore to gitea #12244~ Migrating Progress Updated: - [ ] migrate gitea repository -> https://gitea.com/gitea/gitea blocked by #18165 - [x] migrate go-sdk repository -> https://gitea.com/gitea/go-sdk - [x] migrate git repository -> https://gitea.com/gitea/git - [x] migrate tea repository -> https://gitea.com/gitea/tea - [x] migrate website repository -> https://gitea.com/gitea/website - [x] migrate blog repository -> https://gitea.com/gitea/blog - [x] migrate theme repository -> https://gitea.com/gitea/theme - [x] migrate redirects repository -> https://gitea.com/gitea/redirects - [x] migrate homebrew-gitea repository -> https://gitea.com/gitea/homebrew-gitea
GiteaMirror added the type/proposaltopic/deployment labels 2025-11-02 03:21:15 -06:00
Author
Owner

@Lourens-Rich commented on GitHub (Feb 23, 2017):

Very good idea!

@Lourens-Rich commented on GitHub (Feb 23, 2017): Very good idea!
Author
Owner

@bkcsoft commented on GitHub (Feb 27, 2017):

1.2 in February, 1.3 in April, 1.4 in June, 1.5 in August? should be enough time to implement all that 😄

@bkcsoft commented on GitHub (Feb 27, 2017): 1.2 in February, 1.3 in April, 1.4 in June, 1.5 in August? should be enough time to implement all that 😄
Author
Owner

@zellyn commented on GitHub (Mar 10, 2017):

If you haven't seen it, fantastic and insightful comment supporting your approach to self-hosting only when ready: https://lobste.rs/s/gokjbo/gitea_1_1_0_released/comments/dg9pwe#c_dg9pwe

@zellyn commented on GitHub (Mar 10, 2017): If you haven't seen it, fantastic and insightful comment supporting your approach to self-hosting only when ready: https://lobste.rs/s/gokjbo/gitea_1_1_0_released/comments/dg9pwe#c_dg9pwe
Author
Owner

@bkcsoft commented on GitHub (Apr 7, 2017):

@lunny Now that I think about it (thanks @zellyn for that link 😂 ) Why do we need oauth-provider, complete webhook support, api-documentation, and a complete API for self-hosting?

OAuth Consumer is required (it's merged AFAIK) so people can login using github auth.
Drone only uses push hooks, so why would we need the other?

As for API, not sure why self-hosting requires that at all TBH :)

@bkcsoft commented on GitHub (Apr 7, 2017): @lunny Now that I think about it (thanks @zellyn for that link 😂 ) Why do we need oauth-provider, _complete_ webhook support, api-documentation, and a _complete_ API for self-hosting? OAuth _Consumer_ is required (it's merged AFAIK) so people can login using github auth. Drone only uses push hooks, so why would we need the other? As for API, not sure why self-hosting requires that at all TBH :)
Author
Owner

@strk commented on GitHub (Apr 7, 2017):

I agree about trimming that list. Earlier self-hosting will very likely help us setting priorities better :)

@strk commented on GitHub (Apr 7, 2017): I agree about trimming that list. Earlier self-hosting will very likely help us setting priorities better :)
Author
Owner

@lunny commented on GitHub (Apr 7, 2017):

@bkcsoft maybe we can setup a hosted site and have a try.

@lunny commented on GitHub (Apr 7, 2017): @bkcsoft maybe we can setup a hosted site and have a try.
Author
Owner

@lunny commented on GitHub (Apr 7, 2017):

@bkcsoft I updated the issue, do you mean that?

@lunny commented on GitHub (Apr 7, 2017): @bkcsoft I updated the issue, do you mean that?
Author
Owner

@ekozan commented on GitHub (Aug 31, 2017):

-> OAuth provider (#27) is not closed

@ekozan commented on GitHub (Aug 31, 2017): -> OAuth provider (#27) is not closed
Author
Owner

@bkcsoft commented on GitHub (Aug 31, 2017):

@ekozan not closed, but scratched from the list of "things we need"

@bkcsoft commented on GitHub (Aug 31, 2017): @ekozan not closed, but scratched from the list of "things we need"
Author
Owner

@bkcsoft commented on GitHub (Sep 14, 2017):

Added "Repository Size Limits" since we don't have unlimited storage on the servers...

My proposal for limits:

  • 0 Orgs
  • 3 Repos
  • 1GB/repo
@bkcsoft commented on GitHub (Sep 14, 2017): Added "Repository Size Limits" since we don't have unlimited storage on the servers... My proposal for limits: - 0 Orgs - 3 Repos - 1GB/repo
Author
Owner

@lunny commented on GitHub (Sep 14, 2017):

@bkcsoft Did you mean it will be a public service for anyone?

@lunny commented on GitHub (Sep 14, 2017): @bkcsoft Did you mean it will be a public service for anyone?
Author
Owner

@bkcsoft commented on GitHub (Sep 14, 2017):

Maybe, maybe not, but if it becomes a public service we can't have it unlimited ;)

@bkcsoft commented on GitHub (Sep 14, 2017): Maybe, maybe not, but _if_ it becomes a public service we can't have it unlimited ;)
Author
Owner

@stevegt commented on GitHub (May 5, 2018):

I think dogfooding is important enough that repo size limits may not need to be in the critical path for self-hosting gitea. In the first few days after migrating to gitea, I've run across several feature omissions that made me think self-hosting will help focus effort on getting those things done. Gitea is already a fantastic, highly usable, high-performance tool -- it's a real shame you aren't using it yourselves. ;-)

Rather than depend on hard size limits, it might instead be helpful to think about how the self-hosted server is going to be administered, who's going to police bad behavior, and what tools they will want. For instance, contributor forks of the gitea project ought to be supported on gitea's own server. This exposes the risk that a user forks gitea, then pushes warez to their fork. Size limits might help prevent pushing large binaries, but might not help with a list of passwords or credit card numbers. A tool that might help in that case is something that detects alien files by diff line count or rolling hash.

A nice side-effect of having a diff-size tool available is that the code could be available as an option to run during pushes to flag legitimate commits that should have been broken up into smaller pieces anyway. (Related discussion for ways to do this: https://github.com/go-gitea/gitea/issues/3658#issuecomment-372263759.)

I'd bet there are a lot of other subtle things that will need to be addressed for public-facing servers. It might make sense to use a separate "public hosting" master issue or milestone to track these things.

@stevegt commented on GitHub (May 5, 2018): I think dogfooding is important enough that repo size limits may not need to be in the critical path for self-hosting gitea. In the first few days after migrating to gitea, I've run across several feature omissions that made me think self-hosting will help focus effort on getting those things done. Gitea is already a fantastic, highly usable, high-performance tool -- it's a real shame you aren't using it yourselves. ;-) Rather than depend on hard size limits, it might instead be helpful to think about how the self-hosted server is going to be administered, who's going to police bad behavior, and what tools they will want. For instance, contributor forks of the gitea project ought to be supported on gitea's own server. This exposes the risk that a user forks gitea, then pushes warez to their fork. Size limits might help prevent pushing large binaries, but might not help with a list of passwords or credit card numbers. A tool that might help in that case is something that detects alien files by diff line count or rolling hash. A nice side-effect of having a diff-size tool available is that the code could be available as an option to run during pushes to flag legitimate commits that should have been broken up into smaller pieces anyway. (Related discussion for ways to do this: https://github.com/go-gitea/gitea/issues/3658#issuecomment-372263759.) I'd bet there are a lot of other subtle things that will need to be addressed for public-facing servers. It might make sense to use a separate "public hosting" master issue or milestone to track these things.
Author
Owner

@stevegt commented on GitHub (May 5, 2018):

Speaking of milestones, should this issue be added to 1.5.0?

@stevegt commented on GitHub (May 5, 2018): Speaking of milestones, should this issue be added to 1.5.0?
Author
Owner

@jonasfranz commented on GitHub (May 6, 2018):

@stevegt No, since I think that not all of the PRs will get merged / resolved at 1.5.0.

@jonasfranz commented on GitHub (May 6, 2018): @stevegt No, since I think that not all of the PRs will get merged / resolved at 1.5.0.
Author
Owner

@lunny commented on GitHub (May 8, 2018):

I removed Repository Size Limits (#3658) from the issue since it will not affect Gitea hosted gitea.

@lunny commented on GitHub (May 8, 2018): I removed `Repository Size Limits (#3658)` from the issue since it will not affect Gitea hosted gitea.
Author
Owner

@mxmehl commented on GitHub (May 9, 2018):

I removed Repository Size Limits (#3658) from the issue since it will not affect Gitea hosted gitea.

Great! I'm positive that the sooner Gitea hosts itself, the faster will the whole project profit from real-life experiences, and gain trust and confidence :)

@mxmehl commented on GitHub (May 9, 2018): > I removed Repository Size Limits (#3658) from the issue since it will not affect Gitea hosted gitea. Great! I'm positive that the sooner Gitea hosts itself, the faster will the whole project profit from real-life experiences, and gain trust and confidence :)
Author
Owner

@justinclift commented on GitHub (Jun 4, 2018):

@lafriks mentions in another thread:

Self-hosted would probably require additional funding/sponsorship to pay for additional virtual machine

And @lunny asks above:

@bkcsoft Did you mean it will be a public service for anyone?

Would it be feasible to combine those thoughts into a "How about setting up an online Gitea service, where people pay for (say) private repos?".

If done ok, that should generate the funds to pay for itself + the public repos.

As a concept, it seems to be fairly well travelled ground. 😄

@justinclift commented on GitHub (Jun 4, 2018): @lafriks mentions in another thread: > Self-hosted would probably require additional funding/sponsorship to pay for additional virtual machine And @lunny asks above: > @bkcsoft Did you mean it will be a public service for anyone? Would it be feasible to combine those thoughts into a "How about setting up an online Gitea service, where people pay for (say) private repos?". **If** done ok, that should generate the funds to pay for itself + the public repos. As a concept, it seems to be fairly well travelled ground. :smile:
Author
Owner

@drsect0r commented on GitHub (Jun 4, 2018):

To promptly add to @justinclift idea; the timing might be right with the current news of Microsoft taking over GitHub.

@drsect0r commented on GitHub (Jun 4, 2018): To promptly add to @justinclift idea; the timing might be right with the current news of Microsoft taking over GitHub.
Author
Owner

@mxmehl commented on GitHub (Jun 4, 2018):

@lafriks mentions in another thread:

Self-hosted would probably require additional funding/sponsorship to pay for additional virtual machine

I'm confident that there will be funding from the community or sponsorship from organisations to make gitea hosting itself possible. Since Gitea is resource-friendly (yes, GitLab, I'm looking at you) this won't be a big deal.

@mxmehl commented on GitHub (Jun 4, 2018): > @lafriks mentions in another thread: > >> Self-hosted would probably require additional funding/sponsorship to pay for additional virtual machine I'm confident that there will be funding from the community or sponsorship from organisations to make gitea hosting itself possible. Since Gitea is resource-friendly (yes, GitLab, I'm looking at you) this won't be a big deal.
Author
Owner

@techknowlogick commented on GitHub (Jun 4, 2018):

@mxmehl so far there have been 5 individuals that have contributed since the opencollective was open last month: https://opencollective.com/gitea

@techknowlogick commented on GitHub (Jun 4, 2018): @mxmehl so far there have been 5 individuals that have contributed since the opencollective was open last month: https://opencollective.com/gitea
Author
Owner

@lafriks commented on GitHub (Jun 4, 2018):

@justinclift as Gitea is purely community for driven there is no way we could set up paid private repositories as that requires creating company, dealing with taxes, and have full time staff to deal with technical problems

@lafriks commented on GitHub (Jun 4, 2018): @justinclift as Gitea is purely community for driven there is no way we could set up paid private repositories as that requires creating company, dealing with taxes, and have full time staff to deal with technical problems
Author
Owner

@mxmehl commented on GitHub (Jun 4, 2018):

@mxmehl so far there have been 5 individuals that have contributed since the opencollective was open last month: https://opencollective.com/gitea

@techknowlogick Didn't know this page. Now it's 6 ;)

@mxmehl commented on GitHub (Jun 4, 2018): > @mxmehl so far there have been 5 individuals that have contributed since the opencollective was open last month: https://opencollective.com/gitea @techknowlogick Didn't know this page. Now it's 6 ;)
Author
Owner

@justinclift commented on GitHub (Jun 4, 2018):

@lafriks Well.... there are Community projects around - for both software and non-software things - which seem to manage themselves ok, including financial matters, things they pay for, staff (where needed), and so on.

That being said, it does require a level of will to make it happen + keep it going. The people in any needed roles also need to be good custodians (trustworthy, reliable, clueful).

If there's no interest, then it won't go anywhere anyway. Ditto if no suitable "custodian" types can be agreed upon.

From the Open Collective link mentioned above, it looks like some initial seeds are in place. It demonstrates there are people around who are considered ok as custodians. 😄

@justinclift commented on GitHub (Jun 4, 2018): @lafriks Well.... there **are** Community projects around - for both software and non-software things - which seem to manage themselves ok, including financial matters, things they pay for, staff (where needed), and so on. That being said, it does require a level of will to make it happen + keep it going. The people in any needed roles also need to be good custodians (trustworthy, reliable, clueful). If there's no interest, then it won't go anywhere anyway. Ditto if no suitable "custodian" types can be agreed upon. From the [Open Collective](https://opencollective.com/gitea) link mentioned above, it looks like some initial seeds are in place. It demonstrates there are people around who are considered ok as custodians. :smile:
Author
Owner

@lafriks commented on GitHub (Jun 4, 2018):

@justinclift I'm not saying it is not possible but just not at current stage but in future it could happen. Currently at least I would better focus on developing new Gitea features and improving documentation :) So any help is much appreciated to move faster to this goal.

@lafriks commented on GitHub (Jun 4, 2018): @justinclift I'm not saying it is not possible but just not at current stage but in future it could happen. Currently at least I would better focus on developing new Gitea features and improving documentation :) So any help is much appreciated to move faster to this goal.
Author
Owner

@justinclift commented on GitHub (Jun 4, 2018):

Heh Heh Heh

No worries at all @lafriks. 😄

@justinclift commented on GitHub (Jun 4, 2018): Heh Heh Heh No worries at all @lafriks. :smile:
Author
Owner

@lunny commented on GitHub (Jun 5, 2018):

First of the goal is Gitea hosted Gitea since github married with Microsoft. :)

@lunny commented on GitHub (Jun 5, 2018): First of the goal is Gitea hosted Gitea since github married with Microsoft. :)
Author
Owner

@lunny commented on GitHub (Jun 5, 2018):

I think only #2519 and #3748 need review and merge before we close this issue.

@lunny commented on GitHub (Jun 5, 2018): I think only #2519 and #3748 need review and merge before we close this issue.
Author
Owner

@axifive commented on GitHub (Jun 5, 2018):

@bkcsoft

Added "Repository Size Limits" since we don't have unlimited storage on the servers...

My proposal for limits:

  • 0 Orgs
  • 3 Repos
  • 1GB/repo

I think, with the repos quantity limit, we can add allows setting for fork only existing repositories for all users not in the Gitea team:

  • 0 Orgs
  • 3 Repos (allow only forks)
  • 1GB/repo
@axifive commented on GitHub (Jun 5, 2018): @bkcsoft > Added "Repository Size Limits" since we don't have unlimited storage on the servers... > >My proposal for limits: > >- 0 Orgs >- 3 Repos >- 1GB/repo I think, with the repos quantity limit, we can add allows setting for fork only existing repositories for all users not in the Gitea team: - 0 Orgs - 3 Repos (allow only forks) - 1GB/repo
Author
Owner

@lafriks commented on GitHub (Jun 5, 2018):

I don't think fork count need to be limited, it would be limited by gitea org repository count anyway, so that should be ok.
As for repo size, yeah, probably there should be some limits

@lafriks commented on GitHub (Jun 5, 2018): I don't think fork count need to be limited, it would be limited by gitea org repository count anyway, so that should be ok. As for repo size, yeah, probably there should be some limits
Author
Owner

@lunny commented on GitHub (Jun 5, 2018):

We should limit creating orgs, creating repos, so repo size limit is not a necessary issue for Gitea hosted Gitea.

@lunny commented on GitHub (Jun 5, 2018): We should limit creating orgs, creating repos, so repo size limit is not a necessary issue for Gitea hosted Gitea.
Author
Owner

@stevegt commented on GitHub (Jun 23, 2018):

We might consider adding #3134 and #4302 (PR and issue backlinks) to the prereq list for self-hosting -- maybe I'm unique, but our own little gitea install started getting unwieldy without those backlinks as soon as we added more than a few users and issues. We've been able to work around that some with issue search, but that's limited without global issue search (#2434/#3841).

@stevegt commented on GitHub (Jun 23, 2018): We might consider adding #3134 and #4302 (PR and issue backlinks) to the prereq list for self-hosting -- maybe I'm unique, but our own little gitea install started getting unwieldy without those backlinks as soon as we added more than a few users and issues. We've been able to work around that some with issue search, but that's limited without global issue search (#2434/#3841).
Author
Owner

@bkcsoft commented on GitHub (Jul 4, 2018):

@stevegt While backlinks would be nice to have, I don't see them blocking moving to self-hosting :)

@bkcsoft commented on GitHub (Jul 4, 2018): @stevegt While backlinks would be nice to have, I don't see them blocking moving to self-hosting :)
Author
Owner

@stevegt commented on GitHub (Jul 5, 2018):

@bkcsoft Fair enough -- just thought I'd mention it in case it triggered any realizations. In our local case, we've been developing the habit of manually adding the backlinks in issue comments as a workaround.

@stevegt commented on GitHub (Jul 5, 2018): @bkcsoft Fair enough -- just thought I'd mention it in case it triggered any realizations. In our local case, we've been developing the habit of manually adding the backlinks in issue comments as a workaround.
Author
Owner

@jlelse commented on GitHub (Jul 9, 2018):

I recently heard about the effort of https://teahub.io. They want to start a non-profit org. Can't Gitea use that once they are ready with the setup?

@jlelse commented on GitHub (Jul 9, 2018): I recently heard about the effort of https://teahub.io. They want to start a non-profit org. Can't Gitea use that once they are ready with the setup?
Author
Owner

@lunny commented on GitHub (Jul 9, 2018):

@jlelse No. Gitea will set up a standalone server (i.e. self.gitea.io) to host gitea and mirror to github, gitlab or teahub and etc.

@lunny commented on GitHub (Jul 9, 2018): @jlelse No. Gitea will set up a standalone server (i.e. self.gitea.io) to host gitea and mirror to github, gitlab or teahub and etc.
Author
Owner

@jonasfranz commented on GitHub (Jul 9, 2018):

@lunny Do we really require commments on commits since we are currently only using comments on PR at GitHub?

@jonasfranz commented on GitHub (Jul 9, 2018): @lunny Do we really require commments on commits since we are currently only using comments on PR at GitHub?
Author
Owner

@lunny commented on GitHub (Jul 11, 2018):

@JonasFranzDEV I mean comments on commits of PR, I think it's necessary.

@lunny commented on GitHub (Jul 11, 2018): @JonasFranzDEV I mean comments on commits of PR, I think it's necessary.
Author
Owner

@ryanburnette commented on GitHub (Aug 25, 2018):

I'm commenting here because #4108 is closed. When the Gitea Patreon (or Patreon-like alternative) goes up, I need to know about it. I'll be contributing. I'd like to see this project self-hosted and further developed. Once I move all my repositories I won't be spending money with Github anymore, I'll commit that monthly to the Patreon.

@ryanburnette commented on GitHub (Aug 25, 2018): I'm commenting here because #4108 is closed. When the Gitea Patreon (or Patreon-like alternative) goes up, I need to know about it. I'll be contributing. I'd like to see this project self-hosted and further developed. Once I move all my repositories I won't be spending money with Github anymore, I'll commit that monthly to the Patreon.
Author
Owner

@techknowlogick commented on GitHub (Aug 25, 2018):

@ryanburnette https://opencollective.com/gitea

@techknowlogick commented on GitHub (Aug 25, 2018): @ryanburnette https://opencollective.com/gitea
Author
Owner

@mjmlvp commented on GitHub (Sep 8, 2018):

@lunny looks like 'Approval system' in the topic start can be crossed out. (The issues being respectively closed and merged)?

@mjmlvp commented on GitHub (Sep 8, 2018): @lunny looks like 'Approval system' in the topic start can be crossed out. (The issues being respectively closed and merged)?
Author
Owner

@lunny commented on GitHub (Sep 9, 2018):

@mjmlvp I think you are right. I removed #996 #2519 since it should not be a block of this issue. We will set up a server to host our developments.

@lunny commented on GitHub (Sep 9, 2018): @mjmlvp I think you are right. I removed #996 #2519 since it should not be a block of this issue. We will set up a server to host our developments.
Author
Owner

@strk commented on GitHub (Oct 9, 2018):

Any news on this ?

@strk commented on GitHub (Oct 9, 2018): Any news on this ?
Author
Owner

@lafriks commented on GitHub (Oct 9, 2018):

Yes we still need to add approval limitations and then we can migrate to selfhosted code

@lafriks commented on GitHub (Oct 9, 2018): Yes we still need to add approval limitations and then we can migrate to selfhosted code
Author
Owner

@raucao commented on GitHub (Oct 10, 2018):

Would be nice to add the open issues for that to the list. At the moment it looks like all linked issues and PRs have been closed and merged.

@raucao commented on GitHub (Oct 10, 2018): Would be nice to add the open issues for that to the list. At the moment it looks like all linked issues and PRs have been closed and merged.
Author
Owner

@lunny commented on GitHub (Oct 10, 2018):

@skddc done.

@lunny commented on GitHub (Oct 10, 2018): @skddc done.
Author
Owner

@milahu commented on GitHub (Nov 1, 2018):

for the record

open gitea servers

trust no one. make regular backups

@milahu commented on GitHub (Nov 1, 2018): for the record open gitea servers - https://try.gitea.io/ - https://teahub.io/ - https://dev.sum7.eu/ trust no one. make regular backups
Author
Owner

@ptman commented on GitHub (Nov 29, 2018):

@giteauser I fail to see how that is relevant

@ptman commented on GitHub (Nov 29, 2018): @giteauser I fail to see how that is relevant
Author
Owner

@ptman commented on GitHub (Nov 29, 2018):

@giteauser and this is about self-hosting gitea development, so that gitea development doesn't have to happen on github anymore. I still fail to see how this is relevant.

@ptman commented on GitHub (Nov 29, 2018): @giteauser and this is about self-hosting gitea development, so that gitea development doesn't have to happen on github anymore. I still fail to see how this is relevant.
Author
Owner

@ghost commented on GitHub (Nov 29, 2018):

Oh I posted these for the wrong issue, I'm sorry.

@ghost commented on GitHub (Nov 29, 2018): Oh I posted these for the wrong issue, I'm sorry.
Author
Owner

@davidak commented on GitHub (Dec 12, 2018):

So, every needed feature should be implemented now. Can we have a new release and migrate away?

@davidak commented on GitHub (Dec 12, 2018): So, every needed feature should be implemented now. Can we have a new release and migrate away?
Author
Owner

@lunny commented on GitHub (Dec 12, 2018):

Right, we will setup a gitea instance to host gitea's development.

@lunny commented on GitHub (Dec 12, 2018): Right, we will setup a gitea instance to host gitea's development.
Author
Owner

@max-wittig commented on GitHub (Jan 9, 2019):

I think fixing the backup dump issue and adding proper restore functionality is also an important part to managing infrastructure of a self-hosted gitea

@max-wittig commented on GitHub (Jan 9, 2019): I think fixing the [backup dump issue](https://github.com/go-gitea/gitea/issues/4407) and [adding proper restore functionality](https://docs.gitea.io/en-us/backup-and-restore/) is also an important part to managing infrastructure of a self-hosted gitea
Author
Owner

@raucao commented on GitHub (Jan 10, 2019):

If you're deploying Gitea on Kubernetes, I can recommend Ark for backups and restores.

Generally speaking, backup doesn't seem like it should be a blocking topic for self-hosting Gitea development, because everyone usually has different backup strategies/programs, depending on their choice of platform, method of deployment, existing tools, etc.. It should only be a blocking issue for that very instance's production readiness.

@raucao commented on GitHub (Jan 10, 2019): If you're deploying Gitea on Kubernetes, I can recommend [Ark](https://heptio.github.io/ark) for backups and restores. Generally speaking, backup doesn't seem like it should be a blocking topic for self-hosting Gitea development, because everyone usually has different backup strategies/programs, depending on their choice of platform, method of deployment, existing tools, etc.. It should only be a blocking issue for that very instance's production readiness.
Author
Owner

@lunny commented on GitHub (Jan 10, 2019):

@max-wittig The gitea self-hosted website will run on some public cloud provider. They will provide RDS service and database backup tool and some disk backup function so that backup dump command is not a dependency issue. The dump command is for a single-node gitea service. Of course we should fix that issues.

@lunny commented on GitHub (Jan 10, 2019): @max-wittig The gitea self-hosted website will run on some public cloud provider. They will provide RDS service and database backup tool and some disk backup function so that backup dump command is not a dependency issue. The dump command is for a single-node gitea service. Of course we should fix that issues.
Author
Owner

@lunny commented on GitHub (Jan 10, 2019):

@skddc It's an interesting tool that we can consider that.

@lunny commented on GitHub (Jan 10, 2019): @skddc It's an interesting tool that we can consider that.
Author
Owner

@markg85 commented on GitHub (Jan 24, 2019):

I really hope the 1.8.0 release is going to be the version where gitea becomes self hosted. I personally would love to use it for my own projects but am only using gitea as a mirror for the simple reason that i don't trust it enough if the devs - you guys - don't even use it for the gitea development. Also, i'd like to propose to use gitea in my working environment but can't even propose it as i will just be laughed at when i say: "oh btw, it looks awesome, but the devs of gitea don't use it for their own project" ...

This is not meant as criticism or as a way to push you folks. Just letting you know what i (and probably lots of others) would find troublesome when it comes to using gitea as main source code control system ;)

Lastly, to be a bit more constructive. If you are looking for a very good (and cheap) clous vps for backups or even to host gitea on, take a look at hetzner https://www.hetzner.com/storage/storage-box Though for an important infrastructure as Gitea you'd probably want to back it up at two completely different locations (say hetzner and digitalocean for instance).

@markg85 commented on GitHub (Jan 24, 2019): I really hope the 1.8.0 release is going to be the version where gitea becomes self hosted. I personally would love to use it for my own projects but am only using gitea as a mirror for the simple reason that i don't trust it enough if the devs - you guys - don't even use it for the gitea development. Also, i'd like to propose to use gitea in my working environment but can't even propose it as i will just be laughed at when i say: "oh btw, it looks awesome, but the devs of gitea don't use it for their own project" ... This is not meant as criticism or as a way to push you folks. Just letting you know what i (and probably lots of others) would find troublesome when it comes to using gitea as main source code control system ;) Lastly, to be a bit more constructive. If you are looking for a very good (and cheap) clous vps for backups or even to host gitea on, take a look at hetzner https://www.hetzner.com/storage/storage-box Though for an important infrastructure as Gitea you'd probably want to back it up at two completely different locations (say hetzner and digitalocean for instance).
Author
Owner

@lunny commented on GitHub (Jan 25, 2019):

@markg85 we are working on https://gitea.com

@lunny commented on GitHub (Jan 25, 2019): @markg85 we are working on https://gitea.com
Author
Owner

@zachdoty commented on GitHub (Feb 21, 2019):

Any update on gitea hosted gitea at gitea.com?

@zachdoty commented on GitHub (Feb 21, 2019): Any update on gitea hosted gitea at gitea.com?
Author
Owner

@lunny commented on GitHub (Feb 21, 2019):

@zachdoty Still are working on that.

@lunny commented on GitHub (Feb 21, 2019): @zachdoty Still are working on that.
Author
Owner

@lunny commented on GitHub (Feb 28, 2019):

I forgot something necessary to move from github to gitea. We need move all data(include git data, issues, comments, pull requests from github to gitea), but in fact I haven't found suitable tools to do that. I have sent PR about move migrating repository from frontend to backend, see #6200 , and also https://gitea.com/gitea/migrator should be merged to gitea because gitea's API will not allow create issue with specify index number.

@lunny commented on GitHub (Feb 28, 2019): I forgot something necessary to move from github to gitea. We need move all data(include git data, issues, comments, pull requests from github to gitea), but in fact I haven't found suitable tools to do that. I have sent PR about move migrating repository from frontend to backend, see #6200 , and also https://gitea.com/gitea/migrator should be merged to gitea because gitea's API will not allow create issue with specify index number.
Author
Owner

@raucao commented on GitHub (Feb 28, 2019):

gitea-github-migrator can migrate almost everything, in case you haven't found that one yet. If something is missing, maybe it can be added there, so other projects also have a good tool for migrating.

@raucao commented on GitHub (Feb 28, 2019): [gitea-github-migrator](https://git.jonasfranz.software/JonasFranzDEV/gitea-github-migrator.git) can migrate almost everything, in case you haven't found that one yet. If something is missing, maybe it can be added there, so other projects also have a good tool for migrating.
Author
Owner

@kolaente commented on GitHub (Feb 28, 2019):

@skddc they actually are the same.

@kolaente commented on GitHub (Feb 28, 2019): @skddc they actually are the same.
Author
Owner

@raucao commented on GitHub (Feb 28, 2019):

Ah, sorry. Hadn't followed the link.

@raucao commented on GitHub (Feb 28, 2019): Ah, sorry. Hadn't followed the link.
Author
Owner

@lunny commented on GitHub (Feb 28, 2019):

As @kolaente said, we invited @jonasfranz move gitea-github-migrator to gitea.com and I send a PR https://gitea.com/gitea/migrator/pulls/1 wants to improve that. But I found as a third-party tool, there is one disadvantage. That is it's difficult to keep the issue index as before. (To let all the links on the issue still available.) So I think merge the migrate tool into gitea on the migrate UI is a better idea.

@lunny commented on GitHub (Feb 28, 2019): As @kolaente said, we invited @jonasfranz move gitea-github-migrator to gitea.com and I send a PR https://gitea.com/gitea/migrator/pulls/1 wants to improve that. But I found as a third-party tool, there is one disadvantage. That is it's difficult to keep the issue index as before. (To let all the links on the issue still available.) So I think merge the migrate tool into gitea on the migrate UI is a better idea.
Author
Owner

@raucao commented on GitHub (Feb 28, 2019):

Would definitely be awesome if the internal links in comments etc. could be preserved. Would also be awesome if the PRs that originate from the same repo could be imported as actual PRs instead of issues!

@raucao commented on GitHub (Feb 28, 2019): Would definitely be awesome if the internal links in comments etc. could be preserved. Would also be awesome if the PRs that originate from the same repo could be imported as actual PRs instead of issues!
Author
Owner

@lunny commented on GitHub (Feb 28, 2019):

I added new task Migrate a throughout github repository to gitea on issue content and move this to 1.9.0 so that this will not block v1.8's release. But I don't think we should wait until v1.9 released since gitea.com will follow the master.

@lunny commented on GitHub (Feb 28, 2019): I added new task `Migrate a throughout github repository to gitea` on issue content and move this to 1.9.0 so that this will not block v1.8's release. But I don't think we should wait until v1.9 released since gitea.com will follow the master.
Author
Owner

@BNolet commented on GitHub (Mar 17, 2019):

Is Gitea.com production ready, as in should I worry about storing code there and it being lost?

@BNolet commented on GitHub (Mar 17, 2019): Is Gitea.com production ready, as in should I worry about storing code there and it being lost?
Author
Owner

@lunny commented on GitHub (Apr 20, 2019):

@BNolet we have set up a 6 machines ceph cluster to store the repositories. So it should not be lost easy since all the data will be copied 3 times. We are working on set up another backup via ceph mirror. And since git is distributed. Your codes will always store on your or your colleagues disk.

@lunny commented on GitHub (Apr 20, 2019): @BNolet we have set up a 6 machines ceph cluster to store the repositories. So it should not be lost easy since all the data will be copied 3 times. We are working on set up another backup via ceph mirror. And since git is distributed. Your codes will always store on your or your colleagues disk.
Author
Owner

@BNolet commented on GitHub (Apr 20, 2019):

Wow that's fantastic! Do you all anticipate being able to be a full-on alternative to GitHub or Gitlab?

@BNolet commented on GitHub (Apr 20, 2019): Wow that's fantastic! Do you all anticipate being able to be a full-on alternative to GitHub or Gitlab?
Author
Owner

@lunny commented on GitHub (Apr 20, 2019):

I don't think so. The main target of gitea.com is to host gitea's developments itself. Although we haven't do any limitation on gitea.com, but we encourage you to set up yourself hosted Gitea instance since it's so easy.

@lunny commented on GitHub (Apr 20, 2019): I don't think so. The main target of gitea.com is to host gitea's developments itself. Although we haven't do any limitation on gitea.com, but we encourage you to set up yourself hosted Gitea instance since it's so easy.
Author
Owner

@strk commented on GitHub (Apr 24, 2019):

Any reason for not enabling OpenID sign-in ?

@strk commented on GitHub (Apr 24, 2019): Any reason for not enabling OpenID sign-in ?
Author
Owner

@BNolet commented on GitHub (Apr 24, 2019):

@lunny I have one and I love it :D

How likely is it that CI/CD becomes a part of Gitea the product?

@BNolet commented on GitHub (Apr 24, 2019): @lunny I have one and I love it :D How likely is it that CI/CD becomes a part of Gitea the product?
Author
Owner

@lunny commented on GitHub (Apr 24, 2019):

@strk just forget it. Will enable OpenID sign-in.
@BNolet Gitea itself will use drone as the primary CI/CD.

@lunny commented on GitHub (Apr 24, 2019): @strk just forget it. Will enable OpenID sign-in. @BNolet Gitea itself will use drone as the primary CI/CD.
Author
Owner

@jakimfett commented on GitHub (May 18, 2019):

Getting a 500 error upon attempting to use the Github oauth option on the login page, after I go the permissions request for the go-gitea app on Github.

Should I wait a bit to check out the flagship instance?

@jakimfett commented on GitHub (May 18, 2019): Getting a 500 error upon attempting to use the Github oauth option on the login page, after I go the permissions request for the go-gitea app on Github. Should I wait a bit to check out the flagship instance?
Author
Owner

@lunny commented on GitHub (May 19, 2019):

@jakimfett that's a known issue. You can try twice and it's OK.

@lunny commented on GitHub (May 19, 2019): @jakimfett that's a known issue. You can try twice and it's OK.
Author
Owner

@strk commented on GitHub (May 26, 2019):

@strk just forget it. Will enable OpenID sign-in.

@lunny as it was still off today, is there maybe a deploy script that keeps turning it off ?

@strk commented on GitHub (May 26, 2019): > @strk just forget it. Will enable OpenID sign-in. @lunny as it was still off today, is there maybe a deploy script that keeps turning it off ?
Author
Owner

@jakimfett commented on GitHub (May 26, 2019):

@jakimfett that's a known issue...

Throw an edit in with the issue number and I'll followup there.

edit(s): formatting

@jakimfett commented on GitHub (May 26, 2019): > @jakimfett that's a known issue... <snip/> Throw an edit in with the issue number and I'll followup there. _edit(s): formatting_
Author
Owner

@curbengh commented on GitHub (Jun 22, 2019):

Codeberg is a free Gitea-based service. Perhaps Gitea can set up an official mirror there. Currently it's mirrored at https://codeberg.org/Codeberg/gitea.

@curbengh commented on GitHub (Jun 22, 2019): [Codeberg](https://codeberg.org/) is a free Gitea-based service. Perhaps Gitea can set up an official mirror there. Currently it's mirrored at https://codeberg.org/Codeberg/gitea.
Author
Owner

@lunny commented on GitHub (Jun 23, 2019):

Gitea will be hosted on https://gitea.com/gitea/gitea , and we have moved most other packages to https://gitea.com/gitea, and gitea itself is on progress. Mirror is welcome on any other gitea-based service.

@lunny commented on GitHub (Jun 23, 2019): Gitea will be hosted on https://gitea.com/gitea/gitea , and we have moved most other packages to https://gitea.com/gitea, and gitea itself is on progress. Mirror is welcome on any other gitea-based service.
Author
Owner

@jakimfett commented on GitHub (Jun 24, 2019):

@lunny commented yesterday:
Mirror is welcome on any other gitea-based service.

I'll hack together an up-to-date mirror once I get back from my weekend.

Related:
Is there a list of mirrors somewhere, and do I add myself to it, or...?

@jakimfett commented on GitHub (Jun 24, 2019): > *@lunny commented yesterday:* > Mirror is welcome on any other gitea-based service. I'll hack together an up-to-date mirror once I get back from my weekend. **Related:** Is there a list of mirrors somewhere, and do I add myself to it, or...?
Author
Owner

@kolaente commented on GitHub (Jun 24, 2019):

@jakimfett There isn't, but you could create a pr with a new docs page

@kolaente commented on GitHub (Jun 24, 2019): @jakimfett There isn't, but you could create a pr with a new docs page
Author
Owner

@lunny commented on GitHub (Jul 1, 2019):

For a better user handler when migrating gitea away github, I would like to move this to v1.10 and I think we should implement https://github.com/go-gitea/gitea/issues/7293 before we start to migrate.

@lunny commented on GitHub (Jul 1, 2019): For a better user handler when migrating gitea away github, I would like to move this to v1.10 and I think we should implement https://github.com/go-gitea/gitea/issues/7293 before we start to migrate.
Author
Owner

@SuperSandro2000 commented on GitHub (Sep 10, 2019):

I would be totally for that move if it wasn't hosted in China or activation email took 10 min to arrive.

@SuperSandro2000 commented on GitHub (Sep 10, 2019): I would be totally for that move if it wasn't hosted in China or activation email took 10 min to arrive.
Author
Owner

@programmerjake commented on GitHub (Sep 10, 2019):

I would be totally for that move if it wasn't hosted in China or activation email took 10 min to arrive.

Edit: apparently, I was incorrect.

from some googling, apparently gitea.com's IP address is actually in Japan, not China. That IP address is owned by Alibaba though.

@programmerjake commented on GitHub (Sep 10, 2019): > I would be totally for that move if it wasn't hosted in China or activation email took 10 min to arrive. Edit: apparently, I was incorrect. from some googling, apparently gitea.com's IP address is actually in Japan, not China. That IP address is owned by Alibaba though.
Author
Owner

@lunny commented on GitHub (Sep 10, 2019):

We use mailgun.org to send mails. I don't know why it will spend 10 minutes.

Our donates cloud provider is didiyun which is in China and it provides many machines. We have no other choice currently.

And gitea.com's first purpose will not become as a service like github.com or gitlab.com. It will only host gitea itself and we recommend you set up yourself gitea instance in fact.

@lunny commented on GitHub (Sep 10, 2019): We use `mailgun.org` to send mails. I don't know why it will spend 10 minutes. Our donates cloud provider is didiyun which is in China and it provides many machines. We have no other choice currently. And gitea.com's first purpose will not become as a service like github.com or gitlab.com. It will only host gitea itself and we recommend you set up yourself gitea instance in fact.
Author
Owner

@lunny commented on GitHub (Sep 10, 2019):

@programmerjake That's a bridge server.

@lunny commented on GitHub (Sep 10, 2019): @programmerjake That's a bridge server.
Author
Owner

@SuperSandro2000 commented on GitHub (Sep 10, 2019):

It wasn't my intention to switch away from my instance but I don't like that this project relies on infrastructure donated from a Chinese company that has almost no reputation in the past or search results. You don't really know what they do in the future or if they demand to cut their donation if you don't implement XY or do ZA or if they just go away some day.
You probably know what you are doing and my concerns are just to cautious but you'll never know.

@SuperSandro2000 commented on GitHub (Sep 10, 2019): It wasn't my intention to switch away from my instance but I don't like that this project relies on infrastructure donated from a ~~Chinese~~ company that has almost no reputation in the past or search results. You don't really know what they do in the future or if they demand to cut their donation if you don't implement XY or do ZA or if they just go away some day. You probably know what you are doing and my concerns are just to cautious but you'll never know.
Author
Owner

@lunny commented on GitHub (Sep 10, 2019):

Why a Chinese company will do that but an U.S. company will not? :)

@lunny commented on GitHub (Sep 10, 2019): Why a Chinese company will do that but an U.S. company will not? :)
Author
Owner

@lunny commented on GitHub (Sep 10, 2019):

And I'm a Chinese, and maybe you should be careful. Someday I may stole your codes. :)

@lunny commented on GitHub (Sep 10, 2019): And I'm a Chinese, and maybe you should be careful. Someday I may stole your codes. :)
Author
Owner

@lunny commented on GitHub (Sep 10, 2019):

I think I may have that plan when I started Gogs with other 3 Chinese people on 2014.

@lunny commented on GitHub (Sep 10, 2019): I think I may have that plan when I started Gogs with other 3 Chinese people on 2014.
Author
Owner

@markg85 commented on GitHub (Sep 10, 2019):

It wasn't my intention to switch away from my instance but I don't like that this project relies on infrastructure donated from a Chinese company. You don't really know what they do in the future or if they demand to cut their donation if you don't implement XY or do ZA or if they just go away some day.
You probably know what you are doing and my concerns are just to cautious but you'll never know.

That's a totally idiotic reply.
Now i might be more open minded as i'm Dutch, we kinda embrace that. You should try it too.

As long as this project is open source, there is no risk in my opinion for anything you said.
And even if they do, which probably means forking Gitea, they are fully in their right as the license simply permits it.

The US however... let me remind you that Github has limited their features now due to the "trade war" between the US and China. If anything, the US is more of a risk for free software development at the moment then China has ever been. Heck, @lunny is probably even effected on this very repository due to the trade war.

@lunny and the team developing Gitea. Keep up the awesome work! :)

@markg85 commented on GitHub (Sep 10, 2019): > It wasn't my intention to switch away from my instance but I don't like that this project relies on infrastructure donated from a Chinese company. You don't really know what they do in the future or if they demand to cut their donation if you don't implement XY or do ZA or if they just go away some day. > You probably know what you are doing and my concerns are just to cautious but you'll never know. That's a totally idiotic reply. Now i might be more open minded as i'm Dutch, we kinda embrace that. You should try it too. As long as this project is open source, there is no risk in my opinion for anything you said. And even if they do, which probably means forking Gitea, they are fully in their right as the license simply permits it. The US however... let me remind you that Github has limited their features now due to the "trade war" between the US and China. If anything, the US is more of a risk for free software development at the moment then China has ever been. Heck, @lunny is probably even effected on this very repository due to the trade war. @lunny and the team developing Gitea. Keep up the awesome work! :)
Author
Owner

@kmmndr commented on GitHub (Sep 10, 2019):

And gitea.com's first purpose will not become as a service like github.com or gitlab.com. It will only host gitea itself and we recommend you set up yourself gitea instance in fact.

Is it something you may consider in the future ?

@kmmndr commented on GitHub (Sep 10, 2019): > And gitea.com's first purpose will not become as a service like github.com or gitlab.com. It will only host gitea itself and we recommend you set up yourself gitea instance in fact. Is it something you may consider in the future ?
Author
Owner

@SuperSandro2000 commented on GitHub (Sep 10, 2019):

As long as this project is open source, there is no risk in my opinion for anything you said.

The core project has no risk but the infrastructure does. There are no guaranties that the unknown unreputable donor will be there next month no matter if he comes from anywhere or China. GitHub will be here for a long time and won't go anywhere that quick.

Also if the entire infrastructure moves to China the entire user base will suffer due to the difficulties between the US and China.

@SuperSandro2000 commented on GitHub (Sep 10, 2019): >As long as this project is open source, there is no risk in my opinion for anything you said. The core project has no risk but the infrastructure does. There are no guaranties that the unknown unreputable donor will be there next month no matter if he comes from anywhere or China. GitHub will be here for a long time and won't go anywhere that quick. Also if the entire infrastructure moves to China the entire user base will suffer due to the difficulties between the US and China.
Author
Owner

@guillep2k commented on GitHub (Sep 10, 2019):

@lunny Regarding e-mails taking ~10 minutes, in my case my company server has an anti-SPAM measure that is a "cool off" timer (20 minutes here) within which it will temporarily reject any mails from unknown sources. So, if it's the first time a user (me) receives an e-mail from that domain (e.g. gitea.com), then my server will respond with "try later" and remember that user/domain combination. The next time gitea.com attempts to deliver my mail within the expected time, the server accepts the message.
Obviously we have some "trusted sources" configured, like GMail, Hotmail, etc. that don't need a cool-off period.

@guillep2k commented on GitHub (Sep 10, 2019): @lunny Regarding e-mails taking ~10 minutes, in my case my company server has an anti-SPAM measure that is a "cool off" timer (20 minutes here) within which it will temporarily reject any mails from unknown sources. So, if it's the first time a user (me) receives an e-mail from that domain (e.g. gitea.com), then my server will respond with "try later" and remember that user/domain combination. The next time gitea.com attempts to deliver my mail within the expected time, the server accepts the message. Obviously we have some "trusted sources" configured, like GMail, Hotmail, etc. that don't need a cool-off period.
Author
Owner

@lathama commented on GitHub (Sep 10, 2019):

People, if you want more infrastructure spread around for every region then please vote with your wallet at https://opencollective.com/gitea

@lathama commented on GitHub (Sep 10, 2019): People, if you want more infrastructure spread around for every region then please vote with your wallet at https://opencollective.com/gitea
Author
Owner

@guillep2k commented on GitHub (Sep 10, 2019):

@SuperSandro2000 Are you aware that Gitea is not a service but a product? You download the sources, compile Gitea in your servers and install it. No connection whatsoever required to Gitea's hosting.

@guillep2k commented on GitHub (Sep 10, 2019): @SuperSandro2000 Are you aware that Gitea is not a service but a _product_? You download the sources, compile Gitea in your servers and install it. No connection whatsoever required to Gitea's hosting.
Author
Owner

@techknowlogick commented on GitHub (Sep 10, 2019):

if they demand to cut their donation if you don't implement XY or do ZA or if they just go away some day.

There are no guaranties that the unknown unreputable donor will be there next month.

A couple of responses to this: We wouldn't host on an unreputable company, and the Gitea leads have placed our trust in this company. If they stop providing sponsorship, or stop being a company we have options available to us, and can move elsewhere.

the entire user base will suffer due to the difficulties between the US and China.

A large part of Gitea team is from China (but we also have maintainers in all other continents too), and if development team can't access code then the user base will suffer, which is why we need development team to be able to access code. We build Gitea so everyone can use it, even users who are banned from GitHub (after recent ban wave from GitHub a lot of those users started using Gitea).

As others have mentioned, there are mirrors of the codebase on other instances around the world, and thanks to git there is a ledger of all changes made to code so everyone can have visibility into all changes.

A note on transparency: I have locked this thread. I don't want to stop this conversation, however it should be moved to a different place as this github ticket is about what enhancements need to be done with software for self-hosting (rather than where we are hosting).

@techknowlogick commented on GitHub (Sep 10, 2019): > if they demand to cut their donation if you don't implement XY or do ZA or if they just go away some day. > There are no guaranties that the unknown unreputable donor will be there next month. A couple of responses to this: We wouldn't host on an unreputable company, and the Gitea leads have placed our trust in this company. If they stop providing sponsorship, or stop being a company we have options available to us, and can move elsewhere. > the entire user base will suffer due to the difficulties between the US and China. A large part of Gitea team is from China (but we also have maintainers in all other continents too), and if development team can't access code then the user base will suffer, which is why we need development team to be able to access code. We build Gitea so everyone can use it, even users who are banned from GitHub (after recent ban wave from GitHub a lot of those users started using Gitea). As others have mentioned, there are mirrors of the codebase on other instances around the world, and thanks to git there is a ledger of all changes made to code so everyone can have visibility into all changes. A note on transparency: I have locked this thread. I don't want to stop this conversation, however it should be moved to a different place as this github ticket is about what enhancements need to be done with software for self-hosting (rather than where we are hosting).
Author
Owner

@techknowlogick commented on GitHub (Mar 20, 2023):

There haven't been many updates on this posted, but I just wanted to say it is being worked on. The alternative export API that Github provides is sadly not working for us, it always returns that it fails to export the data. My guess is that the amount of data we have is too much. If anyone has any contacts at Github who can help us out, please let me know :) My contact email is in my bio.

@techknowlogick commented on GitHub (Mar 20, 2023): There haven't been many updates on this posted, but I just wanted to say it is being worked on. The alternative export API that Github provides is sadly not working for us, it always returns that it fails to export the data. My guess is that the amount of data we have is too much. If anyone has any contacts at Github who can help us out, please let me know :) My contact email is in my bio.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#390