Gitea: مناقشة خارطة طريق Gitea

حل مكون إضافي (بما في ذلك السمة) لتوسيع نطاق gitea.

هل من الممكن إضافة حزم نظام تشغيل مناسبة إلى عملية الإنشاء؟ لقد كنت أحاول تجميع شيء ما من أجل فيدورا ولكن يبدو أن الذهاب يبدو نوعًا من الفوضى لحزمه. # 31 نوع من المحادثات حول هذا ولكن يبدو أنه لا يزال مفتوحًا.

نحن نستخدم ansible لنشر tarball على نظام دبيان ، وهذا ليس مفيدًا جدًا ولكنه يعمل. ستكون مستودعات التوزيعات الأكثر شيوعًا رائعة ، ولكن يجب وضعها في مكانها وصيانتها.

بعض الاقتراحات:

• خيار لدمج Drone CI / CD تلقائيًا في Gitea أثناء عملية الإنشاء.
• المزيد من قابلية تكوين إدارة الموقع من Gitea UI ، بعد التثبيت. على سبيل المثال ، أود أن أكون قادرًا على تغيير العناصر في _Service Configuration_ من صفحة _Configuration_.
• خيار لإخفاء المستخدم من صفحة الاستكشاف.

طلبات السحب الموحدة / القضايا / الشوكات

طلبات السحب الموحدة / القضايا / الشوكات

ربما لا يتم توحيدها بالمعنى الفيدرالي للكلمة (ActivityPub ، OStatus ، الشتات * ، إلخ) ولكني أرغب في القدرة على التفاعل مع الحالات البعيدة من تنفيذ المرء بأي طريقة تناسب المشروع بشكل أفضل.

قد يكون من الرائع أيضًا أن يكون لديك فرق ومؤسسات مكونة من مستخدمين من عدة حالات ، على الرغم من أنه من المحتمل أن يكون ذلك صعب التنفيذ بشكل لا يصدق .

اقتراحان من POV لمستخدم نهائي لديه الحد الأدنى من مهارات الترميز والذي يحاول مساعدة المشاريع مفتوحة المصدر التي أستخدمها من خلال الإبلاغ عن الأخطاء وإعطاء ملاحظات UX:
1) ساعد في توحيد ForgeFed! أود أن يكون UX الخاص بملء الأخطاء على مثيل Gitea (وغيره من أشكال الكود التي يستضيفها المجتمع) مثل GH الضخم اللامركزي.
2) اجعل كل جزء من المشروع عبارة عن Git repo ، بحيث يمكن بسهولة سحب المشكلات و wiki وما إلى ذلك منها أو تشعبها أو دفعها أو تشعبها. يقوم GL و sr.ht بعمل ذلك مع بعض مكوناتهما على الأقل. بالإضافة إلى كونه مفيدًا فقط ، فمن المحتمل أن يساعد هذا في النقطة 1)

ستكون القدرة على الرد على التذاكر عبر البريد الإلكتروني خطوة كبيرة إلى الأمام من أجل سهولة الاستخدام

السماح بإصدار كل التكوين من واجهة المستخدم (وربما تغيير تنسيق ملف التكوين أثناء العملية)

ربما تقوم بتخزين غالبية التكوين داخل قاعدة البيانات وتوفير cli و api المناسبين لها

sapktboerger أود أن أقول إننا يجب أن ننتقل إلى viper للتكوين ، وبهذه الطريقة يمكننا التخلص من ini (وبعض الأخطاء التي كانت لدينا معها) والحصول على أشياء مثل إعادة تحميل التكوين أثناء تشغيل Gitea ومتغيرات env المناسبة .

سأكون على استعداد لمعالجة هذا الأمر ، لكنني لست متأكدًا مما إذا كنت سأجد الوقت في المستقبل القريب.

أنا لفايبر أيضًا. كنت أحاول القيام بذلك منذ عامين ، لكن لم يكن لدي وقت لإنهائه ... لكن يمكنني المحاولة مرة أخرى :)

أنا من أجل الحصول على الحد الأدنى من ملف التكوين ... لا يلزم تعيين الكثير من هذه الإعدادات عبر ملف تكوين ثابت ويمكن إضافتها بسهولة إلى db والتخزين المؤقت لأسباب تتعلق بالأداء.

أعتقد أنه يمكننا في البداية إضافة جدول تكوين قاعدة البيانات ونقل عناصر التكوين الأكثر قابلية للتغيير هناك من ملف ini وترك العناصر التي تحتاج إلى إعادة التحميل فقط.

lunny and all: الموافقة على نقل العديد من الإعدادات إلى قاعدة البيانات والسماح بتكوينها في واجهة الويب (سواء على مستوى الموقع أو على مستوى الريبو) يبدو خطوة جيدة إلى الأمام. سيكون من السهل أيضًا أن يكون لديك أداة مثل الشاي أو gitea نفسها قادرة على تغيير هذه القيم من سطر الأوامر ، لذلك لا يزال بإمكانك كتابة إعداد افتراضي.

نظام الوحدة النمطية يبدو رائعًا. أعتقد أن هناك العديد من الأشخاص على استعداد لإضافة وظائف جديدة إلى gitea.

belliashsapk IMO الإضافات / وحدات لا يمكن تنفيذها بكفاءة دون إعادة بيع ديون نماذج حزمة تماما، وإضافة المزيد من التجريد. لقد اختبرت تقنيات متعددة مثل دعم المكون الإضافي الأصلي لـ Go.

كانت النتيجة ثنائيات عملاقة تعتمد بشدة على ثنائي Gitea.

أعتقد أن تحسين دعم webhook وإضافة صفحات مخصصة بواسطة webhooks أكثر واقعية ليتم تنفيذها نظرًا لأن لدينا بالفعل واجهة برمجة تطبيقات هادئة وناضجة يمكن استخدامها لعمليات قاعدة البيانات.

jonasfranz سأكون مؤيدًا جدًا لإعادة بناء النماذج لإزالة الكثير من

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

يكشف عن 98 (!) واردات مباشرة. 50 منها غير نواة.

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

يكشف 437 (!!) التبعيات متعدية. (304 منها غير نواة)

انظر إلى مصدر الطائرة بدون طيار ، لدينا الكثير من الأشياء القابلة للتوصيل بناءً على خطافات الويب.

إلى جانب ذلك ، فإن نموذج البرنامج المساعد مثل packer منطقي ، وهو نظام مكون إضافي قائم على grpc.

tboerger هل يمكنك تقديم مثال من الأشياء القابلة للتوصيل

أنا أتحدث عن ملحقات التكوينات والأسرار وما إلى ذلك ، يجب تحديد الواجهات على https://github.com/drone/drone/tree/master/plugin

أتفق معك ، يجب أن تكون الخطوة الكبيرة التالية لـ Gitea هي نظام المكونات الإضافية. أنا أفكر أيضًا في هذا هذه الأيام. سأجرب نظام البرنامج المساعد.

أعتقد أنه يجب أن يكون مشابهًا لنظام المكونات الإضافية للطائرة بدون طيار ولكن لديه المزيد. يجب أن نسمح للمكون الإضافي بأن يكون لديه واجهة مستخدم ويجب تسجيل الدخول باستخدام Gitea's OAuth2 تلقائيًا. ويجب أن يكون لدينا بعض السياسات الأمنية على المكونات الإضافية. وإلخ.

أرغب في مشاركة جدول مقارنة قمنا بإنشائه في حوالي عام 2016 من أجل _تقرر_ أي منصة استضافة نختارها لمؤسسة Open Source Geospatial Foundation. في هذا الجدول قمنا بإدراج الميزات التي كانت مهمة بالنسبة لنا. Gitea موجود في أحد الأعمدة:

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

سترى أن هناك ميزة مهمة كانت مفقودة في عام 2016 لا تزال مفقودة حتى اليوم: الرد بالبريد (تعليق / رد) - تم تنفيذ البعض الآخر اعتبارًا من اليوم.

strk tool إلى migrate from github و Comments on diff lines انتهيت.

تحتاج إلى تخصيص قالب البريد
انظر # 6037

لذلك هناك قدر كبير من تخصيص القالب ممكن بالفعل - سطر الموضوع هو الشيء الوحيد الذي لا أعتقد أننا نملكه.

ما يجب علينا فعله حقًا هو تمكين i18n للبريد الإلكتروني ورسائل ربط git serv.

مطلوب التراجع عن طلب السحب.
انظر # 6375

الدعم الكامل للعلامات في واجهة المستخدم. إنشاء ، تعيين ، تغيير ، حذف ، إلخ. أنا أفتقد هذه الميزة حقًا.

أنا أؤيد التكوين في قاعدة البيانات (باستخدام cli أو api لتكوينه ، مثل إنشاء مستخدم ومصادقة ldap ، إلخ ..) ونظام البرنامج المساعد.
يجب أن يدفع هذان الشخصان إلى gitea خطوة كبيرة إلى الأمام.

LFS

• [x] نحن بحاجة إلى طريقة ما لإدارة ملفات LFS في المستودع - في الوقت الحالي ، إنها مبهمة تمامًا # 7199 محاولة لتوفير ذلك - ولكن لكي تكون فعالة من حيث الاحتياجات ...
  
  
  
  • [] مرشح Bloom لبحث blob - سيكون من الجيد جدًا أن يكون لديك طريقة فعالة بعض الشيء للعثور على الالتزام وفي أي مسار شجرة يقدم blob
  
  
• [] في الوقت الحالي ، لا توجد طريقة موثوقة لإعادة تشغيل التحميل إلى LFS - لذلك يمكن أن تفشل عمليات التحميل الكبيرة جدًا بشكل متكرر. قم بتنفيذ tus.io حسب # 1723
• [] يجب أن نوفر خيارًا لمجرد استخدام .gitattributes لتحديد ما إذا كان الملف هو مؤشر LFS بدلاً من مجرد افتراض أن أي ملف يبدو كمؤشر هو مؤشر. على الرغم من أن هذا من المحتمل أن يجعل الوظيفة في # 7199 صعبة للغاية ...
• [] يجب أن تكون ملفات LFS قابلة للعرض في طريقة عرض الفرق.

تصلب

إيقاف التشغيل وبداية جعل Gitea قابل للتجميع حقًا

• [] نحن بحاجة إلى تشديد استجابة Gitea للإغلاق.
  
  
  
  • [x] وهذا يعني الإغلاق الجيد لاتصالات الاستماع ، وخاصة SSH المدمج - والذي قد يتسبب حاليًا في تلف مستودعات git من خلال الإغلاق المفاجئ. # 7274 بداية لمحاولة إصلاح هذا.
  
  
  • [] ولكنه يعني أيضًا أن الإخطار مثل الوظائف يجب أن يكون قابلاً للتسلسل - على سبيل المثال ، يجب أن تكون قوائم انتظار الفهرسة من خلال قوائم انتظار على القرص أو db ، وقوائم انتظار البريد بالمثل ، وما إلى ذلك. لدينا بعض من هذا بالفعل ولكن لا يتم إغلاق قوائم الانتظار هذه بأمان.
  
  
• [] كنتيجة طبيعية لما سبق ، يجب أن نفصل بين إجراء الفهرسة والبحث. يتطلب الإغلاق الرشيق هذا في أي حال - ولكنه جزء من الخطوة نحو التجميع. لست متأكدًا من البنية التي يجب أن نتخذها ، لكن هناك خيارات متعددة - افصل المفهرس إلى عملية منفصلة وجعل Gitea يقرأ فقط الفهرس ، أو يصدر الفهرسة بالكامل.

فرق وقراءة البيانات ذات الطول التعسفي في الذاكرة

• [] يحتاج كود الاختلاف إلى إعادة هيكلة - فهو هش ، ويقرأ الفروق بالكامل في الذاكرة ويتطلب اختلافات ضخمة ليحللها المتصفح قبل أن يتمكن المستخدم من الاستجابة. يتطلب ذلك إجراء تغييرات في واجهة المستخدم والخادم - يفترض أن التمرير اللانهائي المدعوم بـ Ajax هو الأسلوب الصحيح لذلك. في الوقت الحالي ، يمكن أن يؤدي وجود فرق كبير شرير بما فيه الكفاية إلى إزالة كل من الخادم والمتصفح.
• [] تقوم بنية الفروق الخاصة بنا حاليًا بتلويث المستودع الأساسي بفروع وكائنات مدمجة مسبقًا.
• [] بشكل عام يجب أن نتوقف عن قراءة البيانات ذات الطول العشوائي في الذاكرة. إذا كان هناك مكان قد يرغب فيه المتصفح في ذلك - يجب أن نحصر ما نقرأه ثم نستخدم إما تقنية تمرير لا نهائية أو رابط كامل مع عرض المتصفح أو يتم تقديمه في خط أنابيب لضمان عدم تخزينه مؤقتًا في الذاكرة بالكامل. حتى الكود الجديد نسبيًا لا يزال يعاني من هذه المشكلة.
• [] (إذا كنا نجري عملية git والتي قد تعيد بيانات طويلة بشكل تعسفي ، فيجب أن نحاول تجنب قراءة كل ذلك مباشرة في مخزن مؤقت stdout بالكامل ولكننا نفعل المزيد من خطوط الأنابيب الروتينية.)

دمج

• [] يجب علينا إعادة بناء المعامل لاستخدام فهرس git تمامًا كما نجري حاليًا عملية دفع متفرقة للدمج - لأن دمج git سينزل إلى https://git-scm.com/docs/git-merge-one-file to التعامل مع عمليات الدمج غير السريعة التقديم. هذا يفرض إنشاء مسارات شبه عشوائية على الخادم - وهي غير ضرورية وتعتمد على عوامل مجموعة الأحرف / نظام الملفات. ليس من الضروري القيام بذلك - يمكننا إجراء عمليات الدمج هذه مع الملفات المؤقتة ، والتجزئة والإضافة إلى الفهرس مباشرةً.

مواقع الهروب والمستودعات

• [] يجب أن نتحقق من الهروب في كل مكان. تم إفلات كود Gogs القديم بشكل سيئ بشكل عام وكان مسؤولاً عن العديد من المشكلات الأمنية.
• [] الافتراض بأن اسم المستخدم وأسماء المستودعات لا تحتاج إلى إلغاء يفرض علينا اتخاذ قرار معماري لسنا بحاجة إليه. حتى أنها لم تحمينا بشكل صحيح من أجل تواقيع git ومن ثم # 5774.
• [] على الرغم من أنه من الجيد للمستخدمين أن يتطابق موقع المستودع الأساسي مع موقع نظام الملفات - على سبيل المثال ، $GITEA_ROOT/owner/reponame إنه قرار معماري سيء IMHO ويؤدي إلى افتراضات من قبل المستخدمين أنه لا يزال من الممكن استخدام مستودعاتنا عن طريق git على الخادم بدون مزيد من التفكير - لا ينبغي. يجب أن ننتقل إلى $GITEA_ROOT/repository-$ID ، ربما تم تقسيمه. (سيسمح هذا بإزالة الكثير من المكالمات إلى repo.MustOwner() أو repo.GetOwner() )
  
  
  
  • [] بمجرد أن ننتقل إلى ما سبق ونهرب من كل شيء بشكل صحيح ، يمكننا حينئذٍ تخفيف القيود المفروضة على أسماء المستخدمين وأسماء المستودعات - على الرغم من أنه يجب التفكير بعناية في هذا الأمر لضمان قيامنا بذلك بطريقة لا تسمح التزييف من خلال قضايا مشابهة للرقم 5774.
  
  
• [x] يجب أن نفرض عمليات git للخادم ليتم تشغيلها مع بيئة Gitea كافية - هناك مستخدمون متكررون يحاولون استخدام مستودعات Gitea على الخادم دون المرور عبر Gitea ، لذا يشتكون من عدم تحديث Gitea وما إلى ذلك. # 6961 عبارة عن خطوة ضرورية لذلك وبعد دمج هذا ، نقوم ببساطة بتغيير https://github.com/go-gitea/gitea/blob/bf552761894dee08f734d91f5c8175cd0cb2f9f5/cmd/hook.go#L72 لفرض إعداد SSH_ORIGINAL_COMMAND أو فرض ذلك تم تعيين البيئة القياسية.
• [] يجب أن نكون قادرين على التعامل مع مستودعات NO_EXEC المركبة - وفي الحقيقة يجب أن نوصي بذلك على الأرجح. ربما ليس من الصعب فعل ذلك - ما عليك سوى تغيير .git/config أو المتغير المركزي .gitconfig core.hooksPath وفكر في المكان الذي سنضع فيه الخطافات بخلاف ذلك.
• [] نقوم في الأساس بتخزين سطور من التعليمات البرمجية مباشرة في قاعدة البيانات للتعليقات - وهذا لا يعمل إذا لم تكن البيانات المخزنة بتنسيق UTF-8. هذا يعني أنه لا يمكنك ببساطة التعليق على رمز بخلاف UTF8.

API / SDK

• [] من الجنون حجم العمل الذي يتعين علينا القيام به لبناء واجهة برمجة تطبيقات عندما نبذل قصارى جهدنا للحصول على التباهي. يجب علينا فقط توليد هذا تلقائيًا من التباهي ، أو التوليد الذاتي قدر الإمكان
• [] ليس لدينا أي طريقة لاختبار إصدار ثابت لواجهة برمجة التطبيقات مقابل تطويرنا Gitea ، لذا لا يمكننا معرفة متى نجري تغييرات عاجلة.
• [] يجب أن نكون قادرين على استخدام API / SDK المُنشأ تلقائيًا لإنشاء أدوات اختبار بسيطة

اختبارات

• [] نجري حاليًا اختبارات الوحدة الخاصة بنا على مستوى TRACE - وهذا يحد من قدرتنا على إضافة أثر مناسب للأشياء. منذ https://gitea.com/gitea/log/pulls/3 وإذا أردنا backport إلى Gitea يمكننا تغيير هذا من ملف makefile الخاص بنا.
• [] تحتاج إلى مزيد من اختبارات الوحدة وفكر فيما إذا كانت بعض اختبارات التكامل هي في الواقع وحدة والعكس صحيح. على سبيل المثال https://github.com/go-gitea/gitea/blob/master/integrations/download_test.go
• [] نحتاج إلى المزيد من اختبارات التكامل التي تحاول استعراض قصص المستخدمين. أي - يقوم المستخدم بتسجيل الدخول ، هل X ، ثم Y و Z يحدث. من الجيد اختبار الأشياء في عزلة على سبيل المثال. https://github.com/go-gitea/gitea/blob/master/integrations/download_test.go ولكن هذا غير متكامل حقًا ويفتقد اختبار تجربة المستخدم. ما زلت أقول هذا ولكن المزيد من الاختبارات يجب أن تبدو مثل: https://github.com/go-gitea/gitea/blob/master/integrations/ssh_key_test.go و https://github.com/go-gitea/gitea/blob /master/integrations/git_test.go الذي يختبر في الواقع ما إذا كانت الميزة تتكامل بشكل صحيح.
• [x] نظام الاختبار الخاص بنا يستغرق وقتًا طويلاً - تستغرق CI من 30 إلى 40 دقيقة للتشغيل في الوقت الحالي! يجب علينا تشغيل هذه بالتوازي.
• [] لا توجد طريقة سهلة لإنشاء اختبارات الترحيل.

Go Package Architecture

عارضات ازياء

• [] code.gitea.io/gitea/models يعتمد على الطريق الكثير من الأشياء يجب أن يتوقف هذا.
• [] يجب تدمير models.x . إنه قرار معماري رهيب.
• [] بالنسبة للعديد من النماذج ، من السهل جدًا التسبب في عدم وجود إشارة مرجعية لمؤشر صفري لأنك لا تعرف ما هي الحالة فيه. هل يمكننا استخدام نظام الكتابة go's بشكل أفضل قليلاً هنا؟
• [x] يجب علينا فقط لصق OwnerName في جدول المستودع لأنه في كل مرة نحصل فيها على مستودع ، يتعين علينا بعد ذلك الذهاب والحصول على المالك. إنه سخيف ومضيعة للوقت. لا تغير المستودعات المالك في كثير من الأحيان ، لذا فإن تكلفة الاضطرار إلى التعامل مع ذلك ليست كبيرة.
• [] لا يزال يتم عمل الكثير من الأشياء في النماذج ويجب نقل المزيد منها.
• [] قد يكون من المنطقي تقسيم النماذج إلى أساسية وغير أساسية.

الوحدات

• [x] هناك نوعان أساسيان من الوحدات: تلك التي تعتمد على النماذج وتلك التي تعتمد عليها النماذج. دعونا نفصل بين هذه ، يمكن أن يسمى أحد الخدمات.

معكرون

• [] أعتقد أننا يجب أن نأخذ على محمل الجد الانتقال إلى الجن الذي اقترحه lunny
• [] قاعدة الشفرة الخاصة بنا مبعثرة بالاعتماد على المعكرون ، لا ينبغي أن يكون هذا هو الحال

ضبط

• [] يعتمد على المعكرون أيضًا (!)
• [] مرتبط ارتباطًا وثيقًا بـ go-ini ، وهي تبعية أخرى يجب أن نفكر في فصل أنفسنا عنها.

تدويل

• [] البريد الإلكتروني غير مدول
• [] رسائل Git لم يتم تدويلها
• [] رسائل خطأ لم يتم تدويلها
• [] يجب علينا أتمتة إزالة وثائق موقع hugo الخاصة بنا حتى يمكن تدويلها باستخدام CrowdIn
• [] من الغريب أن لدينا لغات تستخدم أشكالًا صغيرة مثل français و español في قوائم محدد اللغة - وهذا يمثل بداية الجملة في كل من هذه اللغات ، لذا يجب كتابة AFAICS بأحرف كبيرة. Oui، si j'écris en français j'écris "français"، mais si j'écris une liste á puces، j'écris:
  
  
  
  • إنجليزي
  
  
  • الفرنسية
  
  
  • الاسبانية
  
  

تفريغ واستعادة Gitea

• [] تم كسر Gitea dump للتحويل بين متغيرات SQL
• [] ليس لدينا أمر استعادة

من جانب واجهة المستخدم ، أقترح تقديم اثنين من واجهة المستخدم:

• HTML واحد عادي (على غرار الحالي بدون js)
• JS كامل يعتمد فقط على استدعاء API. قد يجبر هذا على إعادة التفكير في عدد قليل من واجهات برمجة التطبيقات ولكنه سيسمح أيضًا بمزيد من التفاعل من تطبيق خارجي آخر.

• أعتقد أننا يجب أن نأخذ على محمل الجد الانتقال إلى الجن الذي اقترحهlunny

أود أن أقترح go-chi بدلاً من الجن.

• يجب علينا أتمتة تجريد وثائق موقع hugo الخاص بنا بحيث يمكن تدويله باستخدام CrowdIn

IMHO لا ينبغي ترجمة موقع الويب / المستندات على الإطلاق ، فهو دائمًا على أي حال قديم ...

IMHO لا ينبغي ترجمة موقع الويب / المستندات على الإطلاق ، فهو دائمًا على أي حال قديم ...

ولكن مع الحشد ، فإن كونه قديمًا من شأنه أن يخطر الناس ويبطل الترجمات الحالية.

هل من الممكن إضافة حزم نظام تشغيل مناسبة إلى عملية الإنشاء؟ أنا

ربما تكون حزم نمط PPA التي يتحكم فيها مطورو GItea وإصدارها فكرة جيدة ، لكنني لست من المعجبين بطريقة "تجميد وتصحيحات أمان backport" على غرار Debian للمشاريع سريعة الحركة (مثل GItea)

ما زلت أرغب في الحصول على https://github.com/go-gitea/gitea/issues/3840.
أعتقد أنه يمكن تنفيذه بالتوافق مع الإصدارات السابقة.
ولكن هذا لن يتضح إلا بعد تسوية ترحيل lib التوجيه الجديد.
من شأن التنظيف / إعادة البناء التأسيسي الأساسي أن يجعل الأمر أسهل أيضًا.

ما زلت أرغب في الحصول على # 3840.
أعتقد أنه يمكن تنفيذه بالتوافق مع الإصدارات السابقة.
ولكن هذا لن يتضح إلا بعد تسوية ترحيل lib التوجيه الجديد.
من شأن التنظيف / إعادة البناء التأسيسي الأساسي أن يجعل الأمر أسهل أيضًا.

في هذه الحالة ، من المحتمل أن تفقد دعم الطائرات بدون طيار ، لأنه لم يتم تطبيقه حاليًا على Gitlab.

ما زلت أرغب في الحصول على # 3840.
أعتقد أنه يمكن تنفيذه بالتوافق مع الإصدارات السابقة.
ولكن هذا لن يتضح إلا بعد تسوية ترحيل lib التوجيه الجديد.
من شأن التنظيف / إعادة البناء التأسيسي الأساسي أن يجعل الأمر أسهل أيضًا.

ربما لا نحتاج إلى ميزة المجموعة هذه للتأثير على عناوين url الخاصة بالمستودع ، يمكننا فقط إنشاء مجلدات يمكن عرض المستودع فيها مع الاحتفاظ بعناوين url الخاصة بإعادة الشراء كما هي الآن

تضمين التغريدة
كان تفكيري أن عنوان URL يمكن أن يظل كما هو إذا لم يتم دمج الريبو في مجموعة / دليل.
يجب "ترقية" عناوين URL فقط إذا كان الريبو يستخدم ميزة المجموعة / الدليل.
لكن نعم ، ربما لم تستطع عمليات إعادة الشراء التي تحتوي على عناوين URL الجديدة الحصول على دعم بدون طيار من الصندوق.

تضمين التغريدة
تبدو فكرة جيدة. سيناريو استخدامي للميزة هو استضافة وحدات Git أو المشاريع الفرعية لمشاريع Repo. لذلك ، لست متأكدًا من أنه يغطي هذه القضية.

لا داعى للقلق. أنا متردد في إجراء مثل هذا التغيير الشامل ، وربما الانهيار ، أيضًا.

هذه المشكلة لديها فكرة جيدة ويجب أن نحتفظ بها ونتعامل معها.
ومع ذلك ، متى وكيف يجب أن نختار؟ يمكن أن تستمر هذه المناقشة إلى الأبد.

أود أن أقترح إما اختيار المالك للموضوعات أو التصويت بينهم وبين الأعضاء.
ماذا تعتقد؟

DblK هذا صحيح. لكنني أعتقد أنه يمكننا فعل ذلك بعد انتقالنا إلى gitea.com. حاليا نحن بحاجة إلى مزيد من ردود الفعل من المستخدمين.

• دعم زئبقي
• فرز وتصفية أفضل للعلاقات العامة والقضايا

• دعم زئبقي

لا أرجوك. إنه يسمى "git" EA لسبب ما.
أفهم الرغبة في الحصول على نطاق أوسع ولكن
سخام قاب قوسين أو أدنى ...

سيكون استيراد الزئبق بديلاً

في 26 يوليو 2019 ، الساعة 1:52:50 مساءً بالتوقيت العالمي المنسق ، كتب Sandro Santilli [email protected] :

• دعم زئبقي

لا أرجوك. إنه يسمى "git" EA لسبب ما.
أفهم الرغبة في الحصول على نطاق أوسع ولكن
سخام قاب قوسين أو أدنى ...

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/go-gitea/gitea/issues/6998#issuecomment -515461704

طلبات السحب الموحدة / القضايا / الشوكات

ربما لا يتم توحيدها بالمعنى الفيدرالي للكلمة (ActivityPub ، OStatus ، الشتات * ، إلخ) ولكني أرغب في القدرة على التفاعل مع الحالات البعيدة من تنفيذ المرء بأي طريقة تناسب المشروع بشكل أفضل.

هناك بالفعل بعض النقاش حول هذا في # 1612. تقوم ForgeFed بجمع بعض الأفكار الشيقة للحصول على اتحاد في الكود المزيف مثل Gitea. سيكون من الرائع أن تكون هذه هي الميزة الكبيرة التالية لـ Gitea!

أحب أداة فرق مرئية لملفات الرسوم (JPEG ، PNG ، ولكن أيضًا PDF) ، على غرار ما يقدمه Github .

لدينا بالفعل علاقات عامة لفرق الصور

لدينا بالفعل علاقات عامة لفرق الصور

صحيح ، لكن هذا لا يغطي التمرير السريع أو معاينة قشرة البصل ، جنبًا إلى جنب فقط. بالإضافة إلى ذلك ، لا أعتقد أنه يغطي ملفات PDF. نحن نستخدم Gitea هنا لتطوير المواد الرسومية (بما في ذلك الكتيبات والكتيبات) ، وسيكون الاختلاف المرئي الجيد لملفات PDF بمثابة تغيير للحياة.

لدي بعض الأفكار التي أريد طرحها هناك: smile_cat:

1. استخدم Cloud KSM لتشفير / فك تشفير أي سر بشفافية. هذا سوف يحمي من اختراق DB وكشفه. الفكرة هي أنه يمكننا استخدام نوع مخصص مع طرق تشفير / فك تشفير XORM لتشفير البيانات السرية قبل الكتابة إلى قاعدة البيانات. قمنا بعمل مثال توضيحي هنا: https://github.com/gomodules/ksm-xorm

2. دعم OIDC: قم بإرجاع id_token بالإضافة إلى رمز oauth2 المميز عند تسجيل الدخول عبر Gitea

3. يمكن أن يعرض ملف تعريف مستخدم Gitea ملف تعريف المستخدم عبر أي مستودع Git تم التحقق منه. مثال: يمكن للمستخدم تثبيت Github / Gitlab / BitBuket / Gitea repos. الفكرة هي أنه لا يمكن للمستخدمين تجاهل الآخرين أيضًا. لذا ، هل يمكن أن تكون Gitea هي ملف تعريف المستخدم العالمي الواحد؟

4. دعم المجال المخصص لـ repos (Go)

5. متوافق تمامًا مع Github (لقد رأيت بعض الأعمال على هذه الجبهة ، ولا أعرف مقدار ما تم إنجازه بالفعل).

6. تكامل خادم اللغة الاختياري. شيء مثل Sourcegraph مثل التنقل المدمج في واجهة المستخدم.

أود المساهمة في 1 & 2 في وقت قصير.

ربما يمكننا إظهار الاختلافات في شكل شجرة من المجلدات والملفات التي تغيرت - كما هو الحال في BitBucket ، بدلاً من صفحة واحدة ضخمة بها جميع التغييرات. سيكون أكثر قابلية للقراءة.

ربما يكون خيارًا لتجميع الإخطارات على جميع المستودعات يوميًا أو في الأسبوع.
نوع من مثل ملخص أنشطة الأسابيع الماضية.

أضف إمكانية تحديد Webhooks المخصصة عبر قوالب مخصصة ومجموعة من المتغيرات القياسية.

ليس تطورًا لـ Gitea بل مشروعًا جانبيًا سيكون مفيدًا: # 7853

ميزة التكافؤ مع جيثب!

أو ، على الأقل ، قائمة محدثة على الويكي ، والتي تُظهر كل تلك الميزات التي ما زلنا بحاجة إليها قبل أن نحقق التكافؤ. ستكون هذه طريقة جيدة لهيكلة جهود التنمية المستقبلية.

@ lonix1 ألق نظرة على https://docs.gitea.io/en-us/comparison/ لهذه القائمة

يبدو أن kolaente لدينا جميع علامات التجزئة تقريبًا! نعم!

أنا جديد جدًا هنا ، لكنني مبرمج راغب أيضًا ؛ سأحبها إذا دعمت gitea جوهرها. هذا واحد من أكبر الثقوب لاستخدامي. عملت بسهولة بما فيه الكفاية ، لكنني أفضل أن يكون لدي نظام جوهري في مكانه.

أعتقد أن مشكلة البيانات ستكون https://github.com/go-gitea/gitea/issues/693 (الربط حيث لا يبدو أنه تمت الإشارة إليه من هنا حتى الآن).

أضف أيضًا وثائق Help ، والتي يمكن الوصول إليها عن طريق رابط Help . يمكن أن يكون المصدر الأولي لهذه الوثائق من تعليمات GitHub ، مع تعديلات خاصة بـ Gitea.

bagasme مساعدة لا يمكن أن تؤخذ من جيثب ، سيكون ذلك انتهاكًا لحقوق النشر. سيتعين على شخص ما كتابة مساعدة Gitea من الصفر

1. إنشاء المشكلات عبر البريد الإلكتروني (انظر مكتب خدمة GitLab).

إذا بدأ المزيد من الأشخاص في تبني الاستضافة الذاتية لمشاركة مشاريعهم مفتوحة المصدر ، فيجب أن تكون هناك طريقة للمستخدمين غير المسجلين لإرسال المشكلات دون الحاجة إلى إنشاء حساب في كل حالة (من غير المرجح أن يقوم معظم الأشخاص بالتسجيل بسبب خطأ ما أبلغ عن).

1. شيء يشبه AutoDevOps الخاص بـ GitLab. هذا يعني القدرة على تحديد وظيفة CI افتراضية عندما لا يوجد ملف CI yaml في المستودع.

2 أ. علامة تبويب واجهة مستخدم تسجيل الحاوية والمصادقة.

1. الروبوتات
2. تلتزم GPG للويب
3. القدرة على منع عمليات الدمج على أساس الشروط
4. القدرة على إنشاء ملف في واجهة مستخدم الويب (بما في ذلك في مستودع فارغ فارغ)
5. إدارة المقتطفات المرفقة مع الريبو عبر واجهة المستخدم (انظر GitLab)
6. دعم بروتوكول Git v2
7. خيار Web IDE المحسن
8. تكامل Kubernetes (عبر المكون الإضافي لواجهة المستخدم على غرار GitLab)
9. أضف تأخيرًا قدره 400 مللي ثانية قبل عرض تلميح أداة عند التمرير
10. تكامل CI أفضل (عرض خطوط الأنابيب ، دعم Concourse ، إلخ)
11. صقل واجهة المستخدم
12. فرض 2FA
13. قفل الملف
14. إغلاق المشكلات المرتبطة تلقائيًا مع دمج العلاقات العامة.

نوع من الإضافات / نظام الامتداد.

معظم الاقتراحات جيدة ، لكنها ستخلق مشاكل في قاعدة الكود الأساسية.

سيكون من الأفضل أن يكون لديك مكونات إضافية رسمية (وغير رسمية). قد يعني هذا أيضًا أنه يمكن لمؤلفي البرنامج المساعد إصدار المزيد بشكل متكرر.

@ lonix1 حسنًا ، يمكن اعتبار git hooks و webhooks وواجهة برمجة تطبيقات Swagger بمثابة نقاط توصيل للمكونات الإضافية. أنا جميعًا أؤيد المزيد من دعم المكونات الإضافية ، لكن ذكر قائمة بالتفاصيل قد يساعد. على سبيل المثال ، أود دعم سطر أوامر مكافئ لـ webhooks.

@ guillep2k على سبيل المثال ، جميع ميزات إدارة المشروع التي تمت مناقشتها أعلاه. قد تكون هذه مفيدة للغاية - لكن من المحتمل أنها تلامس أجزاء كثيرة جدًا من قاعدة الشفرة بحيث 1) قد تسبب مشكلات حتى لأولئك الذين لا يستخدمون هذه الميزات ، و 2) بسبب ذلك ، فإن هذا التطوير بطيء جدًا لأن المسؤولين عن ذلك دمج الميزات الجديدة يعرفون أن هذا السيناريو ممكن ، لذا فهم حذرون.

إذا كان من الممكن إصدار هذه الميزات الجديدة بشكل منفصل ، فيمكن تجربتها من قبل المستخدمين الراغبين قبل دمجها في الفرع الرئيسي.

وهناك أمثلة أخرى لهذا النوع من الميزات الجديدة الكبيرة ، فقط قم بالتمرير لأعلى.

توقيع brandonkal GPG

أعتقد أنه يجب تقسيم خارطة الطريق إلى تلك الفئات الأربع (لقد أضفت بعض الأمثلة على المشكلات - يجب أن يكون واضحًا أنها بعيدة عن الاكتمال: wink :):

الوظائف الأساسية

لا تزال هناك بعض الوظائف الأساسية التي لا تعمل بشكل صحيح.
على سبيل المثال:

• لا يزال بحاجة إلى حل بحث جيد كما هو مذكور في قضايا مثل # 5694 # 5277 # 3448 ، # 2967 ، # 2434 ، # 8366 ، # 8386 و # 7825
• عارض PDF تالف
• عارض SVG معطل
• يبدو أن هناك تبعيات غير حرة مستخدمة

حماية

هناك أيضًا بعض المشكلات الأمنية:

• [] [لا تزال صورة Docker تعمل كجذر] (https://github.com/go-gitea/gitea/issues/1190) على الرغم من أن دليل Docker واضح جدًا ولا يوجد سبب لاستخدام root user (يمكنك إعادة تعيين المنافذ في الخارج على أي حال)
• [] [لا يزال فرض 2FA غير ممكن] (https://github.com/go-gitea/gitea/issues/880)
• [] [تمكين إعداد رؤوس CSP الأكثر صرامة عن طريق إزالة الأنماط المضمنة] (https://github.com/go-gitea/gitea/issues/305)
• [] [ليس هناك تحقق مما إذا كان مسموحًا لشخص ما بالوصول إلى المرفقات] (https://github.com/go-gitea/gitea/issues/7908)

اندماج

أعتقد أن التكامل مع التطبيقات / الخدمات الأخرى أمر جيد بشكل عام.
لأن تطوير البرامج عادة لا يعتمد فقط على أداة واحدة.
ومن المحتمل أن يساعد في إقناع بعض الناس باستخدام Gitea في أماكن عملهم.

ستعمل هاتان المسألتان على تحسين قابلية التشغيل البيني كثيرًا:

• [] دمج Drone CI / CD تلقائيًا ( مثل BNolet المقترح سابقًا )
• [] [تكامل واجهة برمجة التطبيقات لمراجعات العلاقات العامة التلقائية] (https://github.com/go-gitea/gitea/issues/5733) من خلال أدوات مثل Pronto
• [] [سهولة التكامل مع Container Registry] (https://github.com/go-gitea/gitea/issues/2316)
• [] حل ويب هوك عام يتيح للمستخدمين إعداد خطاطيف ويب مخصصة بسهولة ( كما اقترحه bkcsoft سابقًا )

كما أن خطافات الويب العامة ستتجنب الحاجة إلى معرفة أشخاص آخرين بأجزاء gitea الداخلية. لدى @ guillep2k فكرة رائعة مفادها أنه يمكن إجراء تكامل "أمر خارجي" على غرار التكامل الخطاف للويب العام .
: تحذير: من المحتمل أن يؤدي هذا إلى حل معظم المشكلات المتعلقة بما يريده معظم الأشخاص في هذه المشكلة كـ "دعم المكون الإضافي" . لأن ذلك سيمكن من الاتصال بكل ما يحتاج المستخدمون للاتصال به. ومع ذلك ، ذكرت lunny للتو أن هذا ممكن عمليًا بالفعل عبر خطافات git. لست متأكدًا تمامًا مما إذا كانت هذه هي بالفعل أفضل طريقة لدمج الأدوات / المكونات الإضافية / الخدمات الأخرى.

على أعلى الميزات

علاوة على ذلك ، من الواضح أن هناك بعض الميزات الرائعة في التطبيقات المنافسة (مثل Git [Hub / Lab]) (ربما يكون من الجيد امتلاك معظمها):

• [] [عودة العلاقات العامة] (https://github.com/go-gitea/gitea/issues/6375)
• [] [اختلاف محسّن للأشياء غير النصية كما ورد في @ arthur-bauer] (https://github.com/go-gitea/gitea/issues/6998#issuecomment-516325459)
• [] [تعديلات من المشرفين] (https://github.com/go-gitea/gitea/issues/717)
• [] [مشكلات سرية] (https://github.com/go-gitea/gitea/issues/3217)
• [] عرض المزيد من تفاصيل المستودع (مثل حجم المستودع ، الرسم البياني للمساهمين ، شريط اللغات )
• [] بعض تحسينات الويكي (# 823 # 574)
• [] [وجود فرق مثل BitBucket كما ورد فيSignumPL] (https://github.com/go-gitea/gitea/issues/6998#issuecomment-517151615) (لم أكن أعرف ذلك من قبل ولكنه يبدو مفيدًا بالفعل )
• [] [دمج وظيفة مثل Octotree] (https://github.com/go-gitea/gitea/issues/3045#issuecomment-546233388)

هل يمكن استخدام Oracle Database كخيار؟ إذا كان ذلك ممكنا من الناحية الفنية.

DemiusAcademius إذا كان xorm يدعم أوراكل بشكل أفضل ، أعتقد أن هذا ممكن.

بدأ المزيد والمزيد من الأشخاص في استخدام Gitea ، على سبيل المثال أيضًا بسبب إعلان GitLab الأخير. لكن لا يزال لدى GitHub / GitLab تأثير الشبكة في جانبهم.

سيكون الاتحاد محركًا كبيرًا لتحسين القدرة على التعاون بين مستخدمي مثيلات Gitea المختلفة وبالتالي زيادة شبكة Gitea بأكملها: # 1612

تم الإبلاغ عن القدرة على إظهار الاختلافات الكبيرة في واجهة المستخدم كعامل مقيد في اعتماد Gitea.
تذاكر التصدي لها: # 7341 (ميزة) ، # 7495 (خطأ كراشر)

تم الإبلاغ عن القدرة على إظهار الاختلافات الكبيرة في واجهة المستخدم كعامل مقيد في اعتماد Gitea.
تذاكر التصدي لها: # 7341 (ميزة) ، # 7495 (خطأ كراشر)

هذا حد ضخم. كل شيء في IMOalexanderadam المذكور أعلاه يتضاءل بالمقارنة مع هذا. إذا لم أتمكن من مراجعة الاختلافات الكبيرة من خلال التعليق المضمّن في الكود ، فهذه مشكلة كبيرة.

بسبب الغضب في Microsoft و Github الذي تسبب في هجرة العديد من المشاريع وتسبب في ارتفاع الطلب على الاتحاد - اقترح Gitlab مؤخرًا حظر الموظفين في الصين وروسيا ، وهما من أكبر دول العالم من حيث الكتلة الأرضية والاقتصاد. حوّل الجيش الأمريكي تركيزه إلى الصين وروسيا (من بين دول أخرى) لإضعاف الحواجز التي يفرضونها على التوسع / المصالح الإمبريالية الأمريكية. جلبت الدعاية والحوافز المالية Microsoft (Github و Azure) و Amazon و Google و Atlassian (Trello و Jira) وحتى Gitlab إلى صناعات الحرب والتجسس والدعاية والمراقبة في دور هجومي.

أحضر هذا لأعبر عن شكري لأولئك الذين يعملون في مستودعات بعيدة مفتوحة المصدر متاحة للغاية مع القليل من أوجه القصور في الخدمات المرتبطة بالشركات والبنتاغون التي نستخدمها وما زلنا نعتمد عليها الآن - وللفت انتباهك إلى أن البدائل السريعة هي تختفي لأولئك الذين يرغبون في استخدام الإنترنت والتكنولوجيا بعيدًا عن أقوى إمبراطورية في التاريخ وأكثرها عداءً.

ربما يكون الموضوع كبيرًا بما يكفي لقسم منفصل من الموقع الرسمي لتتبع التقدم المحرز في هذه الميزة ، جنبًا إلى جنب مع حملة منفصلة لجمع الأموال لتلبية هذا الطلب. قد يكون تضمين ForgeFed في جمع التبرعات مفيدًا وعادلاً ، ورؤية عملهم حتى الآن. لقد مرت 17 شهرًا على اليوم منذ أن بدأت Microsoft في استخدام Github ، وآمل أن نتمكن من استخدام 17 فراشة أخرى من Gitea ، أو أن يكون لدينا أجزاء متبقية من صافي الثروة.

من فضلك لا تناقش السياسة هنا ، فلنتابع الموضوع - تحسين Gitea للجميع

lafriks تحسين Gitea يعني تحديد مكانة - شيء لم تتم تلبيته بسلع بديلة. التسويق هو عملية إيجاد الفرص الخارجية ، "السياسية" كونها واحدة من 4 فئات رئيسية لتحليل التسويق. تناشد العلامة التجارية الحكيمة _ قيم_الناس بنفس القدر الذي يقدمون فيه الميزات والمواصفات والسعر. هناك سحب قائم على القيم ("سياسي") لبدائل مثل Gitea ، والفشل في التأكيد عليها والمحافظة عليها سيكون بمثابة فشل في فهم المستهلك وفرصة السوق.

لقد أصبح مصطلح "السياسي" مصطلحًا مبتذلًا ينهي الفكر ويقضي على مناقشة العنصرية والعنف والاستغلال. لقد أتيت إلى هنا ببساطة لأشكر الناس على استمرارهم في العمل على البدائل غير المرتبطة بمعسكرات الاعتقال الأمريكية ، ومراقبة شبكة السحب والمصالح الإمبريالية الأخرى ، فإن غالبية صناعتنا تساعدهم بنشاط. إذا كنت تقول أن هذه ليست صفات تدعم Gitea ، لقد فهمتك بشكل خاطئ وسأغادر.

ملاحظة لـ OKNoah

تسويق 101 لمشروع مفتوح المصدر:

1. لا تحضر معسكرات الاعتقال
2. لا تذكر السياسة
3. تفقد قبعة القصدير
4. لا تستخدم مصطلحات قديمة مثل الإمبريالية
5. تعرف على ميزة منتجك. ميزة Gitea هي بساطتها.

إذا كانت شفافية GitLab.com تزعجك ، فيمكنك استضافة GitLab-FOSS بنفسك. إنه منتج جيد للغاية متعدد الإمكانات. ولكن إذا كنت تريد تثبيتًا بسيطًا أو تتطلب استخدام ذاكرة أقل مقارنة بـ GitLab أو GitHub Enterprise ، فإن Gitea يعد خيارًا جيدًا لميزات الويب الأساسية.

يدور هذا الموضوع حول مناقشة الميزات التي يمكن أن تساعد في سد هذه الفجوة دون المساومة على البساطة.

سنتي 2 - أعتقد أن هذا الموضوع أصبح طويلاً جدًا ، وقد حان الوقت لفتح عدد جديد يلخص أي أفكار تم التعبير عنها هنا بالفعل. وأغلق هذا.

إذا كنت تقول أن هذه ليست صفات يقف Gitea عليها ، فقد أخطأت في الأمر وسأغادر.

ليس هذا ما يقال. ما يقال هو أن هذا الخيط هو المكان المناسب لمناقشة التغييرات / التحسينات التي يمكن إجراؤها على Gitea (على وجه التحديد التغييرات التقنية). هذه المناقشات موضع ترحيب ، ولكن ليس في هذا الموضوع المحدد.

بصفتي أحد العملاء المتوقعين ، سأقوم بإغلاق هذا الموضوع ، كما قال

يمكننا تغيير المسار إلى توافق FHS للإصدار v2. إنه ممكن بالفعل باستخدام العلامات ولكن يجب أن يكون الإعداد الافتراضي لـ v2.