Gitea: Diskusi peta jalan Gitea

Solusi plugin (termasuk tema) untuk memperluas gitea.

Apakah mungkin menambahkan paket OS yang tepat ke proses pembuatan? Saya telah mencoba untuk mengumpulkan sesuatu untuk fedora tetapi tampaknya agak berantakan untuk dikemas. #31 semacam pembicaraan tentang ini tetapi tampaknya masih terbuka.

Kami menggunakan kemungkinan untuk menyebarkan tarball pada sistem Debian, ini tidak terlalu berguna tetapi berhasil. Repositori untuk distro yang paling umum akan menyenangkan, tetapi perlu ditempatkan dan dipelihara.

Beberapa saran:

• Opsi untuk mengintegrasikan Drone CI/CD secara otomatis ke dalam Gitea selama proses pembuatan.
• Lebih banyak konfigurasi Administrasi Situs dari Gitea UI, pasca-instal. Misalnya, saya ingin dapat mengubah hal-hal di _Konfigurasi Layanan_ dari halaman _Konfigurasi_.
• Opsi untuk membuat pengguna disembunyikan dari halaman Jelajahi.

Permintaan tarik / masalah / garpu federasi

Permintaan tarik / masalah / garpu federasi

Mungkin tidak federasi dalam arti kata Fediverse (ActivityPub, OStatus, diaspora*, dll.) tetapi saya ingin kemampuan untuk berinteraksi dengan instance jarak jauh dari yang diterapkan sendiri dengan cara apa pun yang paling sesuai dengan proyek.

Mungkin juga keren untuk memiliki tim dan organisasi yang terdiri dari pengguna dari berbagai contoh, meskipun itu kemungkinan akan sangat sulit untuk diterapkan.

Dua saran dari POV pengguna akhir dengan keterampilan pengkodean minimal yang mencoba membantu proyek sumber terbuka yang saya gunakan dengan melaporkan bug dan memberikan umpan balik UX:
1) Bantu standarisasi ForgeFed! Saya akan menyukai UX pengarsipan bug pada contoh Gitea (dan pemalsuan kode yang dihosting komunitas lainnya) menjadi seperti satu GH besar yang terdesentralisasi.
2) Jadikan setiap bagian dari proyek sebagai repo Git, sehingga masalah, wiki, dll., dapat dengan mudah ditarik, bercabang, didorong, atau bercabang. GL dan sr.ht melakukan ini dengan setidaknya beberapa komponennya. Selain bermanfaat, ini berpotensi membantu poin 1)

Kemampuan untuk membalas tiket melalui email akan menjadi langkah maju yang besar untuk kegunaan

Izinkan edisi semua konfigurasi dari UI (dan mungkin ubah format file konfigurasi selama proses)

Mungkin menyimpan sebagian besar konfigurasi dalam database dan menyediakan cli dan api yang tepat untuk itu

@sapk @tboerger Saya akan mengatakan kita harus beralih ke viper untuk konfigurasi, dengan begitu kita dapat menghilangkan ini (dan beberapa bug yang kita miliki dengannya) dan mendapatkan hal-hal seperti memuat ulang konfigurasi saat Gitea sedang berjalan dan variabel env yang tepat .

Saya bersedia menangani ini, tetapi saya tidak yakin apakah saya akan menemukan waktu dalam waktu dekat.

Saya untuk Viper juga. Saya mencoba melakukannya 2 tahun yang lalu, tetapi tidak punya waktu untuk menyelesaikannya ... tapi saya bisa mencobanya lagi :)

Saya ingin mendapatkan file konfigurasi yang lebih minimal... Banyak pengaturan ini tidak perlu diatur melalui file konfigurasi statis dan dapat dengan mudah ditambahkan ke db dan dan di-cache untuk alasan kinerja.

Saya pikir kita pada awalnya dapat menambahkan tabel konfigurasi database dan memindahkan item konfigurasi yang paling dapat diubah ke sana dari file ini dan hanya meninggalkan item yang perlu dimuat ulang.

@lunny dan semuanya: setuju untuk memindahkan banyak pengaturan ke database dan membiarkannya dikonfigurasi di antarmuka Web (baik situs atau repo) terasa seperti langkah maju yang baik. Kemudian juga akan mudah untuk memiliki alat seperti teh atau gitea itu sendiri yang dapat mengubah nilai-nilai itu dari baris perintah, sehingga Anda masih dapat membuat skrip pengaturan default.

Sistem modul terdengar hebat. Saya percaya ada banyak orang di luar sana yang ingin menambahkan fungsionalitas baru ke gitea.

@belliash @sapk Plugin/modul IMO tidak dapat diimplementasikan secara efisien tanpa memfaktorkan ulang paket model sepenuhnya dan menambahkan lebih banyak abstraksi. Saya telah menguji beberapa teknologi seperti dukungan plugin asli dari Go.

Hasilnya adalah binari raksasa yang sangat bergantung pada biner Gitea.

Saya pikir meningkatkan dukungan webhook dan menambahkan halaman khusus oleh webhook lebih realistis untuk diterapkan karena kami sudah memiliki API matang yang tenang yang dapat digunakan untuk operasi basis data.

@jonasfranz Saya akan sangat mendukung model refactoring untuk menghapus banyak dependensinya.

go list -f  '{{ .Imports }}' code.gitea.io/gitea/models 

mengungkapkan 98 (!) impor langsung. 50 di antaranya adalah non-go core.

go list -f  '{{ .Deps }}' code.gitea.io/gitea/models

mengungkapkan 437 (!!) dependensi transitif. (304 di antaranya adalah non-go core)

Lihatlah sumber drone, di sana kami mendapatkan banyak hal yang dapat dicolokkan berdasarkan webhook.

Selain itu model plugin seperti packer masuk akal, sistem plugin berbasis grpc.

@tboerger Bisakah Anda memberikan contoh dari hal-hal yang dapat

Saya berbicara tentang ekstensi untuk konfigurasi, rahasia, dan sebagainya, antarmuka harus ditentukan di https://github.com/drone/drone/tree/master/plugin

Saya setuju dengan Anda, langkah besar Gitea selanjutnya adalah sistem plugin. Saya juga memikirkan ini hari ini. Saya akan mencoba sistem plugin.

Saya pikir itu harus mirip dengan sistem plugin drone tetapi memiliki lebih banyak. Kami harus mengizinkan plugin memiliki UI dan harus masuk dengan OAuth2 Gitea secara otomatis. Dan kita harus memiliki beberapa kebijakan keamanan pada plugin. dan sebagainya.

Saya ingin membagikan tabel perbandingan yang kami buat sekitar tahun 2016 untuk _memutuskan_ platform hosting mana yang akan dipilih untuk Open Source Geospatial Foundation. Dalam tabel itu kami mencantumkan fitur yang penting bagi kami. Gitea ada di salah satu kolom:

https://wiki.osgeo.org/wiki/GitInfrastructureComparison

Anda akan melihat bahwa fitur penting yang hilang pada tahun 2016 masih hilang hari ini: reply-by-mail (komentar/balasan) --- beberapa lainnya telah diterapkan pada hari ini.

@strk alat untuk migrate from github dan Comments on diff lines selesai.

Perlu kustomisasi template email
Lihat #6037

Jadi ada sedikit kustomisasi template yang sudah mungkin - baris subjek adalah satu-satunya hal yang menurut saya tidak kita miliki.

Apa yang sebenarnya harus kita lakukan adalah mengaktifkan i18n untuk email dan git serv hook pesan.

Diperlukan pengembalian permintaan tarik.
Lihat #6375

Dukungan penuh untuk tag di UI. Buat, tetapkan, ubah, hapus, dll. Saya sangat merindukan fitur ini.

Saya mendukung konfigurasi dalam database (dengan cli atau api untuk mengkonfigurasinya, seperti membuat pengguna dan otentikasi ldap, dll.) dan sistem plugin.
Keduanya harus mendorong gitea selangkah lebih maju.

LFS

• [x] Kami memerlukan beberapa cara untuk mengelola file LFS dalam repositori - saat ini mereka benar-benar buram #7199 adalah upaya untuk menyediakan ini - tetapi untuk menjadi efisien, mungkin perlu...
  
  
  
  • [ ] Filter Bloom untuk pencarian gumpalan - akan sangat baik untuk memiliki beberapa cara yang sedikit efisien untuk menemukan komit dan pada jalur pohon apa yang memperkenalkan gumpalan
  
  
• [ ] Saat ini tidak ada cara yang dapat diandalkan untuk memulai ulang unggahan ke LFS - jadi unggahan yang sangat besar dapat gagal berulang kali. Terapkan tus.io sesuai #1723
• [ ] Kita harus memberikan opsi untuk hanya menggunakan .gitattributes untuk menentukan apakah suatu file adalah penunjuk LFS daripada hanya mengasumsikan bahwa file apa pun yang terlihat seperti penunjuk adalah penunjuk. Meskipun itu mungkin membuat fungsionalitas di #7199 sangat sulit...
• [ ] File LFS harus dapat dilihat dalam tampilan diff.

pengerasan

Shutdown dan awal membuat Gitea benar-benar clusterable

• [ ] Kita perlu memperkuat respons Gitea terhadap shutdown.
  
  
  
  • [x] Ini berarti penghentian koneksi yang mendengarkan dengan baik, terutama SSH bawaan - yang saat ini dapat menyebabkan kerusakan pada repositori git melalui penghentian yang tiba-tiba. #7274 adalah awal dari upaya untuk memperbaikinya.
  
  
  • [ ] tetapi juga berarti bahwa pekerjaan seperti pemberitahuan harus dapat diserialisasi - misalnya antrian pengindeksan harus melalui antrian pada disk atau db, antrian surat yang serupa, dll. Kami sudah memiliki beberapa di antaranya tetapi antrian ini tidak dimatikan dengan baik.
  
  
• [ ] Sebagai akibat wajar di atas, kita harus memisahkan tindakan pengindeksan dari pencarian. Shutdown yang anggun membutuhkan ini dalam hal apa pun - tetapi ini adalah bagian dari langkah menuju pengelompokan. Saya tidak yakin arsitektur mana yang harus kita ambil tetapi, ada beberapa opsi - pisahkan pengindeks ke proses terpisah & minta Gitea hanya-baca indeks, atau ekspor seluruh pengindeksan.

Diff dan Membaca data dengan panjang sewenang-wenang ke dalam memori

• [ ] Kode diff memerlukan pemfaktoran ulang - rapuh, membaca seluruh diff ke dalam memori dan membutuhkan diff yang sangat besar untuk diuraikan oleh browser sebelum pengguna dapat merespons. Ini membutuhkan perubahan UI dan server - mungkin gulir tak terbatas yang didukung dengan Ajax adalah teknik yang tepat untuk ini. Saat ini perbedaan besar yang cukup jahat dapat menurunkan server dan browser.
• [ ] Arsitektur diff kami saat ini mencemari repositori dasar dengan cabang dan objek yang telah digabungkan sebelumnya.
• [ ] Secara umum kita HARUS berhenti hanya membaca data dengan panjang sewenang-wenang ke dalam memori. Jika ada tempat di mana browser mungkin menginginkan ini - kita harus membatasi apa yang kita baca dan kemudian menggunakan teknik gulir tak terbatas atau tautan penuh dengan rendering browser atau dirender dalam pipa untuk memastikan bahwa itu tidak disangga sepenuhnya di memori. Bahkan kode yang relatif baru masih mengalami masalah ini.
• [ ] (Jika kita menjalankan proses git yang dapat mengembalikan data panjang yang sewenang-wenang, kita harus mencoba untuk menghindari membaca semuanya secara langsung ke buffer stdout sepenuhnya tetapi melakukan lebih banyak pipeline go-routine.)

Menggabungkan

• [ ] Kita harus melakukan refactor merge untuk menggunakan indeks git sepenuhnya karena saat ini kita jarang melakukan checkout untuk penggabungan - pada dasarnya karena git merge akan turun ke https://git-scm.com/docs/git-merge-one-file to menangani penggabungan non-maju cepat. Ini memaksa pembuatan jalur semi-arbitrer di server - yang tidak perlu dan bergantung pada faktor charset/sistem file. Ini tidak perlu dilakukan - kita dapat melakukan penggabungan ini dengan file-file sementara, hashing dan menambahkan ke indeks secara langsung.

Lokasi melarikan diri dan Repositori

• [ ] Kita harus memeriksa di mana-mana untuk melarikan diri. Kode Legacy Gogs secara umum tidak lolos dengan baik dan bertanggung jawab atas beberapa masalah keamanan.
• [ ] Asumsi bahwa nama pengguna dan nama repositori tidak perlu diloloskan memaksa kami mengambil keputusan arsitektur yang tidak kami perlukan. Itu bahkan tidak melindungi kami dengan benar untuk tanda tangan git karenanya #5774.
• [ ] Meskipun menyenangkan bagi pengguna untuk memiliki lokasi repositori yang mendasarinya cocok dengan lokasi sistem file - misalnya $GITEA_ROOT/owner/reponame itu adalah keputusan arsitektur yang buruk IMHO dan mengarah pada asumsi oleh pengguna bahwa repositori kami masih dapat digunakan oleh git di server tanpa pemikiran lebih lanjut - MEREKA TIDAK HARUS. Kita harus pindah ke $GITEA_ROOT/repository-$ID , mungkin di-sharded. (Melakukan ini akan memungkinkan penghapusan banyak panggilan ke repo.MustOwner() atau repo.GetOwner() )
  
  
  
  • [ ] Setelah kami pindah ke atas dan kami melarikan diri semuanya dengan benar, kami kemudian dapat mengendurkan batasan pada nama pengguna dan nama repositori - meskipun ini harus dipikirkan dengan cermat untuk memastikan bahwa kami melakukannya dengan cara yang tidak memungkinkan memalsukan masalah yang mirip dengan #5774.
  
  
• [x] Kita harus menerapkan proses git server agar berjalan dengan lingkungan Gitea yang memadai - ada pengguna berulang yang mencoba menggunakan repositori Gitea di server tanpa melalui Gitea sehingga kemudian mengeluh bahwa Gitea tidak diperbarui dll. #6961 adalah langkah yang diperlukan untuk ini dan mengikuti penggabungan ini, kami cukup mengubah https://github.com/go-gitea/gitea/blob/bf552761894dee08f734d91f5c8175cd0cb2f9f5/cmd/hook.go#L72 untuk menegakkan pengaturan SSH_ORIGINAL_COMMAND atau memaksakan sisanya lingkungan standar ditetapkan.
• [ ] Kita seharusnya bisa mengatasi repositori yang dipasang NO_EXEC - dan sebenarnya kita mungkin harus merekomendasikan ini. Ini mungkin sebenarnya tidak sulit untuk dilakukan - cukup ubah variabel .git/config atau pusat .gitconfig core.hooksPath dan pikirkan di mana kita akan menempatkan kait sebaliknya.
• [ ] Kami pada dasarnya menyimpan baris kode langsung di database untuk komentar - yang tidak berfungsi jika data yang disimpan tidak dalam UTF-8. Ini berarti Anda tidak dapat mengomentari kode non-UTF8.

API / SDK

• [ ] Sungguh gila jumlah pekerjaan yang harus kita lakukan untuk membangun API ketika kita melakukan semua upaya untuk memiliki kesombongan. Kita harus membuat ini secara otomatis dari kesombongan, atau membuat otomatis sebanyak mungkin
• [ ] Kami tidak memiliki cara untuk menguji versi API tetap terhadap pengembangan Gitea kami sehingga kami tidak dapat mengetahui kapan kami membuat perubahan yang melanggar.
• [ ] Kita harus dapat menggunakan API/SDK yang dibuat secara otomatis untuk membuat rangkaian pengujian sederhana

Pengujian

• [ ] Saat ini kami menjalankan pengujian unit kami di tingkat TRACE - ini membatasi kemampuan kami untuk menambahkan jejak yang tepat ke berbagai hal. Sejak https://gitea.com/gitea/log/pulls/3 dan jika kami melakukan backport ke Gitea, kami dapat mengubahnya dari makefile kami.
• [ ] Perlu lebih banyak tes Unit dan pertimbangkan apakah beberapa tes integrasi sebenarnya adalah unit dan sebaliknya. misalnya https://github.com/go-gitea/gitea/blob/master/integrations/download_test.go
• [ ] Kami membutuhkan lebih banyak tes integrasi yang mencoba dijalankan melalui cerita pengguna. Yaitu - Seorang pengguna login, apakah X, lalu Y dan Z terjadi. Tidak apa-apa untuk menguji hal-hal dalam isolasi misalnya. https://github.com/go-gitea/gitea/blob/master/integrations/download_test.go tapi itu tidak benar-benar terintegrasi dan gagal menguji apa yang dialami pengguna. Saya terus mengatakan ini tetapi lebih banyak tes akan terlihat seperti: https://github.com/go-gitea/gitea/blob/master/integrations/ssh_key_test.go dan https://github.com/go-gitea/gitea/blob /master/integrations/git_test.go yang sebenarnya menguji apakah suatu fitur terintegrasi dengan benar.
• [x] Rezim pengujian kami membutuhkan waktu terlalu lama - CI membutuhkan waktu 30-40 menit untuk dijalankan saat ini! Kita harus menjalankan ini secara paralel.
• [ ] Tidak ada cara mudah untuk membuat tes migrasi.

Arsitektur Paket Go

model

• [ ] code.gitea.io/gitea/models tergantung pada terlalu banyak hal yang harus dihentikan.
• [ ] models.x harus dimusnahkan. Ini adalah keputusan arsitektur yang mengerikan.
• [ ] Untuk terlalu banyak model, terlalu mudah untuk menyebabkan dereferensi penunjuk nihil karena Anda tidak tahu statusnya. Bisakah kita menggunakan sistem pengetikan go sedikit lebih baik di sini?
• [x] Kita harus memasukkan OwnerName di tabel repositori karena setiap kali kita mendapatkan repositori, kita harus pergi dan mendapatkan Owner. Itu konyol dan buang-buang waktu. Repositori tidak terlalu sering berganti pemilik sehingga biaya untuk menanganinya tidak terlalu besar.
• [ ] Terlalu banyak hal yang masih dilakukan dalam model dan lebih banyak lagi yang harus dipindahkan.
• [ ] Mungkin masuk akal untuk membagi model menjadi inti dan non-inti.

Modul

• [x] Pada dasarnya ada dua jenis modul: modul yang bergantung pada model dan modul yang bergantung pada model. Mari kita pisahkan ini, yang bisa disebut layanan.

makaroni

• [ ] Saya pikir kita harus menganggap serius perpindahan ke gin yang diusulkan oleh @lunny
• [ ] Basis kode kami penuh dengan dependensi pada macaron, ini seharusnya tidak terjadi

Pengaturan

• [ ] Tergantung macaron juga(!)
• [ ] Berhubungan erat dengan go-ini, ketergantungan lain yang harus kita pertimbangkan untuk memutuskan hubungan kita sendiri.

Penginternasionalan

• [ ] Email tidak diinternasionalkan
• [ ] Pesan Git tidak diinternasionalkan
• [ ] Pesan kesalahan tidak diinternasionalkan
• [ ] Kita harus mengotomatiskan penghapusan dokumentasi situs web hugo sehingga dapat diinternasionalkan dengan CrowdIn
• [ ] Aneh bahwa kita memiliki bahasa yang menggunakan bentuk huruf kecil misalnya français, español dalam daftar pemilih bahasa - ini mewakili awal kalimat di masing-masing bahasa tersebut sehingga AFAICS mereka harus dikapitalisasi. Oui, si j'écris en français j'écris "français", mais si j'écris une liste á puces, j'écris:
  
  
  
  • bahasa Inggris
  
  
  • Français
  
  
  • Spanyol
  
  

Pembuangan & Pemulihan Gitea

• [ ] Gitea dump rusak untuk mengkonversi antara varian SQL
• [ ] Kami tidak memiliki perintah pemulihan

Di bagian UI, saya menyarankan untuk memberikan dua UI:

• satu HTML biasa (mirip dengan yang sekarang tanpa js)
• JS lengkap yang hanya mengandalkan panggilan API. Ini akan memaksa untuk memikirkan kembali beberapa API tetapi juga akan memungkinkan lebih banyak interaksi dari aplikasi eksternal lainnya.

• pikir kita harus menganggap serius perpindahan ke gin yang diusulkan oleh @lunny

Saya akan menyarankan go-chi daripada gin.

• Kami harus mengotomatiskan penghapusan dokumentasi situs web hugo kami sehingga dapat diinternasionalkan dengan CrowdIn

IMHO situs web/dokumen tidak boleh diterjemahkan sama sekali, toh selalu ketinggalan jaman ...

IMHO situs web/dokumen tidak boleh diterjemahkan sama sekali, toh selalu ketinggalan jaman ...

Tetapi dengan crowdin, itu menjadi usang akan memberi tahu orang-orang dan membatalkan terjemahan saat ini.

Apakah mungkin menambahkan paket OS yang tepat ke proses pembuatan? Saya

Mungkin paket gaya PPA yang dikontrol dan diversi oleh pengembang GItea akan menjadi ide yang bagus, tapi saya bukan penggemar cara versi "freeze and backport security patch" gaya Debian untuk proyek yang bergerak cepat (seperti GItea)

Saya masih ingin memiliki https://github.com/go-gitea/gitea/issues/3840 .
Saya pikir itu dapat diimplementasikan dengan kompatibilitas ke belakang.
Tapi ini akan menjadi jelas hanya setelah migrasi lib perutean baru diselesaikan.
Pembersihan/refactor dasar prasyarat akan membuatnya lebih mudah juga.

Saya masih ingin memiliki #3840.
Saya pikir itu dapat diimplementasikan dengan kompatibilitas ke belakang.
Tapi ini akan menjadi jelas hanya setelah migrasi lib perutean baru diselesaikan.
Pembersihan/refactor dasar prasyarat akan membuatnya lebih mudah juga.

Dalam hal ini, Anda mungkin akan kehilangan dukungan Drone, karena saat ini juga tidak diterapkan untuk Gitlab.

Saya masih ingin memiliki #3840.
Saya pikir itu dapat diimplementasikan dengan kompatibilitas ke belakang.
Tapi ini akan menjadi jelas hanya setelah migrasi lib perutean baru diselesaikan.
Pembersihan/refactor dasar prasyarat akan membuatnya lebih mudah juga.

Kami mungkin tidak memerlukan fitur grup ini untuk memengaruhi url repositori, kami hanya dapat membuat folder yang repositori dapat ditempatkan ke dalam tampilan tetapi tetap mempertahankan url repo seperti sekarang

@tboerger
Pikiran saya adalah URL dapat tetap sama jika repo tidak bersarang di grup/direktori.
URL perlu "ditingkatkan" hanya jika repo menggunakan fitur grup/direktori.
Tapi ya, repo dengan URL baru mungkin tidak dapat memiliki dukungan Drone di luar kotak.

@lafriks
Itu terdengar seperti ide yang bagus. Skenario penggunaan fitur saya adalah untuk meng-host modul Git atau subproyek dari proyek Repo. Jadi, saya tidak yakin itu mencakup kasus itu.

Jangan khawatir. Saya enggan membuat perubahan yang begitu luas, dan mungkin melanggar, juga.

Masalah ini memiliki banyak ide bagus dan kita harus menyimpannya dan mengatasinya.
Namun, kapan dan bagaimana kita harus memilih? Diskusi ini bisa berlangsung selamanya.

Saya akan menyarankan pemilik memilih subjek atau memilih antara mereka dan anggota.
Bagaimana menurutmu?

@DblK Itu benar. Tapi saya pikir kita bisa melakukannya setelah kita bermigrasi ke gitea.com. Saat ini kami membutuhkan lebih banyak umpan balik dari pengguna.

• Dukungan Mercurial
• penyortiran dan penyaringan yang lebih baik untuk PR dan masalah

• Dukungan Mercurial

Tidak, tolong. Ini disebut "git"ea karena suatu alasan.
Saya mengerti keinginan untuk memiliki ruang lingkup yang lebih luas tetapi
kembung ada di sekitar sudut ...

impor lincah akan menjadi alternatif

Pada 26 Juli 2019 13:52:50 UTC, Sandro Santilli [email protected] menulis:

• Dukungan Mercurial

Tidak, tolong. Ini disebut "git"ea karena suatu alasan.
Saya mengerti keinginan untuk memiliki ruang lingkup yang lebih luas tetapi
kembung ada di sekitar sudut ...

--
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung atau lihat di GitHub:
https://github.com/go-gitea/gitea/issues/6998#issuecomment -515461704

Permintaan tarik / masalah / garpu federasi

Mungkin tidak federasi dalam arti kata Fediverse (ActivityPub, OStatus, diaspora*, dll.) tetapi saya ingin kemampuan untuk berinteraksi dengan instance jarak jauh dari yang diterapkan sendiri dengan cara apa pun yang paling sesuai dengan proyek.

Sudah ada beberapa diskusi tentang ini di # 1612. ForgeFed mengumpulkan beberapa ide menarik untuk memasukkan federasi ke dalam pemalsuan kode seperti Gitea. Akan luar biasa jika ini akan menjadi fitur besar berikutnya dari Gitea!

Saya ingin alat diff visual untuk file grafik (JPEG, PNG, tetapi juga PDF), mirip dengan apa yang ditawarkan Github .

Kami sudah memiliki PR untuk membedakan gambar

Kami sudah memiliki PR untuk membedakan gambar

Benar, tetapi itu tidak mencakup pratinjau gesek atau kulit bawang, hanya berdampingan. Selain itu, saya tidak berpikir itu mencakup file PDF. Kami menggunakan Gitea di sini untuk pengembangan materi grafis (termasuk manual dan brosur), dan perbedaan visual yang baik untuk PDF akan menjadi pengubah hidup.

Saya punya beberapa ide yang ingin saya lemparkan disana :smile_cat:

1. Gunakan Cloud KSM untuk mengenkripsi/mendeskripsi rahasia apa pun secara transparan. Ini akan melindungi dari DB yang diretas dan diekspos. Idenya adalah bahwa kita dapat menggunakan tipe kustom dengan metode encoding/decoding XORM untuk mengenkripsi data rahasia sebelum menulis ke DB. Kami membuat contoh demo di sini: https://github.com/gomodules/ksm-xorm

2. Dukungan OIDC: Kembalikan id_token selain token oauth2 saat masuk melalui Gitea

3. Profil pengguna Gitea dapat menampilkan profil pengguna di seluruh repo Git yang terverifikasi. Contoh: pengguna dapat menyematkan repo Github/Gitlab/BitBuket/Gitea. Idenya adalah bahwa pengguna juga tidak dapat mengabaikan yang lain. Jadi, bisakah gitea menjadi satu-satunya profil pengguna global?

4. Dukungan domain khusus untuk repo (pergi)

5. Compat penuh dengan Github (Saya telah melihat beberapa pekerjaan di depan ini, saya tidak tahu berapa banyak yang sudah dilakukan.)

6. Integrasi server Bahasa Opsional. Sesuatu seperti Sourcegraph seperti navigasi yang dibangun ke dalam UI.

Saya ingin berkontribusi menuju 1 & 2 dalam waktu singkat.

Mungkin kita bisa menampilkan diff dalam bentuk pohon folder dan file yang telah berubah - seperti di BitBucket, alih-alih satu halaman besar dengan semua perubahan di dalamnya. Itu akan jauh, jauh lebih mudah dibaca.

Mungkin Opsi untuk menggabungkan Pemberitahuan di semua Repositori per hari atau per minggu.
Jenis seperti ringkasan Kegiatan minggu lalu.

Tambahkan kemungkinan untuk mendefinisikan webhook khusus melalui templat khusus dan kumpulan variabel standar.

Bukan evolusi Gitea tetapi proyek sampingan yang akan berguna : #7853

Fitur paritas dengan github!

Atau, paling tidak, daftar terbaru di wiki, yang menunjukkan semua fitur yang masih kita perlukan sebelum kita mencapai paritas. Ini akan menjadi cara yang baik untuk menyusun upaya pembangunan di masa depan.

@lonix1 lihat https://docs.gitea.io/en-us/comparison/ untuk daftar itu

@kolaente sepertinya kita memiliki hampir semua tanda centang! Ya!

Saya sangat baru di sini, tetapi juga seorang pembuat kode yang bersedia; Saya akan senang jika gitea mendukung intisari. Itu salah satu lubang terbesar untuk penggunaan saya. Cukup mudah untuk mengatasinya, tetapi saya lebih suka memiliki sistem inti saja.

Saya pikir masalah untuk Intisari adalah https://github.com/go-gitea/gitea/issues/693 (menautkan karena sepertinya belum dirujuk dari sini).

Tambahkan juga dokumentasi Help , yang dapat diakses melalui tautan Help . Sumber awal untuk dokumentasi ini dapat berasal dari GitHub Help , dengan modifikasi khusus Gitea.

Bantuan @bagasme tidak dapat diambil dari github, itu akan menjadi pelanggaran hak cipta. Seseorang harus menulis bantuan Gitea dari nol

1. Pembuatan masalah melalui email (lihat meja layanan GitLab).

Jika lebih banyak orang mulai mengadopsi hosting mandiri untuk berbagi proyek sumber terbuka mereka, perlu ada cara bagi pengguna yang tidak terdaftar untuk mengirimkan masalah tanpa harus membuat akun di setiap instance (kebanyakan orang sangat tidak mungkin mendaftar untuk bug laporan).

1. Sesuatu yang mirip dengan AutoDevOps GitLab. Ini berarti kemampuan untuk mendefinisikan tugas CI default ketika tidak ada file yaml CI di dalam repositori.

2a. Tab UI dan autentikasi registri penampung.

1. Bot
2. GPG untuk komitmen web
3. Kemampuan untuk memblokir penggabungan berdasarkan kondisi
4. Kemampuan untuk membuat file di UI web (termasuk dalam repo kosong kosong)
5. Kelola cuplikan yang dilampirkan ke repo melalui UI (lihat GitLab)
6. Dukungan protokol Git v2
7. Opsi IDE Web yang ditingkatkan
8. Integrasi Kubernetes (melalui plugin UI ala GitLab)
9. Tambahkan penundaan 400 ms sebelum tooltip ditampilkan di hover
10. Integrasi CI yang lebih baik (tampilkan pipeline, dukungan Concourse, dll)
11. Sempurnakan UI
12. Terapkan 2FA
13. Penguncian file
14. Tutup otomatis masalah terkait dengan penggabungan PR.

Beberapa jenis plugin / sistem ekstensi.

Sebagian besar saran bagus, tetapi akan menimbulkan masalah di basis kode inti.

Akan lebih baik untuk memiliki plugin resmi (dan tidak resmi). Ini juga berarti bahwa pembuat plugin dapat merilis lebih sering.

@lonix1 Yah, git hooks, webhooks, dan API Swagger dapat dianggap sebagai titik koneksi plugin. Saya mendukung lebih banyak dukungan plugin, tetapi menyatakan daftar dengan spesifik dapat membantu. Misalnya, saya ingin dukungan untuk baris perintah yang setara dengan webhook.

@guillep2k Misalnya semua fitur manajemen proyek yang dibahas di atas. Itu akan sangat berguna - tetapi mereka mungkin menyentuh begitu banyak bagian dari basis kode sehingga 1) mereka dapat menyebabkan masalah bahkan bagi mereka yang tidak menggunakan fitur-fitur itu, dan 2) karena itu, pengembangan seperti itu sangat lambat karena mereka yang bertanggung jawab atas menggabungkan fitur baru tahu bahwa skenario ini dimungkinkan, jadi mereka berhati-hati.

Jika fitur baru ini dapat dirilis secara terpisah, fitur tersebut dapat dicoba oleh pengguna yang bersedia sebelum digabungkan ke cabang utama.

Dan ada contoh lain dari fitur baru yang besar ini, cukup gulir ke atas.

@brandonkal GPG penandatanganan komit yang dibuat secara otomatis sekarang dimungkinkan dengan penggabungan #7631

Saya kira peta jalan harus dibagi ke dalam empat kategori tersebut (saya menambahkan beberapa contoh masalah — harus jelas bahwa itu jauh dari lengkap :wink:):

Fungsionalitas dasar

Masih ada beberapa _fungsi dasar_ yang tidak berfungsi dengan baik.
Contohnya:

• masih membutuhkan solusi pencarian yang baik seperti yang disebutkan dalam masalah seperti #5694 #5277 #3448, #2967, #2434, #8366, #8386 dan #7825
• penampil PDF rusak
• penampil SVG rusak
• tampaknya ada dependensi tidak bebas yang digunakan

Keamanan

Ada juga beberapa masalah keamanan:

• [ ] [gambar Docker masih berjalan sebagai root](https://github.com/go-gitea/gitea/issues/1190) meskipun panduan Docker sangat jelas tentangnya dan tidak ada alasan untuk menggunakan root pengguna (Anda dapat memetakan kembali port di luar)
• [ ] [menerapkan 2FA masih tidak mungkin](https://github.com/go-gitea/gitea/issues/880)
• [ ] [Aktifkan setelan header CSP yang lebih ketat dengan menghapus gaya sebaris](https://github.com/go-gitea/gitea/issues/305)
• [ ] [tidak ada pemeriksaan apakah seseorang diizinkan mengakses lampiran](https://github.com/go-gitea/gitea/issues/7908)

Integrasi

Saya kira integrasi dengan aplikasi/layanan lain adalah hal yang baik secara umum.
Karena pengembangan perangkat lunak biasanya tidak hanya mengandalkan satu alat saja.
Dan mungkin akan membantu meyakinkan beberapa orang untuk menggunakan Gitea di tempat kerja mereka.

Kedua masalah itu akan sangat meningkatkan interoperabilitas:

• [ ] secara otomatis mengintegrasikan Drone CI/CD ( seperti @BNolet yang diusulkan sebelumnya )
• [ ] [Integrasi API untuk tinjauan PR otomatis](https://github.com/go-gitea/gitea/issues/5733) melalui alat seperti Pronto
• [ ] [integrasi mudah dengan Container Registry](https://github.com/go-gitea/gitea/issues/2316)
• [ ] solusi webhook generik yang memungkinkan pengguna untuk mengatur webhook kustom dengan mudah ( seperti yang diusulkan oleh @bkcsoft sebelumnya )

Juga webhook generik akan menghindari perlunya orang lain mengetahui bagian dalam gitea. @guillep2k punya ide bagus bahwa integrasi "perintah eksternal" dapat dilakukan mirip dengan integrasi webhook generik .
:warning: Ini mungkin akan menyelesaikan sebagian besar masalah tentang apa yang diinginkan kebanyakan orang dalam masalah ini sebagai 'dukungan plugin' . Karena itu akan memungkinkan untuk memanggil apa pun yang perlu dipanggil oleh pengguna. Namun, @lunny baru saja menyebutkan bahwa ini secara praktis sudah dimungkinkan melalui git hooks. Saya hanya tidak yakin apakah ini benar-benar cara terbaik untuk mengintegrasikan alat/plugin/layanan lain.

Fitur di atas

Selain itu, jelas ada beberapa fitur bagus dalam aplikasi yang bersaing (yaitu Git[Hub/Lab]) (kebanyakan dari mereka mungkin agak bagus untuk dimiliki):

• [ ] [Kembalikan PR](https://github.com/go-gitea/gitea/issues/6375)
• [ ] [Peningkatan perbedaan untuk hal-hal non-tekstual seperti yang disebutkan oleh @arthur-bauer](https://github.com/go-gitea/gitea/issues/6998#issuecomment-516325459)
• [ ] [editan dari pengelola](https://github.com/go-gitea/gitea/issues/717)
• [ ] [Masalah rahasia](https://github.com/go-gitea/gitea/issues/3217)
• [ ] tampilkan lebih banyak detail repositori (yaitu ukuran repositori , grafik kontributor , bilah bahasa )
• [ ] beberapa perbaikan wiki (#823 #574)
• [ ] [memiliki perbedaan seperti BitBucket seperti yang disebutkan oleh @SignumPL](https://github.com/go-gitea/gitea/issues/6998#issuecomment-517151615) (saya tidak tahu itu sebelumnya tetapi tampaknya memang berguna )
• [ ] [mengintegrasikan fungsi seperti Octotree](https://github.com/go-gitea/gitea/issues/3045#issuecomment-5462333388)

Mungkinkah menggunakan Oracle Database sebagai opsi? Jika memungkinkan secara teknis.

@DemiusAcademius Jika xorm mendukung Oracle lebih baik, saya pikir itu mungkin.

Semakin banyak orang mulai menggunakan Gitea, misalnya juga disebabkan oleh pengumuman pelacak GitLab baru-baru ini. Tetapi GitHub/GitLab masih memiliki efek jaringan di pihak mereka.

Federasi akan menjadi pendorong besar untuk meningkatkan kemampuan berkolaborasi di antara pengguna instance Gitea yang berbeda dan dengan demikian meningkatkan keseluruhan jaringan Gitea: #1612

Kemampuan untuk menunjukkan perbedaan besar di UI dilaporkan menjadi faktor pembatas dalam adopsi Gitea.
Tiket mengatasinya: #7341 (fitur), #7495 (bug penghancur)

Kemampuan untuk menunjukkan perbedaan besar di UI dilaporkan menjadi faktor pembatas dalam adopsi Gitea.
Tiket mengatasinya: #7341 (fitur), #7495 (bug penghancur)

Itu batasan _besar_. IMO semua @alexanderadam yang tercantum di atas artinya jika dibandingkan dengan ini. Jika saya tidak dapat meninjau perbedaan besar dengan berkomentar sebaris dalam kode, itu masalah besar.

W/R/T kemarahan pada Microsoft dan Github yang menyebabkan banyak proyek bermigrasi dan menyebabkan tingginya permintaan untuk federasi--Gitlab baru-baru ini mengusulkan pelarangan karyawan di Cina dan Rusia, 2 negara terbesar di dunia berdasarkan luas daratan dan ekonomi. Militer AS telah mengalihkan fokus ke China dan Rusia (antara lain) untuk melemahkan hambatan yang mereka ajukan terhadap ekspansi/kepentingan kekaisaran AS. Propaganda dan insentif keuangan telah membawa Microsoft (Github, Azure), Amazon, Google, Atlassian (Trello, Jira) dan bahkan Gitlab ke dalam industri perang, spionase, propaganda, dan pengawasan dalam peran ofensif.

Saya menyampaikan ini untuk mengucapkan terima kasih kepada mereka yang bekerja pada repositori jarak jauh open source yang sangat tersedia dengan sedikit kekurangan pada layanan perusahaan dan terkait Pentagon yang kami gunakan dan masih mengandalkan sekarang--dan untuk memberi perhatian Anda bahwa alternatif cepat tersedia menghilang bagi mereka yang ingin menggunakan Internet dan teknologi sejauh mungkin dari kerajaan yang paling kuat dan bermusuhan dalam sejarah.

Mungkin topiknya cukup besar untuk bagian terpisah dari situs resmi untuk melacak kemajuan fitur ini, bersama dengan kampanye penggalangan dana terpisah untuk menangkap permintaan ini. Memasukkan ForgeFed dalam penggalangan dana mungkin bermanfaat dan adil, melihat kerja mereka sejauh ini. Sudah 17 bulan sejak Microsoft bertarung dengan Github, dan saya berharap dalam 17 bulan lagi kita dapat menggunakan Gitea federasi, atau memiliki bagian yang tersisa dari 'pengembangan kekayaan bersih.

Tolong jangan membahas politik di sini, mari kita lanjutkan ke topik - meningkatkan Gitea untuk semua orang

@lafriks Meningkatkan Gitea berarti mendefinisikan ceruk--sesuatu yang tidak terpenuhi oleh barang pengganti. Pemasaran adalah proses menemukan peluang eksternal, "politik" menjadi 1 dari 4 kategori utama analisis pemasaran. Merek yang bijaksana menarik _nilai_ orang sama seperti mereka memberikan fitur, spesifikasi, dan harga. Ada penarikan berbasis nilai ("politik") untuk alternatif seperti Gitea, dan kegagalan untuk menggarisbawahi dan mempertahankannya akan menjadi kegagalan untuk memahami konsumen Anda dan peluang pasar.

"Politik" sebagai sebuah istilah telah menjadi klise yang mengakhiri pemikiran, memadamkan diskusi tentang rasisme, kekerasan, dan eksploitasi. Saya hanya datang ke sini untuk berterima kasih kepada orang-orang karena terus bekerja pada alternatif yang tidak terkait dengan kamp konsentrasi AS, pengawasan jaring-jaring, dan kepentingan imperialis lainnya yang sebagian besar industri kami secara aktif membantu. Jika Anda mengatakan ini bukan kualitas yang dipertahankan Gitea, Aku salah paham dan aku akan pergi.

Catatan untuk @OKNoah

Pemasaran 101 untuk proyek sumber terbuka:

1. Jangan bawa kamp konsentrasi
2. Jangan sebut politik
3. Kehilangan topi kertas timah
4. Jangan gunakan istilah antik seperti imperialisme
5. Ketahui keunggulan produk Anda. Keunggulan Gitea adalah kesederhanaannya.

Jika transparansi GitLab.com menyinggung Anda, Anda dapat menghosting sendiri GitLab-FOSS. Ini adalah produk all-in-one yang sangat bagus. Tetapi jika Anda ingin instalasi sederhana atau memerlukan penggunaan memori yang lebih rendah dibandingkan dengan GitLab atau GitHub Enterprise, Gitea adalah pilihan yang baik untuk fitur web dasar.

Utas ini membahas tentang fitur-fitur yang dapat membantu menutup celah itu tanpa mengorbankan kesederhanaan.

2 sen saya - Saya pikir utas ini menjadi terlalu panjang, dan inilah saatnya untuk membuka edisi baru yang merangkum semua ide yang sudah diungkapkan di sini. Dan tutup yang ini.

Jika Anda mengatakan ini bukan kualitas yang dipertahankan Gitea, saya salah paham dan saya akan pergi.

Ini bukan apa yang dikatakan. Apa yang dikatakan adalah bahwa utas ini adalah tempat untuk mendiskusikan perubahan/perbaikan apa yang dapat dilakukan pada Gitea (khususnya yang teknis). Diskusi ini disambut baik, tetapi tidak di utas khusus ini.

Sebagai salah satu petunjuk, saya akan mengunci utas ini, seperti yang dikatakan @XVilka dengan benar, kami telah meminta banyak umpan balik, dan sekarang harus dievaluasi untuk langkah selanjutnya.

Kami dapat mengubah jalur ke kepatuhan FHS untuk v2. Itu sudah dimungkinkan dengan flag tetapi itu harus menjadi default untuk v2.