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

65

किसी भी सभ्य आकार की परियोजना के लिए बग ट्रैकर मेरे लिए एक नो-ब्रेनर की तरह लगता है - यह सैकड़ों या हजारों मुद्दों को व्यवस्थित करने के लिए आसान बनाता है, बिना मुद्दों के टकराए या मिलाए बिना।

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

Git - सामुदायिक पृष्ठ:

... इस मेलिंग सूची में बग रिपोर्ट भेजी जानी चाहिए।
डेबियन बग ट्रैकिंग सिस्टम , प्रति विकिपीडिया:

... इसकी अनूठी विशेषता यह है कि इसमें बग रिपोर्ट संपादित करने के लिए वेब-इंटरफ़ेस का कोई रूप नहीं है - सभी संशोधन ईमेल के माध्यम से किए जाते हैं।

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

तो वेब-आधारित बग ट्रैकर पर मेलिंग सूची के मुख्य लाभ क्या हैं? कुछ बड़ी परियोजनाएं केवल मेलिंग सूची का उपयोग क्यों करती हैं?

— naught101
स्रोत

2

हां, नहीं, मैं आपसे सहमत हूं, Git मेलिंग सूचियों का उपयोग करता है :) जो मैं कह रहा था कि आप इसे "कुछ वास्तव में बड़ी परियोजनाओं" के साथ जोड़ रहे हैं और मैं बस सोच रहा था कि यदि आप ऐसा करते हैं तो आपको थोड़ा और देना चाहिए उन बड़ी परियोजनाओं के लिए उदाहरण। अन्यथा सवाल नीचे आता है "Git मेलिंग सूची का उपयोग करता है, ऐसा क्यों है?" जो मामले में Jörg W Mittag का जवाब बेहतर है ...

— शिवन ड्रैगन

1

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

— naught101

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

— सेड्रिक मार्टिन

2

@CedricMartin: मुझे पता है, मैं सहमत हूँ। मेलिंग सूची बग ट्रैकिंग स्पष्ट रूप से कुछ टीमों के लिए पर्याप्त रूप से काम करती है, लेकिन यह अभी भी मेरे लिए बग ट्रैकर की तुलना में कम आसान है। हालांकि मैं सोच रहा था, कि कोर प्रोजेक्ट डेवलपर्स के लिए, अंतर बहुत छोटा लग सकता है: वे लगभग हर चीज का अनुसरण करते हैं जो वैसे भी चल रहा है। लेकिन नए लोगों के लिए, एक मेलिंग सूची को टटोलना लगभग असंभव है, इसलिए प्रोजेक्ट फिटनेस का कोई सरल अवलोकन नहीं किया जा सकता है। एक बग ट्रैकर नए उपयोगकर्ताओं / देवों को जल्दी से यह पता लगाने देता है कि कोई परियोजना कैसे चल रही है, और यह अंदाजा लगाएं कि कोर टीम द्वारा किस तरह के सुधारों को महत्वपूर्ण माना जाता है।

— n

ग्रेग क्रोहा-हार्टमैन का इस पर एक चर्चा है क्योंकि यह इस चर्चा के हिस्से के रूप में लिनक्स कर्नेल से संबंधित है । विशेष रूप से: "वहाँ कोई रास्ता

— n

45

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

4.7.2 --help

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

‘--help’विकल्प के आउटपुट के अंत के पास , बग रिपोर्ट , पैकेज के होम पेज (सामान्य रूप ‘http://www.gnu.org/software/pkg’से और जीएनयू कार्यक्रमों का उपयोग करने में मदद के लिए सामान्य पृष्ठ) के लिए ईमेल पता देने वाली लाइनें रखें । प्रारूप इस तरह होना चाहिए:
    Report bugs to: mailing-address
    pkg home page: <http://www.gnu.org/software/pkg/>
    General help using GNU software: <http://www.gnu.org/gethelp/>
अन्य उपयुक्त मेलिंग सूचियों और वेब पृष्ठों का उल्लेख करना ठीक है।

वरीयता के ऊपर, बदले में, इलेक्ट्रॉनिक संचार के रूप में ईमेल की सार्वभौमिक स्वीकृति को दर्शाता है। --helpऊपर दिए गए सुझाव जैसे किसी भी उपयोगकर्ता के संदेश को आसानी से समझा जा सकता है कि अगर वे बग देखते हैं तो क्या करना है - मेल करना आसान है।

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

एक परियोजना Bugzilla का उपयोग कर सकती है, एक और JIRA के साथ चिपकेगी , तीसरा ... GNATS , आदि आदि के साथ, यह सब "चिड़ियाघर" पेश करने का कोई तरीका नहीं है जो मानक और समान होगा

Report bugs to: mailing-address

ऊपर नोट का मतलब यह नहीं है कि परियोजनाओं को आंतरिक रूप से समस्या ट्रैकर का उपयोग नहीं करना चाहिए । जैसा कि संबंधित प्रश्न के उत्कृष्ट उत्तर में बताया गया है ,

आपका बग ट्रैकर आपकी सुविधा के लिए है, आपके ग्राहकों के लिए नहीं। ' यदि आप उनके फोन या ईमेल के मुद्दे को लेने और खुद को दर्ज करने के लिए परेशान नहीं हो सकते हैं, तो आपको कैसे लगता है कि वे कैसा महसूस करते हैं?

आपको समस्याओं को दर्ज करने और उन्हें क्लाइंट को मैन्युअल रूप से असाइन करने में सक्षम होने की आवश्यकता है ...

— कुटकी
स्रोत

3

बहुत बढ़िया जवाब! ईमेल, इश्यू ट्रैकर्स की तुलना में बेहतर है, और समझने में आसान है (जो हर किसी को "ईमेल" नहीं कहता है: P)

— एंड्रेस एफ।

21

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

— रॉस पैटरसन

@RossPatterson मैं यही सोच रहा था। लेकिन ऐसा लगता है कि यह वेब की तुलना में पुराना है, यह URL का एक गुच्छा होता है ...

— naught101

6

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

— n

1

@ naught101 यह वेब से पुराना नहीं हो सकता है, लेकिन यह निश्चित रूप से वेब-आधारित ट्रैकर्स से पुराना है

— sakisk

30

Git के साथ, विशेष रूप से, एक साधारण ऐतिहासिक कारण है: Git को लिनक्स हैकर्स के लिए Linux हैकर्स द्वारा शुरू किया गया था, और यह उसी विकास मॉडल और टूल का उपयोग करता है जैसा कि लिनक्स खुद करता है। लिनक्स, हालांकि, डब्ल्यूडब्ल्यूडब्ल्यू से पुराना है, इसलिए, जब लिनक्स शुरू किया गया था तो बस कोई वेब-आधारित मुद्दा ट्रैकर नहीं थे , क्योंकि कोई वेब नहीं था !

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

— जोर्ग डब्ल्यू मित्तग
स्रोत

3

मुझे लगा कि डब्ल्यूडब्ल्यूडब्ल्यू ने लिनक्स से पहले। थोड़ा। वे दोनों एक ही समय में और बहुत से लोगों के विभिन्न समूहों द्वारा किए गए थे; यह वास्तव में मध्य 90 के दशक तक नहीं था जो या तो बंद हो गया।

— डोनाल्ड फेलो

6

ठीक है, लेकिन लिनक्स कर्नेल में अब एक बग ट्रैकर है: bugzilla.kernel.org । स्पष्ट रूप से यह इतना बड़ा अवरोध नहीं है।

— naught101

7

-1 Git वेब से गंभीर रूप से छोटा है। विंटेज 2005. उस समय काफी सारे ट्रैकर्स जारी थे, जिसमें बुग्जिला भी शामिल था। लिनुस सिर्फ मुद्दे ट्रैकर्स को पसंद नहीं करता है, और उसका शब्द उस वातावरण में कानून है।

— रॉस पैटरसन

6

@RossPatterson - उन्होंने कहा कि लिनक्स वेब से पुराना था, न कि गिट। मुझे नहीं लगता कि आपकी टिप्पणी एक डाउन वोट को सही ठहराती है, क्योंकि आपने मूल रूप से वही दोहराया है जो उसने कहा था।

— बीटगैमिट

2

@tjameson hindsight पर, आप सही कह रहे हैं। वापस तटस्थ है।

— रॉस पैटरसन

17

Git के लिए:

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

मेलिंग सूची की एक पोस्ट में , जूनियो सी हमानो (गिट के अनुचर) ने सारांशित किया कि क्यों उसे लगता है कि बग ट्रैकर बहुत उपयोगी नहीं है। मैं पूरी पोस्ट को शामिल नहीं करना चाहता (यह काफी लंबा है), लेकिन यह नीचे उबलता है:

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

— sleske
स्रोत

5

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

— TheLQ

1

@ THELQ: सच है। हालांकि, जाहिरा तौर पर यह एक जोखिम है कि कुछ परियोजनाएं लेने के लिए तैयार हैं। और निष्पक्ष होने के लिए, git बिना किसी ट्रैकर के भी सॉफ्टवेयर का काफी ठोस टुकड़ा है।

— साल्स्के

1

@ LQ: सभी ज्ञात बगों (और उनके संबंधित धागे) का उल्लेख करने वाला एक साधारण वेब पेज नहीं होगा? कुछ इसी तरह यह करने के लिए संग्रह धागे करने के लिए कि लिंक बिंदु को छोड़कर।

— हैलो वर्ल्ड

1

@ हेलोवर्ल्ड: ठीक है, यह एक सरल (सरल) मुद्दा ट्रैकर होगा। और एक मुद्दे पर नजर रखने वाले की तरह, किसी को इसे प्रबंधित करना होगा ...

— 7:17 पर sleske

क्या मेरे पास एक ईमेल की ऑफ़लाइन प्रतिलिपि प्राप्त करने का एक अच्छा तरीका है, जबकि मैं एक ग्राहक नहीं था, हालांकि?

— PSkocik

6

डेबियन एक बग ट्रैकर का उपयोग करता है, इसका डिफ़ॉल्ट इंटरफ़ेस ईमेल है। और यह सुविधाजनक है। वर्तमान डेबियन प्रोजेक्ट लीडर लुकास नुस्बाउम ने कुछ दिन पहले पोस्ट किया :

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

अंतिम भाग यहां एक हत्यारा सुविधा है - बस अपने स्थानीय मेल कतार में उन रिपोर्टों को पंक्तिबद्ध करें जब तक आप विमान से नहीं उतर गए!

— डोमिनिक जॉर्ज
स्रोत

4

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

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

— नमस्ते दुनिया
स्रोत

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

— gnat

धन्यवाद। लेकिन क्या यह एक पतन का औचित्य साबित करता है? इस उत्तर का मुख्य विषय एक एमएल के फायदे हैं, और यह मूल प्रश्न का उत्तर देता है। मैंने "वेब फ़ोरम" शेख़ी हटा दिया है।

— हैलो वर्ल्ड

2

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

— रोमन स्टार्कोव

6

सुधार: 25 साल के बच्चों को बाहर रखता है। हाल ही में मुझे पता चला कि उन मेलिंग सूची में कुछ वास्तविक परियोजनाओं में योगदान करने के लिए चीजें कैसे काम करती हैं । और मुझे इससे नफरत है !!

— सिरो सेंटिल्ली 新疆改造 iro i 事件 '

2

"प्रत्येक फोरम के लिए एक अलग खाता बनाने की आवश्यकता नहीं है।" - अक्सर स्पैम को रोकने के लिए आपको सूची में साइन अप करने की आवश्यकता होती है। लेकिन वह सभी ईमेल की सदस्यता लेता है। इसलिए आपको 'स्पैम' से सदस्यता लेने और चुनने की आवश्यकता है और आपको सीसी या टीओ में रखने के लिए अनुरोध जोड़ना होगा। बगज़िला की तुलना में यह बहुत अधिक है।

— मिकीज पीचोटका