Mozilla Firefox कोड रिपॉज़िटरी Mercurial से GitHub पर स्थानांतरित

• Firefox ने हाल ही में अपने मुख्य रिपॉज़िटरी को Mercurial से GitHub पर स्थानांतरित किया है
• bug tracking के लिए Bugzilla, code review के लिए Phabricator, और CI के लिए Taskcluster का उपयोग जारी है
• फिलहाल GitHub केंद्रीय रिपॉज़िटरी है, लेकिन Mercurial सर्वर GitHub से sync होकर बनाए रखे जा रहे हैं, और मौजूदा automation सिस्टम भी धीरे-धीरे Git में बदले जाएंगे
• CI testing के लिए 'try' रिपॉज़िटरी अभी भी Mercurial आधारित है, लेकिन इसे धीरे-धीरे abstraction layer के पीछे छिपाया जा रहा है और आगे चलकर इसे Git में स्थानांतरित किया जाएगा
• Git को default रूप में इस्तेमाल कर पाने से नए contributors को अब Mercurial अलग से सीखने की जरूरत नहीं होगी, केवल Git जानना काफी होगा
  • पहले git cinnabar नाम का extension इंस्टॉल करना पड़ता था, लेकिन अब केवल standard Git ही पर्याप्त है
• Mercurial में मौजूद mozilla-central को Git में main branch में बदला गया है, और autoland branch Git में भी autoland ही रहेगी
• GitHub का PR-आधारित workflow फिलहाल अपनाया नहीं गया है, और यह बदलाव उसका हिस्सा नहीं है। भविष्य में संभावना खुली है, लेकिन कोई आधिकारिक योजना नहीं है
• GitHub पर जाने से Mozilla अपनी VCS infrastructure चलाने का बोझ कम कर सकता है
• बड़े प्रोजेक्ट के लिए जरूरी performance, reliability, और availability को खुद उपलब्ध कराने में लगने वाली लागत और जटिलता को कम करना इसका मुख्य लक्ष्य है

git-cinnabar के लेखक Glandium द्वारा लिखा गया विस्तृत इतिहास और विवरण: How I (kind of) killed Mercurial at Mozilla

> Mozilla ने Firefox code repository को GitHub पर ले जाकर Mercurial युग को समाप्त किया

• Mozilla ने Firefox development के केंद्रीय VCS को Mercurial से Git में बदलकर GitHub को आधिकारिक रिपॉज़िटरी बनाने का निर्णय लिया है
• इस निर्णय की नींव में git-cinnabar नामक extension tool का लंबा विकास और प्रसार था, जिसकी मदद से Git उपयोगकर्ता भी Mercurial रिपॉज़िटरी तक आसानी से पहुँच पाते थे
• Mercurial की branch संरचना की समस्याएँ, रिपॉज़िटरी का बढ़ता आकार, और अपने सर्वर चलाने का बोझ—इन सबके संयुक्त प्रभाव से अपनी infrastructure को बनाए रखना लगातार कठिन होता गया
• GitHub को चुनने पर विवाद भी है, लेकिन Mozilla के भीतर हजारों repositories पहले से GitHub पर मौजूद होने जैसी स्थितियों के कारण contributor friendliness और practicality के लिहाज़ से यह लगभग अनिवार्य विकल्प था
• git-cinnabar Mozilla की आंतरिक जरूरत से शुरू हुआ एक व्यक्तिगत side project था, लेकिन संक्रमण काल में भी इसके महत्वपूर्ण tool के रूप में बने रहने की संभावना है
  > “मैंने आग नहीं लगाई, लेकिन उस आग में तेल ज़रूर डाला।”

[GN⁺]

Hacker News टिप्पणियाँ

• मैं Mozilla में काम करता/करती हूँ, लेकिन VCS tooling या इस बदलाव में शामिल नहीं था/थी; बस थोड़ा अतिरिक्त संदर्भ देना चाहता/चाहती हूँ। Firefox कोड का आधिकारिक repository हाल ही में hg.mozilla.org के mercurial से GitHub पर स्थानांतरित किया गया है। इसका असर केवल कोड पर है; issue tracking अभी भी bugzilla पर, code review और landing अभी भी phabricator पर, और CI अभी भी taskcluster सिस्टम पर ही चल रहे हैं। अल्पकाल में mercurial server GitHub से sync हो रहा है ताकि automation सिस्टम धीरे-धीरे git backend पर जा सकें। mercurial अभी भी “try” repository में इस्तेमाल होता है, जहाँ WIP patch पर CI चलाया जाता है, लेकिन इसे धीरे-धीरे abstraction layer के पीछे छिपाया जा रहा है और बाद में इसे भी migrate किया जाएगा। पुराने repository के आदी लोगों के लिए “mozilla-central” को git के मानक branch नाम “main” से, और “autoland” को “autoland” branch से map किया गया है। पहले भी केवल git के साथ Firefox में योगदान देना संभव था, लेकिन उसके लिए git cinnabar extension इंस्टॉल करना पड़ता था। hg सीखना या git+extension इस्तेमाल करना—इन दोनों में से चुनना नए contributors के लिए एक प्रवेश-बाधा था, और ज़्यादातर लोग git जानते थे, mercurial नहीं। अब यह चिंता नहीं रही। git cinnabar के लेखक glandium ने migration की घोषणा के समय विस्तार से संदर्भ और कारणों पर ब्लॉग लिखा था। अल्पकाल में contributors के नज़रिये से लगभग कुछ नहीं बदलेगा। सामान्य git उपयोग अब default workflow बन गया है, उसके अलावा और कुछ नहीं बदला। आगे चलकर GitHub PR-आधारित workflow का समर्थन आ सकता है, लेकिन यह बदलाव उसका हिस्सा नहीं है। backend की तरफ, migration पूरा होने के बाद Mozilla अपने VCS infrastructure को चलाने में लगने वाला समय और मेहनत घटा सकेगा, और इस पैमाने के प्रोजेक्ट की performance और availability requirements पूरी करना काफ़ी चुनौतीपूर्ण है
  • निजी तौर पर मुझे लगता है कि Mozilla का Microsoft-owned बंद platform पर जाना सही फ़ैसला नहीं है
  • चूँकि Phabricator बंद हो चुका है, मैं जानना चाहूँगा/चाहूँगी कि उसके replacement की कोई योजना है या नहीं, जैसे Phorge पर विचार हो रहा है या नहीं
  • अतिरिक्त संदर्भ के लिए धन्यवाद। मैं जानना चाहूँगा/चाहूँगी कि self-hosted solution में मुख्य scale समस्याएँ क्या थीं
  • मैं पूछना चाहूँगा/चाहूँगी कि क्या GeckoView और Mozilla Android Components भी GitHub पर जा रहे हैं
  • यह खेदजनक है कि केवल कोड GitHub पर गया है, जबकि issue tracking bugzilla पर ही है। GitHub के बड़े फ़ायदों में से एक यह है कि बहुत से users के पास पहले से account होता है और वे platform से परिचित होते हैं, लेकिन अगर issues केवल bugzilla पर लिए जाएँगे तो bug report करना भी एक बाधा बन जाएगा। मैंने bugzilla और Firefox के ज़रिये macOS accessibility bug रिपोर्ट की थी, और site ढूँढना, signup करना, और उसे समझना काफ़ी असुविधाजनक था। आख़िरकार bug को verify किया गया, लेकिन ठीक नहीं किया गया
• Mozilla के strategic नज़रिये से यह समझ में आने वाला फ़ैसला लगता है। Google से मिलने वाली आमदनी कम हो सकती है और शायद staff भी घटाना पड़े, लेकिन अगर Firefox development जारी रखना है तो community की ज़्यादा भागीदारी चाहिए, और GitHub सबसे जाना-पहचाना developer platform है, इसलिए entry barrier कम होता है। GitHub के बजाय GitLab आदि का उपयोग न करने पर शिकायत हो सकती है, लेकिन Firefox development का जारी रहना और बाज़ार में competing engine का मौजूद रहना सबके लिए फ़ायदेमंद है
  • जो लोग GitHub इस्तेमाल नहीं कर सकते और इसलिए योगदान छोड़ देते हैं, वे आम तौर पर बहुत मूल्यवान contributors नहीं होते। अपवाद हो सकते हैं, लेकिन मैंने जिन non-trivial open source projects में सीधे भाग लिया है, उनमें ऐसा नहीं देखा। उल्टा, थोड़ा ऊँचा entry barrier low-quality one-off contributors को छाँटने का सकारात्मक असर भी ला सकता है
  • मैं gh और phabricator के संयोजन को समझ नहीं पाया/पाई, इसलिए Firefox में patch के रूप में योगदान देना पूरी तरह छोड़ दिया। मुझे समझ नहीं आया कि दोनों कैसे integrate होते हैं, और branch/PR को कैसे update करना है, इसलिए अंत में कोशिश ही छोड़ दी
  • GitLab के बारे में मेरे निजी अनुभव में, कुछ साल पहले GitLab ने यह काफ़ी स्पष्ट कर दिया था कि उसे बड़े open source projects की hosting में विशेष रुचि नहीं है, और FOSS के लिए उसका जवाब बस open source program तक सीमित था। यह प्रक्रिया जटिल है और इसमें अतिरिक्त requirements भी हैं, जिन्हें Mozilla के लिए स्वीकार करना मुश्किल होता। उदाहरण के लिए, GitLab उपयोग करने के लिए open source project को GitLab FOSS version को modify/fork करने का अधिकार छोड़ना पड़ता था, और यह किसी भी project के लिए गंभीर समस्या है। शायद किसी lawyer ने routine clause जोड़ दी हो, लेकिन सिर्फ़ यह बात ही दिखाती है कि यह बड़ा मुद्दा है। इसलिए GitLab बाहर हो जाता है। Codeberg वगैरह बचते हैं, लेकिन नए contributors के लिए entry barrier कम करना हो तो GitHub उपयुक्त है, जहाँ अधिकांश लोग पहले से registered हैं
  • GitHub की ओर यह बदलाव तकनीकी परिवर्तन है, लेकिन असली मूल बात mercurial से git की ओर जाना है, और संभव है कि social considerations ने तकनीकी निर्णय को प्रभावित किया हो
  • जो लोग entry barrier पार नहीं कर सकते, उन्हें सिर्फ़ bug report ही नहीं बल्कि code change भी नहीं करना चाहिए—मैं ऐसा सोचता/सोचती हूँ
• अच्छा लगा कि Firefox contribution में एक बड़ा technical debt हल हुआ। कुछ साल पहले जब मैंने कोशिश की थी, mercurial में repository clone होने में कई घंटे लगते थे, और official git support भी नहीं था, इसलिए ठीक से काम करने के लिए unofficial git support का इस्तेमाल करना पड़ता था। उस समय documentation भी बहुत ख़राब थी, जिससे बेवजह सब कुछ फिर से build करना पड़ता था
• मैं जानना चाहता/चाहती हूँ कि मौजूदा mozilla org के बजाय mozilla-firefox org क्यों चुना गया
  • शायद access rules अलग होने के कारण, या वे इसे मौजूदा org से अलग रखना चाहते थे ताकि automation का असर दूसरी जगहों तक न पहुँचे
  • मुझे भी लगता है कि यह सचमुच अच्छा सवाल है
• मैं जानना चाहता/चाहती हूँ कि “Firefox Moves to GitHub” का स्रोत क्या है। यह सिर्फ़ mirror भी हो सकता है। Linux का भी GitHub पर mirror है। (बाद में संपादन: स्रोत जोड़ा गया)
  • मेरी भी यही सोच थी। वास्तव में GitHub पर सेट किया गया workflow बस PR को एक default reply के साथ बंद करना है
• Firefox Mobile (Fenix) पहले GitHub इस्तेमाल करता था, फिर कुछ समय पहले Mozilla के mercurial mozilla-central repository में migrate किया गया था, और अब desktop और mobile दोनों version GitHub पर हैं, जबकि issues अभी भी bugzilla में हैं। इससे GitHub की बेहतर search, source browsing, और git की familiarity का लाभ मिल सकता है। Firefox और Thunderbird के पूर्व contributor के रूप में मैंने mozilla-central site search की तुलना में local search कहीं ज़्यादा इस्तेमाल की। development के दौरान तो IDE में search करते हैं, लेकिन site पर आसान search नए contributors के लिए स्वागतयोग्य चीज़ है
  • इसके उलट, मुझे लगता है कि searchfox अब तक का सबसे अच्छा code navigation tool है जो मैंने इस्तेमाल किया है। इसमें cross-language navigation, हमेशा चालू blame जैसी कई सुविधाएँ हैं, और यह GitHub से कहीं तेज़ और हल्का है। काश ऐसे tools और projects में इस्तेमाल हो पाते; इसके गायब होने का दुख होगा
  • मुझे लगता है कि GitHub की source browsing quality हाल में काफ़ी बिगड़ी है। async loading (js की ज़रूरत), network अस्थिर होने पर टूट जाना, और in-page search का ख़राब होना—ये सब समस्याएँ हैं। हाल की issues/PR redesign भी मुझे पीछे की ओर कदम लगती है, और uBlock Origin के साथ PR search काम नहीं करती
• बदलाव अच्छा लगता है, लेकिन मैं जानना चाहता/चाहती हूँ कि मौजूदा github.com/mozilla org के बजाय नया org क्यों बनाया गया
  • मुझे सटीक कारण नहीं पता, लेकिन कई मामलों में org के हिसाब से चीज़ों को अलग करना पड़ता है। उदाहरण के लिए, SSO पूरे org पर ही लागू होता है, इसलिए Firefox repo की authentication/user configuration Mozilla के मुख्य repo से पूरी तरह अलग हो सकती है
  • Mozilla के कई org हैं
  • शायद Conway’s Law की वजह से
  • GitHub में केवल org या repo स्तर होते हैं, उससे ऊपर का कोई स्तर नहीं। बहुत-सी settings—जैसे SSO, access permissions, common settings—org के हिसाब से लागू होती हैं, इसलिए आम तौर पर नया org बनाना साफ़ समाधान होता है, भले ही वह असुविधाजनक हो। (GitLab में एक ही instance या org के भीतर Firefox और बाकी चीज़ों के लिए namespace बनाए जा सकते थे)
• Mozilla जैसी संस्था का GitHub जैसी external hosting का उपयोग करना अजीब लगता है। छोटे one-person project के लिए तो समझ आता है, लेकिन contributors पर external service account थोपना user-friendly नहीं है
  • अगर यह open source project है, तो सबके लिए खुलापन, आसान contribution, और visibility देना सकारात्मक बात है—मैं ऐसा मानता/मानती हूँ
• मुझे जहाँ तक याद है, “master” branch ही mozilla-central थी। अब “main” और “autoland” हैं; मैं जानना चाहता/चाहती हूँ कि ये क्या हैं और पुरानी mozilla-central के बराबर कौन-सी branch है
  • मैं Firefox developer नहीं हूँ, लेकिन “main” mozilla-central के बराबर है, और “autoland” वह branch है जो पहले भी साथ मौजूद थी, जहाँ commits पहले पहुँचते हैं
• मैं चाहता/चाहती हूँ कि bugzilla कम-से-कम read-only रूप में बनी रहे। web एक “ad-hoc” तरीके से बनी हुई platform है, इसलिए अतीत के बहुत से कारण सिर्फ़ bugzilla में बचे हुए हैं। जो websites या browsers अब नहीं रहे, उनके कुछ व्यवहारों के कारण भी यहीं पता चल सकते हैं
  • bugzilla अभी भी Firefox का bug tracker है। इसे बदलने की कोई योजना नहीं है। (GitHub issues का उपयोग नहीं होता)
  • bugzilla शानदार था, और अपने समय से आगे का product था। मुझे आज भी उसी स्तर का self-hosted bug tracker नहीं दिखता