Gitea: Gitea menjamu Gitea

Ide yang sangat bagus!

1.2 di bulan Februari, 1.3 di bulan April, 1.4 di bulan Juni, 1.5 di bulan Agustus? seharusnya cukup waktu untuk mengimplementasikan semua itu

Jika Anda belum melihatnya, komentar fantastis dan berwawasan luas yang mendukung pendekatan Anda terhadap hosting mandiri hanya jika sudah siap: https://lobste.rs/s/gokjbo/gitea_1_1_0_released/comments/dg9pwe#c_dg9pwe

@lunny Sekarang saya memikirkannya (terima kasih @zellyn untuk tautan itu 😂 ) Mengapa kita membutuhkan penyedia oauth, dukungan _complete_ webhook, dokumentasi api, dan _complete_ API untuk hosting sendiri?

OAuth _Consumer_ diperlukan (ini menggabungkan AFAIK) sehingga orang dapat masuk menggunakan github auth.
Drone hanya menggunakan kait dorong, jadi mengapa kita membutuhkan yang lain?

Adapun API, tidak yakin mengapa hosting mandiri mengharuskan itu sama sekali TBH :)

Saya setuju tentang pemangkasan daftar itu. Hosting mandiri sebelumnya kemungkinan besar akan membantu kami menetapkan prioritas dengan lebih baik :)

@bkcsoft mungkin kita bisa mengatur situs yang dihosting dan mencoba.

@bkcsoft Saya memperbarui masalah, maksud Anda?

-> Penyedia OAuth (#27) tidak ditutup

@ekozan tidak ditutup, tetapi tergores dari daftar "hal-hal yang kita butuhkan"

Menambahkan "Batas Ukuran Repositori" karena kami tidak memiliki penyimpanan tak terbatas di server...

Proposal saya untuk batasan:

• 0 Org
• 3 Repo
• 1GB/repo

@bkcsoft Apakah maksud Anda ini akan menjadi layanan publik bagi siapa saja?

Mungkin, mungkin tidak, tetapi _jika_ itu menjadi layanan publik, kami tidak dapat memilikinya tanpa batas;)

Saya pikir dogfooding cukup penting sehingga batas ukuran repo mungkin tidak perlu berada di jalur kritis untuk gitea hosting sendiri. Dalam beberapa hari pertama setelah bermigrasi ke gitea, saya mengalami beberapa penghilangan fitur yang membuat saya berpikir hosting mandiri akan membantu memfokuskan upaya untuk menyelesaikan hal-hal tersebut. Gitea sudah menjadi alat yang fantastis, sangat berguna, dan berkinerja tinggi -- sayang sekali Anda tidak menggunakannya sendiri. ;-)

Daripada bergantung pada batasan ukuran yang keras, mungkin akan lebih membantu untuk memikirkan bagaimana server yang dihosting sendiri akan dikelola, siapa yang akan mengawasi perilaku buruk, dan alat apa yang mereka inginkan. Misalnya, garpu kontributor proyek gitea harus didukung di server gitea sendiri. Ini memperlihatkan risiko bahwa pengguna melakukan fork gitea, kemudian mendorong warez ke fork mereka. Batas ukuran mungkin membantu mencegah mendorong binari besar, tetapi mungkin tidak membantu dengan daftar kata sandi atau nomor kartu kredit. Alat yang mungkin membantu dalam kasus itu adalah sesuatu yang mendeteksi file asing dengan jumlah baris yang berbeda atau hash bergulir.

Efek samping yang bagus dari memiliki alat ukuran berbeda yang tersedia adalah bahwa kode dapat tersedia sebagai opsi untuk dijalankan selama push untuk menandai komit yang sah yang seharusnya dipecah menjadi bagian yang lebih kecil. (Diskusi terkait untuk cara melakukan ini: https://github.com/go-gitea/gitea/issues/3658#issuecomment-372263759.)

Saya berani bertaruh ada banyak hal halus lainnya yang perlu ditangani untuk server yang menghadap publik. Mungkin masuk akal untuk menggunakan masalah utama atau tonggak sejarah "hosting publik" yang terpisah untuk melacak hal-hal ini.

Berbicara tentang pencapaian, haruskah masalah ini ditambahkan ke 1.5.0?

@stevegt Tidak, karena saya pikir tidak semua PR akan digabungkan / diselesaikan pada 1.5.0.

Saya menghapus Repository Size Limits (#3658) dari masalah karena tidak akan memengaruhi gitea yang dihosting Gitea.

Saya menghapus Batas Ukuran Repositori (#3658) dari masalah karena tidak akan memengaruhi gitea yang dihosting Gitea.

Besar! Saya yakin bahwa semakin cepat Gitea menghosting dirinya sendiri, semakin cepat seluruh proyek mendapat untung dari pengalaman kehidupan nyata, dan mendapatkan kepercayaan dan keyakinan :)

@lafriks menyebutkan di utas lain:

Hosting mandiri mungkin memerlukan dana/sponsor tambahan untuk membayar mesin virtual tambahan

Dan @lunny bertanya di atas:

@bkcsoft Apakah maksud Anda ini akan menjadi layanan publik bagi siapa saja?

Apakah mungkin untuk menggabungkan pemikiran itu menjadi "Bagaimana dengan menyiapkan layanan Gitea online, di mana orang membayar (katakanlah) repo pribadi?".

Jika dilakukan ok, itu akan menghasilkan dana untuk membayar sendiri + repo publik.

Sebagai sebuah konsep, tampaknya ini adalah tempat yang cukup baik untuk dilalui. :senyum:

Untuk segera menambah ide @justinclift ; waktunya mungkin tepat dengan berita terbaru tentang Microsoft yang mengambil alih GitHub.

@lafriks menyebutkan di utas lain:

Hosting mandiri mungkin memerlukan dana/sponsor tambahan untuk membayar mesin virtual tambahan

Saya yakin akan ada pendanaan dari komunitas atau sponsor dari organisasi untuk membuat hosting gitea itu sendiri mungkin. Karena Gitea ramah sumber daya (ya, GitLab, saya melihat Anda) ini tidak akan menjadi masalah besar.

@mxmehl sejauh ini sudah ada 5 individu yang berkontribusi sejak opencollective dibuka bulan lalu: https://opencollective.com/gitea

@justinclift karena Gitea adalah murni komunitas untuk didorong, tidak mungkin kami dapat mengatur repositori pribadi berbayar karena itu memerlukan pembuatan perusahaan, berurusan dengan pajak, dan memiliki staf penuh waktu untuk menangani masalah teknis

@mxmehl sejauh ini sudah ada 5 individu yang berkontribusi sejak opencollective dibuka bulan lalu: https://opencollective.com/gitea

@techknowlogick Tidak tahu halaman ini. Sekarang jam 6 ;)

@lafriks Nah .... ada proyek Community sekitar - untuk kedua perangkat lunak dan non-software hal - yang tampaknya untuk mengelola sendiri ok, termasuk masalah keuangan, hal-hal yang mereka bayar, staf (jika diperlukan), dan sebagainya.

Dikatakan demikian, itu memang membutuhkan tingkat kemauan untuk mewujudkannya + mempertahankannya. Orang-orang dalam peran apa pun yang dibutuhkan juga perlu menjadi penjaga yang baik (dapat dipercaya, dapat diandalkan, penuh petunjuk).

Jika tidak ada minat, maka bagaimanapun juga tidak akan kemana-mana. Ditto jika tidak ada tipe "penjaga" yang cocok yang dapat disepakati.

Dari tautan Open Collective yang disebutkan di atas, sepertinya ada beberapa seed awal. Ini menunjukkan ada orang-orang di sekitar yang dianggap baik-baik saja sebagai penjaga. :senyum:

@justinclift Saya tidak mengatakan itu tidak mungkin tetapi tidak pada tahap saat ini tetapi di masa depan itu bisa terjadi. Saat ini setidaknya saya akan lebih fokus pada pengembangan fitur Gitea baru dan meningkatkan dokumentasi :) Jadi bantuan apa pun sangat dihargai untuk bergerak lebih cepat ke tujuan ini.

Hehehe

Jangan khawatir sama sekali @lafriks. :senyum:

Tujuan pertama adalah Gitea menjadi tuan rumah Gitea sejak github menikah dengan Microsoft. :)

Saya pikir hanya #2519 dan #3748 yang perlu ditinjau dan digabungkan sebelum kami menutup masalah ini.

@bkcsoft

Menambahkan "Batas Ukuran Repositori" karena kami tidak memiliki penyimpanan tak terbatas di server...

Proposal saya untuk batasan:

• 0 Org
• 3 Repo
• 1GB/repo

Saya pikir, dengan batas kuantitas repo, kami dapat menambahkan pengaturan yang memungkinkan untuk fork saja repositori yang ada untuk semua pengguna yang tidak ada di tim Gitea:

• 0 Org
• 3 Repos (izinkan hanya garpu)
• 1GB/repo

Saya tidak berpikir jumlah garpu perlu dibatasi, itu akan dibatasi oleh jumlah repositori gitea org, jadi itu tidak masalah.
Untuk ukuran repo, ya, mungkin harus ada batasan

Kita harus membatasi pembuatan org, membuat repo, jadi batas ukuran repo bukanlah masalah yang diperlukan untuk Gitea yang dihosting Gitea.

Kami mungkin mempertimbangkan untuk menambahkan #3134 dan #4302 (PR dan mengeluarkan tautan balik) ke daftar prareq untuk hosting mandiri -- mungkin saya unik, tetapi pemasangan gitea kecil kami mulai menjadi berat tanpa tautan balik tersebut segera setelah kami menambahkan lebih dari beberapa pengguna dan masalah. Kami telah dapat mengatasinya beberapa dengan pencarian masalah, tapi itu terbatas tanpa pencarian masalah global (#2434/#3841).

@stevegt Sementara backlink akan menyenangkan untuk dimiliki, saya tidak melihat mereka memblokir pindah ke hosting sendiri :)

@bkcsoft Cukup adil -- kupikir aku akan menyebutkannya kalau-kalau itu memicu realisasi apa pun. Dalam kasus lokal kami, kami telah mengembangkan kebiasaan menambahkan tautan balik secara manual dalam komentar masalah sebagai solusi.

Saya baru-baru ini mendengar tentang upaya https://teahub.io. Mereka ingin memulai organisasi nirlaba. Tidak bisakah Gitea menggunakannya setelah mereka siap dengan pengaturan?

@jlelse No. Gitea akan menyiapkan server mandiri (yaitu self.gitea.io) untuk meng-host gitea dan mirror ke github, gitlab atau teahub dan lain-lain.

@lunny Apakah kami benar-benar memerlukan komentar pada komit karena saat ini kami hanya menggunakan komentar pada PR di GitHub?

@JonasFranzDEV maksud saya komentar tentang komitmen PR, saya pikir itu perlu.

Saya berkomentar di sini karena #4108 ditutup. Ketika Gitea Patreon (atau alternatif seperti Patreon) naik, saya perlu mengetahuinya. Saya akan berkontribusi. Saya ingin melihat proyek ini dihosting sendiri dan dikembangkan lebih lanjut. Setelah saya memindahkan semua repositori saya, saya tidak akan menghabiskan uang dengan Github lagi, saya akan melakukan itu setiap bulan ke Patreon.

@ryanburnette https://opencollective.com/gitea

@lunny sepertinya 'Sistem persetujuan' di topik mulai dapat dicoret. (Masalahnya masing-masing ditutup dan digabungkan)?

@mjmlvp Saya pikir Anda benar. Saya menghapus #996 #2519 karena seharusnya tidak menjadi blok masalah ini. Kami akan menyiapkan server untuk menampung perkembangan kami.

Ada berita tentang ini?

Ya, kami masih perlu menambahkan batasan persetujuan dan kemudian kami dapat bermigrasi ke kode yang dihosting sendiri

Akan menyenangkan untuk menambahkan masalah terbuka untuk itu ke daftar. Saat ini sepertinya semua masalah terkait dan PR telah ditutup dan digabungkan.

@skddc selesai.

untuk catatan

buka server gitea

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

tidak percaya siapapun. buat cadangan reguler

@giteauser Saya gagal melihat bagaimana itu relevan

@giteauser dan ini tentang pengembangan gitea yang di-hosting sendiri, sehingga pengembangan gitea tidak harus terjadi lagi di github. Saya masih gagal untuk melihat bagaimana ini relevan.

Oh saya memposting ini untuk masalah yang salah, saya minta maaf.

Jadi, setiap fitur yang dibutuhkan harus diimplementasikan sekarang. Bisakah kita memiliki rilis baru dan bermigrasi?

Benar, kami akan menyiapkan instance gitea untuk meng-host pengembangan gitea.

Saya pikir memperbaiki masalah dump cadangan dan menambahkan fungsionalitas pemulihan yang tepat juga merupakan bagian penting untuk mengelola infrastruktur gitea yang dihosting sendiri

Jika Anda menerapkan Gitea di Kubernetes, saya dapat merekomendasikan Ark untuk pencadangan dan pemulihan.

Secara umum, pencadangan sepertinya tidak menjadi topik pemblokiran untuk pengembangan Gitea hosting sendiri, karena setiap orang biasanya memiliki strategi/program pencadangan yang berbeda, tergantung pada pilihan platform, metode penerapan, alat yang ada, dll. seharusnya hanya menjadi masalah pemblokiran untuk kesiapan produksi instance itu sendiri.

@max-wittig Situs web yang dihosting sendiri oleh gitea akan berjalan di beberapa penyedia cloud publik. Mereka akan menyediakan layanan RDS dan alat pencadangan basis data dan beberapa fungsi pencadangan disk sehingga perintah dump cadangan tidak menjadi masalah ketergantungan. Perintah dump adalah untuk layanan gitea node tunggal. Tentu saja kita harus memperbaiki masalah itu.

@skddc Ini adalah alat yang menarik yang dapat kami pertimbangkan.

Saya sangat berharap rilis 1.8.0 akan menjadi versi dimana gitea menjadi self-host. Saya pribadi ingin menggunakannya untuk proyek saya sendiri tetapi saya hanya menggunakan gitea sebagai cermin untuk alasan sederhana bahwa saya tidak cukup percaya jika devs - kalian - bahkan tidak menggunakannya untuk pengembangan gitea. Juga, saya ingin mengusulkan untuk menggunakan gitea di lingkungan kerja saya tetapi bahkan tidak dapat mengusulkannya karena saya hanya akan ditertawakan ketika saya mengatakan: "oh btw, itu terlihat luar biasa, tetapi para pengembang gitea tidak menggunakan itu untuk proyek mereka sendiri" ...

Ini tidak dimaksudkan sebagai kritik atau sebagai cara untuk mendorong kalian. Hanya memberi tahu Anda apa yang menurut saya (dan mungkin banyak lainnya) akan merepotkan ketika menggunakan gitea sebagai sistem kontrol kode sumber utama;)

Terakhir, untuk menjadi sedikit lebih konstruktif. Jika Anda mencari vps clous yang sangat bagus (dan murah) untuk cadangan atau bahkan untuk meng-host gitea, lihat hetzner https://www.hetzner.com/storage/storage-box Meskipun untuk infrastruktur penting seperti Gitea Anda mungkin ingin mencadangkannya di dua lokasi yang sama sekali berbeda (misalnya hetzner dan digitalocean).

@ markg85 kami sedang mengerjakan https://gitea.com

Adakah pembaruan tentang gitea yang dihosting gitea di gitea.com?

@zachdoty Masih mengerjakannya.

Saya lupa sesuatu yang diperlukan untuk pindah dari github ke gitea. Kami perlu memindahkan semua data (termasuk data git, masalah, komentar, permintaan tarik dari github ke gitea), tetapi sebenarnya saya belum menemukan alat yang cocok untuk melakukan itu. Saya telah mengirim PR tentang memindahkan repositori yang bermigrasi dari frontend ke backend, lihat #6200 , dan juga https://gitea.com/gitea/migrator harus digabungkan ke gitea karena API gitea tidak akan mengizinkan pembuatan masalah dengan nomor indeks yang ditentukan.

gitea-github-migrator dapat memigrasikan hampir semua hal, jika Anda belum menemukannya. Jika ada yang hilang, mungkin bisa ditambahkan di sana, jadi proyek lain juga memiliki alat yang bagus untuk bermigrasi.

@skddc mereka sebenarnya sama.

Ah maaf. Tidak mengikuti tautan.

Seperti yang dikatakan @kolaente , kami mengundang @jonasfranz memindahkan gitea-github-migrator ke gitea.com dan saya mengirim PR https://gitea.com/gitea/migrator/pulls/1 ingin memperbaikinya. Tapi saya menemukan sebagai alat pihak ketiga, ada satu kelemahan. Artinya sulit untuk menjaga indeks masalah seperti sebelumnya. (Agar semua tautan tentang masalah ini tetap tersedia.) Jadi saya pikir menggabungkan alat migrasi ke gitea di UI migrasi adalah ide yang lebih baik.

Pasti akan luar biasa jika tautan internal di komentar, dll. Dapat dipertahankan. Juga akan luar biasa jika PR yang berasal dari repo yang sama dapat diimpor sebagai PR yang sebenarnya, bukan masalah!

Saya menambahkan tugas baru Migrate a throughout github repository to gitea pada konten masalah dan memindahkan ini ke 1.9.0 sehingga ini tidak akan memblokir rilis v1.8. Tapi saya rasa kita tidak perlu menunggu sampai v1.9 dirilis karena gitea.com akan mengikuti masternya.

Apakah produksi Gitea.com siap, seperti yang harus saya khawatirkan tentang menyimpan kode di sana dan hilang?

@BNolet kami telah menyiapkan 6 mesin ceph cluster untuk menyimpan repositori. Jadi jangan mudah hilang karena semua data akan dicopy sebanyak 3 kali. Kami sedang menyiapkan cadangan lain melalui cermin ceph. Dan karena git didistribusikan. Kode Anda akan selalu disimpan di disk Anda atau rekan kerja Anda.

Wow itu fantastis! Apakah Anda semua mengantisipasi untuk dapat menjadi alternatif lengkap untuk GitHub atau Gitlab?

Saya tidak berpikir begitu. Target utama gitea.com adalah menjadi tuan rumah pengembangan gitea itu sendiri. Meskipun kami tidak melakukan pembatasan apa pun pada gitea.com, tetapi kami mendorong Anda untuk mengatur sendiri instance Gitea yang dihosting karena sangat mudah.

Adakah alasan untuk tidak mengaktifkan masuk OpenID?

@lunny saya punya satu dan saya menyukainya :D

Seberapa besar kemungkinan CI/CD menjadi bagian dari produk Gitea?

@strk lupakan saja. Akan mengaktifkan masuk OpenID.
@BNolet Gitea sendiri akan menggunakan drone sebagai CI/CD utama.

Mendapatkan kesalahan 500 saat mencoba menggunakan opsi oauth Github di halaman login, setelah saya membuka permintaan izin untuk aplikasi go-gitea di Github.

Haruskah saya menunggu sebentar untuk melihat instance unggulan?

@jakimfett itu masalah yang diketahui. Anda dapat mencoba dua kali dan tidak apa-apa.

@strk lupakan saja. Akan mengaktifkan masuk OpenID.

@lunny karena masih mati hari ini, apakah mungkin ada skrip penyebaran yang terus mematikannya?

@jakimfett itu masalah yang diketahui...

Lempar edit dengan nomor masalah dan saya akan menindaklanjuti di sana.

_edit: pemformatan_

Codeberg adalah layanan berbasis Gitea gratis. Mungkin Gitea bisa memasang mirror resmi di sana. Saat ini dicerminkan di https://codeberg.org/Codeberg/gitea.

Gitea akan dihosting di https://gitea.com/gitea/gitea , dan kami telah memindahkan sebagian besar paket lainnya ke https://gitea.com/gitea , dan gitea sendiri sedang dalam proses. Mirror diterima di layanan berbasis gitea lainnya.

@lunny berkomentar kemarin:
Mirror diterima di layanan berbasis gitea lainnya.

Saya akan meretas cermin terbaru setelah saya kembali dari akhir pekan saya.

Terkait:
Apakah ada daftar cermin di suatu tempat, dan apakah saya menambahkan diri saya ke dalamnya, atau...?

@jakimfett Tidak ada, tetapi Anda dapat membuat

Untuk penangan pengguna yang lebih baik saat memigrasi gitea ke github, saya ingin memindahkan ini ke v1.10 dan saya pikir kita harus menerapkan https://github.com/go-gitea/gitea/issues/7293 sebelum kita mulai bermigrasi.

Saya akan benar-benar untuk langkah itu jika tidak di-host di China atau email aktivasi membutuhkan waktu 10 menit untuk tiba.

Saya akan benar-benar untuk langkah itu jika tidak di-host di China atau email aktivasi membutuhkan waktu 10 menit untuk tiba.

Sunting: ternyata, saya salah.

dari beberapa googling, ternyata alamat IP gitea.com sebenarnya di Jepang, bukan China. Alamat IP itu dimiliki oleh Alibaba.

Kami menggunakan mailgun.org untuk mengirim email. Saya tidak tahu mengapa itu akan menghabiskan 10 menit.

Penyedia cloud donasi kami adalah didiyun yang ada di China dan menyediakan banyak mesin. Kami tidak punya pilihan lain saat ini.

Dan tujuan pertama gitea.com tidak akan menjadi sebagai layanan seperti github.com atau gitlab.com. Itu hanya akan meng-host gitea itu sendiri dan kami sarankan Anda mengatur sendiri instance gitea sebenarnya.

@programmerjake Itu adalah server jembatan.

Bukan niat saya untuk beralih dari contoh saya, tetapi saya tidak suka bahwa proyek ini bergantung pada infrastruktur yang disumbangkan dari perusahaan China yang hampir tidak memiliki reputasi di masa lalu atau hasil pencarian. Anda tidak benar-benar tahu apa yang mereka lakukan di masa depan atau jika mereka menuntut untuk memotong donasi mereka jika Anda tidak menerapkan XY atau melakukan ZA atau jika mereka pergi begitu saja suatu hari nanti.
Anda mungkin tahu apa yang Anda lakukan dan kekhawatiran saya hanya untuk berhati-hati tetapi Anda tidak akan pernah tahu.

Mengapa perusahaan China akan melakukan itu tetapi perusahaan AS tidak? :)

Dan saya orang Cina, dan mungkin Anda harus berhati-hati. Suatu hari nanti saya mungkin mencuri kode Anda. :)

Saya pikir saya mungkin memiliki rencana itu ketika saya memulai Gogs dengan 3 orang Tionghoa lainnya pada tahun 2014.

Bukan niat saya untuk beralih dari contoh saya, tetapi saya tidak suka bahwa proyek ini bergantung pada infrastruktur yang disumbangkan dari perusahaan Cina. Anda tidak benar-benar tahu apa yang mereka lakukan di masa depan atau jika mereka menuntut untuk memotong donasi mereka jika Anda tidak menerapkan XY atau melakukan ZA atau jika mereka pergi begitu saja suatu hari nanti.
Anda mungkin tahu apa yang Anda lakukan dan kekhawatiran saya hanya untuk berhati-hati tetapi Anda tidak akan pernah tahu.

Itu jawaban yang benar-benar bodoh.
Sekarang saya mungkin lebih berpikiran terbuka karena saya orang Belanda, kami menerimanya. Anda harus mencobanya juga.

Selama proyek ini open source, menurut saya tidak ada risiko untuk apa pun yang Anda katakan.
Dan bahkan jika mereka melakukannya, yang mungkin berarti forking Gitea, mereka sepenuhnya berhak karena lisensi mengizinkannya.

Namun AS... izinkan saya mengingatkan Anda bahwa Github telah membatasi fitur mereka sekarang karena "perang dagang" antara AS dan China. Jika ada, AS lebih berisiko untuk pengembangan perangkat lunak bebas saat ini daripada China. Heck, @lunny bahkan mungkin terpengaruh pada repositori ini karena perang dagang.

@lunny dan tim yang mengembangkan Gitea. Pertahankan pekerjaan yang luar biasa! :)

Dan tujuan pertama gitea.com tidak akan menjadi sebagai layanan seperti github.com atau gitlab.com. Itu hanya akan meng-host gitea itu sendiri dan kami sarankan Anda mengatur sendiri instance gitea sebenarnya.

Apakah itu sesuatu yang dapat Anda pertimbangkan di masa depan?

Selama proyek ini open source, menurut saya tidak ada risiko untuk apa pun yang Anda katakan.

Proyek inti tidak memiliki risiko tetapi infrastruktur memilikinya. Tidak ada jaminan bahwa pendonor yang tidak dikenal dan tidak bereputasi akan berada di sana bulan depan tidak peduli apakah dia datang dari mana saja atau dari China. GitHub akan berada di sini untuk waktu yang lama dan tidak akan pergi ke mana pun secepat itu.

Juga jika seluruh infrastruktur pindah ke China, seluruh basis pengguna akan menderita karena kesulitan antara AS dan China.

@lunny Mengenai email yang memakan waktu ~ 10 menit, dalam kasus saya, server perusahaan saya memiliki ukuran anti-SPAM yang merupakan pengatur waktu "dingin" (20 menit di sini) yang untuk sementara akan menolak email apa pun dari sumber yang tidak dikenal. Jadi, jika ini pertama kalinya pengguna (saya) menerima email dari domain tersebut (misalnya gitea.com), maka server saya akan merespons dengan "coba nanti" dan mengingat kombinasi pengguna/domain tersebut. Kali berikutnya gitea.com mencoba mengirimkan email saya dalam waktu yang diharapkan, server menerima pesan tersebut.
Jelas kami memiliki beberapa "sumber tepercaya" yang dikonfigurasi, seperti GMail, Hotmail, dll. yang tidak memerlukan periode pendinginan.

Teman-teman, jika Anda ingin lebih banyak infrastruktur tersebar di setiap wilayah, silakan pilih dengan dompet Anda di https://opencollective.com/gitea

@SuperSandro2000 Apakah Anda sadar bahwa Gitea bukan layanan tetapi _produk_? Anda mengunduh sumbernya, mengkompilasi Gitea di server Anda dan menginstalnya. Tidak ada koneksi apa pun yang diperlukan ke hosting Gitea.

jika mereka menuntut untuk memotong donasi mereka jika Anda tidak menerapkan XY atau melakukan ZA atau jika mereka pergi begitu saja suatu hari nanti.

Tidak ada jaminan bahwa pendonor yang tidak dikenal dan tidak bereputasi itu akan berada di sana bulan depan.

Beberapa tanggapan untuk ini: Kami tidak akan menjadi tuan rumah di perusahaan yang tidak bereputasi baik, dan para pemimpin Gitea telah mempercayakan kami pada perusahaan ini. Jika mereka berhenti memberikan sponsor, atau berhenti menjadi perusahaan, kami memiliki opsi yang tersedia untuk kami, dan dapat pindah ke tempat lain.

seluruh basis pengguna akan menderita karena kesulitan antara AS dan China.

Sebagian besar tim Gitea berasal dari China (tetapi kami juga memiliki pengelola di semua benua lain juga), dan jika tim pengembangan tidak dapat mengakses kode maka basis pengguna akan terganggu, itulah sebabnya kami membutuhkan tim pengembangan untuk dapat mengakses kode. Kami membangun Gitea sehingga semua orang dapat menggunakannya, bahkan pengguna yang dilarang dari GitHub (setelah gelombang larangan baru-baru ini dari GitHub, banyak dari pengguna tersebut mulai menggunakan Gitea).

Seperti yang telah disebutkan orang lain, ada cermin dari basis kode pada contoh lain di seluruh dunia, dan berkat git ada buku besar dari semua perubahan yang dibuat pada kode sehingga setiap orang dapat memiliki visibilitas ke semua perubahan.

Catatan tentang transparansi: Saya telah mengunci utas ini. Saya tidak ingin menghentikan percakapan ini, namun itu harus dipindahkan ke tempat lain karena tiket github ini adalah tentang peningkatan apa yang perlu dilakukan dengan perangkat lunak untuk hosting sendiri (daripada tempat kami hosting).