Gitea: Gitea에서 호스팅하는 Gitea

아주 좋은 생각입니다!

2월에 1.2, 4월에 1.3, 6월에 1.4, 8월에 1.5? 이 모든 것을 구현하기에 충분한 시간이어야 합니다 😄

아직 보지 못했다면 준비된 경우에만 자체 호스팅에 대한 접근 방식을 지원하는 환상적이고 통찰력 있는 설명: https://lobste.rs/s/gokjbo/gitea_1_1_0_released/comments/dg9pwe#c_dg9pwe

@lunny 이제 생각해 보니 (링크에 대해 @zellyn 에게 감사드립니다

사람들이 github 인증을 사용하여 로그인할 수 있도록 OAuth _Consumer_가 필요합니다(AFAIK 병합됨).
드론은 푸시 후크만 사용하는데 왜 다른 것이 필요할까요?

API의 경우 자체 호스팅에서 TBH가 필요한 이유를 잘 모르겠습니다. :)

나는 그 목록을 다듬는 것에 동의합니다. 이전 자체 호스팅은 우선 순위를 더 잘 설정하는 데 도움이 될 가능성이 큽니다. :)

@bkcsoft 아마도 호스팅 사이트를 설정하고 시도해 볼 수 있습니다.

@bkcsoft 문제를 업데이트

-> OAuth 공급자(#27)가 닫히지 않았습니다.

@ekozan은 닫히지 않았지만 "필요한 것" 목록에서

서버에 무제한 저장 공간이 없기 때문에 "저장소 크기 제한"을 추가했습니다...

제한에 대한 나의 제안:

• 0 조직
• 3 레포
• 1GB/리포지토리

@bkcsoft 누구를 위한 공익사업이라는

아마도, 아닐 수도 있지만 _만약_ 그것이 공공 서비스가 된다면 우리는 그것을 무제한으로 가질 수 없습니다 ;)

자체 호스팅 gitea의 중요한 경로에 repo 크기 제한이 필요하지 않을 수 있으므로 dogfooding이 충분히 중요하다고 생각합니다. gitea로 마이그레이션한 후 처음 며칠 동안 몇 가지 기능 누락을 경험했는데 셀프 호스팅이 이러한 작업을 완료하는 데 집중하는 데 도움이 될 것이라고 생각했습니다. Gitea는 이미 환상적이고 매우 유용하며 고성능 도구입니다. 직접 사용하지 않는 것은 정말 부끄러운 일입니다. ;-)

하드 크기 제한에 의존하기보다는 자체 호스팅 서버가 어떻게 관리될 것인지, 누가 나쁜 행동을 단속할 것인지, 그리고 그들이 원하는 도구에 대해 생각하는 것이 도움이 될 수 있습니다. 예를 들어, gitea 프로젝트의 기고자 포크는 gitea 자체 서버에서 지원되어야 합니다. 이것은 사용자가 gitea를 포크한 다음 warez를 포크로 푸시할 위험을 노출시킵니다. 크기 제한은 큰 바이너리를 푸시하는 것을 방지하는 데 도움이 될 수 있지만 암호 또는 신용 카드 번호 목록에는 도움이 되지 않을 수 있습니다. 이 경우에 도움이 될 수 있는 도구는 diff 행 수 또는 롤링 해시로 외계인 파일을 감지하는 것입니다.

diff-size 도구를 사용할 수 있는 좋은 부작용은 푸시 중에 코드를 실행하여 어쨌든 더 작은 조각으로 쪼개졌어야 하는 합법적인 커밋에 플래그를 지정하는 옵션으로 사용할 수 있다는 것입니다. (이를 수행하는 방법에 대한 관련 토론: https://github.com/go-gitea/gitea/issues/3658#issuecomment-372263759.)

공개 서버에 대해 해결해야 할 다른 미묘한 것들이 많이 있을 것입니다. 이러한 사항을 추적하기 위해 별도의 "공개 호스팅" 마스터 문제 또는 이정표를 사용하는 것이 합리적일 수 있습니다.

이정표에 대해 말하자면 이 문제를 1.5.0에 추가해야 합니까?

@stevegt 아니요, 모든 PR이 1.5.0에서 병합/해결되지 않을 것이라고 생각하기 때문입니다.

문제에서 Repository Size Limits (#3658) 를 제거했는데 이는 Gitea에서 호스팅하는 gitea에 영향을 미치지 않기 때문입니다.

리포지토리 크기 제한(#3658)이 문제에서 제거된 이유는 Gitea에서 호스팅하는 gitea에 영향을 미치지 않기 때문입니다.

엄청난! Gitea가 더 빨리 자체적으로 호스팅할수록 전체 프로젝트가 실제 경험에서 더 빨리 이익을 얻고 신뢰와 확신을 얻을 수 있다고 확신합니다. :)

@lafriks 는 다른 스레드에서 다음과

자체 호스팅은 추가 가상 머신 비용을 지불하기 위해 추가 자금/후원을 요구할 수 있습니다.

그리고 @lunny 는 위에서 묻습니다.

@bkcsoft 누구를 위한 공익사업이라는

이러한 생각을 "사람들이 개인 저장소에 비용을 지불하는 온라인 Gitea 서비스를 설정하는 것은 어떻습니까?"로 결합하는 것이 가능할까요?

제대로 완료

개념적으로는 꽤 잘 다녀온 땅인 것 같다. :웃다:

@justinclift 아이디어에 즉시 추가하려면; Microsoft가 GitHub를 인수한다는 현재 뉴스와 타이밍이 맞을 수 있습니다.

@lafriks 는 다른 스레드에서 다음과

자체 호스팅은 추가 가상 머신 비용을 지불하기 위해 추가 자금/후원을 요구할 수 있습니다.

저는 커뮤니티에서 자금 지원이나 조직의 후원을 받아 gitea 호스팅 자체를 가능하게 할 것이라고 확신합니다. Gitea는 리소스 친화적이기 때문에(예, GitLab, 저는 당신을 보고 있습니다) 이것은 큰 문제가 되지 않을 것입니다.

@mxmehl 은 지난달 opencollective가 열린 이후 지금까지 5명의 개인이 기여했습니다: https://opencollective.com/gitea

@justinclift Gitea는 순전히 주도적인 커뮤니티이므로 회사를 만들고 세금을 처리하고 기술 문제를 처리할 정규 직원이 있어야 하므로 유료 개인 리포지토리를 설정할 수 있는 방법이 없습니다.

@mxmehl 은 지난달 opencollective가 열린 이후 지금까지 5명의 개인이 기여했습니다: https://opencollective.com/gitea

@techknowlogick 이 페이지를 몰랐습니다. 이제 6입니다;;

@lafriks 음.... 주변 에 커뮤니티 프로젝트가

그렇긴 하지만, 그것이 일어나게 하고 그것을 계속하기 위해서는 어느 정도의 의지가 필요합니다. 필요한 역할에 있는 사람들은 또한 좋은 관리인(신뢰할 수 있고, 신뢰할 수 있고, 실마리가 있음)이 필요합니다.

관심이 없으면 아무데도 가지 않습니다. 적절한 "관리인" 유형에 동의할 수 없는 경우에도 마찬가지입니다.

위에서 언급한 Open Collective 링크에서 일부 초기 시드가 제자리에 있는 것처럼 보입니다. 주변에 관리인으로 괜찮은 사람이 있다는 것을 보여줍니다. :웃다:

@justinclift 불가능하다는 말은 아니지만 현재 단계에서는 아니지만 미래에는 일어날 수 있습니다. 현재로서는 적어도 새로운 Gitea 기능을 개발하고 문서를 개선하는 데 더 집중할 것입니다. :) 따라서 이 목표를 더 빨리 달성할 수 있도록 도움을 주시면 감사하겠습니다.

허허허허

@lafriks 전혀 걱정하지 마세요. :웃다:

첫 번째 목표는 github가 Microsoft와 결혼한 이후로 Gitea가 Gitea를 호스팅하는 것입니다. :)

이 문제를 종료하기 전에 #2519 및 #3748만 검토하고 병합해야 한다고 생각합니다.

@bkcsoft

서버에 무제한 저장 공간이 없기 때문에 "저장소 크기 제한"을 추가했습니다...

제한에 대한 나의 제안:

• 0 조직
• 3 레포
• 1GB/리포지토리

repos 수량 제한을 사용하여 Gitea 팀에 속하지 않은 모든 사용자에 대해 기존 리포지토리만 포크하도록 설정을 추가할 수 있다고 생각합니다.

• 0 조직
• 3개의 리포지토리(포크만 허용)
• 1GB/리포지토리

나는 포크 수를 제한할 필요가 없다고 생각합니다. 어쨌든 gitea org 저장소 수에 의해 제한될 것이므로 괜찮을 것입니다.
repo 크기에 관해서는, 예, 아마도 약간의 제한이 있어야 합니다.

조직 생성, 저장소 생성을 제한해야 하므로 저장소 크기 제한은 Gitea에서 호스팅하는 Gitea에 필요한 문제가 아닙니다.

자체 호스팅을 위한 사전 요구 사항 목록에 #3134 및 #4302(PR 및 이슈 백링크)를 추가하는 것을 고려할 수 있습니다. -- 아마도 저는 고유한 사람일 수 있지만, 우리가 다음 이상을 추가하자마자 백링크 없이 우리 자신의 작은 gitea 설치가 다루기 어려워지기 시작했습니다. 일부 사용자 및 문제. 문제 검색을 통해 일부 문제를 해결할 수 있었지만 글로벌 문제 검색 없이는 제한적입니다(#2434/#3841).

@stevegt 백링크가 있으면 좋겠지만 자체 호스팅으로 이동하는 것을 차단하지는 않습니다. :)

@bkcsoft 충분히 공정합니다. 실현 가능성을 촉발할 경우에 대비하여 언급할 것이라고 생각했습니다. 우리 지역의 경우 해결 방법으로 문제 의견에 백링크를 수동으로 추가하는 습관을 개발했습니다.

최근에 https://teahub.io 의 노력에 대해 들었습니다

@jlelse 아니요. Gitea는 github, gitlab 또는 Teahub 등에 미러링하고 gitea를 호스팅하기 위해 독립형 서버(예: self.gitea.io)를 설정합니다.

@lunny 현재 GitHub에서 PR에 대한 주석만 사용하고 있기 때문에 커밋에 대한 주석이 정말로 필요한가요?

@JonasFranzDEV 내 말은 PR 커밋에 대한 댓글이 필요하다고 생각합니다.

# 4108이 닫혀 있기 때문에 여기에 댓글을 남깁니다. Gitea Patreon(또는 Patreon과 유사한 대안)이 올라오면 그것에 대해 알아야 합니다. 기여하겠습니다. 이 프로젝트가 자체 호스팅되고 더 발전되는 것을 보고 싶습니다. 모든 리포지토리를 옮기면 더 이상 Github에 돈을 쓰지 않을 것이며, 매월 Patreon에 이를 커밋할 것입니다.

@ryanburnette https://opencollective.com/gitea

@lunny 는 주제 시작에서 '승인 시스템'에

@mjmlvp 네

이것에 대한 소식이 있습니까?

예, 여전히 승인 제한을 추가해야 하며 그런 다음 자체 호스팅 코드로 마이그레이션할 수 있습니다.

이에 대한 미해결 문제를 목록에 추가하는 것이 좋습니다. 현재 연결된 모든 문제와 PR이 닫히고 병합된 것 같습니다.

@skddc 완료.

기록을 위해

오픈 기테아 서버

• https://try.gitea.io/
• https://teahub.io/
• https://dev.sum7.eu/

아무도 믿지 마세요. 정기적인 백업을 하십시오

@giteauser 나는 그것이 어떻게 관련이 있는지 보지 못했습니다.

@giteauser 그리고 이것은 자체 호스팅 gitea 개발에 관한 것이므로 더 이상 github에서 gitea 개발이 발생하지 않아도 됩니다. 나는 이것이 어떻게 관련이 있는지 여전히 알지 못합니다.

아 문제를 잘못 올렸네요 죄송합니다.

따라서 필요한 모든 기능을 지금 구현해야 합니다. 새 릴리스를 갖고 이전할 수 있습니까?

네, gitea 개발을 호스트하기 위해 gitea 인스턴스를 설정할 것입니다.

백업 덤프 문제를 수정하고 적절한 복원 기능을 추가 하는 것도 자체 호스팅 gitea의 인프라 관리에 중요한 부분이라고 생각합니다.

Kubernetes에 Gitea를 배포하는 경우 백업 및 복원에 Ark 를 추천할 수 있습니다.

일반적으로 백업은 플랫폼, 배포 방법, 기존 도구 등의 선택에 따라 모든 사람이 일반적으로 다른 백업 전략/프로그램을 가지고 있기 때문에 자체 호스팅 Gitea 개발을 위한 차단 주제가 되어서는 안 될 것 같습니다. 바로 그 인스턴스의 프로덕션 준비에 대한 차단 문제여야 합니다.

@max-wittig gitea 자체 호스팅 웹사이트는 일부 공용 클라우드 제공업체에서 실행됩니다. 백업 덤프 명령이 종속성 문제가 되지 않도록 RDS 서비스 및 데이터베이스 백업 도구 및 일부 디스크 백업 기능을 제공합니다. dump 명령은 단일 노드 gitea 서비스용입니다. 물론 우리는 그 문제를 해결해야 합니다.

@skddc 우리가 고려할 수 있는 흥미로운 도구입니다.

1.8.0 릴리스가 gitea가 자체 호스팅되는 버전이 되기를 진심으로 바랍니다. 개인적으로 내 자신의 프로젝트에 사용하고 싶지만 개발자(여러분)가 gitea 개발에도 사용하지 않는다면 충분히 신뢰할 수 없다는 단순한 이유 때문에 gitea를 미러로 사용하고 있습니다. 또한, 제 작업 환경에서 gitea를 사용하는 것을 제안하고 싶지만 "오 btw, 멋있어 보이지만 gitea 개발자는 사용하지 않습니다. 자신의 프로젝트를 위해" ...

이것은 비판이나 여러분을 밀어붙이기 위한 것이 아닙니다. gitea를 주요 소스 코드 제어 시스템으로 사용하는 것과 관련하여 내가(그리고 아마도 많은 다른 사람들)이 문제를 발견할 수 있는 것을 알려주기만 하면 됩니다. ;)

마지막으로, 조금 더 건설적입니다. 백업을 위한 아주 좋은(저렴한) clous vps를 찾고 있거나 심지어 gitea를 호스팅하려면 hetzner https://www.hetzner.com/storage/storage-box를 살펴보십시오. 완전히 다른 두 위치(예: hetzner 및 digitalocean)에 백업하고 싶을 것입니다.

@markg85 https://gitea.com에서 작업 중입니다.

gitea.com에서 gitea 호스팅 gitea에 대한 업데이트가 있습니까?

@zachdoty 아직 작업 중입니다.

github에서 gitea로 이동하는 데 필요한 것을 잊었습니다. 모든 데이터(git 데이터, 문제, 주석, github에서 gitea로의 pull 요청 포함)를 이동해야 하지만 실제로 그렇게 하는 데 적합한 도구를 찾지 못했습니다. 프론트엔드에서 백엔드로 리포지토리를 마이그레이션하는 방법에 대한 PR을 보냈습니다(#6200 참조). 또한 gitea의 API가 인덱스 번호를 지정하는 문제 생성을 허용하지 않기 때문에 https://gitea.com/gitea/migrator 를 gitea에 병합해야 합니다.

gitea-github-migrator 는 아직 찾지 못한 경우에 대비하여 거의 모든 것을 마이그레이션할 수 있습니다. 누락된 것이 있으면 추가할 수 있으므로 다른 프로젝트에서도 마이그레이션을 위한 좋은 도구를 사용할 수 있습니다.

@skddc 그들은 실제로 동일합니다.

아, 죄송합니다. 링크를 따라가지 않았습니다.

@kolaente가 말했듯이 우리는 @jonasfranz move gitea-github-migrator를 gitea.com으로 초대했고 저는 이를 개선하기 위해 https://gitea.com/gitea/migrator/pulls/1 PR을 보냅니다. 그러나 타사 도구로 발견한 한 가지 단점이 있습니다. 이슈 인덱스를 예전처럼 유지하기 어렵다는 점이다. (문제에 대한 모든 링크를 계속 사용할 수 있게 하려면.) 따라서 마이그레이션 UI에서 마이그레이션 도구를 gitea로 병합하는 것이 더 나은 아이디어라고 생각합니다.

주석 등의 내부 링크가 보존될 수 있다면 확실히 굉장할 것입니다. 동일한 리포지토리에서 가져온 PR을 문제 대신 실제 PR로 가져올 수 있다면 정말 좋을 것입니다!

이슈 콘텐츠에 새 작업 Migrate a throughout github repository to gitea 을 추가하고 이것을 1.9.0으로 이동하여 v1.8의 릴리스를 차단하지 않도록 합니다. 그러나 gitea.com이 마스터를 따를 것이기 때문에 v1.9가 릴리스될 때까지 기다려야 한다고 생각하지 않습니다.

거기에 코드를 저장하고 손실되는 것에 대해 걱정해야 하는 것처럼 Gitea.com 프로덕션이 준비되어 있습니까?

@BNolet 리포지토리를 저장하기 위해 6개의 머신 ceph 클러스터를 설정했습니다. 따라서 모든 데이터가 3번 복사되므로 쉽게 잃어버리지 않아야 합니다. 우리는 ceph 미러를 통해 다른 백업을 설정하기 위해 노력하고 있습니다. 그리고 git이 배포되기 때문에. 귀하의 코드는 항상 귀하 또는 귀하의 동료 디스크에 저장됩니다.

와~ 환상적이네요! GitHub 또는 Gitlab에 대한 완전한 대안이 될 수 있을 것으로 예상하십니까?

나는 그렇게 생각하지 않는다. gitea.com의 주요 목표는 gitea의 개발 자체를 호스팅하는 것입니다. gitea.com에 제한을 두지는 않았지만 호스팅된 Gitea 인스턴스는 너무 쉽기 때문에 직접 설정하는 것이 좋습니다.

OpenID 로그인을 활성화하지 않는 이유가 있습니까?

@lunny 하나 가지고 있고 좋아합니다 :D

CI/CD가 Gitea 제품의 일부가 될 가능성은 얼마나 됩니까?

@strk 그냥 잊어버려. OpenID 로그인을 활성화합니다.
@BNolet Gitea 자체는 기본 CI/CD로 드론을 사용합니다.

Github에서 go-gitea 앱에 대한 권한 요청을 한 후 로그인 페이지에서 Github oauth 옵션을 사용하려고 하면 500 오류가 발생합니다.

플래그십 인스턴스를 확인하려면 조금 기다려야 하나요?

@jakimfett 그것은 알려진 문제입니다. 두 번 시도할 수 있으며 괜찮습니다.

@strk 그냥 잊어버려. OpenID 로그인을 활성화합니다.

@lunny 는 오늘 아직 꺼져 있는데 계속 끄는 배포 스크립트가 있습니까?

@jakimfett 알려진 문제입니다...

문제 번호로 수정 사항을 입력하면 거기에서 후속 조치를 취하겠습니다.

_편집: 서식_

Codeberg 는 무료 Gitea 기반 서비스입니다. 아마도 Gitea는 거기에 공식 미러를 설정할 수 있습니다. 현재 https://codeberg.org/Codeberg/gitea에 미러링되어

Gitea는 https://gitea.com/gitea/gitea 에서 호스팅되며 대부분의 다른 패키지를 https://gitea.com/gitea 로 이동했으며 gitea 자체는 진행 중입니다. 미러는 다른 기테아 기반 서비스에서 환영합니다.

@lunny가 어제 댓글을
미러는 다른 기테아 기반 서비스에서 환영합니다.

주말에서 돌아오면 최신 거울을 함께 해킹할 것입니다.

관련된:
어딘가에 거울 목록이 있고, 거기에 나를 추가하거나...?

@jakimfett 없지만 새 문서 페이지로 홍보를 만들 수 있습니다.

github에서 github를 마이그레이션할 때 더 나은 사용자 핸들러를 위해 이것을 v1.10으로 옮기고 싶습니다. 마이그레이션을 시작하기 전에 https://github.com/go-gitea/gitea/issues/7293 을 구현해야 한다고 생각합니다.

중국에서 호스팅되지 않았거나 활성화 이메일이 도착하는 데 10분이 걸렸다면 저는 전적으로 찬성할 것입니다.

중국에서 호스팅되지 않았거나 활성화 이메일이 도착하는 데 10분이 걸렸다면 저는 전적으로 찬성할 것입니다.

편집: 분명히, 나는 틀렸다.

일부 인터넷 검색에서 분명히 gitea.com의 IP 주소는 실제로 중국이 아닌 일본에 있습니다. 그 IP 주소는 Alibaba의 소유입니다.

mailgun.org 를 사용하여 메일을 보냅니다. 왜 10분이 걸리는지 모르겠습니다.

우리의 기부 클라우드 공급자는 중국에 있는 didiyun이며 많은 기계를 제공합니다. 현재로서는 다른 선택이 없습니다.

그리고 gitea.com의 첫 번째 목적은 github.com이나 gitlab.com과 같은 서비스가 되지 않을 것입니다. gitea 자체만 호스팅하므로 실제로 gitea 인스턴스를 직접 설정하는 것이 좋습니다.

@programmerjake 브리지 서버입니다.

내 인스턴스에서 전환할 의도는 없었지만 이 프로젝트가 과거에 평판이 거의 없거나 검색 결과가 없는 중국 회사에서 기부한 인프라에 의존하는 것이 마음에 들지 않습니다. 그들이 미래에 무엇을 하는지 또는 XY를 구현하지 않거나 ZA를 수행하지 않거나 언젠가는 그냥 가버리면 기부금 삭감을 요구하는지 실제로 알지 못합니다.
당신은 아마도 당신이 무엇을 하는지 알고 있을 것이고 내 걱정은 단지 조심스러울 뿐이지만 당신은 결코 알지 못할 것입니다.

왜 중국 회사는 그렇게 하고 미국 회사는 하지 않을 것입니까? :)

그리고 나는 중국인이고 아마도 조심해야 할 것입니다. 언젠가는 내가 당신의 코드를 훔칠 수 있습니다. :)

2014년에 다른 3명의 중국인과 Gogs를 시작할 때 그런 계획이 있었던 것 같아요.

내 인스턴스에서 전환할 의도는 없었지만 이 프로젝트가 중국 회사에서 기부한 인프라에 의존하는 것이 마음에 들지 않습니다. 그들이 미래에 무엇을 하는지 또는 XY를 구현하지 않거나 ZA를 수행하지 않거나 언젠가는 그냥 가버리면 기부금 삭감을 요구하는지 실제로 알지 못합니다.
당신은 아마도 당신이 무엇을 하는지 알고 있을 것이고 내 걱정은 단지 조심스러울 뿐이지만 당신은 결코 알지 못할 것입니다.

완전 바보같은 답변입니다.
이제 나는 네덜란드 사람으로서 더 열린 마음을 가질 수 있습니다. 우리는 그것을 포용합니다. 당신도 그것을 시도해야합니다.

이 프로젝트가 오픈 소스인 한, 제 생각에는 당신이 말한 어떤 것에도 위험이 없습니다.
그리고 아마도 Gitea를 분기하는 것을 의미하는 경우에도 라이선스가 허용하는 대로 완전히 권리가 있습니다.

그러나 미국은... Github이 현재 미국과 중국 간의 "무역 전쟁"으로 인해 기능이 제한되었음을 상기시켜 드리겠습니다. 어쨌든 미국은 중국보다 현재 자유 소프트웨어 개발의 위험이 더 큽니다. 젠장 , 미쳤을 것입니다.

@lunny 와

그리고 gitea.com의 첫 번째 목적은 github.com이나 gitlab.com과 같은 서비스가 되지 않을 것입니다. gitea 자체만 호스팅하므로 실제로 gitea 인스턴스를 직접 설정하는 것이 좋습니다.

그것은 당신이 미래에 고려할 수 있는 것입니까?

이 프로젝트가 오픈 소스인 한, 제 생각에는 당신이 말한 어떤 것에도 위험이 없습니다.

핵심 프로젝트에는 위험이 없지만 인프라에는 위험이 있습니다. 알려지지 않은 평판이 좋지 않은 기증자가 어디에서 왔는지 또는 중국에서 왔는지에 관계없이 다음 달에 거기에 올 것이라는 보장은 없습니다. GitHub는 오랫동안 여기에 있을 것이며 그렇게 빨리 가지 않을 것입니다.

또한 전체 인프라가 중국으로 이전되면 미국과 중국 간의 어려움으로 인해 전체 사용자 기반이 어려움을 겪을 것입니다.

@lunny ~10분이 소요되는 전자 메일과 관련하여 제 경우에는 회사 서버에 "쿨 오프" 타이머(여기서는 20분)인 스팸 방지 조치가 있어 알 수 없는 출처의 메일을 일시적으로 거부합니다. 따라서 사용자(나)가 해당 도메인(예: gitea.com)에서 이메일을 처음 수신하는 경우 내 서버는 "나중에 시도"로 응답하고 해당 사용자/도메인 조합을 기억합니다. 다음에 gitea.com이 예상 시간 내에 내 메일을 배달하려고 시도하면 서버가 메시지를 수락합니다.
분명히 GMail, Hotmail 등과 같이 휴지 기간이 필요하지 않은 "신뢰할 수 있는 출처"가 구성되어 있습니다.

여러분, 모든 지역에 더 많은 인프라가 확산되기를 원한다면 https://opencollective.com/gitea 에서 지갑으로 투표

@SuperSandro2000 Gitea는 서비스가 아니라 _제품_이라는 사실, 알고 계셨나요? 소스를 다운로드하고 서버에서 Gitea를 컴파일하고 설치합니다. Gitea의 호스팅에는 연결이 필요하지 않습니다.

XY를 구현하지 않거나 ZA를 수행하지 않거나 언젠가는 그냥 가버리면 그들이 기부금 삭감을 요구한다면.

알려지지 않은 평판이 좋지 않은 기증자가 다음 달에 그곳에 올 것이라는 보장은 없습니다.

이에 대한 몇 가지 응답: 우리는 평판이 좋지 않은 회사에서 호스팅하지 않을 것이며 Gitea 리드는 이 회사를 신뢰했습니다. 그들이 후원 제공을 중단하거나 회사가 되는 것을 중단하면 우리는 선택할 수 있는 옵션이 있으며 다른 곳으로 이동할 수 있습니다.

전체 사용자 기반은 미국과 중국 간의 어려움으로 인해 어려움을 겪을 것입니다.

Gitea 팀의 상당 부분은 중국 출신이며(그러나 다른 모든 대륙에도 유지 관리자가 있음) 개발 팀이 코드에 액세스할 수 없으면 사용자 기반이 어려움을 겪을 수 있으므로 액세스할 수 있는 개발 팀이 필요합니다. 암호. 우리는 GitHub에서 금지된 사용자를 포함한 모든 사람이 사용할 수 있도록 Gitea를 구축합니다(최근 GitHub의 금지 물결 이후 많은 사용자가 Gitea를 사용하기 시작했습니다).

다른 사람들이 언급했듯이 전 세계의 다른 인스턴스에 코드베이스의 미러가 있으며 git 덕분에 코드에 대한 모든 변경 사항의 원장이 있으므로 모든 사람이 모든 변경 사항을 볼 수 있습니다.

투명성에 대한 참고 사항: 이 스레드를 잠갔습니다. 이 대화를 중단하고 싶지는 않지만 이 github 티켓은 (우리가 호스팅하는 곳이 아닌) 자체 호스팅을 위해 소프트웨어에서 수행해야 하는 개선 사항에 대한 것이기 때문에 다른 장소로 옮겨야 합니다.