Gitea: गीता ने गीता की मेजबानी की

बहुत अच्छा विचार!

फरवरी में 1.2, अप्रैल में 1.3, जून में 1.4, अगस्त में 1.5? यह सब लागू करने के लिए पर्याप्त समय होना चाहिए

यदि आपने इसे नहीं देखा है, तो तैयार होने पर ही सेल्फ-होस्टिंग के लिए आपके दृष्टिकोण का समर्थन करने वाली शानदार और व्यावहारिक टिप्पणी: https://lobste.rs/s/gokjbo/gitea_1_1_0_released/comments/dg9pwe#c_dg9pwe

@lunny अब जब मैं इसके बारे में सोचता हूं (उस लिंक के लिए @zellyn धन्यवाद) हमें स्वयं-होस्टिंग के लिए oauth-provider, _complete_ webhook समर्थन, api-documentation, और _complete_ API की आवश्यकता क्यों है?

OAuth _Consumer_ आवश्यक है (यह विलय AFAIK है) ताकि लोग github auth का उपयोग करके लॉगिन कर सकें।
ड्रोन केवल पुश हुक का उपयोग करता है, तो हमें दूसरे की आवश्यकता क्यों होगी?

एपीआई के लिए, सुनिश्चित नहीं है कि स्वयं-होस्टिंग के लिए सभी टीबीएच की आवश्यकता क्यों है :)

मैं उस सूची को कम करने के बारे में सहमत हूं। पहले सेल्फ-होस्टिंग से हमें प्राथमिकताएं बेहतर तरीके से सेट करने में मदद मिलेगी :)

@bkcsoft शायद हम एक होस्टेड साइट सेट

@bkcsoft मैंने इस मुद्दे को अपडेट किया, क्या आपका मतलब यह है?

-> OAuth प्रदाता (#27) बंद नहीं है

@ekozan बंद नहीं है, लेकिन "हमें जिन चीज़ों की ज़रूरत है" की सूची से खरोंच कर दिया गया है

"रिपॉजिटरी साइज लिमिट्स" जोड़ा गया क्योंकि हमारे पास सर्वर पर असीमित स्टोरेज नहीं है ...

सीमा के लिए मेरा प्रस्ताव:

• 0 संगठन
• 3 रिपोज
• 1GB/रेपो

@bkcsoft क्या आपका मतलब यह था कि यह किसी के लिए सार्वजनिक सेवा होगी?

हो सकता है, शायद नहीं, लेकिन _if_ यह एक सार्वजनिक सेवा बन जाती है, हम इसे असीमित नहीं कर सकते;)

मुझे लगता है कि डॉगफूडिंग इतना महत्वपूर्ण है कि रेपो आकार की सीमा को स्वयं-होस्टिंग गीता के लिए महत्वपूर्ण पथ में होने की आवश्यकता नहीं है। गीता में माइग्रेट करने के बाद पहले कुछ दिनों में, मैंने कई फीचर चूकों का सामना किया है, जिससे मुझे लगा कि सेल्फ-होस्टिंग उन चीजों को पूरा करने के प्रयास पर ध्यान केंद्रित करने में मदद करेगा। गीता पहले से ही एक शानदार, अत्यधिक प्रयोग करने योग्य, उच्च प्रदर्शन वाला उपकरण है - यह एक वास्तविक शर्म की बात है कि आप इसे स्वयं उपयोग नहीं कर रहे हैं। ;-)

कठोर आकार की सीमाओं पर निर्भर होने के बजाय, यह सोचने में मददगार हो सकता है कि स्व-होस्ट किए गए सर्वर को कैसे प्रशासित किया जा रहा है, जो पुलिस के बुरे व्यवहार के लिए जा रहा है, और वे कौन से उपकरण चाहते हैं। उदाहरण के लिए, गीता परियोजना के योगदानकर्ता कांटे को गीता के अपने सर्वर पर समर्थित होना चाहिए। यह जोखिम को उजागर करता है कि एक उपयोगकर्ता गिटिया को फोर्क करता है, फिर वेयरज़ को अपने कांटे पर धक्का देता है। आकार सीमाएं बड़ी बायनेरिज़ को धकेलने से रोकने में मदद कर सकती हैं, लेकिन पासवर्ड या क्रेडिट कार्ड नंबरों की सूची के साथ मदद नहीं कर सकती हैं। एक उपकरण जो उस मामले में मदद कर सकता है वह कुछ ऐसा है जो विदेशी फाइलों को अलग लाइन गिनती या रोलिंग हैश द्वारा पहचानता है।

एक भिन्न-आकार का उपकरण उपलब्ध होने का एक अच्छा साइड-इफ़ेक्ट यह है कि कोड वैध कमिट्स को फ़्लैग करने के लिए पुश के दौरान चलाने के विकल्प के रूप में उपलब्ध हो सकता है जिसे वैसे भी छोटे टुकड़ों में तोड़ा जाना चाहिए था। (ऐसा करने के तरीकों के लिए संबंधित चर्चा: https://github.com/go-gitea/gitea/issues/3658#issuecomment-372263759।)

मैं शर्त लगाता हूं कि सार्वजनिक-सामना करने वाले सर्वरों के लिए कई अन्य सूक्ष्म चीजें हैं जिन्हें संबोधित करने की आवश्यकता होगी। इन चीजों को ट्रैक करने के लिए एक अलग "सार्वजनिक होस्टिंग" मास्टर इश्यू या मील का पत्थर का उपयोग करना समझ में आता है।

मील के पत्थर की बात करें तो क्या इस मुद्दे को 1.5.0 में जोड़ा जाना चाहिए?

@stevegt नहीं, क्योंकि मुझे लगता है कि सभी

मैंने इस मुद्दे से Repository Size Limits (#3658) हटा दिया है क्योंकि यह Gita द्वारा होस्ट किए गए gita को प्रभावित नहीं करेगा।

मैंने इस मुद्दे से रिपोजिटरी आकार सीमा (#3658) हटा दी है क्योंकि यह गीता होस्टेड गीता को प्रभावित नहीं करेगा।

महान! मुझे विश्वास है कि जितनी जल्दी गीता खुद को होस्ट करेगी, उतनी ही तेजी से पूरी परियोजना वास्तविक जीवन के अनुभवों से लाभान्वित होगी, और विश्वास और आत्मविश्वास हासिल करेगी :)

@lafriks एक और सूत्र में उल्लेख करते हैं:

स्व-होस्टेड को अतिरिक्त वर्चुअल मशीन के भुगतान के लिए शायद अतिरिक्त धन/प्रायोजन की आवश्यकता होगी

और @ लुनी ऊपर पूछता है:

@bkcsoft क्या आपका मतलब यह था कि यह किसी के लिए सार्वजनिक सेवा होगी?

क्या उन विचारों को एक "ऑनलाइन गीता सेवा स्थापित करने के बारे में कैसे" में जोड़ना संभव होगा, जहां लोग निजी रेपो के लिए भुगतान करते हैं?

यदि ठीक किया जाता है, तो उसे स्वयं के लिए भुगतान करने के लिए धन उत्पन्न करना चाहिए + सार्वजनिक रेपो।

एक अवधारणा के रूप में, ऐसा लगता है कि यह काफी अच्छी तरह से यात्रा की गई जमीन है। :मुस्कुराओ:

@justinclift विचार को तुरंत जोड़ने के लिए; Microsoft द्वारा GitHub को संभालने की वर्तमान खबर के साथ समय सही हो सकता है।

@lafriks एक और सूत्र में उल्लेख करते हैं:

स्व-होस्टेड को अतिरिक्त वर्चुअल मशीन के भुगतान के लिए शायद अतिरिक्त धन/प्रायोजन की आवश्यकता होगी

मुझे विश्वास है कि गीता होस्टिंग को स्वयं संभव बनाने के लिए समुदाय से धन या संगठनों से प्रायोजन होगा। चूंकि गीता संसाधन के अनुकूल है (हां, गिटलैब, मैं आपको देख रहा हूं) यह कोई बड़ी बात नहीं होगी।

@mxmehl अब तक 5 व्यक्तियों ने योगदान दिया है क्योंकि पिछले महीने ओपनकोलेक्टिव खुला था: https://opencollective.com/gitea

@justinclift के रूप में गीता पूरी तरह से संचालित के लिए समुदाय है, कोई रास्ता नहीं है जिससे हम भुगतान किए गए निजी भंडार स्थापित कर सकें क्योंकि इसके लिए कंपनी बनाने, करों से निपटने और तकनीकी समस्याओं से निपटने के लिए पूर्णकालिक कर्मचारी की आवश्यकता होती है।

@mxmehl अब तक 5 व्यक्तियों ने योगदान दिया है क्योंकि पिछले महीने ओपनकोलेक्टिव खुला था: https://opencollective.com/gitea

@techknowlogic इस पेज को नहीं जानता था। अब यह 6 है;)

खुद को प्रबंधित करने के लिए ठीक है जो लगता है, वित्तीय मामलों, बातें वे, स्टाफ (जहां आवश्यक हो), और इतने पर के लिए भुगतान सहित - दोनों सॉफ्टवेयर और गैर सॉफ्टवेयर बातों के लिए - @lafriks खैर .... वहाँ के आसपास सामुदायिक परियोजनाओं कर रहे हैं।

कहा जा रहा है, इसे करने के लिए एक स्तर की इच्छाशक्ति की आवश्यकता होती है + इसे जारी रखें। किसी भी आवश्यक भूमिका में लोगों को भी अच्छे संरक्षक (भरोसेमंद, विश्वसनीय, जानकारीपूर्ण) होने की आवश्यकता है।

अगर कोई दिलचस्पी नहीं है, तो यह वैसे भी कहीं नहीं जाएगा। ठीक इसी तरह यदि कोई उपयुक्त "संरक्षक" प्रकारों पर सहमति नहीं हो सकती है।

ऊपर उल्लिखित ओपन कलेक्टिव लिंक से, ऐसा लगता है कि कुछ शुरुआती बीज जगह में हैं। यह दर्शाता है कि आस-पास ऐसे लोग हैं जिन्हें संरक्षक के रूप में ठीक माना जाता है। :मुस्कुराओ:

@justinclift मैं यह नहीं कह रहा हूं कि यह संभव नहीं है, लेकिन वर्तमान स्तर पर नहीं, लेकिन भविष्य में ऐसा हो सकता है। वर्तमान में कम से कम मैं नई गीता सुविधाओं को विकसित करने और दस्तावेज़ीकरण में सुधार करने पर बेहतर ध्यान केंद्रित करूंगा :) इसलिए इस लक्ष्य के लिए तेजी से आगे बढ़ने के लिए किसी भी मदद की बहुत सराहना की जाती है।

हे हे हे हे

कोई चिंता नहीं @lafriks। :मुस्कुराओ:

माइक्रोसॉफ्ट के साथ जिथब की शादी के बाद से पहला लक्ष्य गीता की मेजबानी गीता है। :)

मुझे लगता है कि इस मुद्दे को बंद करने से पहले केवल #2519 और #3748 को समीक्षा और विलय की आवश्यकता है।

@bkcsoft

"रिपॉजिटरी साइज लिमिट्स" जोड़ा गया क्योंकि हमारे पास सर्वर पर असीमित स्टोरेज नहीं है ...

सीमा के लिए मेरा प्रस्ताव:

• 0 संगठन
• 3 रिपोज
• 1GB/रेपो

मुझे लगता है, रेपो मात्रा सीमा के साथ, हम सभी उपयोगकर्ताओं के लिए केवल मौजूदा भंडारों के लिए फोर्क सेटिंग की अनुमति दे सकते हैं जो गीता टीम में नहीं हैं:

• 0 संगठन
• 3 रेपो (केवल कांटे की अनुमति दें)
• 1GB/रेपो

मुझे नहीं लगता कि कांटे की गिनती सीमित करने की आवश्यकता है, यह वैसे भी gitea org रिपॉजिटरी काउंट द्वारा सीमित होगा, इसलिए यह ठीक होना चाहिए।
रेपो आकार के लिए, हाँ, शायद कुछ सीमाएँ होनी चाहिए

हमें संगठन बनाना, रेपो बनाना सीमित करना चाहिए, इसलिए गीता द्वारा होस्ट किए गए गीता के लिए रेपो आकार सीमा एक आवश्यक मुद्दा नहीं है।

हम सेल्फ-होस्टिंग के लिए प्रीरेक सूची में #3134 और #4302 (पीआर और इश्यू बैकलिंक्स) जोड़ने पर विचार कर सकते हैं - शायद मैं अद्वितीय हूं, लेकिन जैसे ही हमने इससे अधिक जोड़ा, उन बैकलिंक्स के बिना हमारी अपनी छोटी सी गीता इंस्टाल बोझिल होने लगी। कुछ उपयोगकर्ता और मुद्दे। हम समस्या खोज के साथ उस पर काम करने में सक्षम हैं, लेकिन यह वैश्विक समस्या खोज (#2434/#3841) के बिना सीमित है।

@stevegt जबकि बैकलिंक्स होना अच्छा होगा, मैं उन्हें सेल्फ-होस्टिंग में जाने से नहीं

@bkcsoft मेला पर्याप्त - बस सोचा कि अगर मैं किसी भी प्राप्ति को ट्रिगर करता हूं तो मैं इसका उल्लेख करूंगा। हमारे स्थानीय मामले में, हम समस्या टिप्पणियों में मैन्युअल रूप से बैकलिंक्स को वर्कअराउंड के रूप में जोड़ने की आदत विकसित कर रहे हैं।

मैंने हाल ही में https://teahub.io के प्रयास के बारे में सुना

@jlelse No. Gitea, gita और मिरर को github, gitlab या teahub और आदि पर होस्ट करने के लिए एक स्टैंडअलोन सर्वर (यानी self.gita.io) स्थापित करेगा।

@lunny क्या हमें वास्तव में

@JonasFranzDEV मेरा मतलब पीआर के

मैं यहां टिप्पणी कर रहा हूं क्योंकि #4108 बंद है। जब गीता पैट्रियन (या पैट्रियन जैसा विकल्प) ऊपर जाता है, तो मुझे इसके बारे में जानने की जरूरत है। मैं योगदान दूंगा। मैं इस परियोजना को स्व-होस्ट और आगे विकसित देखना चाहता हूं। एक बार जब मैं अपने सभी रिपॉजिटरी को स्थानांतरित कर देता हूं तो मैं अब जीथब के साथ पैसा खर्च नहीं करूंगा, मैं उस मासिक को पैट्रियन को दूंगा।

@ryanburnette https://opencollective.com/gitea

@lunny विषय में 'अनुमोदन प्रणाली' की तरह दिखता है, शुरुआत को पार किया जा सकता है। (मुद्दों को क्रमशः बंद और विलय किया जा रहा है)?

@mjmlvp मुझे लगता है कि आप सही हैं। मैंने #996 #2519 को हटा दिया क्योंकि यह इस मुद्दे का खंड नहीं होना चाहिए। हम अपने विकास को होस्ट करने के लिए एक सर्वर स्थापित करेंगे।

इस पर कोई भी समाचार ?

हाँ, हमें अभी भी अनुमोदन सीमाएँ जोड़ने की आवश्यकता है और फिर हम स्व-होस्ट किए गए कोड में माइग्रेट कर सकते हैं

उसके लिए खुले मुद्दों को सूची में जोड़ना अच्छा होगा। फिलहाल ऐसा लगता है कि सभी जुड़े हुए मुद्दे और पीआर को बंद कर दिया गया है और विलय कर दिया गया है।

@skddc किया।

रिकार्ड के लिए

गीता सर्वर खोलें

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

किसी पर भरोसा नहीं। नियमित बैकअप बनाएं

@giteauser मैं यह देखने में विफल हूं कि यह कैसे प्रासंगिक है

@giteauser और यह स्वयं-होस्टिंग gitea विकास के बारे में है, ताकि gitea का विकास अब github पर न हो। मैं अभी भी यह देखने में विफल हूं कि यह कैसे प्रासंगिक है।

ओह, मैंने इन्हें गलत मुद्दे के लिए पोस्ट किया है, मुझे क्षमा करें।

इसलिए, हर आवश्यक सुविधा को अभी लागू किया जाना चाहिए। क्या हम एक नई रिलीज़ प्राप्त कर सकते हैं और पलायन कर सकते हैं?

ठीक है, हम गीता के विकास की मेजबानी के लिए एक गीता उदाहरण स्थापित करेंगे।

मुझे लगता है कि बैकअप डंप समस्या को ठीक करना और

यदि आप कुबेरनेट्स पर गीता को तैनात कर रहे हैं, तो मैं बैकअप और पुनर्स्थापना के लिए आर्क की सिफारिश कर सकता हूं।

सामान्यतया, बैकअप ऐसा नहीं लगता है कि यह स्वयं-होस्टिंग गीता विकास के लिए एक अवरुद्ध विषय होना चाहिए, क्योंकि हर किसी के पास आमतौर पर अलग-अलग बैकअप रणनीतियाँ/कार्यक्रम होते हैं, जो उनकी पसंद के प्लेटफॉर्म, परिनियोजन की विधि, मौजूदा टूल आदि पर निर्भर करता है। केवल उसी उदाहरण की उत्पादन तत्परता के लिए एक अवरुद्ध मुद्दा होना चाहिए।

@ max-wittig gita स्वयं-होस्टेड वेबसाइट कुछ सार्वजनिक क्लाउड प्रदाता पर चलेगी। वे आरडीएस सेवा और डेटाबेस बैकअप उपकरण और कुछ डिस्क बैकअप फ़ंक्शन प्रदान करेंगे ताकि बैकअप डंप कमांड एक निर्भरता समस्या न हो। डंप कमांड सिंगल-नोड गीता सेवा के लिए है। बेशक हमें उन मुद्दों को ठीक करना चाहिए।

@skddc यह एक दिलचस्प टूल है जिस पर हम विचार कर सकते हैं।

मैं वास्तव में आशा करता हूं कि 1.8.0 रिलीज वह संस्करण होगा जहां गीता स्वयं होस्ट की जाती है। मैं व्यक्तिगत रूप से इसे अपनी परियोजनाओं के लिए उपयोग करना पसंद करूंगा, लेकिन मैं केवल गीता को दर्पण के रूप में उपयोग कर रहा हूं, क्योंकि मैं इस पर पर्याप्त भरोसा नहीं करता हूं यदि देव - आप लोग - इसका उपयोग गीता के विकास के लिए भी नहीं करते हैं। इसके अलावा, मैं अपने कामकाजी माहौल में गीता का उपयोग करने का प्रस्ताव देना चाहता हूं, लेकिन इसे प्रस्तावित भी नहीं कर सकता क्योंकि जब मैं कहता हूं तो मुझे हंसी आएगी: "ओह बीटीडब्ल्यू, यह बहुत अच्छा लग रहा है, लेकिन गीता के देवता इसका उपयोग नहीं करते हैं यह उनकी अपनी परियोजना के लिए "...

यह आलोचना के रूप में या आप लोगों को धक्का देने के तरीके के रूप में नहीं है। जब मैं मुख्य स्रोत कोड नियंत्रण प्रणाली के रूप में गिटिया का उपयोग करने की बात करता हूं तो बस आपको यह बताना कि मैं (और शायद बहुत से अन्य) को परेशानी होगी;)

अंत में, थोड़ा और रचनात्मक होने के लिए। यदि आप बैकअप के लिए या यहां तक ​​कि गिटिया को होस्ट करने के लिए एक बहुत अच्छे (और सस्ते) क्लॉस वीपीएस की तलाश कर रहे हैं, तो हेट्ज़नर पर एक नज़र डालें https://www.hetzner.com/storage/storage-box हालांकि एक महत्वपूर्ण बुनियादी ढांचे के लिए जैसे कि गीता आप शायद इसे दो पूरी तरह से अलग-अलग स्थानों पर बैक अप लेना चाहेंगे (उदाहरण के लिए हेट्ज़नर और डिजिटलोसियन कहें)।

@markg85 हम https://gita.com पर काम कर रहे हैं

gita.com पर gitea होस्टेड gita पर कोई अपडेट?

@zachdoty अभी भी उस पर काम कर रहे हैं।

मैं जीथब से गीता में जाने के लिए आवश्यक कुछ भूल गया। हमें सभी डेटा को स्थानांतरित करने की आवश्यकता है (गिट डेटा, मुद्दों, टिप्पणियों, जिथब से गिटिया तक पुल अनुरोध शामिल करें), लेकिन वास्तव में मुझे ऐसा करने के लिए उपयुक्त टूल नहीं मिला है। मैंने पीआर को फ्रंटएंड से बैकएंड तक माइग्रेट करने वाले रिपॉजिटरी को स्थानांतरित करने के बारे में भेजा है, #6200 देखें, और साथ ही https://gita.com/gitea/migrator को gitea में विलय कर दिया जाना चाहिए क्योंकि gita का API निर्दिष्ट इंडेक्स नंबर के साथ समस्या पैदा करने की अनुमति नहीं देगा।

gitea-github-migrator लगभग हर चीज को माइग्रेट कर सकता है, अगर आपको वह अभी तक नहीं मिला है। अगर कुछ गुम है, तो शायद इसे वहां जोड़ा जा सकता है, इसलिए अन्य परियोजनाओं में भी माइग्रेट करने के लिए एक अच्छा टूल है।

@skddc वे वास्तव में वही हैं।

आह क्षमा करें। लिंक का पालन नहीं किया था।

जैसा कि @kolaente ने कहा, हमने @jonasfranz को gitea-github-migrator को https://gitea.com/gitea/migrator/pulls/1 उसमें सुधार करना चाहता है। लेकिन मैंने तीसरे पक्ष के उपकरण के रूप में पाया, एक नुकसान है। यानी इश्यू इंडेक्स को पहले की तरह रखना मुश्किल है। (इस मुद्दे पर सभी लिंक अभी भी उपलब्ध होने के लिए।) तो मुझे लगता है कि माइग्रेट टूल को माइग्रेट यूआई पर गिटिया में मर्ज करना एक बेहतर विचार है।

अगर टिप्पणियों आदि में आंतरिक लिंक संरक्षित किए जा सकते हैं तो निश्चित रूप से बढ़िया होगा। यह भी बहुत अच्छा होगा यदि उसी रेपो से उत्पन्न होने वाले पीआर को मुद्दों के बजाय वास्तविक पीआर के रूप में आयात किया जा सकता है!

मैंने समस्या सामग्री पर नया कार्य Migrate a throughout github repository to gitea जोड़ा और इसे 1.9.0 पर स्थानांतरित कर दिया ताकि यह v1.8 की रिलीज़ को अवरुद्ध न करे। लेकिन मुझे नहीं लगता कि हमें v1.9 जारी होने तक इंतजार करना चाहिए क्योंकि gitea.com मास्टर का अनुसरण करेगा।

क्या Gita.com प्रोडक्शन तैयार है, क्या मुझे वहां कोड स्टोर करने और उसके खो जाने की चिंता करनी चाहिए?

@BNolet हमने रिपॉजिटरी को स्टोर करने के लिए 6 मशीन सेफ क्लस्टर स्थापित किया है। इसलिए इसे आसानी से खोना नहीं चाहिए क्योंकि सभी डेटा को 3 बार कॉपी किया जाएगा। हम सिफ मिरर के जरिए एक और बैकअप सेट अप करने पर काम कर रहे हैं। और चूंकि गिट वितरित किया जाता है। आपके कोड हमेशा आपकी या आपके सहयोगियों की डिस्क पर संग्रहीत होंगे।

वाह यह शानदार है! क्या आप सभी GitHub या Gitlab के पूर्ण विकल्प बनने में सक्षम होने का अनुमान लगाते हैं?

मुझे ऐसा नहीं लगता। gita.com का मुख्य लक्ष्य गीता के विकास को ही होस्ट करना है। हालांकि हमने gita.com पर कोई सीमा नहीं लगाई है, लेकिन हम आपको प्रोत्साहित करते हैं कि आप स्वयं को होस्टेड Gita इंस्टेंस सेट करें क्योंकि यह इतना आसान है।

OpenID साइन-इन सक्षम न करने का कोई कारण?

@ लूनी मेरे पास एक है और मुझे यह पसंद है: डी

इसकी कितनी संभावना है कि सीआई/सीडी उत्पाद गीता का हिस्सा बन जाए?

@strk बस इसे भूल जाओ। OpenID साइन-इन सक्षम करेगा।
@BNolet गीता स्वयं ड्रोन का उपयोग प्राथमिक CI/CD के रूप में करेगी।

जब मैं Github पर go-gita ऐप के लिए अनुमति अनुरोध पर जाता हूं, तो लॉगिन पृष्ठ पर Github oauth विकल्प का उपयोग करने का प्रयास करने पर 500 त्रुटि प्राप्त करना।

क्या मुझे फ्लैगशिप इंस्टेंस को देखने के लिए थोड़ा इंतजार करना चाहिए?

@jakimfett यह एक ज्ञात मुद्दा है। आप दो बार कोशिश कर सकते हैं और यह ठीक है।

@strk बस इसे भूल जाओ। OpenID साइन-इन सक्षम करेगा।

@ लुनी जैसा कि आज भी बंद था, क्या शायद एक तैनाती स्क्रिप्ट है जो इसे बंद कर देती है?

@jakimfett यह एक ज्ञात मुद्दा है ...

इश्यू नंबर के साथ एक संपादन करें और मैं वहां फॉलोअप करूंगा।

_संपादित करें: स्वरूपण_

कोडबर्ग एक मुफ्त गीता-आधारित सेवा है। शायद गीता वहां एक आधिकारिक दर्पण स्थापित कर सकती है। वर्तमान में इसे https://codeberg.org/Codeberg/gitea पर दिखाया गया है

गीता को https://gita.com/gitea/gitea पर होस्ट किया जाएगा, और हमने अधिकांश अन्य पैकेजों को https://gita.com/gitea पर स्थानांतरित कर दिया है, और gitea स्वयं प्रगति पर है। किसी अन्य गीता आधारित सेवा में आईना का स्वागत है।

@ लुनी ने कल टिप्पणी की:
किसी अन्य गीता आधारित सेवा में आईना का स्वागत है।

अपने सप्ताहांत से वापस आने के बाद मैं एक साथ अप-टू-डेट मिरर को हैक कर लूंगा।

सम्बंधित:
क्या कहीं दर्पणों की सूची है, और क्या मैं इसमें स्वयं को जोड़ूँ, या...?

@jakimfett ऐसा नहीं है, लेकिन आप एक नए दस्तावेज़ पृष्ठ के साथ एक जनसंपर्क बना सकते हैं

एक बेहतर उपयोगकर्ता हैंडलर के लिए जब gitea को github से माइग्रेट किया जाता है, तो मैं इसे v1.10 पर ले जाना चाहता हूं और मुझे लगता है कि हमें माइग्रेट करना शुरू करने से पहले https://github.com/go-gitea/gitea/issues/7293 लागू करना चाहिए।

मैं उस कदम के लिए पूरी तरह से होगा यदि इसे चीन में होस्ट नहीं किया गया था या सक्रियण ईमेल आने में 10 मिनट लग गए थे।

मैं उस कदम के लिए पूरी तरह से होगा यदि इसे चीन में होस्ट नहीं किया गया था या सक्रियण ईमेल आने में 10 मिनट लग गए थे।

संपादित करें: जाहिर है, मैं गलत था।

कुछ googling से, जाहिरा तौर पर gita.com का आईपी पता वास्तव में जापान में है, चीन में नहीं। हालांकि उस आईपी पते का स्वामित्व अलीबाबा के पास है।

हम मेल भेजने के लिए mailgun.org का उपयोग करते हैं। मुझे नहीं पता कि यह 10 मिनट क्यों बिताएगा।

हमारा दान क्लाउड प्रदाता दीदीयुन है जो चीन में है और यह कई मशीनें प्रदान करता है। हमारे पास फिलहाल कोई दूसरा विकल्प नहीं है।

और gitea.com का पहला उद्देश्य github.com या gitlab.com जैसी सेवा के रूप में नहीं होगा। यह केवल gita को ही होस्ट करेगा और हम अनुशंसा करते हैं कि आप वास्तव में स्वयं gita इंस्टेंस सेट करें।

@programmerjake यह एक ब्रिज सर्वर है।

मेरा इरादा अपने उदाहरण से दूर जाने का नहीं था, लेकिन मुझे यह पसंद नहीं है कि यह परियोजना एक चीनी कंपनी से दान किए गए बुनियादी ढांचे पर निर्भर है, जिसकी अतीत या खोज परिणामों में लगभग कोई प्रतिष्ठा नहीं है। आप वास्तव में नहीं जानते कि वे भविष्य में क्या करते हैं या यदि आप XY को लागू नहीं करते हैं या ZA करते हैं या यदि वे किसी दिन चले जाते हैं तो वे अपने दान में कटौती करने की मांग करते हैं।
आप शायद जानते हैं कि आप क्या कर रहे हैं और मेरी चिंता सिर्फ सतर्क रहने की है लेकिन आप कभी नहीं जान पाएंगे।

एक चीनी कंपनी ऐसा क्यों करेगी लेकिन एक अमेरिकी कंपनी ऐसा क्यों नहीं करेगी? :)

और मैं एक चीनी हूं, और शायद आपको सावधान रहना चाहिए। किसी दिन मैं आपके कोड चुरा सकता हूँ। :)

मुझे लगता है कि मेरे पास वह योजना हो सकती है जब मैंने 2014 में अन्य 3 चीनी लोगों के साथ गोग्स शुरू किया था।

मेरा इरादा अपने उदाहरण से दूर जाने का नहीं था, लेकिन मुझे यह पसंद नहीं है कि यह परियोजना एक चीनी कंपनी से दान किए गए बुनियादी ढांचे पर निर्भर है। आप वास्तव में नहीं जानते कि वे भविष्य में क्या करते हैं या यदि आप XY को लागू नहीं करते हैं या ZA करते हैं या यदि वे किसी दिन चले जाते हैं तो वे अपने दान में कटौती करने की मांग करते हैं।
आप शायद जानते हैं कि आप क्या कर रहे हैं और मेरी चिंता सिर्फ सतर्क रहने की है लेकिन आप कभी नहीं जान पाएंगे।

यह बिल्कुल मूर्खतापूर्ण जवाब है।
अब मैं और अधिक खुले विचारों वाला हो सकता हूं क्योंकि मैं डच हूं, हम इसे स्वीकार करते हैं। आपको भी इसे आजमाना चाहिए।

जब तक यह परियोजना खुला स्रोत है, मेरे विचार से आपके द्वारा कही गई किसी भी बात के लिए कोई जोखिम नहीं है।
और अगर वे ऐसा करते भी हैं, जिसका अर्थ शायद गीता को छोड़ना है, तो वे पूरी तरह से अपने अधिकार में हैं क्योंकि लाइसेंस इसकी अनुमति देता है।

हालांकि अमेरिका... मैं आपको याद दिला दूं कि अमेरिका और चीन के बीच "व्यापार युद्ध" के कारण जीथब ने अब अपनी सुविधाओं को सीमित कर दिया है। अगर कुछ भी हो, तो अमेरिका इस समय मुफ्त सॉफ्टवेयर विकास के लिए अधिक जोखिम वाला है, तो चीन कभी भी रहा है। हेक, @lunny शायद व्यापार युद्ध के कारण इस बहुत ही भंडार पर भी प्रभावित है।

@ लूनी और टीम गीता को विकसित कर रही है। मस्त काम करते रहो! :)

और gitea.com का पहला उद्देश्य github.com या gitlab.com जैसी सेवा के रूप में नहीं होगा। यह केवल gita को ही होस्ट करेगा और हम अनुशंसा करते हैं कि आप वास्तव में स्वयं gita इंस्टेंस सेट करें।

क्या ऐसा कुछ है जिस पर आप भविष्य में विचार कर सकते हैं?

जब तक यह परियोजना खुला स्रोत है, मेरे विचार से आपके द्वारा कही गई किसी भी बात के लिए कोई जोखिम नहीं है।

मुख्य परियोजना में कोई जोखिम नहीं है लेकिन बुनियादी ढांचा है। इस बात की कोई गारंटी नहीं है कि अज्ञात अप्रतिष्ठित दाता अगले महीने होगा चाहे वह कहीं से भी आए या चीन से। GitHub यहां लंबे समय तक रहेगा और इतनी जल्दी कहीं नहीं जाएगा।

साथ ही अगर पूरा बुनियादी ढांचा चीन में चला जाता है तो अमेरिका और चीन के बीच की कठिनाइयों के कारण पूरे उपयोगकर्ता आधार को नुकसान होगा।

@lunny ~ 10 मिनट लेने वाले ई-मेल के बारे में, मेरे मामले में मेरी कंपनी के सर्वर में एक एंटी-स्पैम उपाय है जो एक "कूल ऑफ" टाइमर (यहां 20 मिनट) है जिसके भीतर यह अज्ञात स्रोतों से किसी भी मेल को अस्थायी रूप से अस्वीकार कर देगा। इसलिए, यदि यह पहली बार है जब कोई उपयोगकर्ता (मुझे) उस डोमेन (जैसे gitea.com) से ई-मेल प्राप्त करता है, तो मेरा सर्वर "बाद में प्रयास करें" के साथ प्रतिक्रिया देगा और उस उपयोगकर्ता/डोमेन संयोजन को याद रखेगा। अगली बार जब gita.com मेरे मेल को अपेक्षित समय के भीतर डिलीवर करने का प्रयास करता है, तो सर्वर संदेश को स्वीकार कर लेता है।
जाहिर है कि हमारे पास कुछ "विश्वसनीय स्रोत" कॉन्फ़िगर किए गए हैं, जैसे जीमेल, हॉटमेल, आदि जिन्हें कूल-ऑफ अवधि की आवश्यकता नहीं है।

लोग, यदि आप चाहते हैं कि हर क्षेत्र के लिए और अधिक बुनियादी ढांचा फैले तो कृपया अपने वॉलेट के साथ https://opencollective.com/gitea पर वोट

@SuperSandro2000 क्या आप जानते हैं कि गीता एक सेवा नहीं बल्कि एक _उत्पाद_ है? आप स्रोत डाउनलोड करें, गीता को अपने सर्वर में संकलित करें और इसे स्थापित करें। गीता की मेजबानी के लिए किसी भी तरह के कनेक्शन की आवश्यकता नहीं है।

यदि वे अपने दान में कटौती करने की मांग करते हैं यदि आप XY लागू नहीं करते हैं या ZA करते हैं या यदि वे किसी दिन चले जाते हैं।

इस बात की कोई गारंटी नहीं है कि अज्ञात अप्रतिष्ठित दाता अगले महीने वहां होगा।

इस पर कुछ प्रतिक्रियाएँ: हम एक अप्रतिष्ठित कंपनी की मेजबानी नहीं करेंगे, और गीता लीड्स ने इस कंपनी पर हमारा भरोसा रखा है। यदि वे प्रायोजन प्रदान करना बंद कर देते हैं, या एक कंपनी बनना बंद कर देते हैं, तो हमारे पास विकल्प उपलब्ध हैं, और वे कहीं और जा सकते हैं।

अमेरिका और चीन के बीच की कठिनाइयों के कारण पूरे उपयोगकर्ता आधार को नुकसान होगा।

गीता टीम का एक बड़ा हिस्सा चीन से है (लेकिन हमारे पास अन्य सभी महाद्वीपों में भी अनुरक्षक हैं), और यदि विकास दल कोड का उपयोग नहीं कर सकता है, तो उपयोगकर्ता आधार को नुकसान होगा, यही कारण है कि हमें विकास टीम की आवश्यकता है ताकि हम इसका उपयोग कर सकें। कोड। हम गीता का निर्माण करते हैं ताकि हर कोई इसका उपयोग कर सके, यहां तक ​​कि जिन उपयोगकर्ताओं को गिटहब से प्रतिबंधित किया गया है (हाल ही में गिटहब से प्रतिबंध की लहर के बाद उनमें से बहुत से उपयोगकर्ताओं ने गीता का उपयोग करना शुरू कर दिया)।

जैसा कि अन्य ने उल्लेख किया है, दुनिया भर में अन्य उदाहरणों पर कोडबेस के दर्पण हैं, और गिट के लिए धन्यवाद कोड में किए गए सभी परिवर्तनों का एक खाता है ताकि सभी को सभी परिवर्तनों में दृश्यता हो सके।

पारदर्शिता पर एक नोट: मैंने इस धागे को बंद कर दिया है। मैं इस बातचीत को रोकना नहीं चाहता, हालांकि इसे एक अलग जगह पर ले जाया जाना चाहिए क्योंकि यह जीथब टिकट इस बारे में है कि स्वयं-होस्टिंग के लिए सॉफ़्टवेयर के साथ क्या सुधार करने की आवश्यकता है (बजाय जहां हम होस्ट कर रहे हैं)।