Bun सपोर्ट अब सीमित किया गया है और इसे deprecated करने की योजना है

• यह issue अभी भी Open स्थिति में है, और अगली yt-dlp तथा/या ejs रिलीज़ से Bun सपोर्ट की सीमा 1.2.11 या उससे ऊपर और 1.3.14 या उससे नीचे तक कर दी जाएगी, साथ ही इस सपोर्ट को deprecated करने की दिशा में ले जाया जाएगा
• yt-dlp, Bun को ejs के साथ संगत JavaScript runtime के रूप में इस्तेमाल करना जारी रखेगा, लेकिन यदि maintenance का बोझ बढ़ता है तो Bun सपोर्ट को पूरी तरह हटाने का अधिकार अपने पास रखेगा
• न्यूनतम समर्थित वर्शन पहले के 1.0.31 से बढ़ाकर 1.2.11 किया जाएगा, क्योंकि 1.2.0 से पहले के Bun पर ejs package build करने पर ejs lock file को नज़रअंदाज़ किया जाता है, जिसे हालिया npm supply-chain हमलों को देखते हुए बड़ा security concern माना गया है
• निचली सीमा 1.2.0 के बजाय 1.2.11 इसलिए रखी गई है क्योंकि 1.2.11 से पहले के Bun में ejs test suite चलाया नहीं जा सकता
• ऊपरी सीमा 1.3.14 तय की गई है, और इसका आधार यह बताया गया है कि यह मूल Zig codebase से built आख़िरी release थी
• यह भी कहा गया है कि Bun को हाल में Claude का उपयोग करते हुए Rust में rewrite किया गया है, और इसका development direction “पूरी तरह vibe-coded” होता दिख रहा है, जिससे आगे maintenance burden और reliability को लेकर सवाल उठते हैं
• एक comment में Deno को भी “vibe coded” बताया गया, लेकिन maintainer ने जवाब दिया कि Claude का उपयोग करना और Claude पर पूरी तरह निर्भर होना — इन दोनों में बड़ा अंतर है
• 1.3.4 से 1.3.14 तक के versions भी Anthropic अधिग्रहण के बाद “vibe coding” से प्रभावित हुए हो सकते हैं, इसलिए क्या उन्हें भी support से बाहर करना चाहिए — इस सवाल पर maintainer ने कहा कि वह इसकी समीक्षा करेंगे
• कुछ users ने इसका विरोध करते हुए कहा कि वास्तविक समस्या सामने आने से पहले ही नए Bun versions को चलने से रोकना बिना आधार की पूर्व-रोकथाम है, और warning या flag देकर उन्हें चलते रहने देना चाहिए
• दूसरे comment में समझाया गया कि --js-runtimes में Bun binary path सीधे दिया जा सकता है, इसलिए workaround के तौर on latest Bun सामान्य रूप से इस्तेमाल किया जा सकता है और yt-dlp के लिए अलग से static Bun 1.3.14 निर्दिष्ट किया जा सकता है
• संबंधित घोषणा के रूप में Node v20·v21 सपोर्ट बंद करने वाला issue और Deno की न्यूनतम समर्थित version को v2.3.0 तक बढ़ाने वाला issue भी जोड़े गए, और यह भी बताया गया कि EJS wiki document में अभी यह बदलाव परिलक्षित नहीं हुआ है
• maintainer ने Hacker News से आए comments को ध्यान में रखते हुए एक pinned comment छोड़ा, जिसमें कहा गया कि comment करने से पहले यह सोचें कि क्या आप वास्तव में yt-dlp में Bun इस्तेमाल करने से जुड़ी समस्या में रुचि रखते हैं

[GN⁺]

Hacker News की राय

• यह फ़ैसला समझ में आता है। अगर ज़्यादातर कोड मेंटेनर ने खुद नहीं लिखा है, तो codebase को ठीक से समझना मुश्किल ही होगा।
  पूरे rewritten code की समीक्षा करना भी व्यवहारिक रूप से असंभव है। वहाँ ठीक 10 लाख lines का कोड है https://github.com/oven-sh/bun/pull/30412

  • मेरा नहीं मानना कि Zig से Rust में बदल जाने से अचानक यह समझना बंद हो जाता है कि कोई file क्या रखती है, कैसे काम करती है, और दूसरी files से कैसे जुड़ती है।
    आखिरकार वही बात अलग syntax में लिखी गई है, और शायद Rust developers को यह देखने में अच्छा नहीं लगता। Bun developers शायद ऐसा code चाहते थे जो उन्हें परिचित लगे।
    फिर भी, मुझे लगता है इसे 2.0 कहना चाहिए था। तब यह इतनी हड़बड़ी जैसा भी नहीं लगता। 1.3.14 में भी कुछ regressions हैं, लेकिन अभी Rust से जुड़ी छोटी-छोटी आग इतनी ज़्यादा हैं कि कोई उस पर खास ध्यान नहीं दे रहा।
    बड़ी समस्या यह है कि Bun लगातार चमकदार नई features के पीछे भागता है और चीज़ों को अंत तक पूरा नहीं करता। testing में Vitest का अधिकांश हिस्सा है, पर सब नहीं; Jest का अधिकांश है, पर सब नहीं; pnpm का अधिकांश है, पर सब नहीं। अब image feature भी आ गया है, तो sharp का अधिकांश है, पर सब नहीं। dev server भी Vite का अधिकांश है, लेकिन फिर भी पूरा नहीं। लंबे समय तक चलने वाली processes Node जैसी तो हैं, लेकिन उनमें memory leaks हैं, और शायद यही Rust transition की वजह रही हो।
    image routines वाली पोस्ट पढ़कर मेरा मन बैठ गया। वह फिर एक और चमकदार लक्ष्य था, और testing bugs के साथ मिलकर आखिरकार मैं पूरी तरह Vitest पर चला गया
  • लगभग 20 लाख lines का Zig code लिखा जा सकता था, और उसमें शामिल वही test suite चलती रह सकती थी, लेकिन 10 लाख lines का Rust code review नहीं किया जा सकता—यह बात बहुत भरोसेमंद नहीं लगती।
    मुझे यकीन नहीं कि यह rewrite खुद में अच्छा विचार है और सफल होगा, लेकिन इसके उलट वाली दलील भी उतनी ही कमज़ोर लगती है
  • यह high-turnover corporate culture में काफ़ी आम है। आपको 10 साल पुराने, लाखों lines वाले codebase को “maintain” करने वाली टीम में डाल दिया जाता है, और टीम में सबसे पुराना व्यक्ति भी बस 1–2 साल पुराना होता है।
    उन 10 लाख से ज़्यादा lines का क्या काम है, यह किसी को नहीं पता। कोई भी उसे लगन से संभालता नहीं। requirements ली जाती हैं, और जिसे छूना ज़रूरी है उसके अलावा बाकी सबको black box मान लिया जाता है।
    इसलिए एक ही काम करने वाली 14 background service implementations, उसी भूमिका की 8 dependencies, 6 overlapping frameworks, और style व approach में पूरी असंगति पैदा हो जाती है। फिर भी किसी को ज़्यादा फ़र्क नहीं पड़ता
  • जिन काफ़ी बड़े codebases पर मैं अभी काम कर रहा हूँ, उनमें कुछ ऐसे भी हैं जिन्हें agentic tools से generate करने वाले लोग खुद भी उनकी कार्यप्रणाली लगभग नहीं समझते।
    यह शुद्ध “vibe coding” से बेहतर है, लेकिन अगर हिस्सा महत्वपूर्ण न हो तो ठीक है; सच में गहराई से सोचना पड़ने वाले core infrastructure में यह स्वीकार्य नहीं लगता
  • वे Windows भी support करते हैं, और Windows में अभी भी ऐसा code लाखों lines में है जो मौजूदा मेंटेनर ने नहीं लिखा

• यह किसी की नस्ल या धर्म के खिलाफ भेदभाव नहीं है। अगर कोई बड़े पैमाने पर vibe-coded surface area नहीं चाहता, तो क्या उसे इसके लिए सफाई देनी चाहिए?
  लगता है लोग भूल रहे हैं कि यह developer की “कलात्मक” स्वतंत्रता का हिस्सा है, और software में स्वाभाविक रूप से राय शामिल होती है

  • GitHub issue की कुछ पोस्ट देखकर लगता है, कुछ लोग इसे ऐसे ले रहे हैं जैसे उनके धर्म का अपमान हो गया हो
  • comments देखकर लगता है, बहुत लोग मान रहे हैं कि शीर्षक Bun खुद के बारे में है
  • हाँ। fork करके सिर्फ minimum version number बढ़ाना मुश्किल नहीं होना चाहिए। मैंने देखा नहीं है, लेकिन संभव है कि कहीं सिर्फ एक संख्या बदलनी पड़े।
    अगर वह काम कर रहा है तो करता रहेगा। बस वे इसे support और maintain नहीं करना चाहते और issues fix नहीं करना चाहते
  • इसे नस्ल या धर्म वाले भेदभाव जैसा भी कहा जा सकता है, इस अर्थ में कि यह मनमाने और अर्थहीन मानदंडों पर बाहर करना है।
    अगर Rust में port किया गया Bun हर मापने योग्य पहलू में बेहतर है, सारे tests pass करता है, performance बराबर या बेहतर है, और पुराने bugs भी ठीक हैं, तो यह क्यों मायने रखे कि वह किस language में लिखा गया है और कैसे implement हुआ? असली बात यह है कि quality ज़्यादा अच्छी है।
    अगर आप Bun team पर Rust version release और approve करने के बाद भी भरोसा नहीं करते, तो फिर 2 हफ्ते पहले वाले Zig version पर भरोसा क्यों था, यह भी तार्किक नहीं बैठता। yt-dlp developers तब मूर्ख लगते हैं

• मुझे Bun इस्तेमाल करना सच में बहुत पसंद है, इसलिए Anthropic acquisition के बाद दिशा का इस तरह बदलना थोड़ा दुखद है।
  मैं batteries-included वाला अच्छा Node चाहता हूँ, लेकिन यह नहीं चाहता कि वह vibe-coded हो

  • सोच रहा हूँ कि vibe-coded conversion की वजह से वास्तव में कोई बड़ी समस्या हुई भी है या नहीं।
    इसका मतलब यह नहीं कि मैं merge का समर्थन करता हूँ। मैं इस तरह की YOLO engineering approach के खिलाफ हूँ। बस घोषणा के बाद की खबरें नहीं देखीं, तो जानना चाहता हूँ कि transition कैसा चल रहा है
  • Bun team के मुताबिक, Anthropic acquisition से पहले ही यह कई महीनों से vibe coding के साथ चल रहा था
  • acquisition के समय लोगों को उम्मीद थी कि Bun लगभग पहले जैसा ही चलता रहेगा, और यह देखना काफ़ी विडंबनापूर्ण है कि वह उम्मीद पूरी तरह उलट गई और टूट गई।
    बेशक, मज़ेदार नहीं बल्कि बेहद दुखद अर्थ में विडंबनापूर्ण
  • अगर “vibe coding” की वजह से कोई ठोस समस्या साबित नहीं हुई है, तो बिना असली सबूत देखे उसे सीधे खारिज कर देना क्या उसी तरह की प्रतिक्रिया नहीं है जिसकी आलोचना की जा रही है?

• यह फ़ैसला engineering से ज़्यादा political judgment जैसा लगता है। क्या आपने Rust rewrite के बाद Bun में segmentation faults, out-of-memory, security vulnerabilities, या bugs बढ़ते देखे हैं?
  बेशक नहीं, क्योंकि rewrite अभी शामिल ही नहीं हुई है। यह ऐसा लगता है जैसे AI की भागीदारी का विचार ही बुरा लगा और उसी पर फ़ैसला कर लिया गया।
  engineering tools को मूड से नहीं, बल्कि इस आधार पर चुना जाता है कि वे इच्छित काम करते हैं या नहीं। अगर Bun में bugs बढ़ते हैं और वह खराब software लगे, तो मैं उसे नहीं इस्तेमाल करूँगा, लेकिन वह फ़ैसला data पर आधारित होगा। Jarred ने Bun के साथ बहुत प्रभावशाली काम किया है, और ऐसा नहीं लगता कि वह अपने quality bar से नीचे rewrite release करेगा, इसलिए मैं देखना चाहूँगा कि आगे क्या होता है

  • उल्टा देखें तो, Bun की नई development process segmentation faults, out-of-memory, या security vulnerabilities बढ़ाती है या नहीं, यह yt-dlp की तरफ़ से प्रयोग करके साबित करना उनका दायित्व नहीं है।
    अगर उन्हें वाजिब रूप से लगता है कि security vulnerabilities बढ़ सकती हैं, तो users पर प्रयोग करना लापरवाही भी माना जा सकता है।
    ज़िम्मेदार विकल्प ज़्यादा करीब यह है: “अभी main से कटे नए Bun release पर अपने software के execution को तुरंत support नहीं करेंगे।”
    हाँ, यह अफ़सोस की बात है कि यह भविष्य के releases का दोबारा मूल्यांकन करने की योजना नहीं, बल्कि आगे भी कभी support न करने के इरादे जैसा दिख रहा है। हालांकि yt-dlp developers किसी के ऋणी नहीं हैं
  • यह ज़रूरी नहीं कि राजनीतिक हो। yt-dlp शायद राजनीतिक ढंग से व्यवहार कर रहा हो, लेकिन core dependency को production में 6 महीने से 1 साल तक व्यापक उपयोग से पहले adopt न करने का सिद्धांत आम तौर पर राजनीति नहीं है।
    10 लाख lines की पूरी rewrite, उसी ABI के साथ भी, व्यवहार में लगभग एक नया runtime है, और कई downstream consumers के लिए इसे production dependency बनाना असुविधाजनक है।
    बहस के लिए मान लें कि Bun पूरी तरह इंसानों ने हाथ से दोबारा लिखा होता, तब भी स्थिति वही रहती। मुझे लगता है ऐसा फ़ैसला काफ़ी standard है, और व्यक्तिगत रूप से मुझे भी Bun की LLM rewrite quality शायद कुल मिलाकर अच्छी लगे, लेकिन मैं अपने product या company को इस पर दाँव नहीं लगाऊँगा। जोखिम भरे बदलाव मैं अपने software में खुद चुनना चाहता हूँ, किसी downstream dependency की वजह से मजबूरी में नहीं लेना चाहता
  • अगर आप segmentation faults, out-of-memory और दूसरी समस्याओं के बढ़ने का इंतज़ार करते हैं, तो तब तक आप समस्या से बचने में असफल हो चुके होंगे। मुझे यह दिशा सही लगती है, और इतिहास दिखाएगा कि कौन सही था
  • projects में governance बहुत महत्वपूर्ण है। Bun के authors का नए मालिकों के आगे झुकना यह दिखाता है कि उनकी प्राथमिकताएँ कहाँ हैं।
    मैं बैठकर यह इंतज़ार नहीं करूँगा कि bugs फूटें और सब कुछ टूटना शुरू हो जाए।
    अगर किसी project के लोग “tool काम करता है या नहीं” जैसी सोच से ही चुनते हैं, तो मैं उसे अपनी dependencies से हटा दूँगा
  • engineering के मूल तत्वों में से एक है मौजूदा trajectory का अनुमान लगाना। उस हिसाब से बुरा एहसास देने वाले tools से बचना पूरी तरह समझदारी है।
    जिस tool के train wreck बनने की आशंका हो, उससे दूर जाने का सबसे आसान समय integration से पहले होता है

• यह Rust conversion के बारे में है, लेकिन अभी release नहीं हुई है।
  वे “expected compatibility and security issues” कह रहे हैं, लेकिन Zig version वाला Bun भी काफ़ी crash होता है।
  अच्छा होता अगर yt-dlp यह link करता कि expected compatibility issues क्यों हैं, उसका ठोस आधार क्या है। दोनों projects के पास test suites हैं, तो आदर्श दुनिया में तेज rewrite संभव होनी चाहिए।
  शायद वे स्थिति को और भड़काना नहीं चाहते, लेकिन अगर उन्हें कोई ठोस समस्या मिली है, तो मैं उसे देखना चाहूँगा।
  Bun.rs को minor release नहीं बल्कि 1.4 या 2.0 होना चाहिए था, और alpha/beta releases भी होने चाहिए थे

  • अगर वास्तव में किसी project ने Bun.rs में गंभीर regressions दिखाने वाला data साझा किया होता, तो बात अलग होती।
    लेकिन इसे public हुए सिर्फ एक हफ्ता हुआ है, और अभी तक असली regression data लगभग नहीं दिख रहा। ज़्यादा यह “बस पसंद नहीं आया” वाली शिकायत जैसा लग रहा है

• यह तर्क कुछ हद तक ऐसा पढ़ाई देता है जैसे “libfoo अब vim की जगह emacs से develop होने लगा है, इसलिए अब उस पर भरोसा नहीं किया जा सकता।”
  बेशक यह बिल्कुल वही बात नहीं है, लेकिन कुछ हद तक ऐसा एहसास देता है।
  software में एकमात्र सच्चाई यह है कि मेरे use case में क्या यह काम करता है। AI से पहले भी यह पता नहीं होता था कि author ने सख़्ती से काम किया या बस random कोशिशें करता रहा जब तक कुछ चल न पड़ा।
  यानी मैंने methodology या इस्तेमाल किए गए tools की जाँच करके software का आकलन नहीं किया। मैंने ऐसे बहुत software इस्तेमाल किए हैं जिनके test suites नहीं थे या खराब थे, और memory safety पसंद करने वाले लोग भी C में लिखे tools इस्तेमाल करते हैं, और उल्टा भी।
  इसलिए “मुझे AI का इस्तेमाल करने का तरीका पसंद नहीं, इसलिए मैं इसे नहीं इस्तेमाल करूँगा” वाला तर्क उतना ही कमज़ोर लगता है जितना यह कहना कि author के editor पसंद नहीं आए इसलिए उपयोग बंद कर दिया

  • कुछ लोग सच में यह चिंता करते हैं कि चीज़ें किस तरह बनाई गईं, और उसी आधार पर तय करते हैं कि वे उस प्रक्रिया से सहमत हैं या नहीं।
    अगर ऐसा न होता, तो fair-trade chocolate/coffee जैसी अवधारणा भी मौजूद न होती
  • वह analogy कुछ ज़्यादा ही खींची हुई है। यह न एक ही मैदान है, न पास-पड़ोस का मैदान
  • तो एक कदम आगे चलते हैं: मान लें आपने हर महीने के पहले सोमवार को पूरे codebase को नई language में दोबारा लिखने वाला cron job लगा दिया—Rust से C++, फिर Go, Swift, और फिर वापस।
    क्या product इस्तेमाल करने वाले customers के लिए भी यह लगभग वही बात होगी जैसे किसी maintainer ने editor बदल लिया हो, यानी एक अप्रासंगिक विवरण?
  • ज़्यादातर लोग मानेंगे कि किस text editor का उपयोग हुआ, उसका लिखे गए code पर अर्थपूर्ण असर नहीं पड़ता।
    लेकिन LLM के बारे में यह बात बहुत कम लोग कहेंगे।
    vibe Bun पुरानी Bun जितनी अच्छी या उससे बेहतर हो सकती है, लेकिन अभी हम यह कैसे जानें?
    और यह कहना भी सही नहीं कि “हमें कभी पता नहीं होता था कि software सख़्ती से बना है या नहीं, इसलिए methodology से निर्णय नहीं लेते थे।” कुछ लोग किसी project को अपनाने या उसका उपयोग जारी रखने से पहले खुद यह जाँचते हैं कि उसमें स्वीकार्य स्तर की rigor है या नहीं। मैं भी महत्वपूर्ण चीज़ों में ऐसा ही करता हूँ।
    और अधिकतर लोग reputation signals का उपयोग करते हैं—वे perfect नहीं होते, लेकिन उनका कुछ correlation होता है, वे काफी हो सकते हैं, और सीधे manual review से कहीं आसान होते हैं

• development work में LLM के उपयोग के तरीके को समझाने के लिए नए शब्द की बहुत ज़रूरत है। “vibe coding” की एक सख़्त परिभाषा है, लेकिन लगता है किसी को परवाह नहीं।
  यह मानना सच में मुश्किल है कि Rust port पूरी तरह 100% “vibe” में ही किया गया था, जैसे मूल परिभाषा कहती है।
  यह सकारात्मक और नकारात्मक भावनाओं के मिले-जुले कीचड़ में बदल गया है, और अगर “vibe coding” को सामान्य LLM-usage slur की तरह इस्तेमाल किया जाए, तो असल समस्या क्या है यह समझना बहुत मुश्किल हो जाता है।
  मैं development में मदद के लिए LLM इस्तेमाल करता हूँ, और engineer जिन लगभग सभी metrics की परवाह करेंगे, उनमें मैं बेहतर काम ज़्यादा तेज़ी से कर रहा हूँ

  • vibe coding का मूल मतलब था “बस vibes के हवाले छोड़ देना [...] और यहाँ तक भूल जाना कि code नाम की कोई चीज़ मौजूद है”
    https://x.com/karpathy/status/1886192184808149383
    इस खास port के मामले में, यह इतनी तेज़ी से हुआ कि साफ़ लगता है इंसानों ने translation की validity verify नहीं की। आगे manual verification वास्तव में होगी भी या नहीं, यह भी स्पष्ट नहीं है।
    हालाँकि Dijkstra के मानदंड से देखें तो AI आने से बहुत पहले से ज़्यादातर software projects पहले ही “vibe coding” कर रहे थे—यानी vibes पर छोड़कर correctness के अस्तित्व को भूल जाना।
    जटिल code की correctness सुनिश्चित करना कठिन है, लेकिन अब जब data center के भीतर 100 करोड़ hackers का युग आ गया है, तो यह धीरे-धीरे वैकल्पिक चीज़ नहीं रह जाएगी।
    अतिरिक्त: “Bun के pre-release Rust port में 13,365 unsafe blocks हैं”
    https://news.ycombinator.com/item?id=48239790
  • यह दावा करने के विपरीत कि LLM से बेहतर काम तेज़ी से होता है, studies यह संकेत देती हैं कि यह तेज़ न भी हो सकता है, बल्कि धीमा भी हो सकता है।
    तकनीक इतनी नई है कि research कठिन है, लेकिन आशावादी नज़रिए से भी empirical evidence कुछ क्षेत्रों में बस करीब 3% improvement ही दिखाता है।
    code लिखना हमारे काम में अक्सर bottleneck नहीं होता

• समझ नहीं आता कि इतने लोग इस फ़ैसले से इतना दबाव क्यों महसूस कर रहे हैं। अगर आप सच में vibe coding के शौकीन हैं, तो बेहतर yt-dlp खुद vibe code कर सकते हैं या मौजूदा वाले को fork करके अपने हिसाब से बना सकते हैं, है न?

  • मैंने बहुत सुना है कि vibe coding की वजह से software बनाना इतना आसान हो गया है कि कोई भी इसे पल भर में बना सकता है।
    यहाँ तक कहा गया कि लोग हर काम के लिए one-off personal software vibe code करेंगे।
    अगर ऐसा है, तो vibe coders को किसी भी software decision पर शिकायत नहीं करनी चाहिए। अपनी पसंद का personal fork vibe code करना तो बच्चों का खेल होना चाहिए, है न? क्या यही vibe coding का वादा नहीं था?
  • ऊपर से yt-dlp में पहले से ही third-party interpreter plugins का support है। वे बस यह कह रहे हैं कि वे Bun को खुद support नहीं करना चाहते, और किसी दूसरे को अपनी पसंद की चीज़ इस्तेमाल करने देने का infrastructure पहले से मौजूद है।
    यह उस गलत entitlement का उदाहरण है जो लोग अक्सर ऐसे projects के प्रति महसूस करते हैं जिन्हें दूसरे लोग अपने समय और मेहनत से maintain करते हैं। अपनी मनचाही feature के लिए दूसरों के समय और श्रम को मनमाने ढंग से volunteer कर देना चाहना हमेशा चौंकाने वाला होता है।
    जो लोग काम कर रहे हैं, उन्हें फ़ैसला लेने का अधिकार है, और अगर पसंद न हो तो खुद fork कर लें। यह ecosystem शुरू से ऐसा ही रहा है।
    yt-dlp आज भी आश्चर्यजनक रूप से आसानी से छेड़छाड़ करने लायक है
  • बहुत से AI fans के लिए, सबके लिए नहीं लेकिन कई के लिए, यह लगभग धर्म जैसा काम करता है। वे यह कहकर संतुष्ट नहीं होते कि सब अपने-अपने रास्ते चलें और इतिहास तय करे कि software बनाने का कौन-सा तरीका बेहतर है; वे चाहते हैं कि हर कोई उनसे सहमत हो।
    मैं दफ़्तर में भी यही देख रहा हूँ, और AI के मामले में ईमानदार technical disagreement की अनुमति न होना सच में पागल कर देने वाला है

• मुझे समझ नहीं आता कि Bun rewrite के बारे में कैसा महसूस करूँ।
  एक तरफ़, codebase का अधिकांश हिस्सा review नहीं हुआ—यह बहुत डरावना लगता है।
  दूसरी तरफ़, सुनने में आया है कि यह लगभग बिना regressions के tests pass कर रहा है।
  शायद मुझे उस क्षेत्र का पर्याप्त अनुभव नहीं है, लेकिन मैं tests पर इतना भरोसा करके code पढ़े बिना पूरी तरह निर्भर नहीं हो पाता