फ़ीचर विवरण

• एक-पंक्ति सुविधा विवरण (रिलीज़ नोट के रूप में उपयोग किया जा सकता है):
• प्राथमिक संपर्क (असाइनी):
• जिम्मेदार एसआईजी:
• डिजाइन प्रस्ताव लिंक (सामुदायिक रेपो): https://github.com/kubernetes/community/issues/429
• समीक्षक (ओं) - (एलजीटीएम के लिए) अनुशंसा करते हैं कि 2+ समीक्षक (कोड-क्षेत्र OWNERS फ़ाइल से कम से कम एक) समीक्षा के लिए सहमत हों। कई कंपनियों के समीक्षकों को पसंद:
• अनुमोदक (एसआईजी/क्षेत्र से संभावित रूप से किस सुविधा से संबंधित है):
• फ़ीचर लक्ष्य (कौन सा लक्ष्य किस मील के पत्थर के बराबर है):
  
  
  
  • अल्फा रिलीज लक्ष्य (xy)
  
  
  • बीटा रिलीज़ लक्ष्य (xy)
  
  
  • स्थिर रिलीज लक्ष्य (xy)
  
  

######### पुराना टेम्प्लेट नीचे

विवरण

आईपीवीएस या एलवीएस एक कर्नेल सुविधा है जो 3 अलग-अलग तरीकों से प्रॉक्सी अनुरोध कर सकती है, डायरेक्ट रूटिंग मॉडल पसंदीदा मॉडल है।

प्रगति ट्रैकर

• [] अल्फा
  
  
  
  • [ ] मसौदा गुणवत्ता दस्तावेज़ लिखें और बनाए रखें
    
    
    
    
    
    • [ ] विकास के दौरान सुविधा के वांछित अनुभव के बारे में एक दस्तावेज़ अप-टू-डेट रखें और कोई व्यक्ति इस सुविधा को उसकी वर्तमान स्थिति में कैसे आज़मा सकता है। इसे अपनी नई सुविधा का README और कुबेरनेट्स रिलीज़ से पहले लिखे जाने वाले डॉक्स के लिए एक कंकाल के रूप में सोचें। Google Doc से लिंक पेस्ट करें: DOC-LINK
    
    
    
  
  
  • [ ] डिजाइन अनुमोदन
    
    
    
    
    
    • [x] डिजाइन प्रस्ताव। https://github.com/kubernetes/community/issues/429
    
    
    
    • [ ] तय करें कि इस फीचर के कोड को किस रेपो में चेक किया जाएगा। कोर कुबेरनेट्स रेपो में सब कुछ उतरने की जरूरत नहीं है। रेपो-नाम
    
    
    
    • [ ] प्रारंभिक एपीआई समीक्षा (यदि एपीआई)। शायद वही पीआर डिजाइन डॉक्टर के रूप में। पीआर-नंबर
    
    
    
    • कोई भी कोड जो एपीआई को बदलता है ( /pkg/apis/... )
    
    
    
    • सीसी @kubernetes/api
    
    
    
    • [ ] चरवाहे की पहचान करें (आपकी SIG लीड और/या [email protected] आपकी मदद करने में सक्षम होगी)। मेरा चरवाहा है: _बदलें। [email protected]_ (और/या जीएच हैंडल)
    
    
    
    • एक चरवाहा एक व्यक्ति है जो आपको रेपो में अपनी सुविधा प्राप्त करने की प्रक्रिया से परिचित कराने में मदद करेगा, समीक्षकों की पहचान करेगा और सुविधा पर प्रतिक्रिया प्रदान करेगा। वे _not_ (आवश्यक रूप से) सुविधा के कोड समीक्षक, या क्षेत्र के लिए तकनीकी नेतृत्व हैं।
    
    
    
    • चरवाहा _not_ कुबेरनेट्स-पीएम मीटिंग्स को दिखाने और/या संचार करने के लिए ज़िम्मेदार है यदि यह सुविधा रिलीज़ लक्ष्य बनाने के लिए ऑन-ट्रैक है। यह अभी भी आपकी जिम्मेदारी है।
    
    
    
    • [ ] द्वितीयक/बैकअप संपर्क बिंदु की पहचान करें। मेरा द्वितीयक संपर्क बिंदु है: _replace। [email protected]_ (और/या जीएच हैंडल)
    
    
    
  
  
  • [ ] लिखें (कोड + परीक्षण + डॉक्स) फिर उनका विलय करवाएं। सभी पीआर-नंबर
    
    
    
    
    
    • [] कोड को डिफ़ॉल्ट रूप से अक्षम करने की आवश्यकता है। कोड OWNERS . द्वारा सत्यापित
    
    
    
    • [] न्यूनतम परीक्षण
    
    
    
    • [] न्यूनतम दस्तावेज़
    
    
    
    • सीसी @kubernetes/docs डॉक्स पर पीआर
    
    
    
    • cc @kubernetes/feature-reviewers इस मुद्दे पर जाँच करने से पहले अनुमोदन प्राप्त करने के लिए
    
    
    
    • नया एपिस: डॉक्स रेपो में शब्दावली अनुभाग आइटम : Kubernetes/kubernetes.github.io
    
    
    
    • [ ] रिलीज़ नोट अपडेट करें
    
    
    
  
  
• [ ] बीटा
  
  
  
  • [] बीटा के लिए परीक्षण पर्याप्त है
  
  
  • [ ] ट्यूटोरियल के साथ यूजर डॉक्स
    
    
    
    
    
    • डॉक्स रेपो में अपडेटेड वॉकथ्रू / ट्यूटोरियल : Kubernetes/kubernetes.github.io
    
    
    
    • सीसी @kubernetes/docs डॉक्स पर पीआर
    
    
    
    • cc @kubernetes/feature-reviewers इस मुद्दे पर जाँच करने से पहले अनुमोदन प्राप्त करने के लिए
    
    
    
  
  
  • [] पूरी तरह से एपीआई समीक्षा
  
  
  • सीसी @kubernetes/api
  
  
• [ ] स्थिर
  
  
  
  • [ ] डॉक्स/प्रस्ताव/foo.md डॉक्स/डिजाइन/foo.md में ले जाया गया
    
    
    
    
    
    • cc @kubernetes/feature-reviewers इस मुद्दे पर जाँच करने से पहले अनुमोदन प्राप्त करने के लिए
    
    
    
  
  
  • [ ] सोखें, लोड परीक्षण
  
  
  • [ ] विस्तृत उपयोगकर्ता दस्तावेज़ और उदाहरण
  
  
  • सीसी @kubernetes/docs
  
  
  • cc @kubernetes/feature-reviewers इस मुद्दे पर जाँच करने से पहले अनुमोदन प्राप्त करने के लिए
  
  

FEATURE_STATUS का उपयोग फीचर ट्रैकिंग और @kubernetes/feature-reviewers द्वारा अपडेट किए जाने के लिए किया जाता है।
FEATURE_STATUS: IN_DEVELOPMENT

अधिक सलाह:

डिज़ाइन

• एक बार जब आप @kubernetes/feature-reviewers सदस्य से LGTM प्राप्त कर लेते हैं, तो आप इस चेकबॉक्स को चेक कर सकते हैं, और समीक्षक "डिज़ाइन-पूर्ण" लेबल लागू करेगा।

कोडन

• जितनी जरूरत हो उतने पीआर का इस्तेमाल करें। एक ही या अलग-अलग पीआर में परीक्षण लिखें, जो आपके लिए सुविधाजनक हो।
• जैसा कि प्रत्येक पीआर का विलय होता है, पीआर के संदर्भ में इस मुद्दे पर एक टिप्पणी जोड़ें। कोड http://github.com/kubernetes/kubernetes रिपॉजिटरी में जाता है,
  और कभी-कभी http://github.com/kubernetes/contrib , या अन्य रेपो।
• जब आप कोड के साथ काम कर लें, तो "कोड-पूर्ण" लेबल लागू करें।
• जब सुविधा में उपयोगकर्ता दस्तावेज़ हों, तो कृपया @kubernetes/feature-reviewers उल्लेख करते हुए एक टिप्पणी जोड़ें और वे करेंगे
  जांचें कि कोड प्रस्तावित सुविधा और डिज़ाइन से मेल खाता है, और यह कि सब कुछ किया गया है, और यह कि पर्याप्त है
  परिक्षण। वे विस्तृत कोड समीक्षा नहीं करेंगे: यह तब हो चुका है जब आपके पीआर की समीक्षा की गई थी।
  जब यह हो जाए, तो आप इस बॉक्स को चेक कर सकते हैं और समीक्षक "कोड-पूर्ण" लेबल लागू करेगा।

डॉक्स

• [ ] उपयोगकर्ता दस्तावेज़ लिखें और उनका विलय करवाएं।
• उपयोगकर्ता दस्तावेज़ http://github.com/kubernetes/kubernetes.github.io में जाते हैं।
• जब सुविधा में उपयोगकर्ता दस्तावेज़ हों, तो कृपया @kubernetes/docs उल्लेख करते हुए एक टिप्पणी जोड़ें।
• जब आप LGTM प्राप्त करते हैं, तो आप इस चेकबॉक्स को चेक कर सकते हैं, और समीक्षक "दस्तावेज़-पूर्ण" लेबल लागू करेगा।