Codeberg पर जाने के एक साल बाद Guix

• Guix ने 10 साल से अधिक समय तक Savannah और ईमेल-आधारित Debbugs पर चलने वाले सहयोग मॉडल को 2025 में Codeberg पर स्थानांतरित किया, जिससे हर साल 400 से अधिक प्रतिभागियों वाले प्रोजेक्ट के योगदान प्रवेश-बिंदु में बड़ा बदलाव आया
• यह बदलाव 2024 के दिसंबर में शुरू की गई Guix Consensus Document प्रक्रिया का पहला वास्तविक उपयोग था, और GCD 002 दो महीने की चर्चा के बाद 2025 के मई की शुरुआत में प्रभावी हुआ
• पुराना ईमेल वर्कफ़्लो Emacs, mumi, qa.guix.gnu.org जैसे टूल्स की वजह से अनुभवी योगदानकर्ताओं के लिए प्रभावी था, लेकिन 900 उत्तरों वाले सर्वे में इसे योगदानकर्ताओं के लिए अक्सर रुकावट बताया गया
• Codeberg पर जाने के बाद authors और नए authors की संख्या बढ़ी, लेकिन 2025 के जून की अस्थायी peak को छोड़ दें तो स्पष्ट Codeberg effect की पुष्टि करना मुश्किल है
• हर महीने 500 से अधिक pull requests खुल रही हैं और backlog बढ़ रहा है, इसलिए CI की कमी, हस्ताक्षर की अनिवार्यता, और review का बोझ कम करना Guix का अगला व्यावहारिक काम बना हुआ है

---

ईमेल-आधारित सहयोग से Codeberg की ओर

• Guix ने 2025 में source code hosting, issue tracking, pull requests को Codeberg पर स्थानांतरित किया
  • इससे पहले 10 साल से अधिक समय तक कोड Savannah पर होस्ट किया जाता था
  • bug reports और patches ईमेल से संभाले जाते थे और उन्हें Debbugs instance में ट्रैक किया जाता था
  • हर साल 400 से अधिक लोग कोड में योगदान करते थे, इसलिए यह बदलाव अपने आप में बड़ा था
• मौजूदा मुख्य योगदानकर्ता ईमेल वर्कफ़्लो के आदी थे, और Emacs के Debbugs package या उन्नत ईमेल clients के साथ कुशलता से काम करते थे
  • Debbugs जहां कुछ सौ लाइनों के Perl code और ईमेल standards व federation संरचना पर आधारित है, वहीं Forgejo जैसे web forges Go dependencies वाले कहीं बड़े सिस्टम हैं
• ईमेल प्रवाह के आसपास पहले से सहायक टूल्स भी मौजूद थे
  • mumi Debbugs के लिए web interface देता है
  • Quality Assurance service ईमेल patch series को अपने-आप Git branch पर लागू करता है और उस branch पर packages build करता है
• 2025 के जनवरी में जारी पहले user और contributor survey में 900 से अधिक लोगों ने जवाब दिया, और contributors ने ईमेल वर्कफ़्लो को योगदान की रुकावट के रूप में बार-बार बताया

GCD 002 के ज़रिए सहमति-आधारित निर्णय

• Guix में निर्णय लेने के लिए कोई “benevolent dictator” नहीं था, और 2024 के दिसंबर में Guix Consensus Document process शुरू की गई
• GCD प्रक्रिया का लक्ष्य साधारण voting से अधिक सहमति बनाना है
  • प्रस्ताव लिखने वाले को प्रतिभागियों के साथ मिलकर प्रस्ताव को समायोजित करना होता है
  • प्रतिभागियों को केवल विरोध करने के बजाय अपनी ज़रूरतें और उन्हें शामिल करने वाले ठोस बदलाव सुझाने होते हैं
  • अंतिम मसौदे में support, accept, disapprove से रुख दर्ज किया जाता है
• GCD 002 2025 के फरवरी में Codeberg migration proposal के रूप में जमा किया गया
  • चर्चा प्रक्रिया की अधिकतम अवधि यानी दो महीने तक चली
  • Guix टीम के दो-तिहाई सदस्यों ने विचार-विमर्श में हिस्सा लिया
  • प्रतिभागियों में 72% ने support और बाकी 28% ने accept चुना
  • disapprove किसी ने नहीं चुना, और प्रस्ताव 2025 के मई की शुरुआत में प्रभावी हो गया
• लंबे समय से योगदान देने वाले कुछ सदस्यों को web-first दिखने वाला वर्कफ़्लो ईमेल से कम प्रभावी लगा, और ईमेल-आधारित infrastructure के कुछ हिस्सों को छोड़ना भी उन्हें असहज लगा
• व्यापक community से संपर्क बढ़ने और developer experience बेहतर होने की संभावना ने इस बदलाव को समर्थन दिया
• free software आधारित forge और गैर-लाभकारी संस्था Codeberg e.V. द्वारा होस्ट की गई forge को पसंद किया जाना कोई बड़ी बहस का विषय नहीं बना, और यह Guix की दिशा से भी मेल खाता था

चरणबद्ध बदलाव और उम्मीद से बड़ा CI gap

• Codeberg migration, GCD सहमति के अनुसार, क्रमिक तरीके से की गई
  • मुख्य repository को 2025 के 25 मई को स्थानांतरित किया गया
  • पुरानी repository अभी भी mirror के रूप में बनी हुई है
  • मौजूदा issue और patch tracker को 1 जनवरी 2026 तक बनाए रखा जाएगा
  • इसके बाद केवल Codeberg issues और pull requests ही समर्थित तंत्र रहेंगे
  • पुराने bug reports और patches अब भी online उपलब्ध हैं
• सहमति चर्चा के दौरान बनाई गई योजना की वजह से migration के समय बड़ी समस्याएं या अप्रत्याशित स्थितियां कम रहीं
• Codeberg e.V. के कर्मचारियों और स्वयंसेवकों द्वारा दी गई service quality अच्छी रही, और बीच-बीच का downtime आम तौर पर छोटा और स्पष्ट रूप से घोषित था
• browser के बाहर वर्कफ़्लो पसंद करने वाले contributors के लिए Emacs interface में सुधार मददगार रहा
  • fj.el और Emacs-Forgejo आगे बढ़े
  • AGit workflow से pull requests बना पाना भी अनुकूलन का बोझ कम करता है
• जो समस्या पर्याप्त रूप से अनुमानित नहीं की गई थी, वह pull requests के लिए continuous integration थी
  • qa.guix.gnu.org पर ईमेल patches build करने वाली सुविधा को Codeberg पर port नहीं किया गया
  • कई महीनों तक reviewers को खुद जांचना पड़ा कि pull request कोई समस्या तो नहीं ला रही, और यह टिकाऊ स्थिति नहीं थी
• 2025 के सितंबर में Cuirass instance को pulls.ci.guix.gnu.org पर बनाया गया और उसने pull requests build करना शुरू किया
  • शुरुआत में इसे qa.guix.gnu.org की तुलना में अधिक सीमाओं वाला अंतरिम उपाय माना गया
  • अभी packages केवल एक architecture के लिए build किए जाते हैं
  • नए contributors guix-cuirass-bot द्वारा pull requests पर छोड़े गए success/failure results तुरंत देख सकते हैं

योगदान का प्रवाह बढ़ा, लेकिन backlog भी

• 2024 के मई से 2026 के मई तक main branch commits की संख्या के आधार पर देखें तो Guix की commit गति लगातार “high” और “very high” के बीच रही
• सिर्फ commit velocity से बदलाव साफ़ नहीं दिखता, इसलिए monthly commit authors, committers, और नए commit authors की संख्या ज़्यादा उपयोगी संकेतक बनती है
• monthly authors और नए authors की संख्या लगातार बढ़ी
  • Codeberg migration के तुरंत बाद, 2025 के जून में authors और नए authors दोनों की peak थी
  • बाकी अवधियों में वृद्धि 2025–2026 और 2024–2025, दोनों चरणों में लगभग समान रही
  • Guix नए contributors को लगातार आकर्षित करता रहा, लेकिन साफ़ Codeberg effect बड़ा नहीं था
• monthly committers की वृद्धि authors की वृद्धि से धीमी थी, जो यह संकेत दे सकती है कि committers अधिक मात्रा में contributions संभाल रहे हैं
• pull request data, Codeberg के Forgejo API से इकट्ठा किया गया
• हर महीने 500 से अधिक pull requests खुलती हैं और merge की गति भी ऊंची है, लेकिन यह incoming flow से थोड़ी कम है, इसलिए backlog लगातार बढ़ रहा है
  • अभी खुली pull requests कुल 6,459 में से लगभग 639 हैं, यानी करीब 10%
  • तुलना के लिए Nixpkgs में कुल 473k में से 12k pull requests खुली हैं, यानी लगभग 2.5%
  • Guix का backlog अत्यधिक friction या अपर्याप्त CI feedback की वजह से हो सकता है
• Guix में हर commit पर स्वीकृत committer के signature की ज़रूरत होती है
  • यह Nixpkgs सहित कई projects की तरह सिर्फ Merge बटन दबाने वाली प्रक्रिया नहीं है
  • merge करने वाले व्यक्ति पर बदलाव लागू करने और sign करने की ज़िम्मेदारी होती है
  • Guix ने developer convenience और user security के बीच software supply chain security को चुना है
  • इस लागत को कम किया जा सकता है या नहीं, यह अभी देखना बाकी है

Codeberg पर सहयोग अब अधिक दिखता है

• Codeberg migration के बाद project activity अधिक visible हो गई
• CI results सीधे pull requests के भीतर दिखाई देते हैं, इसलिए contributors उन्हें तुरंत देख सकते हैं
• Guix teams को Codeberg teams के रूप में लागू किया गया है
  • team scope को CODEOWNERS file में परिभाषित किया गया है
  • संबंधित क्षेत्र के ज़िम्मेदार लोगों को अपने-आप बुलाया जाता है
  • bot team-python जैसे labels लगाता है ताकि issues और pull requests को labels से filter किया जा सके
• उस label वाले issues पर team को notifications न मिलना एक असुविधा बनी हुई है
• issues और pull requests के बीच cross-reference, और milestones जैसी सुविधाएं भी सहयोग में मददगार दिखती हैं

बाकी infrastructure चुनौतियां और Codeberg के साथ रिश्ता

• Guix infrastructure को और मदद की ज़रूरत है
  • pulls.ci.guix.gnu.org की build performance बढ़ानी होगी
  • x86 के अलावा दूसरी architectures के builds भी संभव होना अच्छा होगा
  • Cuirass में कई सीमाएं हैं, जिनमें कुछ पर नियोजित 1.4.x series में काम हो रहा है
  • pulls.ci.guix.gnu.org अभी भी package-केंद्रित है, और उपयुक्त होने पर system tests भी चला पाना अच्छा होगा
• packager workflow में भी सुधार की गुंजाइश है
  • topic branches और world rebuild scheduling काफी हद तक उस bug tracker से बंधे हैं जो अब रिटायर हो रहा है
• Guix को यह भी देखना है कि वह Codeberg servers पर अत्यधिक लोड न डाले और repository storage usage पर नज़र रखे
  • Codeberg servers पर अत्यधिक लोड डालने की घटना पहले हो चुकी है
  • Guix का एक single fork, Codeberg के नए per-user 750MiB quota से ऊपर जा सकता है
• एक समाधान यह हो सकता है कि नए contributors से AGit workflow का उपयोग कर pull requests बनाने की मांग की जाए
  • AGit पहले से Guix contributors के बीच लोकप्रिय है
  • लेकिन कुछ लोग इसे आम और परिचित pull request workflow की तुलना में कम सहज मानते हैं और “downgrade” समझते हैं
  • Gentoo के उदाहरण की तरह “AGit fork” icon जोड़ने से discoverability बढ़ सकती है
• Guix Foundation ने आभार और समर्थन के संकेत के रूप में Codeberg e.V. का supporting member बनने के लिए vote किया
• Forgejo और उसे Guix में configure करने वाली service जोड़ने वाला pull request भी जमा किया गया
  • इससे Guix के भीतर declarative configuration और reproducible forge deployment की दिशा खुलती है

[GN⁺]

Lobste.rs की राय

• Codeberg माइग्रेशन से जुड़े वास्तविक प्रोजेक्ट मेट्रिक्स देखना काफ़ी दिलचस्प है। व्यक्तिगत रूप से, मेरे पास GitHub छोड़ने की बहुत ज़्यादा वजहें हैं, इसलिए मैं चाहता हूँ कि Codeberg नया GitHub बने, लेकिन मैं अपने खुद के Forgejo सर्वर पर शिफ्ट हो गया हूँ और अभी Codeberg को अपने सभी रिपॉज़िटरी के बैकअप टार्गेट के रूप में इस्तेमाल कर रहा हूँ

  • बात अच्छे इरादे से कही गई थी, लेकिन मेरी राय में सब कुछ Codeberg पर केंद्रित होने के बजाय कई स्वतंत्र forge का ForgeFed के ज़रिए एक-दूसरे से संवाद करना बेहतर होगा
    किसी नए open source-केंद्रित हब की फिर से ज़रूरत नहीं है
  • अभी मुझे नहीं लगता कि Forgejo इस भूमिका को संभालने लायक पर्याप्त रूप से स्केल हुआ है। Codeberg की तरफ़ से जितना हो सकता है उतना किया जा रहा है, और उम्मीद है कि यह बेहतर होगा, लेकिन इसमें समय लगेगा
  • जो काम मैं निजी तौर पर करता हूँ, वह आखिरकार सब Fossil पर चला गया, और जिन चीज़ों को मैं दूसरों के साथ सार्वजनिक रूप से साझा करना चाहता हूँ, उनके लिए मैंने अपना खुद का Fossil सर्वर खड़ा किया है
    अब तक यह बहुत अच्छा रहा है, और मैं इसे git से साफ़ तौर पर ज़्यादा पसंद करता हूँ। आज के मानकों से देखें तो इसकी बाधा इतनी भी ऊँची नहीं है, हालाँकि

• Codeberg इस्तेमाल करना शुरू करने के बाद जो बात सच में परेशान करने वाली लगी, वह यह है कि git इंटीग्रेशन को ठीक से सपोर्ट करने वाले टूल लगभग नहीं हैं, और ज़्यादातर व्यवहार में सिर्फ GitHub / GitLab के लिए बने हैं

  • magit forge इस्तेमाल करने वालों के लिए तो यह रोने वाली बात है

• यह बात समझ में नहीं आती कि पुराने issue·patch tracker को 1 जनवरी 2026 तक बनाए रखकर उसके बाद सिर्फ Codeberg issues और pull requests को ही सपोर्ट किया जाएगा
  अगर काफ़ी योगदानकर्ताओं को यह नया तरीका पसंद नहीं है, तो फिर इसे ज़बरदस्ती क्यों बदला जा रहा है, समझ नहीं आता, और यह भी जानना दिलचस्प होगा कि कई workflows को अनुमति देने में कोई छिपी हुई लागत है या नहीं। यह सवाल बना रहता है कि सब पर एक ही तरीका क्यों थोपा जाना चाहिए
  छोटी-सी आपत्ति है, लेकिन ऐसा नहीं लगा था कि Codeberg में कई paid कर्मचारी हैं; मेरी जानकारी में सिर्फ एक ही था। संशोधन: कहा गया है कि पिछले दिसंबर में दूसरा कर्मचारी जोड़ा गया था