কুবারনেটিস রিলিজ সাইকেল

মাইলস্টোন রিলিজের জন্য টার্গেটিং এনহ্যান্সমেন্টস, ইস্যু এবং PR

এই ডকুমেন্টটি ফোকাস করা কুবারনেটিস ডেভেলপার এবং কন্ট্রিবিউটরদের জন্য যাদের একটি এনহ্যান্সমেন্ট, ইস্যু, অথবা পুল রিকুয়েস্ট তৈরি করতে হয় যা লক্ষ্য করে একটি নির্দিষ্ট মাইলফলক।

• TL;DR
  • নরমাল ডেভ (সপ্তাহ ১-১১)
  • কোড ফ্রিজ (সপ্তাহ ১২-১৪)
  • পোস্ট-রিলিজ (সপ্তাহ ১৪+)
• সংজ্ঞা
• রিলিজ সাইকেল
• মাইলস্টোন থেকে আইটেম অপসারণ
• মাইলস্টোনে একটি আইটেম সংযোজন
  • মাইলস্টোন রক্ষণাবেক্ষণকারী
  • ফিচার সংযোজন
  • ইস্যু সংযোজন
  • PR সংযোজন
• অন্যান্য প্রয়োজনীয় লেবেল
  • SIG ওনার লেবেল
  • প্রাইওরিটি লেবেল
  • ইস্যু/PR লেবেল

একটি Kubernetes রিলিজে বর্ধিতকরণ, সমস্যা, এবং পুল অনুরোধের শেফারডিং(shepherding) প্রক্রিয়া একাধিক স্টেকহোল্ডারকে বিস্তৃত করে:

• এনহ্যান্সমেন্টস, ইস্যু, এবং পুল রিকুয়েস্ট ওনার
• SIG লিডারশিপ
• রিলিজ টিম

ওয়ার্কফ্লো এবং ইন্টারেকশন সম্পর্কিত তথ্য নীচে বর্ণিত হয়েছে।

একটি এনহ্যান্সমেন্ট, ইস্যু, অথবা পুল রিকুয়েস্ট (PR) এর ওনার হিসেবে, এটি আপনার দায়িত্ব রিলিজ মাইলস্টোন রিকোয়ারমেন্ট পূরণ হয়েছে নিশ্চিত করা। অটোমেশন এবং রিলিজ টিম আপনার সাথে যোগাযোগ করবে যদি আপডেট প্রয়োজন হয়, কিন্তু নিষ্ক্রিয়তার ফলে আপনার কাজ মাইলস্টোন থেকে সরে যেতে পারে। অতিরিক্ত রিকোয়ারমেন্ট প্রয়োজন যখন লক্ষ্য মাইলস্টোন একটি পূর্ববর্তী রিলিজ (আরও তথ্যের জন্য চেরি পিক প্রোসেস দেখ)

TL;DR

আপনি যদি আপনার PR মার্জ করাতে চান তার জন্য নিম্নলিখিত প্রয়োজনীয় লেবেল এবং মাইলস্টোনগুলো প্রয়োজন, এখানে Prow /commands দ্বারা প্রতিনিধিত্ব করা হয়েছে যেগুলি যোগ করা লাগবে:

নরমাল ডেভ (সপ্তাহ ১-১১)

• /sig {name}
• /kind {type}
• /lgtm
• /approved

কোড ফ্রিজ (সপ্তাহ ১২-১৪)

• /milestone {v1.y}
• /sig {name}
• /kind {bug, failing-test}
• /lgtm
• /approved

পোস্ট-রিলিজ (সপ্তাহ ১৪+)

'নরমাল ডেভ' পর্যায়ের ফিরে যাওয়ার রিকোয়ারমেন্ট:

• /sig {name}
• /kind {type}
• /lgtm
• /approved

1.y ব্রাঞ্চে মার্জ করা এখন চেরি পিক্সের মাধ্যমে, রিলিজ ম্যানেজার দ্বারা অনুমোদিত।

পূর্বে, মাইলস্টোন-লক্ষ্যযুক্ত পুল রিকুয়েস্টের জন্য একটি সংস্থায়িত গিটহাব ইস্যু খোলা প্রয়োজন ছিল, কিন্তু এটি আর প্রয়োজন নয় ফিচার বা এনহ্যান্সমেন্ট হলো ইফেক্টিভ গিটহাব ইস্যু বা KEPs যা পরবর্তী পুল রিকুয়েস্টের পথে পরিচালিত হয়।

সাধারণ লেবেলিং প্রক্রিয়াটি আর্টিফ্যাক্ট টাইপ জুড়ে সামঞ্জস্যপূর্ণ হওয়া উচিত।

সংজ্ঞা

• ইস্যু ওনার: সৃষ্টিকারক, অ্যাসাইনিজ, এবং ইস্যুটি রিলিজ মাইলস্টোনে সরবরাহ করা ব্যবহারকারী।

• রিলিজ টিম: প্রতিটি Kubernetes রিলিজে একটি দল আছে যারা বর্ণিত প্রজেক্ট ম্যানেজমেন্টের কাজ করে এখানে।

  যে কোনো প্রদত্ত রিলিজের সাথে সংশ্লিষ্ট দলের যোগাযোগের তথ্য পাওয়া যাবে এখানে.

• Y days: বিজনেস ডে বুঝায়।

• এনহ্যান্সমেন্ট: দেখ "আমার কাজটা কী এনহ্যান্সমেন্ট?"

• এনহ্যান্সমেন্ট ফ্রিজ: সময়সীমা যার মধ্যে KEPs সম্পন্ন করতে হবে এনহ্যান্সমেন্টগুলো বর্তমান রিলিজের অংশ করার জন্য

• এক্সেপশন রিকোয়েস্ট: কোন এনহ্যান্সমেন্ট এর জন্য সময়সীমা বাড়ানোর অনুরোধ করার প্রক্রিয়া

• কোড ফ্রিজ: চূড়ান্ত প্রকাশের তারিখের আগে ~4 সপ্তাহের সময়কাল, যে সময়ে শুধুমাত্র ক্রিটিকাল বাগ ফিক্স রিলিজে মার্জ করা হয়েছে।

• Pruning: একটি রিলিজ মাইলস্টোন থেকে একটি এনহ্যান্সমেন্ট অপসারণের প্রক্রিয়া যদি এটি সম্পূর্ণরূপে বাস্তবায়িত বা অন্যথায় স্থিতিশীল নয় বলে মনে করা হয়।

• রিলিজ মাইলস্টোন: সিমেনটিক ভার্সন স্ট্রিং বা GitHub milestone যা একটি রিলিজ ভার্সন MAJOR.MINOR vX.Y নির্দেশ করে।

  আরও দেখ রিলিজ ভার্সনিং.

• রিলিজ ব্রাঞ্চ: Git ব্রাঞ্চ release-X.Y তৈরি করা হয়েছে vX.Y মাইলস্টোনের জন্য।

  vX.Y-rc.0 রিলিজের সময় তৈরি করা হয়েছে এবং রিলিজের পর প্রায় ১২ মাস ধরে vX.Y.Z প্যাচ রিলিজের সাথে রক্ষণাবেক্ষণ করা হয়েছে।

  দ্রষ্টব্য: রিলিজ 1.19 এবং পরবর্তী ভার্সন 1 বছরের প্যাচ রিলিজ সাপোর্ট পায়, এবং রিলিজ 1.18 এবং তার আগে 9 মাসের প্যাচ রিলিজ সাপোর্ট পেয়েছে।

রিলিজ সাইকেল

কুবারনেটিস রিলিজ বর্তমানে প্রতি বছর প্রায় তিনবার হয়।

রিলিজ প্রক্রিয়াটিকে তিনটি প্রধান পর্যায় হিসাবে বিবেচনা করা যেতে পারে:

• এনহ্যান্সমেন্ট ডেফিনেশন
• ইমপ্লিমেন্টেশন
• স্ট্যাবিলাইজেশন

কিন্তু বাস্তবে, এটি একটি ওপেন সোর্স এবং অ্যাজাইল(agile) প্রকল্প, ফিচার পরিকল্পনা এবং বাস্তবায়ন সব সময়ে ঘটছে। প্রজেক্ট স্কেল এবং বিশ্বব্যাপী ডিস্ট্রিবিউটেড ডেভেলপার বেস এর ফলে, এটি গুরুত্বপূর্ণ যে প্রজেক্টের গতি যেনো ট্রেইলিং স্টেবিলাইজেশন ফেজ এর উপর নির্ভর না করে এবং বরং ক্রমাগত ইন্টিগ্রেশন টেস্টিং চলমান থাকে যা নিশ্চিত করে যে প্রকল্পটি সর্বদা স্থিতিশীল যাতে একজন ডেভেলপার কোন নির্দিষ্ট কমিটে কোন সমস্যা তৈরি করেছে তা চিহ্নিত করা যেতে পারে।

বছর ধরে চলমান ফিচার নির্ধারণের সাথে, কিছু আইটেম একটি নির্দিষ্ট রিলিজের লক্ষ্য হিসেবে উঠে আসবে। এনহ্যান্সমেন্ট ফ্রিজ রিলিজ সাইকেলের ~৪ সপ্তাহের মধ্যে শুরু হয়। এই মুহুর্তে সমস্ত উদ্দেশ্যমূলক ফিচার কাজকে রিলিজ টিমের সাথে একযোগে এনহ্যান্সমেন্ট লিড প্রদত্ত রিলিজ উপযুক্ত পরিকল্পনা নিদর্শনে সংজ্ঞায়িত করা হয়েছে ।

এনহ্যান্সমেন্ট ফ্রিজের পরে, PR এবং ইস্যুগুলোর মাইলস্টোন ট্র্যাক করা গুরুত্বপূর্ণ। মাইলস্টোন থাকা আইটেমগুলি সম্পূর্ণ করার জন্য একটি পাঞ্চডাউন তালিকা হিসাবে ব্যবহৃত হয় রিলিজের জন্য। ইস্যুতে, মাইলস্টোন অবশ্যই সঠিকভাবে প্রয়োগ করতে হবে, triage মাধ্যমে SIG, যাতে রিলিজ টিম বাগ এবং এনহ্যান্সমন্ট ট্র্যাক করতে পারে (যেকোন এনহ্যান্সমেন্ট-সম্পর্কিত ইস্যুর একটি মাইলস্টোন প্রয়োজন)।

PR এ স্বয়ংক্রিয়ভাবে মাইলফলক বরাদ্দ করতে সাহায্য করার জন্য কিছু অটোমেশন রয়েছে৷

এই অটোমেশনটি বর্তমানে নিম্নলিখিত রিপোতে প্রযোজ্য:

• kubernetes/enhancements
• kubernetes/kubernetes
• kubernetes/release
• kubernetes/sig-release
• kubernetes/test-infra

তৈরি করার সময়, master ব্রাঞ্চের বিপরীতে PR গুলোর মানুষের দেওয়া নির্দেশনা প্রয়োজন কোন মাইলস্টোন টার্গেট করতে হবে তার জন্য। একবার মার্জ হলে, master ব্রাঞ্চের বিপরীতে তৈরি করা PR গুলোয় মাইলস্টোন় স্বয়ংক্রিয়ভাবে প্রয়োগ করা হয় তাই সেই সময় থেকে ওই PR এর মাইলস্টোনে মানুষের ব্যবস্থাপনা কম প্রয়োজনীয়। রিলিজ ব্রাঞ্চ এর বিপরীতে তৈরি PR এ, মাইলস্টোন সংক্রিয়ভাবে প্রয়োগ হয় তাই মানুষবিহীন ব্যবস্থাপনা মাইলস্টোনের জন্য সবসময় প্রয়োজন।

অন্য কোনো প্রচেষ্টা যা রিলিজ টিমের দ্বারা ট্র্যাক করা উচিত যা কোনো অটোমেশন আম্ব্রেলার অধীনে নেই তাতে একটি মাইলফলক প্রয়োগ করা উচিত।

ইমপ্লিমেন্টেশন এবং বাগ ফিক্সিং পুরো সাইকেল জুড়ে চলেছে, কিন্তু শেষ হয় কোড-ফ্রিজ সময়কালে।

কোড ফ্রিজ শুরু হয় ~১২ সপ্তাহে এবং পরবর্তী ~২ সপ্তাহ পর্যন্ত চলে। এই সময়ে রিলিজ কোডবেসে শুধুমাত্র গুরুত্বপূর্ণ বাগ ফিক্স গ্রহণ করা হয়।

Code Freeze এর পরে এবং রিলিজের পূর্বে প্রায় দুই সপ্তাহের সময় রয়েছে, যা রিলিজ পূর্বে সমস্ত অবশিষ্ট গুরুত্বপূর্ণ সমস্যাগুলি সমাধান করা আবশ্যক। এটি ডকুমেন্টেশন চূড়ান্ত করার জন্য সময় দেয়।

যখন কোড বেস স্টেবল হয়, তখন মাস্টার ব্রাঞ্চটি সাধারণ উন্নতির জন্য পুনরায় খোলা হয় এবং পরবর্তী রিলিজের মাইলস্টোনে কাজ সেখানে শুরু করা হয়। বর্তমান রিলিজের জন্য অবশিষ্ট যেকোনো সংশোধন মাস্টার থেকে রিলিজ ব্রাঞ্চে চেরি-পিক করা হয়। রিলিজ ব্রাঞ্চ থেকে রিলিজ তৈরি করা হয়।

প্রত্যেকটি রিলিজ একটি বৃহৎ কুবারনেটিস লাইফসাইকের অংশ:

মাইলস্টোন থেকে আইটেম অপসারণ

মাইলস্টোন আইটেম যোগ করার প্রক্রিযার অধিক দূরে যাওয়ার আগে, দয়া করে লক্ষ্য করুন:

রিলিজ টিম এর সদস্যরা মাইলস্টোন থেকে ইস্যু সরাতে পারে যদি তারা অথবা যদি দায়িত্বশীল SIG মনে করে যে সমস্যাটি বাস্তবে রিলিজ ব্লক করছে না এবং সম্ভবত সময়ের মধ্যে সমাধান হবে না।

রিলিজ দলের সদস্যরা নিম্নলিখিত কারণে অথবা এর সমান কারণে মাইলস্টোন থেকে PR-গুলি সরাতে পারেন:

• PR সম্ভবত অস্থিতিশীল এবং ব্লকিং সমস্যা সমাধানের প্রয়োজন নেই
• নতুন PR, লেট ফিচার PR এবং এনহ্যান্সমেন্ট প্রক্রিয়ার অথবা এক্সেপশন প্রক্রিয়া এর মধ্যে যায় নি
• পিআর এর মালিকানা নিতে এবং এটির সাথে কোন ফলো-আপ সমস্যা সমাধান করতে ইচ্ছুক কোন দায়িত্বশীল SIG নেই
• PR সঠিকভাবে লেবেল করা হয় না
• PR-এ কাজ দৃশ্যত থেমে গেছে এবং ডেলিভারির তারিখ অনিশ্চিত বা দেরি হবে

রিলিজ টিমের সদস্যরা লেবেলিং এবং SIG দের সাথে যোগাযোগে সাহায্য করবে,PR কে শ্রেণীবদ্ধ করা জমাদানকারীর দায়িত্ব এবং প্রাসঙ্গিক SIG হতে সাহায্য নিশ্চিত করা যেনো PR দ্বারা কোনো ব্রেক হলে ধ্রুত সমাধানের গ্যারেন্টি দেওয়া হবে।

যেখানে অতিরিক্ত পদক্ষেপ প্রয়োজন, রিলিজ দল নিম্নলিখিত চ্যানেলের মাধ্যমে মানুষ থেকে মানুষে এস্ক্যালেশনের চেষ্টা করবে:

• ইস্যু প্রকারের উপযুক্ত SIG দল এবং SIG সদস্যদের উল্লিখিত করে GitHub-এ মন্তব্য করুন।
• SIG মেইলিং লিস্টে ইমেইল পাঠানো
  • কমিউনিটি সিগ লিস্ট থেকে গ্রুপ ইমেল ঠিকানা দিয়ে বুটস্ট্র্যাপ করা হয়েছে
  • ঐচ্ছিকভাবে সরাসরি SIG নেতৃত্ব বা অন্যান্য SIG সদস্যদের সম্বোধন করে
• SIG এর স্ল্যাক চ্যানেলে বার্তা পাঠানো।
  • কমিউনিটি সিগ লিস্ট থেকে স্ল্যাকচ্যানেল এবং SIG নেতৃত্বের সাথে বুটস্ট্র্যাপ করা হয়েছে
  • ঐচ্ছিকভাবে সরাসরি "@" হ্যান্ডেল দ্বারা SIG নেতৃত্ব বা অন্যদের উল্লেখ করে

মাইলস্টোনে একটি আইটেম সংযোজন

মাইলস্টোন রক্ষণাবেক্ষণকারী

milestone-maintainers এর সদস্যদের GitHub টিম দ্বারা GitHub আর্টিফ্যাক্টগুলিতে রিলিজ মাইলস্টোন নির্দিষ্ট করার দায়িত্ব দেওয়া হয়েছে।

এই গ্রুপটি SIG রিলিজের দ্বারা রক্ষণাবেক্ষণ করা হয়েছে এবং বিভিন্ন SIG-এর নেতৃত্বের প্রতিনিধিত্ব রয়েছে।

ফিচার সংযোজন

ফিচার পরিকল্পনা এবং সংজ্ঞা আজ অনেক রূপ নেয়, কিন্তু একটি সাধারণ উদাহরণ হতে পারে একটি KEP-এ বর্ণিত কাজের একটি বড় অংশ, GitHub-এ সংশ্লিষ্ট টাস্ক সমস্যা সহ। যখন পরিকল্পনাটি একটি বাস্তবায়নযোগ্য অবস্থায় পৌঁছেছে এবং কাজ চলছে, তখন বর্ধন বা এর অংশগুলিকে GitHub সমস্যা তৈরি করে এবং Prow "/milestone" কমান্ড দিয়ে চিহ্নিত করে একটি আসন্ন মাইলফলকের জন্য লক্ষ্য করা হয়।

রিলিজ চক্রের প্রথম ~4 সপ্তাহের জন্য, রিলিজ টিমের এনহ্যান্সমেন্ট লিড সমস্ত প্রয়োজনীয় পরিকল্পনা নিদর্শনগুলি ক্যাপচার করতে GitHub, Slack এবং SIG মিটিংয়ের মাধ্যমে SIG এবং ফিচার মালিকদের সাথে যোগাযোগ করবে।

আপনার যদি আসন্ন রিলিজের মাইলস্টোন লক্ষ্য করার জন্য একটি এনহ্যান্সমেন্ট থাকে, তাহলে আপনার SIG নেতৃত্বের সাথে এবং সেই রিলিজের এনহ্যান্সমেন্ট লিডের সাথে কথা বলুন।

ইস্যু সংযোজন

ইস্যুগুলোকে Prow "/milestone" কমান্ডের মাধ্যমে একটি মাইলস্টোন লক্ষ্য করে চিহ্নিত করা হয়েছে৷

রিলিজ টিমের বাগ Triage লিড এবং সামগ্রিক কমিউনিটি আগত সমস্যাগুলি দেখে এবং সেগুলিকে Triage করে ইস্যু Triage. এর অবদানকারী নির্দেশিকা বিভাগে বর্ণিত হয়েছে।

মাইলস্টোনের সাথে সমস্যাগুলি চিহ্নিত করা কমিউনিটি একটি সমস্যা কখন পর্যবেক্ষণ করা হয়েছিল এবং কখন কমিউনিটি মনে করে এটির সমাধান করা উচিত সে সম্পর্কে আরও ভাল দৃশ্যমানতা প্রদান করে। কোড ফ্রিজ চলাকালীন, একটি PR মার্জ করার জন্য একটি মাইলফলক সেট করতে হবে৷

PR-এর জন্য ওপেন ইস্যুর আর প্রয়োজন নেই, কিন্তু ওপেন ইস্যু এবং সংশ্লিষ্ট PR-এর সিঙ্ক্রোনাইজড লেবেল থাকা উচিত। উদাহরণস্বরূপ, একটি উচ্চ অগ্রাধিকারের বাগ ইস্যু এর সাথে যুক্ত PR মার্জ নাও হতে পারে যদি PR শুধুমাত্র নিম্ন অগ্রাধিকার হিসাবে চিহ্নিত করা হয়।

PR সংযোজন

PR গুলোকে Prow "/milestone" কমান্ডের মাধ্যমে একটি মাইলফলককে লক্ষ্য করে চিহ্নিত করা হয়েছে।

উপরে বর্ণিত কোড ফ্রিজের সময় এটি একটি ব্লকিং প্রয়োজনীয়তা।

অন্যান্য প্রয়োজনীয় লেবেল

এখানে লেবেল এবং তাদের ব্যবহার এবং উদ্দেশ্য তালিকা আছে।

SIG ওনার লেবেল

SIG মালিকের লেবেল SIG কে সংজ্ঞায়িত করে যার দিকে আমরা অগ্রসর হই যদি একটি মাইলস্টোন সমস্যা স্থবির হয় বা অতিরিক্ত মনোযোগের প্রয়োজন হয়। যদি বৃদ্ধির পরে কোন আপডেট না থাকে, তাহলে সমস্যাটি মাইলফলক থেকে স্বয়ংক্রিয়ভাবে সরানো হতে পারে।

এগুলি Prow "/sig" কমান্ডের সাথে যোগ করা হয়। যেমন SIG স্টোরেজ দায়ী লেবেল যোগ করতে, /sig storage দিয়ে মন্তব্য করুন।

প্রাইওরিটি লেবেল

অগ্রাধিকার লেবেলগুলি ইস্যুগুলির রিলিস মাইলস্টোন থেকে বের হতে প্রারম্ভিক এস্ক্যালেশন পথ নির্ধারণে ব্যবহৃত হয়। তারা এটা নির্ধারণ করতে ব্যবহৃত হয় যে ইস্যুর সমাধানের উপরে রিলিস ব্লক করা উচিত কি না।

• priority/critical-urgent: কখনই স্বয়ংক্রিয়ভাবে রিলিজ মাইলস্টোন থেকে সরে যাবেন না; সব উপলভ্য চ্যানেলের মাধ্যমে ক্রমাগত অবদানকারী এবং SIG-এর কাছে এগিয়ে যান।
  • একটি রিলিজ ব্লকিং সমস্যা হিসাবে বিবেচিত।
  • কোড ফ্রিজ চলাকালীন ইস্যু মালিকদের কাছ থেকে দৈনিক আপডেটের প্রয়োজন।
  • একটি প্যাচ রিলিজ প্রয়োজন হবে যদি অনাবিষ্কৃত কিছু মাইনর রিলিজের পর থেকে যায়।
• priority/important-soon: ইস্যু মালিক এবং SIG মালিকের কাছে এগিয়ে যান; বেশ কয়েকটি অসফল বৃদ্ধি প্রচেষ্টার পরে মাইলফলক থেকে সরে যান।
  • একটি রিলিজ ব্লকিং সমস্যা হিসাবে বিবেচনা করা হয় না
  • একটি প্যাচ রিলিজ প্রয়োজন হবে না
  • 4 দিনের গ্রেস পিরিয়ডের পরে কোড ফ্রিজে স্বয়ংক্রিয়ভাবে রিলিজের মাইলফলক থেকে সরে যাবে
• priority/important-longterm: ইস্যু মালিকদের কাছে এগিয়ে যান; 1 বার প্রচেষ্টার পরে মাইলফলক থেকে সরে যান।
  • এমনকি priority/important-soon এর চেয়ে কম জরুরি/সমালোচনা
  • priority/important-soon এর চেয়ে বেশি আক্রমনাত্মকভাবে মাইলফলক থেকে সরে গেছে

ইস্যু/PR লেবেল

ইস্যুর ধরন ব্যবহার করা হয় সময়ের সাথে রিলিজের বিভিন্ন পরিবর্তন সনাক্ত করার জন্য। যা রিলিজ টিমকে ভালো ধারণা দেয় একটি দ্রুত রিলিজ কেডেন্সে কোন ইস্যু গুলো হারিয়ে যাচ্ছে তা সম্পর্কে।

রিলিজ টার্গেট করা সমস্যাগুলির জন্য, পুল অনুরোধ সহ, নিম্নলিখিত একটি সমস্যা ধরনের লেবেল সেট করা আবশ্যক:

• kind/api-change: একটি API যোগ করে, অপসারণ করে বা পরিবর্তন করে।
• kind/bug: একটি নতুন আবিষ্কৃত বাগ সংশোধন করে।
• kind/cleanup: টেস্ট যোগ করা, রিফ্যাক্টরিং, পুরানো বাগ ঠিক করা।
• kind/design: ডিজাইনের সাথে সম্পর্কিত।
• kind/documentation: ডকুমেন্টেশন যোগ করে।
• kind/failing-test: CI টেস্ট কেস ধারাবাহিকভাবে ব্যর্থ হয়।
• kind/feature: নতুন ফিচার।
• kind/flake: CI টেস্ট কেস মাঝে মাঝে ব্যর্থতা দেখাচ্ছে।