एक सॉफ्टवेयर बग की परिभाषा। बर्फ़ीला तूफ़ान मनोरंजन करता है कि मेरा "बग" एक बग बिल्कुल नहीं है। क्या वे सही हैं? [बन्द है]


18

विकिपीडिया के अनुसार,

एक सॉफ्टवेयर बग एक कंप्यूटर प्रोग्राम या सिस्टम में एक त्रुटि, दोष, गलती, विफलता, या गलती का वर्णन करने के लिए उपयोग किया जाने वाला सामान्य शब्द है जो गलत या अप्रत्याशित परिणाम उत्पन्न करता है, या इसे अनपेक्षित तरीके से व्यवहार करने का कारण बनता है।

हाल ही में मैंने StarCraft 2 में एक "बग" पाया है जो एक अप्रत्याशित परिणाम उत्पन्न करता है: http://eu.battle.net/sc2/en/forum/topic/2868627470

समस्या यह है कि अगर मैं StarCraft 2 को लंबे समय तक कम से कम रखता हूं, तो गेम किसी भी प्रकार का टाइमआउट डिस्कनेक्ट या उत्पन्न नहीं करता है। हालांकि यह पहली लड़ाई के बाद डिस्कनेक्ट करता है और कभी-कभी गेम डेटा (मैच आँकड़े) भी खो देता है।

दुर्भाग्य से, बर्फ़ीला तूफ़ान के अनुसार:

खेल को इतनी लंबी अवधि के लिए कम से कम रखने के लिए डिज़ाइन नहीं किया गया है। (बर्फ़ीला तूफ़ान) इस तरह के व्यवहार को गलत नहीं मान सकता क्योंकि StarCraft II को घंटों तक कम से कम करने के लिए नहीं है।

तो, क्या मेरा "बग" वास्तव में एक बग है?


31
ज़रूर, इसकी बग, लेकिन वे इसे ठीक करने नहीं जा रहे हैं क्योंकि वे इस स्थिति को एक समर्थित नहीं मानते हैं (अर्थात चूंकि यह इस तरह से काम करने के लिए डिज़ाइन नहीं किया गया था, यदि आप इसे इस तरह से उपयोग करने की कोशिश करते हैं, तो आप अपने आप ह) हो। और निश्चित रूप से, एक साधारण काम है चारों ओर - ऐसा मत करो।
ऊद

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

29
@ Stargazer712 बर्फ़ीला तूफ़ान ने इसे ठीक से संभाला। उन्हें यह उम्मीद नहीं करनी चाहिए कि वे एक बग को ठीक कर देंगे, जिसका कोई इरादा नहीं है।
मैटलबेलर

3
TeleShoTTgun के लिए निष्पक्ष होने के लिए, मुझे लगता है कि बर्फ़ीला तूफ़ान को कम से कम "लंबी अवधि" के रूप में गिना जाना चाहिए। मैं कुछ मिनट के लिए बाथरूम जाने के लिए खेल को कम कर सकता हूं। मुझे नहीं लगता कि यह बहुत लंबा समय है लेकिन बर्फ़ीला तूफ़ान है? मैं इस संदर्भ में> 30 मिनट का समय "लंबी अवधि" मानूंगा, लेकिन मुझे नहीं पता कि क्या बर्फ़ीला तूफ़ान सहमत होगा।
FrustratedWithFormsDesigner

3
Old Vaudeville अधिनियम - "डॉक्टर, डॉक्टर, यह दर्द होता है जब मैं ऐसा करता हूं" - "ऐसा मत करो!"
साइक्लॉप्स

जवाबों:


58

सॉफ़्टवेयर टीम के लिए, बग एक सॉफ़्टवेयर समस्या है जिसे ठीक करने की आवश्यकता है। सभी सॉफ़्टवेयर समस्याओं को ठीक करने की आवश्यकता नहीं है।

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


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

2
@MattRyan: और वास्तविक दुनिया में (जो मैंने देखा है), यदि विशिष्टताओं में दोषपूर्ण व्यवहार होता है, जिसे व्यावसायिक उपयोगकर्ता "बग" कहते हैं, तो विकास टीम आमतौर पर समाधान को "परिवर्तन अनुरोध" के रूप में फिर से वर्गीकृत करती है, "बग फिक्स" के रूप में नहीं । ;)
FrustratedWithFormsDesigner

3
दूसरे शब्दों में, "बग" या "दोष" एक आवश्यकता का प्रतिनिधित्व करता है जिसे सही तरीके से लागू नहीं किया जाता है। इस मामले में, खेल को कम से कम छोड़ना एक आवश्यकता नहीं है।
रे

22

इस तरह की याद मुझे माइक्रोवेव में बिल्ली की याद दिलाती है , विशेष रूप से 1983 में श्रीमती स्मिथ के मामले में।

मुद्दा यह है, आप उत्पाद को इस तरह से काम करने की उम्मीद करते हैं। अधिकतर इसलिए कि इसी तरह के कई उत्पाद काम करते हैं, जैसे कि यदि आप उन्हें घंटों तक कम करते हैं और फिर उन्हें खोलते हैं, तो वे काम करते हैं (हालांकि यह विपरीत उतना असामान्य नहीं है जितना आप सोच सकते हैं)।

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

अब माइक्रोवेव के निर्माता के रूप में, आप माइक्रोवेव में एक हीटिंग कॉइल और सेंसर की संख्या रख सकते हैं। उत्तरार्द्ध यह निर्धारित करेगा कि क्या वर्तमान सामग्री एक बिल्ली है और माइक्रोवेव के बजाय कॉइल का उपयोग करें।

उसी तरह, कि कोई सूखी बिल्लियों के लिए उपयुक्त माइक्रोवेव का उत्पादन कर सकता है, ब्लिज़ार्ड SC2 का एक संस्करण बना सकता है जो विस्तारित अवधि के लिए न्यूनतम अवस्था में रहने के लिए उपयुक्त है।

व्यक्तिगत रूप से, मैं सिर्फ एक बिल्ली-सुखाने-सक्षम माइक्रोवेव के लिए और अधिक पैसा देने के लिए तैयार हूँ, यह मानकर (कि वहाँ एक बड़ी बिल्ली-सुखाने-उपयुक्तता-लोगो है, जिसे मैं गर्व से इंगित कर सकता हूँ)। लेकिन मैं एक ऐसे खेल की परवाह नहीं करूंगा जो घंटों तक कम से कम रह सके।

SC2 को कुछ आवश्यकताओं को पूरा करने के लिए डिज़ाइन किया गया था। आपकी उम्मीद उन लोगों का हिस्सा नहीं है। आप अपनी अपेक्षाओं के संबंध में SC2 को मापने के लिए स्वतंत्र हैं। लेकिन बर्फ़ीला तूफ़ान शामिल है या नहीं, यह सब उनकी आवश्यकताओं के दायरे में शामिल है और अंततः उनकी पसंद है।

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


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

11

मुझे लगता है कि यह सॉफ्टवेयर का एक मामला है जिसका उपयोग चश्मा द्वारा परिभाषित नहीं किया जा रहा है। वे कहते हैं

खेल को इतनी लंबी अवधि के लिए कम से कम रखने के लिए डिज़ाइन नहीं किया गया है।

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

तो नहीं, मुझे नहीं लगता कि यह वास्तव में एक बग है। मेरे कार्यालय में, इसे "उपयोगकर्ता प्रशिक्षण समस्या" कहा जाएगा (जो मैं कहूंगा कि यह एक संचार समस्या का एक रूप है, क्योंकि इस मामले में क्योंकि उपयोगकर्ता के लिए न्यूनतम-समय के लिए कोई अधिकतम अवधि संचारित नहीं हुई थी)। कार्यक्रम का ठीक से उपयोग नहीं करना। ऐसा नहीं है कि यह बर्फ़ीला तूफ़ान के लिए बहुत मदद करता है, जब तक कि वे इसे मैनुअल में नहीं डालते ...


3
मिशन-क्रिटिकल सिस्टम के लिए, हमारे पास एक आवश्यकता है जो कहती है कि "यह सिस्टम n घंटे के लिए चालू रहना चाहिए" और हम बाह्य रूप से परीक्षण और दस्तावेज़ करते हैं कि सिस्टम n घंटे के लिए संचालित होता है। हम आंतरिक रूप से दस्तावेज़ भी दे सकते हैं कि हमने m> n घंटे के लिए परीक्षण किया और सिस्टम अभी भी कार्य कर रहा है। एक गेम के लिए, जो महत्वपूर्ण मिशन नहीं है, आपको जरूरी नहीं कि यह औपचारिक रूप से बाहरी रूप से कब्जा कर लिया जाए, क्योंकि ज्यादातर लोग शायद इस मुद्दे का सामना कभी नहीं करेंगे।
थॉमस ओवेन्स

8

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

इस परिदृश्य में, सभी पर काम करने वाले खेल को अपरिभाषित व्यवहार के रूप में माना जा सकता है।


यह एक विशाल चकमा है। मैं इसे सुनकर हर बार घृणा करता हूं। क्योंकि यह तभी सामने आता है जब "युक्ति" अधूरी होती है।
शॉन मैकमिलन

2
@ सीनमेकिलन: इस तरह की चीजों के बिना, फीचर रेंगना हम सभी को मार देगा। किसी भी तरह से, यह एक चकमा नहीं है, क्योंकि यह एक ऐसा परिदृश्य है जो विशेष रूप से इंगित किया गया है कि समर्थित नहीं है।
स्टीवन एवर्स

1
@SnOrfus: यह बताया गया है। तथ्य के बाद। क्या आप वास्तव में मानते हैं कि कोई विनिर्देश स्पष्ट रूप से कहा गया है कि "x मिनट से अधिक समय तक आवेदन को कम से कम समर्थित नहीं है"? जाहिर है, यह एक बग है।
9

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

@ThomasX यह मानते हुए कि जिस परियोजना पर मैं चल रहा हूं, उसमें 200-400 पृष्ठ की कल्पना है, और वास्तव में रनटाइम से परिभाषित सीमाएं हैं। हां मैं करता हूं।
स्टीवन एवर्स

5

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

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


5

मैं यहां ज्यादातर लोगों से असहमत हूं।

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

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

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

वैसे भी, मैंने सोचा था कि अब तक जो पोस्ट किया गया है, उससे थोड़ा अलग जवाब दूंगा।


1
मैं वास्तव में लंबे समय तक स्क्रीन को कम कर दूंगा अगर मैं वास्तव में स्टारक्राफ्ट खेलता हूं। मुझे लगता है कि सवाल यह है कि क्या यह बग अप्रासंगिक है, लेकिन ऐसा लगता है कि इसे संभालना चाहिए और अगर यह नहीं हुआ तो यह वास्तव में मुझे बग देगा।
Psr

सहमत - यह एक बग के रूप में वर्गीकृत किया जाना चाहिए, सभी यह एक बहुत कम प्राथमिकता वाला होना चाहिए। हालांकि वे कह सकते हैं कि "खेल को कम से कम समय के लिए छोड़ना समर्थित नहीं है", क्या वास्तव में समय की लंबी अवधि का गठन होता है? उन्हें कैसे पता चलेगा कि 10 मिनट के लिए कम से कम एक ही मुद्दा नहीं होगा? बहुत कम से कम एक गेम टाइमआउट को डिज़ाइन और कार्यान्वित किया जाना चाहिए जो उपयोगकर्ता को डिस्कनेक्ट कर देता है यदि इसे ऐसे कार्यों का समर्थन करने का इरादा नहीं है तो इसे एक्स मिनट से अधिक के लिए कम से कम छोड़ दिया जाता है।
गेविन 24:05

4

बग को यथोचित रूप से "सॉफ़्टवेयर के इच्छित व्यवहार से कोई विचलन" के रूप में परिभाषित किया जा सकता है।

स्पष्ट रूप से वे (और यह उनका सॉफ्टवेयर है इसलिए उन्हें यह निर्धारित करना है कि इसे कैसे व्यवहार करना चाहिए) इस परिदृश्य को संभालने के लिए सॉफ़्टवेयर का इरादा कभी नहीं था, इसलिए यह बग की इस परिभाषा को पूरा नहीं करता है।

हालाँकि मैं जो कहूंगा वह बहुत कम से कम, उप-अपनाने का तरीका है जो इस स्थिति को संभाल रहा है।

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

तो सख्ती से बग नहीं है, लेकिन एक किनारे के मामले की खराब हैंडलिंग।

अगर मैंने कहा कि मैं ऐसा नहीं था, तो मैं निश्चित रूप से तय करने लायक समझूंगा (बहुत कम लाभ के लिए महंगा होना), हालांकि मैं भविष्य के संदर्भ के लिए टीम का उल्लेख कर सकता हूं कि यह कुछ ऐसा था जिसे उन्होंने बेहतर तरीके से संभाला होगा।


1

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

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

(एक तरफ के रूप में, यह दोनों तरीकों में कटौती करता है। एक ग्राहक के लिए जिसे बग फिक्स के लिए भुगतान नहीं करना पड़ता है, लेकिन नए विकास के लिए भुगतान करना पड़ता है "यह कुछ ऐसा फीचर नहीं करता है जो मैंने अभी सोचा था, लेकिन जो मैंने अब किया है तय किया गया कि 100% उन चीजों से निहित है जिनका मैंने उल्लेख किया "स्पष्ट रूप से एक बग है।"


क्या यह OpenBSD नहीं है जो किसी भी चीज़ को बग होने के लिए ठीक से दस्तावेज नहीं होने की घोषणा करता है, चाहे वह कुछ भी हो?
कैनाईकेक

1

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

कहा कि, लड़ाई के बाद डेटा खोना - यह बग हो सकता है। मैं Starcraft के बारे में ज्यादा नहीं जानता, लेकिन मुझे शक है कि डिजाइन से नहीं।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.