Gitea: फ़ेडरेशन के लिए तैयारी: "दूरस्थ" उपयोगकर्ता / फ़ेडरेटेड आईडी

यह वास्तव में इस बात पर निर्भर करता है कि फ़ेडरेटेड/बाहरी उपयोगकर्ता क्या करने में सक्षम होंगे, इस बारे में उपयोग के मामले क्या हैं। यदि वे भंडारों की मेजबानी नहीं कर सकते हैं, तो फ़ेडरेटेड उपयोगकर्ता तालिका और प्रदर्शन नाम, उपयोगकर्ता नाम इत्यादि को स्थानांतरित करना ठीक है। इसके माध्यम से कोड के हर हिस्से पर कुल पुनर्लेखन की आवश्यकता होगी जहां स्थानीय उपयोगकर्ता तालिका का उपयोग अब संघीय उपयोगकर्ता तालिका का उपयोग करने के लिए किया जाता है जो काम का नरक हो सकता है :)

मैं @lafriks से पूरी तरह सहमत हूं। इससे पहले कि हम ऐसा करना शुरू करें, हमें कुछ प्रश्नों को जानना होगा:

1. यह सुविधा कौन चाहता है? व्यक्तिगत gita उपयोगकर्ता / निजी gita वाली कंपनियाँ / gita या अन्य के माध्यम से Git होस्टिंग वेबसाइट?
2. उन्हें इस सुविधा की आवश्यकता क्यों है?
3. वे इस सुविधा का उपयोग कैसे करना चाहते हैं?

यदि वे भंडारों की मेजबानी नहीं कर सकते हैं, तो फ़ेडरेटेड उपयोगकर्ता तालिका और प्रदर्शन नाम, उपयोगकर्ता नाम इत्यादि को स्थानांतरित करना ठीक है।

फ़ेडरेटेड उपयोगकर्ताओं के पास रिपॉजिटरी हो सकती हैं, लेकिन उपयोगकर्ता के उदाहरण पर होस्ट की जाती हैं।
दूसरे शब्दों में, आपके पास न केवल फ़ेडरेटेड उपयोगकर्ता हैं, बल्कि फ़ेडरेटेड प्रोजेक्ट भी हैं (जिसमें रेपो, इश्यू, पीआर आदि शामिल हैं)। लेकिन यह इस मुद्दे के दायरे से बाहर है।

1. यह सुविधा कौन चाहता है? व्यक्तिगत gita उपयोगकर्ता / निजी gita वाली कंपनियाँ / gita या अन्य के माध्यम से Git होस्टिंग वेबसाइट?

मेरे जैसे लोग जिन्हें फ्री और ओपन सोर्स सॉफ्टवेयर के विकास के विचार को अच्छी तरह से केंद्रीकृत, गैर-मुक्त सेवाओं पर केंद्रीकृत किया जाना पसंद नहीं है। (गिटहब)

1. उन्हें इस सुविधा की आवश्यकता क्यों है?

जबकि गीता और गिटलैब जैसे नि: शुल्क विकल्प मौजूद हैं, उनके उदाहरण एक दूसरे से अलग हैं और इसलिए उपयोग के नुकसान हैं। (और नेटवर्क प्रभाव के अधीन हैं।)
भले ही मुझे डेबियन गिटलैब पर एक खाता बनाने के लिए प्रेरित किया गया हो, यह उस उदाहरण तक ही सीमित है।
सबसे खराब स्थिति में प्रत्येक परियोजना का अपना उदाहरण होता है और मेरे पास जांचने के लिए बहुत सारे खाते हैं। (हां ईमेल सूचनाएं हैं, लेकिन हम कुछ वेब चाहते हैं- अन्यथा गिट + एमएल भी पर्याप्त होगा।)

1. वे इस सुविधा का उपयोग कैसे करना चाहते हैं?

फ़ेडरेटेड सहयोग के लिए, GitHub के नेटवर्क प्रभाव को तोड़ना।

मेरे पास मेरे घरेलू उदाहरण पर 1 खाता है और मैं किसी भी परियोजना के साथ सहयोग कर सकता हूं जो संघ का समर्थन करता है (यानी ForgeFed )।

https://github.com/go-gitea/gitea/blob/7217b703e95a3ab01b69f91879fb4d6532f0b2c5/models/user.go#L94 -L97

क्या यह सही है

• Name उपयोगकर्ता नाम है ( criztovyl ) और
• FullName प्रदर्शन नाम है ("क्रिस्टोफ़ शुल्ज")

?

लेकिन LowerName का कारण क्या है? ( strings.ToLower(u.Name) )

SQL क्वेरी में lower(Name) का उपयोग न करने के लिए।

SQL क्वेरी में lower(Name) का उपयोग न करने के लिए।

लेकिन बिल्कुल क्यों? इसे बदलना नहीं चाहते, बस इसे समझें। :)

मैंने थोड़ा इधर-उधर करना शुरू कर दिया और मूर्खतापूर्ण तरीके से कुछ विशेषताओं को user.go (टाइप User ) से एक नए user_identity.go (टाइप Identity ) में स्थानांतरित कर दिया और कुछ कोड जोड़ा से AfterLoad जो पुरानी विशेषताओं को पहचान के मूल्यों से भर देता है।

बाद में मुझे माइग्रेशन लिखने में समस्या हुई जो User से Identity तक विशेषताओं को स्थानांतरित करता है। मैं मौजूदा माइग्रेशन और xorm डॉक्स का अध्ययन करके इस पर और गौर करूंगा, लेकिन कुछ और संकेतों के लिए वास्तव में खुशी होगी। :)

मैं अगली बार कुछ कमिट शेयर करूंगा।

लेकिन बिल्कुल क्यों? इसे बदलना नहीं चाहते, बस इसे समझें। :)

क्योंकि उपयोगकर्ता नाम केस असंवेदनशील है, और जब कोई उपयोगकर्ता https://try.gitea.io/AxIFiVe या https://try.gitea.io/Axifive जैसे अनुरोध भेजता है, तो उसे तुरंत अद्वितीय उपयोगकर्ता खोजने की आवश्यकता होती है, इसलिए हम केवल strings.ToLower(username) और एक साधारण SQL क्वेरी भेजता है।
चयन के लिए फ़ील्ड को लोअरकेस में कनवर्ट करना एक बहुत महंगा डीबी ऑपरेशन है, दूसरा फ़ील्ड जोड़ना बहुत आसान है।

मैंने कोड का वादा किया था।

मैंने अभी उस कोड को आगे बढ़ाया है जिसके साथ मैं संघर्ष कर रहा हूं, आप इसे यहां पा सकते हैं: https://github.com/criztovyl/gitea/blob/master/models/migrations/v200.go (200 मर्जिंग/रीबेसिंग को आसान बनाने के लिए)

लाइन 30, आइडेंटिटी मॉडल का सिंक, उम्मीद के मुताबिक काम करता है: टेबल बन जाती है।
लेकिन लाइन 35, उपयोगकर्ता मॉडल का सिंक, काम नहीं कर रहा है, तालिका में अभी भी पुराने कॉलम हैं।

Sync2 केवल कॉलम जोड़ेगा।

यदि आप उन स्तंभों को हटाना चाहते हैं जिनका आपको उपयोग करने की आवश्यकता है:

https://github.com/go-gitea/gitea/blob/80bfd5145c7b159ebdad3746efe11378b282fa86/models/migrations/migrations.go#L348

कृपया ध्यान दें कि माइग्रेशन मॉडल या अन्य जगहों की चीज़ों को संदर्भित नहीं करना चाहिए - जिन्हें भविष्य के माइग्रेशन में बदला जा सकता है। उन्हें पूरी तरह से आत्म-निहित होना चाहिए - अन्य गीता कोड का कोई संदर्भ नहीं।

इसलिए:

https://github.com/criztovyl/gitea/blob/2b4065f5ea0921090092b4a5ed61db3bdde2d725/models/migrations/v200.go#L30

यहां आपके पास वास्तव में पहचान की एक प्रति होनी चाहिए। इसी तरह यहाँ:

https://github.com/criztovyl/gitea/blob/2b4065f5ea0921090092b4a5ed61db3bdde2d725/models/migrations/v200.go#L14

यह संभवतः xorm: "-" होने का इरादा था, इस मामले में शायद माइग्रेशन में इसकी आवश्यकता नहीं है।

अपनी प्रस्तावित पहचान तालिका को देखते हुए आप इसके लिए login_source का उपयोग कैसे नहीं कर सकते?

संकेतों के लिए धन्यवाद :)

जहां तक ​​​​मैंने इसका विश्लेषण किया है, login_source के साथ समस्या यह है कि इसके लिए अभी भी उपयोगकर्ता नामों को अपने आप में अद्वितीय होना आवश्यक है।

संघ के लिए, उपयोगकर्ता नाम अद्वितीय नहीं हैं, केवल पहचान है (जहां ऐसी पहचान के लिए विशिष्ट पहचानकर्ता आमतौर पर एक यूआरआई/आईआरआई है); उपयोगकर्ता नाम एक और सीमित प्रदर्शन नाम की तरह हैं।

https://github.com/criztovyl/gitea/blob/2b4065f5ea0921090092b4a5ed61db3bdde2d725/models/migrations/v200.go#L14

यह संभवतः xorm: "-" होने का इरादा था, इस मामले में शायद माइग्रेशन में इसकी आवश्यकता नहीं है।

मैं देखता हूं, लेकिन IdentityId द्वारा संदर्भित पहचान कैसे भरी जाती है? क्या यह स्वचालित रूप से है या क्या मुझे इसे कहीं जोड़ने की ज़रूरत है?

और अगर मैं शुरू में तालिका बनाता हूं, तो मुझे अभी भी पहचान मॉडल की आवश्यकता है, इसलिए मैं इसे छोड़ नहीं सकता, है ना?

और एक और त्वरित प्रश्न; क्या गीता इंस्टेंस को चलाना संभव है जिसमें डीबी में फिक्स्चर से सभी टेस्टडेटा हैं?

मैं कभी-कभी दृश्य प्रकार का होता हूं। उदाहरण के लिए, क्या मैं सत्यापित करना चाहूंगा कि प्रोफ़ाइल अभी भी सही ढंग से प्रदर्शित है, उदाहरण के लिए सही संगठन असाइनमेंट है।

आप https://github.com/go-gitea/gitea/blob/master/contrib/pr/checkout.go पर एक नज़र डाल सकते हैं क्योंकि यह पीआर की जांच करने में हमारी मदद करने के लिए फिक्स्चर लोड करता है।

आप शायद एक संशोधित संस्करण बना सकते हैं।

go run -tags "sqlite sqlite_unlock_notify" contrib/pr/checkout.go -run आकर्षण की तरह काम करता है :)

हॉट कोड-रीलोड न होने के अलावा, लेकिन मुझे लगता है कि यह थोड़ा अधिक जटिल है: D

मैं @lafriks से पूरी तरह सहमत हूं। इससे पहले कि हम ऐसा करना शुरू करें, हमें कुछ प्रश्नों को जानना होगा:

1. Who wants this feature? Personal gitea user / Companies with private gitea / Git hosting website via gitea or others?

2. Why they need this feature?

3. How they want to use this feature?

निजी

व्यक्तिगत उपयोग, यह निश्चित रूप से बहुत अच्छी सुविधा होगी। मेरे पास एक उदाहरण है जहां मैं अपने भंडार, सार्वजनिक और निजी स्टोर करता हूं (सभी नहीं बल्कि बहुत कुछ)। यदि कोई उन पर सहयोग करना चाहता है, तो उन्हें मेरे उदाहरण पर एक उपयोगकर्ता प्राप्त करना होगा और यह उसी तरह से काम करता है, अगर मुझे गीता के उदाहरण पर कहीं कोई प्रोजेक्ट दिखाई देता है और मैं सहयोग करना चाहता हूं, जैसे कि कुछ ठीक करना या किसी सुविधा अनुरोध को हल करना, तो मैं वहां एक उपयोगकर्ता प्राप्त करना है या diff/ref-links के साथ एक पुल अनुरोध ईमेल भेजना है।

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

निगमित

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

दूसरी तरफ, मुझे लगता है कि यह करने के लिए बहुत काम होगा और मुझे यकीन नहीं है कि यह काम करेगा और उपयोगकर्ताओं को छोटे टुकड़ों में विभाजित कर सकता है कि वे इसका उपयोग कैसे करना चाहते हैं।

यह सुविधा कौन चाहता है? व्यक्तिगत gita उपयोगकर्ता / निजी gita वाली कंपनियाँ / gita या अन्य के माध्यम से Git होस्टिंग वेबसाइट?

एक व्यक्तिगत उपयोगकर्ता के रूप में…

उन्हें इस सुविधा की आवश्यकता क्यों है?

मैं सैकड़ों उदाहरणों पर खाता नहीं बनाना चाहता,

वे इस सुविधा का उपयोग कैसे करना चाहते हैं?

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

बीटीडब्ल्यू: एक बार के फिक्स वाले "न्यूनतम पीआर/एमआर" के लिए भी यही लागू होता है। तो संक्षेप में: अगर मैं एक परियोजना में "वास्तव में शामिल होने" की योजना नहीं बना रहा हूं, लेकिन फिर भी मेरे 2 सेंट का योगदान देता हूं।

मैं @lafriks से पूरी तरह सहमत हूं। इससे पहले कि हम ऐसा करना शुरू करें, हमें कुछ प्रश्नों को जानना होगा:

1. यह सुविधा कौन चाहता है? व्यक्तिगत gita उपयोगकर्ता / निजी gita वाली कंपनियाँ / gita या अन्य के माध्यम से Git होस्टिंग वेबसाइट?

मैं एक व्यक्तिगत गीता उपयोगकर्ता हूं जो @a1batross जैसे अन्य लोगों के साथ सहयोग करता है। हम दोनों के अपने-अपने गीता इंस्टेंस हैं, लेकिन मैं उनके किसी एक रिपॉजिटरी में कोड को आसानी से योगदान करने में सक्षम होना चाहता हूं, जैसे कि क्रॉस-इंस्टेंस पुल अनुरोध के साथ।

1. उन्हें इस सुविधा की आवश्यकता क्यों है?

दूसरे उदाहरण पर खाता बनाने की तुलना में बहुत आसान है - और इस तरह आपको दूसरों से कोड स्वीकार करने के लिए खुले पंजीकरण की आवश्यकता नहीं है। मुझे लाखों गीता खाते नहीं चाहिए।

1. वे इस सुविधा का उपयोग कैसे करना चाहते हैं?

मुख्य रूप से क्रॉस-इंस्टेंस पुल अनुरोध और मुद्दे। मैं यह भी चाहता हूं कि संगठनों में दूरस्थ उपयोगकर्ता शामिल हों (ताकि वे सीधे धक्का दे सकें)।

1. यह सुविधा कौन चाहता है? व्यक्तिगत gita उपयोगकर्ता / निजी gita वाली कंपनियाँ / gita या अन्य के माध्यम से Git होस्टिंग वेबसाइट?

व्यक्तिगत क्योंकि मुझे लगता है कि यह ज्यादातर उनके लिए सक्रिय खातों की संख्या को कम करने में मदद करेगा।

गिट होस्टिंग वेबसाइटें क्योंकि यह नेटवर्किंग प्रभाव को कम कर देगी और उन्हें एक समय में किसी समस्या की रिपोर्ट करने के लिए आने वाले प्रत्येक व्यक्ति के लिए खातों का विवरण संग्रहीत नहीं करना पड़ेगा।

1. उन्हें इस सुविधा की आवश्यकता क्यों है?

विदेशी परियोजनाओं में योगदान को आसान बनाने के लिए, आपको एक त्वरित समाधान करने की समस्या की रिपोर्ट करने के लिए एक खाता बनाने की आवश्यकता नहीं होगी।

1. वे इस सुविधा का उपयोग कैसे करना चाहते हैं?

मैं इसका उपयोग केवल एक गिट पहचान के लिए करना चाहता हूं, न कि विभिन्न स्थानों से जुड़े गिट भंडारों में एक टन खाते।

मैं वह सब करने में सक्षम होना चाहता हूं जो मैं वर्तमान में Gittea, GitHub और GitLab पर एक ही स्थान पर करता हूं। वह है मुद्दे, पुल/मर्ज अनुरोध, संगठन।

1. Who wants this feature? Personal gitea user / Companies with private gitea / Git hosting website via gitea or others?

निजी। अपना खुद का गिट सर्वर चलाने से मेरी परियोजनाएं छोटे बुनियादी ढांचे के कारण कम उपलब्ध होती हैं। Github/GitLab के साथ विकेंद्रीकरण और इंटरऑपरेबिलिटी होने से मेरी परियोजनाएँ सुलभ और अधिक उपलब्ध हो जाती हैं जैसे कि वे इन प्लेटफ़ॉर्म पर हों। मेरे सर्वर पर हर किसी के खाते होने की कोई आवश्यकता नहीं है, यह योगदानकर्ताओं के लिए और अधिक आकर्षक बनाता है।

2. Why they need this feature?

समेकि एकीकरण। उस इंटरफ़ेस का उपयोग करें जिसे आप अपनी पसंद की परियोजनाओं पर सहयोग करना चाहते हैं।

3. How they want to use this feature?

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

fr33domlover (फोर्जफेड टीम) से विविध फीडबैक की प्रतिलिपि बनाना:

वर्तमान स्थिति यह है कि गीता या गिटलैब या जीथू 8 आदि जैसे फोर्ज पर होस्ट किए गए रेपो के साथ बातचीत करने के लिए आपको वहां एक खाता होना चाहिए। प्रत्येक फोर्ज वेबसाइट एक अलग द्वीप है।

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

और githu8 मालिकाना और केंद्रीकृत है और लोगों द्वारा लोगों के लिए एक सामुदायिक परियोजना नहीं है।

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

उदाहरण:

• संगठनों/टीमों/समूहों में विभिन्न फोर्ज के उपयोगकर्ता शामिल हो सकते हैं
• आप अलग-अलग फोर्ज पर रेपो में कमिट्स को पुश कर सकते हैं
• आप मुद्दों को खोल सकते हैं, मर्ज अनुरोध खोल सकते हैं, टिप्पणी कर सकते हैं, कोड समीक्षा भेज सकते हैं, आदि
• रेपो, सीआई सर्वर, विकी, इश्यू ट्रैकर्स आदि विभिन्न सर्वरों पर हो सकते हैं और फिर भी एक साथ निर्बाध रूप से काम कर सकते हैं

1. वे इस सुविधा का उपयोग कैसे करना चाहते हैं?

दूसरों ने जो पहले ही उल्लेख किया है उसके अलावा: वेब पर सर्फिंग करते समय मुझे कई दिलचस्प परियोजनाओं का सामना करना पड़ता है जो उनके अपने उदाहरण गीता/गिटलैब इंस्टेंस पर मौजूद हैं। मैं अक्सर इन रेपो को केवल तारांकित करना चाहता हूं, लेकिन यहां (साइन अप) घर्षण बहुत अधिक है। इसके बजाय मैं उन्हें अपने ब्राउज़र में बुकमार्क करता हूं, और अधिकतर बाद में उन्हें जांचना भूल जाता हूं (बहुत सारे बुकमार्क)।

जीथब पर मैं स्टार्स को बुकमार्क करने के साधन के साथ-साथ परियोजना के लिए प्रशंसा के टोकन के रूप में उपयोग करता हूं। विशेष रुचि के प्रोजेक्ट मैं देखता हूं इसलिए मेरे पास गतिविधि पर नज़र रखने के आसान तरीके के रूप में मेरा नोटिफिकेशन डैशबोर्ड है।

सितारों का दुरुपयोग किया जा सकता है, लेकिन अगर एक जीथब रेपो में 14k सितारे हैं, तो यह इसकी लोकप्रियता के बारे में कुछ कहता है और मुझे यकीन है कि परियोजना उपयोगी और अच्छी गुणवत्ता की है। गीता/गिटलैब पर सितारे फिलहाल मुझे ज्यादा कुछ नहीं बताते हैं।

आदर्श रूप से भविष्य में मेरे पास एक है - मेरा अपना - विविध-जुड़ा हुआ स्थान जहां मेरे पास मेरी सभी कोडिंग गतिविधियों का अवलोकन है, चाहे मैंने उन्हें कहीं भी किया हो।

1. Who wants this feature? Personal gitea user / Companies with private gitea / Git hosting website via gitea or others?

मैं एक व्यक्तिगत-ईश गीता उपयोगकर्ता हूं
मेरे पास दो गीता उदाहरण हैं, एक मेरे कला समूह के लिए (जहां हम अपनी परियोजनाओं के लिए कोड रखते हैं), और दूसरा मेरे लिए (जहां मैं अपना व्यक्तिगत और अनुबंध कार्य करता हूं, और अपने छात्रों के साथ कुछ प्रोजेक्ट भी करता हूं)

2. Why they need this feature?

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

3. How they want to use this feature?

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

बहुत सारे अन्य उपयोगकर्ता जो कह रहे हैं, उसकी प्रतिध्वनि करते हुए, मैं लोगों को आसानी से अपनी परियोजनाओं में योगदान करने की अनुमति देना चाहता हूं, यहां तक ​​कि केवल केवल समस्याएं पैदा करने के लिए, मेरे सर्वर पर पंजीकरण खोले बिना, और मैं बनना चाहता हूं अधिक खाते बनाने की परेशानी के बिना मुद्दे बनाने या छोटे योगदान प्रदान करने में सक्षम
एक आदर्श दुनिया में, मेरे पास अब GitHub खाता नहीं होगा

1. Who wants this feature? Personal gitea user / Companies with private gitea / Git hosting website via gitea or others?

मैं सब 3.

1. मैं एक व्यक्तिगत गीता उपयोगकर्ता हूं (चालू और बंद, ज्यादातर बंद, भाग 2 का उत्तर देखें)।
2. मेरे डेजॉब में (एकाधिक!) आंतरिक/निजी गीता उदाहरण हैं।
3. अगर फोर्जफेड एक विकल्प था तो मैं गिटिया के माध्यम से एक निजी (यानी आमंत्रण-केवल) गिट होस्टिंग वेबसाइट प्रदान करने पर विचार करूंगा (जिसे मैं व्यक्तिगत रूप से भी उपयोग करूंगा)।

2. Why they need this feature?

एक निजी उपयोगकर्ता के रूप में:
अपने डेटा को जीथब, गिटलैब और "कहीं और" पर होस्ट करने के बीच का विकल्प एक गंभीर है।
अगर मैं जीथब/गिटलैब को चुनता हूं, तो मैं एक मंच के रूप में उनके फैसलों की दया पर हूं, और मेरे डेटा पर मेरा कोई नियंत्रण नहीं है।
अगर मैं कुछ और चुनता हूं (उदाहरण के लिए मेरा अपना गीता उदाहरण), तो परियोजना को खोजना मुश्किल है [1], और योगदान के लिए या तो अपना खाता होना चाहिए (इसलिए अब मैं एक वेबसाइट होस्ट हूं? यह अच्छा नहीं है) या ईमेल पर जाना मार्ग (जो प्रतिबंधात्मक है, हर कोई उस कार्यप्रवाह को पसंद नहीं करता है)।
फ़ेडरेशन के साथ (भले ही जाली न हो, लेकिन विभिन्न सेवाओं के बीच आदर्श रूप से इंटरऑपरेबल हो), मुझे दोनों दुनिया के सर्वश्रेष्ठ मिलते हैं - कोई भी अपने स्वयं के खातों का उपयोग करके किसी भी उदाहरण से योगदान कर सकता है, और मेरी किसी भी स्थानीय रूप से होस्ट की गई परियोजनाओं की खोज कर सकता है, जब तक मुझे मिलता है मेरे डेटा और प्लेटफॉर्म पर नियंत्रण रखें।

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

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

3. How they want to use this feature?

सारांश के रूप में / दोहराने के लिए:

एक निजी उपयोगकर्ता के रूप में (और उन उपयोगकर्ताओं के माध्यम से वेबसाइट होस्ट जो प्रभावी रूप से बस यही हैं):

• खोज के माध्यम से बाहरी परियोजनाओं को आसानी से खोजें (और अपनी खोज करने दें)
• किसी दिए गए प्रोजेक्ट में योगदान करने की अनुमति दें (समस्याओं की रिपोर्ट करना, टिप्पणी करना, आदि सहित) इसके उदाहरण पर खाता न होने पर

एक कॉर्पोरेट उपयोगकर्ता के रूप में:

• श्वेतसूची संघ:
  
  
  
  • विभिन्न-उद्देश्य वाले नोड्स के बीच आंतरिक संचार की अनुमति दें
  
  
  • हमारे नोड्स और विभिन्न सॉफ़्टवेयर भागीदारों के बीच शून्य-विश्वास और शून्य-विशेषाधिकार संचार की अनुमति दें
  
  

1. Who wants this feature? Personal gitea user / Companies with private gitea / Git hosting website via gitea or others?

मैं अपनी व्यक्तिगत गीता और काम पर इस्तेमाल होने वाली गीता दोनों के लिए करता हूं।

2. Why they need this feature?

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

3. How they want to use this feature?

मैं इसका उपयोग ओपन सोर्स और मालिकाना दोनों परियोजनाओं पर सहयोग करने के लिए करूंगा।

1. यह सुविधा कौन चाहता है? व्यक्तिगत gita उपयोगकर्ता / निजी gita वाली कंपनियाँ / gita या अन्य के माध्यम से Git होस्टिंग वेबसाइट?

व्यक्तिगत उपयोगकर्ता निश्चित रूप से।

1. उन्हें इस सुविधा की आवश्यकता क्यों है?

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

1. वे इस सुविधा का उपयोग कैसे करना चाहते हैं?

फेडरेशन उपर्युक्त मुद्दे को हल करता है, क्योंकि इससे कोई फर्क नहीं पड़ता कि उपयोगकर्ता किस उदाहरण या प्लेटफॉर्म पर है, वे केवल एक दूरस्थ परियोजना को खींच सकते हैं और अपने स्वयं के स्थानीय खाते का उपयोग करके अपने स्वयं के उदाहरण से इसमें योगदान कर सकते हैं।

किसी तरह GitHub ने मुझे यहाँ नई टिप्पणियों के बारे में कोई सूचना मेल नहीं भेजा, मैंने उन्हें पूरी तरह से याद किया।

वैसे भी, मैं पृष्ठभूमि में इधर-उधर खेलना जारी रखता हूं, अभी मैं xorm और उत्सुक लोडिंग से जूझ रहा हूं।

मेरे पास है:

type Identity struct {
  ID          int64 `xorm:"pk autoincr"`
  UserName    string
  DisplayName string
}

type User struct {
  ID          int64 `xorm:"pk autoincr"`
  Slug        string // LowerName
  IdentityId  int64 `xorm:"NOT NULL DEFAULT 0"`
  Identity    Identity `xorm:"-"`
}

मैं e.Get(&User{Slug: slug}) को Identity द्वारा दिए गए IdentityId ऑटो-लोड (?) कैसे

मुझे नहीं लगता कि यह काम करेगा। मुझे लगता है कि xorm केवल दूसरी तरफ ही कर सकता है, यानी यदि Identity में UserID कॉलम होता, तो xorm Identities में User Identities टुकड़ा भर सकता था।

यदि xorm पर्याप्त रूप से गोर्म के बराबर है तो आपको ऐसा करने के लिए पहचान कॉलम को प्रीलोड करने में सक्षम होना चाहिए। सामान्य एसक्यूएल में जो एक जॉइन होगा इसलिए http://gobook.io/read/gitea.com/xorm/manual-en-US/chapter-05/5.join.html मदद करनी चाहिए।

नमूना जैसा कुछ

engine.Table("user").Alias("u").
    Join("INNER", []string{"group", "g"}, "g.id = u.group_id").
    Join("INNER", "type", "type.id = u.type_id").
    Where("u.name like ?", "%"+name+"%").Find(&users, &User{Name:name})

डॉक्स के अनुसार चाल चलनी चाहिए।

हम्म, मेरी समस्या के लिए पहचान की सूची होने से मदद नहीं मिलती है।
और दुर्भाग्य से जॉइन-अप्रोच भी काम नहीं करता है।

मैंने कोडबेस में थोड़ा और देखा और पाया कि Repository में Owner *User जो मैन्युअल रूप से GetOwner फ़ंक्शन का उपयोग करके लोड किया गया लगता है, मैंने अपने कोड पर एक ही पैटर्न लागू किया है अभी। :)

इसलिए मैंने अपने स्थानीय भंडार को साफ किया, उपयोगकर्ता/पहचान विभाजन का एक मसौदा संस्करण तैयार किया और धक्का दिया जो स्थानीय उपयोगकर्ता प्रोफ़ाइल प्रदर्शित करने के लिए काम करता है, उदाहरण के लिए स्थानीयहोस्ट: 8080/उपयोगकर्ता 1। :) देखें https://github.com/criztovyl/gitea/commit/d0f24f7919d15ee481f5eae7ec6131ff369eaa66
अभी के लिए यह केवल उपयोगकर्ताओं के लिए काम करता है, संगठन अभी तक काम नहीं करते हैं।
यह ज्यादा नहीं है, लेकिन यह कुछ है। :)

संगठनों के पास मौजूद सभी मांस को खत्म करने के साथ, संगठन प्रोफाइल पेज अब भी काम करता है। देखें https://github.com/criztovyl/gitea/compare/d0f24f7...3901206bc।

मेरा कोड बल्कि शोषक है, यह कुछ भी अंतिम नहीं है। :)

उपयोगकर्ता तालिका में दो कॉलम क्यों न जोड़ें, is_local , और remote_url (शायद domain भी, हालांकि सभी gitea उदाहरण किसी विशिष्ट डोमेन के मुख्य फ़ोल्डर में होस्ट नहीं किए जाते हैं, इसलिए क्यों मैं romain_url )? इस तरह एक अतिरिक्त तालिका, और जुड़ने की आवश्यकता नहीं है।

यह पहली बार नहीं है जब किसी ने यह सुझाव दिया है, मैंने भी इसके बारे में सोचा था।
लेकिन मुझे डर है (एड) कि यह आसानी से गलती से केवल उपयोगकर्ता नाम से उपयोगकर्ता की तुलना कर सकता है, जो अमान्य है क्योंकि आपको (इस विशिष्ट मामले में) तीनों is_local , remote_url और username तुलना करनी चाहिए। remote_url और username तुलना करने के लिए अनुकूलित किया जा सकता है जब remote_url = "" अर्थ है is_local )।
एक और चिंता उपयोगकर्ता तालिका को बढ़ाना होगा और इसके साथ उदाहरण के लिए lower_name लिए सूचकांक, जिसे अब remote_url और lower_name एक संयुक्त सूचकांक होना चाहिए। (दूसरी ओर कोई भी केवल स्थानीय उपयोगकर्ताओं के लिए lower_name सेट कर सकता है ... हम्म।)

मैं लेख/पहचान-विभाजन पसंद करता हूं क्योंकि मुझे लगता है कि यह लागू करने के लिए क्लीनर है। (चूंकि पहचान एक नई अवधारणा है, यह केवल उपयोगकर्ता नामों की तुलना करने के लिए नहीं होनी चाहिए।)
लेकिन मुझे लगता है कि मुझे फिर से अपना मन बना लेना चाहिए, अब जब मैं देख सकता हूं कि विभाजन का परिचय कितना जटिल है। :)
मैं कभी-कभी थोड़ा भोला हूँ। ^^

@criztovyl ऐसे मामले हैं जहां remote_url या domain (sub domain) परिवर्तन हो सकते हैं, वे भी बदल सकते हैं

• https://mydownmain.com/gitea <--- शुरुआत में
• https://gita.mydownmain.com <--- उप डोमेन में ले जाया गया
• https://source.mydownmain.com <--- एक सामान्य नाम चाहता था
• https://git.mydownmain.com <--- अंत में सादगी चाहता था

जैसा कि आप जानते हैं कि चीजों का

निम्नलिखित को भी समझने का प्रयास करें

• उदाहरण के लिए यदि मैंने अपना डोमेन खो दिया तो क्या होगा? या कानूनी कारणों से नाम बदलना पड़ता है, या मैंने अभी अपना डोमेन बेचा है क्या इसका मतलब यह है कि मैं उन परियोजनाओं में योगदान नहीं कर पाऊंगा जिन पर मैं पहले काम कर रहा था?
• क्या यह username और email का उपयोग करने का समर्थन करेगा?
• जैसा कि आप जानते हैं कि मेरे पास अपना उपयोगकर्ता नाम बदलने या उपयोगकर्ता नाम के बजाय लॉगिन करने के लिए ईमेल का उपयोग करने का लचीलापन भी है, यह आपके द्वारा प्रस्तावित किए जा रहे कार्यों में कैसे फिट बैठता है

1. Who wants this feature? Personal gitea user / Companies with private gitea / Git hosting website via gitea or others?

हर कोई नस्लवाद का विरोध करता है, उदाहरण के लिए - 2019 से, गीथब, बिटबकेट और गिटलैब कथित भौगोलिक स्थिति के आधार पर उपयोगकर्ताओं को अवरुद्ध कर रहे हैं - https://archive.today/U1R2L । बीएलएम प्रदर्शनों की विशाल लहर के साथ, सॉफ्टवेयर समुदाय में नस्लवाद का समर्थन करने के लिए इतिहास में यह एक अच्छा क्षण नहीं है। मैं केवल https://codeberg.org पर गीता के उपयोगकर्ता के रूप में अपने नाम से बोल रहा हूं। इसे https://codeberg.org/Codeberg/Community/issues/142 के रूप में पोस्ट किया गया है, हालांकि मुझे लगता है कि इसे कोडबर्ग में एक स्वतंत्र मुद्दा बनना चाहिए। वहां की चर्चा कोडबर्ग में _some_ रुचि का सुझाव देती है।

2. Why they need this feature?

सुविधा के (की 2009) (वू 2018) । जीथब/बिटबकेट/गिटलैब के ऑनलाइन सोशल नेटवर्क कार्य अत्यंत शक्तिशाली हैं। '@' टाइप करें और कुछ अक्षर, और संभावना है कि आपको उस व्यक्ति की उपयोगकर्ता आईडी के लिए संकेत दिया जाए जिसे आप फ्री-सॉफ्टवेयर समुदाय के एक बड़े हिस्से के बीच चाहते हैं। यह कुशल, सार्वजनिक (डिफ़ॉल्ट रूप से) है, और पिंग वाला व्यक्ति अपने ईमेल बॉक्स को साफ किए बिना समस्या का जवाब दे सकता है या उसे अनदेखा कर सकता है।

लेकिन https://codeberg.org और अन्य गैर-नस्लवादी git रिपॉजिटरी सर्वर में अभी तक एक्टिविटीपब टाइप फेडरेशन नहीं है। यह एक कारण है कि जीथब के उपयोगकर्ताओं को समुदाय-आधारित सर्वर पर जाने से मना किया जाता है: सुविधा का अत्याचार_ यह है कि विश्व-व्यापी समुदाय में आसान सामाजिक कनेक्शन छोटे-समुदाय सर्वर पर मौजूद नहीं हैं - _yet_।

दूसरे शब्दों में, केंद्रीकृत, गुप्त, नस्लवादी (2019/2020 तक, ऊपर देखें) कॉर्पोरेट सर्वरों से स्वतंत्र सर्वरों में विद्वानों के पंचांग को संग्रहीत करने के लिए सुविधा की आवश्यकता है।

3. How they want to use this feature?

सोशल नेटवर्किंग के लिए विशेष रूप से सॉफ्टवेयर विकास पर (ज्यादातर फ्री-सॉफ्टवेयर) सॉफ्टवेयर डेवलपर्स के खुले समुदाय के बीच सॉफ्टवेयर विकास पर केंद्रित है।

इस थ्रेड को लॉक करना क्योंकि अब हमें उपरोक्त प्रश्नों के लिए बड़ी मात्रा में प्रतिक्रिया मिली है और अब जो कोई भी इस पर काम करने के लिए आगे बढ़ेगा, उसके पास यह जानकारी होगी कि वे पार्स कर सकते हैं।