Gitea hosted Gitea

[lunny]

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 (#996 #2519 (PR #1332)) Drone PR: (#2017)
• Comment on commit and PR (#124 #2583 #3748 )
• Approvals system (#2794 #3748 )

[Lourens-Rich]

Very good idea!

[Lourens-Rich]

Very good idea!

[bkcsoft]

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]

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

[zellyn]

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]

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

[bkcsoft]

@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]

@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 :)

[strk]

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

[strk]

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

[lunny]

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

[lunny]

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

[lunny]

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

[lunny]

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

[ekozan]

-> OAuth provider (#27) is not closed

[ekozan]

-> OAuth provider (#27) is not closed

[bkcsoft]

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

[bkcsoft]

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

[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

[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

[lunny]

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

[lunny]

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

[bkcsoft]

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

[bkcsoft]

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

[stevegt]

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: #3658 (comment).)

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]

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: #3658 (comment).)

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]

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

[stevegt]

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

[JonasFranzDEV]

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

[JonasFranzDEV]

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

[lunny]

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

[lunny]

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

[mxmehl]

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]

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 :)

[justinclift]

@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]

@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. 😄

[drsect0r]

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

[drsect0r]

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

[mxmehl]

@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]

@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.

[techknowlogick]

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

[techknowlogick]

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

[lafriks]

@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]

@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

[mxmehl]

@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]

@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 ;)

[justinclift]

@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]

@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. 😄

[lafriks]

@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]

@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.

[justinclift]

Heh Heh Heh

No worries at all @lafriks. 😄

[justinclift]

Heh Heh Heh

No worries at all @lafriks. 😄

[lunny]

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

[lunny]

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

[lunny]

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

[lunny]

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

[axifive]

@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]

@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

[lafriks]

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]

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

[lunny]

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

[lunny]

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

[stevegt]

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]

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).