Bazel রক্ষণাবেক্ষণকারীদের জন্য গাইড, Bazel রক্ষণাবেক্ষণকারীদের জন্য গাইড

এটি Bazel ওপেন সোর্স প্রকল্পের রক্ষণাবেক্ষণকারীদের জন্য একটি নির্দেশিকা।

আপনি যদি Bazel-এ অবদান রাখতে চান, তাহলে অনুগ্রহ করে এর পরিবর্তে Bazel-এ অবদান পড়ুন।

এই পৃষ্ঠার উদ্দেশ্য হল:

  1. প্রকল্পের অবদান প্রক্রিয়ার জন্য সত্যের রক্ষণাবেক্ষণকারীর উত্স হিসাবে পরিবেশন করুন।
  2. সম্প্রদায়ের অবদানকারী এবং প্রকল্প রক্ষণাবেক্ষণকারীদের মধ্যে প্রত্যাশা সেট করুন।

ওপেন সোর্স প্রজেক্টের দিকগুলি পরিচালনা করার জন্য Bazel- এর অবদানকারীদের মূল গোষ্ঠীতে নিবেদিত সাবটিম রয়েছে৷ এইগুলো:

  • রিলিজ প্রসেস : ব্যাজেলের রিলিজ প্রসেস ম্যানেজ করুন।
  • সবুজ দল : নিয়ম এবং সরঞ্জামগুলির একটি স্বাস্থ্যকর ইকোসিস্টেম বাড়ান।
  • ডেভেলপার এক্সপেরিয়েন্স গার্ডেনার্স : বাহ্যিক অবদানকে উৎসাহিত করুন, সমস্যা পর্যালোচনা করুন এবং অনুরোধগুলি টানুন এবং আমাদের উন্নয়ন কর্মপ্রবাহকে আরও উন্মুক্ত করুন।

মুক্তি দেয়

একটানা সমাকলান

Bazelbuild/continuous-integration repository-এ Bazel-এর CI পরিকাঠামোর জন্য সবুজ দলের নির্দেশিকা পড়ুন।

একটি ইস্যু জীবনচক্র

  1. একজন ব্যবহারকারী ইস্যু টেমপ্লেট ব্যবহার করে একটি সমস্যা তৈরি করে এবং এটি পর্যালোচনা না করা উন্মুক্ত সমস্যাগুলির পুলে প্রবেশ করে।
  2. ডেভেলপার এক্সপেরিয়েন্স (DevEx) সাবটিম রোটেশনের একজন সদস্য সমস্যাটি পর্যালোচনা করেন।
    1. সমস্যাটি বাগ বা বৈশিষ্ট্যের অনুরোধ না হলে, DevEx সদস্য সাধারণত সমস্যাটি বন্ধ করে দেবে এবং ব্যবহারকারীকে স্ট্যাকওভারফ্লোতে পুনঃনির্দেশ করবে এবং প্রশ্নটির উচ্চতর দৃশ্যমানতার জন্য বেজেল-আলোচনা করবে।
    2. যদি সমস্যাটি সম্প্রদায়ের মালিকানাধীন নিয়ম ভান্ডারগুলির একটিতে থাকে, যেমন rules_apple , তাহলে DevEx সদস্য এই সমস্যাটিকে সঠিক সংগ্রহস্থলে স্থানান্তর করবে৷
    3. যদি সমস্যাটি অস্পষ্ট হয় বা তথ্য অনুপস্থিত থাকে, তাহলে চালিয়ে যাওয়ার আগে DevEx সদস্য আরও তথ্যের জন্য অনুরোধ করার জন্য ব্যবহারকারীকে সমস্যাটি ফিরিয়ে দেবেন। এটি সাধারণত ঘটে যখন ব্যবহারকারী ইস্যু টেমপ্লেট অনুসরণ করেন না।
  3. সমস্যাটি পর্যালোচনা করার পর, DevEx সদস্য সিদ্ধান্ত নেয় যে সমস্যাটির অবিলম্বে মনোযোগ প্রয়োজন কিনা। যদি তা হয়, তাহলে তারা P0 অগ্রাধিকার লেবেল এবং টিম লিডের তালিকা থেকে একজন মালিক বরাদ্দ করবে।
  4. untriaged মেম্বার রাউটিং এর জন্য অপ্রস্তুত লেবেল এবং ঠিক একটি টিম লেবেল বরাদ্দ করে।
  5. এছাড়াও DevEx সদস্য ঠিক এক type: লেবেল, যেমন type: bug বা type: feature request , সমস্যার ধরন অনুযায়ী।
  6. প্ল্যাটফর্ম-নির্দিষ্ট সমস্যার জন্য, DevEx সদস্য একটি platform: লেবেল, যেমন platform:apple ম্যাক-নির্দিষ্ট সমস্যার জন্য। এই পর্যায়ে, সমস্যাটি অপ্রকাশিত উন্মুক্ত সমস্যাগুলির পুলে প্রবেশ করে।

প্রতিটি Bazel সাবটিম তাদের মালিকানাধীন লেবেলের অধীনে সমস্ত সমস্যা বিচার করবে, বিশেষত একটি সাপ্তাহিক ভিত্তিতে। সাবটিম সমস্যাটি পর্যালোচনা করবে এবং মূল্যায়ন করবে এবং সম্ভব হলে একটি সমাধান প্রদান করবে। আপনি যদি একটি টিম লেবেলের মালিক হন তবে আরও তথ্যের জন্য এই বিভাগটি দেখুন৷

যখন একটি সমস্যা সমাধান করা হয়, এটি বন্ধ করা যেতে পারে।

একটি টান অনুরোধের জীবনচক্র

  1. একজন ব্যবহারকারী একটি টান অনুরোধ তৈরি করে।
  2. আপনি যদি Bazel টিমের একজন সদস্য হন এবং আপনার নিজের এলাকার বিরুদ্ধে PR পাঠান, তাহলে আপনার টিমের লেবেল বরাদ্দ করা এবং সেরা পর্যালোচক খোঁজার জন্য আপনি দায়ী।
  3. অন্যথায়, দৈনিক ট্রাইজের সময়, একজন DevEx সদস্য একটি টিম লেবেল এবং টিমের টেকনিক্যাল লিড (TL) রাউটিং এর জন্য বরাদ্দ করে।
    1. TL ঐচ্ছিকভাবে PR পর্যালোচনা করার জন্য অন্য কাউকে বরাদ্দ করতে পারে।
  4. নির্ধারিত পর্যালোচক PR পর্যালোচনা করেন এবং এটি অনুমোদিত বা বাদ না হওয়া পর্যন্ত লেখকের সাথে কাজ করেন।
  5. অনুমোদিত হলে, পর্যালোচক আরও পরীক্ষার জন্য Google-এর অভ্যন্তরীণ সংস্করণ নিয়ন্ত্রণ ব্যবস্থায় PR-এর প্রতিশ্রুতি(গুলি) আমদানি করে৷ যেহেতু Bazel Google-এ অভ্যন্তরীণভাবে ব্যবহৃত একই বিল্ড সিস্টেম, তাই আমাদের অভ্যন্তরীণ পরীক্ষা স্যুটের বিরুদ্ধে সমস্ত PR প্রতিশ্রুতি পরীক্ষা করতে হবে। এই কারণেই আমরা সরাসরি PRs একত্রিত করি না।
  6. যদি আমদানি করা প্রতিশ্রুতি সমস্ত অভ্যন্তরীণ পরীক্ষায় উত্তীর্ণ হয়, তাহলে প্রতিশ্রুতিটি স্কোয়াশ করা হবে এবং গিটহাবে আবার রপ্তানি করা হবে।
  7. যখন কমিট মাস্টারে একত্রিত হয়, GitHub স্বয়ংক্রিয়ভাবে PR বন্ধ করে দেয়।

আমার দল একটি লেবেল মালিক. আমার কি করা উচিৎ?

সাবটিমগুলিকে তাদের মালিকানাধীন লেবেলে সমস্ত সমস্যা ট্রাইজ করতে হবে, বিশেষত একটি সাপ্তাহিক ভিত্তিতে৷

ইস্যু

  1. আপনার টিম লেবেল এবং untriaged লেবেল দ্বারা সমস্যার তালিকা ফিল্টার করুন।
  2. সমস্যাটি পর্যালোচনা করুন।
  3. একটি অগ্রাধিকার স্তর সনাক্ত করুন এবং লেবেল বরাদ্দ করুন।
    1. যদি এটি একটি P0 হয় তবে DevEx সাবটিম দ্বারা সমস্যাটিকে ইতিমধ্যেই অগ্রাধিকার দেওয়া হতে পারে। প্রয়োজন হলে পুনরায় অগ্রাধিকার দিন।
    2. প্রতিটি সমস্যার ঠিক একটি অগ্রাধিকার লেবেল থাকা প্রয়োজন৷ যদি একটি সমস্যা P0 বা P1 হয় তবে আমরা ধরে নিই যে এটি সক্রিয়ভাবে কাজ করা হয়েছে।
  4. untriaged লেবেল সরান.

মনে রাখবেন লেবেল যোগ করতে বা সরাতে সক্ষম হওয়ার জন্য আপনাকে বেজেলবিল্ড সংস্থায় থাকতে হবে।

অনুরোধ টানুন

  1. আপনার দলের লেবেল দ্বারা পুল অনুরোধের তালিকা ফিল্টার করুন.
  2. খোলা টান অনুরোধ পর্যালোচনা করুন.
    1. ঐচ্ছিক : যদি আপনাকে পর্যালোচনার জন্য নিয়োগ করা হয় কিন্তু আপনি এটির জন্য উপযুক্ত না হন, তাহলে একটি কোড পর্যালোচনা করার জন্য উপযুক্ত পর্যালোচককে পুনরায় বরাদ্দ করুন।
  3. একটি কোড পর্যালোচনা সম্পূর্ণ করতে পুল অনুরোধ নির্মাতার সাথে কাজ করুন।
  4. পিআর অনুমোদন করুন।
  5. নিশ্চিত করুন যে সমস্ত পরীক্ষা পাস।
  6. অভ্যন্তরীণ সংস্করণ নিয়ন্ত্রণ সিস্টেমে প্যাচ আমদানি করুন এবং অভ্যন্তরীণ প্রিসবমিট চালান।
  7. অভ্যন্তরীণ প্যাচ জমা দিন. যদি প্যাচ জমা দেয় এবং সফলভাবে রপ্তানি করে, তাহলে PR GitHub দ্বারা স্বয়ংক্রিয়ভাবে বন্ধ হয়ে যাবে।

অগ্রাধিকার

অগ্রাধিকারের জন্য নিম্নলিখিত সংজ্ঞাগুলি রক্ষণাবেক্ষণকারীরা সমস্যা সমাধানের জন্য ব্যবহার করবে।

  • P0 - প্রধান ভাঙা কার্যকারিতা যা একটি Bazel রিলিজ (মাইনাস রিলিজ প্রার্থীদের) অব্যবহারযোগ্য হতে পারে, অথবা একটি ডাউনড পরিষেবা যা Bazel প্রকল্পের উন্নয়নকে মারাত্মকভাবে প্রভাবিত করে৷ এর মধ্যে রয়েছে একটি নতুন রিলিজে প্রবর্তিত রিগ্রেশন যা উল্লেখযোগ্য সংখ্যক ব্যবহারকারীকে ব্লক করে, অথবা একটি বেমানান ব্রেকিং পরিবর্তন যা ব্রেকিং চেঞ্জ নীতির সাথে সঙ্গতিপূর্ণ ছিল না। কোন ব্যবহারিক সমাধান বিদ্যমান নেই.
  • P1 - গুরুতর ত্রুটি বা বৈশিষ্ট্য যা পরবর্তী রিলিজে সমাধান করা উচিত, বা একটি গুরুতর সমস্যা যা অনেক ব্যবহারকারীকে প্রভাবিত করে (ব্যাজেল প্রকল্পের বিকাশ সহ), কিন্তু একটি বাস্তব সমাধান বিদ্যমান। সাধারণত অবিলম্বে পদক্ষেপের প্রয়োজন হয় না। বর্তমান ত্রৈমাসিকের রোডম্যাপে উচ্চ চাহিদা এবং পরিকল্পিত।
  • P2 - ত্রুটি বা বৈশিষ্ট্য যা সমাধান করা উচিত কিন্তু আমরা বর্তমানে কাজ করি না। একটি মুক্তিপ্রাপ্ত Bazel সংস্করণে মধ্যম লাইভ সমস্যা যা একটি ব্যবহারকারীর জন্য অসুবিধাজনক যা ভবিষ্যতের রিলিজে সমাধান করা প্রয়োজন এবং/অথবা একটি সহজ সমাধান বিদ্যমান।
  • P3 - পছন্দসই ছোটখাট বাগ ফিক্স বা ছোট প্রভাব সহ বর্ধিতকরণ। Bazel রোডম্যাপ বা কোনো আসন্ন প্রকাশে অগ্রাধিকার দেওয়া হয়নি, তবে সম্প্রদায়ের অবদানগুলিকে উৎসাহিত করা হয়।
  • P4 - কম অগ্রাধিকার ত্রুটি বা বৈশিষ্ট্য অনুরোধ যা বন্ধ হওয়ার সম্ভাবনা নেই। আরও ব্যবহারকারী প্রভাবিত হলে সম্ভাব্য পুনরায় অগ্রাধিকারের জন্যও খোলা রাখা যেতে পারে।
  • বরফের বাক্স
    • যে সমস্যাগুলি আমাদের কাছে মোকাবেলা করার সময় নেই এবং অবদান গ্রহণ করার সময় নেই৷ আমরা এই সমস্যাগুলি বন্ধ করে দিব যাতে বোঝা যায় যে কেউ এগুলি নিয়ে কাজ করছে না, তবে সময়ের সাথে সাথে তাদের বৈধতা নিরীক্ষণ করা চালিয়ে যাব এবং যদি যথেষ্ট লোক প্রভাবিত হয় এবং যদি আমাদের কাছে তাদের মোকাবেলা করার জন্য সংস্থান থাকে তবে সেগুলিকে পুনরুজ্জীবিত করব৷ বরাবরের মতো, বন্ধ থাকা সত্ত্বেও এই সমস্যাগুলিতে মন্তব্য করতে বা প্রতিক্রিয়া যোগ করতে নির্দ্বিধায়।

টিম লেবেল

  • team-Android : Android দলের জন্য সমস্যা
  • team-Bazel : সাধারণ বেজেল পণ্য/কৌশল সমস্যা
  • team-Build-Language : BUILD, .bzl API এবং Stardoc-এর জন্য সমস্যা।
  • team-Configurability : কনফিগারেবিলিটি টিমের জন্য সমস্যা
  • team-Core : মূল দলের জন্য সমস্যা
    • যোগাযোগ: haxorz
  • team-Documentation : ডকুমেন্টেশন দলের জন্য সমস্যা
  • team-ExternalDeps : বাহ্যিক নির্ভরতা হ্যান্ডলিং, Bzlmod, দূরবর্তী সংগ্রহস্থল, WORKSPACE ফাইল
  • team-Local-Exec : এক্সিকিউশন (স্থানীয়) দলের জন্য সমস্যা
  • team-OSS : ব্যাজেল ওএসএস টিমের সমস্যা: ইনস্টলেশন, রিলিজ প্রক্রিয়া, ব্যাজেল প্যাকেজিং, ওয়েবসাইট, ডক্স অবকাঠামো
  • team-Performance : ব্যাজেল পারফরম্যান্স দলের জন্য সমস্যা
  • team-Remote-Exec : এক্সিকিউশন (রিমোট) দলের জন্য সমস্যা
  • team-Rules-CPP : C++ নিয়মের সমস্যা, যার মধ্যে নেটিভ অ্যাপল রুল লজিক রয়েছে
  • team-Rules-Java : জাভা নিয়মের জন্য সমস্যা
    • যোগাযোগ: comius
  • team-Rules-Python : স্থানীয় পাইথন নিয়মের সমস্যা
    • যোগাযোগ: comius
  • team-Rules-Server : Bazel-এর সাথে অন্তর্ভুক্ত সার্ভার-সাইড নিয়মের সমস্যা
    • যোগাযোগ: comius
  • team-Starlark-integration : নন-এপিআই বেজেল + স্টারলার্ক ইন্টিগ্রেশন। অন্তর্ভুক্ত: ব্যাজেল কীভাবে স্টারলার্ক ইন্টারপ্রেটার, স্টারডক, বিল্টিন ইনজেকশন, ক্যারেক্টার এনকোডিং ট্রিগার করে। এতে অন্তর্ভুক্ত নয় : BUILD বা .bzl ভাষার সমস্যা।
  • team-Starlark-interpreter : স্টারলার্ক দোভাষীর জন্য সমস্যা ( java.net.starlark- এ যেকোনো কিছু)। BUILD এবং .bzl API সমস্যাগুলি (যা স্টারলার্কের সাথে ব্যাজেলের একীকরণের প্রতিনিধিত্ব করে) team-Build-Language যায়।

নতুন সমস্যাগুলির জন্য, আমরা category: * টিম লেবেলের পক্ষে লেবেল।

এখানে লেবেলের সম্পূর্ণ তালিকা দেখুন।

,

এটি Bazel ওপেন সোর্স প্রকল্পের রক্ষণাবেক্ষণকারীদের জন্য একটি নির্দেশিকা।

আপনি যদি Bazel-এ অবদান রাখতে চান, তাহলে অনুগ্রহ করে এর পরিবর্তে Bazel-এ অবদান পড়ুন।

এই পৃষ্ঠার উদ্দেশ্য হল:

  1. প্রকল্পের অবদান প্রক্রিয়ার জন্য সত্যের রক্ষণাবেক্ষণকারীর উত্স হিসাবে পরিবেশন করুন।
  2. সম্প্রদায়ের অবদানকারী এবং প্রকল্প রক্ষণাবেক্ষণকারীদের মধ্যে প্রত্যাশা সেট করুন।

ওপেন সোর্স প্রজেক্টের দিকগুলি পরিচালনা করার জন্য Bazel- এর অবদানকারীদের মূল গোষ্ঠীতে নিবেদিত সাবটিম রয়েছে৷ এইগুলো:

  • রিলিজ প্রসেস : ব্যাজেলের রিলিজ প্রসেস ম্যানেজ করুন।
  • সবুজ দল : নিয়ম এবং সরঞ্জামগুলির একটি স্বাস্থ্যকর ইকোসিস্টেম বাড়ান।
  • ডেভেলপার এক্সপেরিয়েন্স গার্ডেনার্স : বাহ্যিক অবদানকে উৎসাহিত করুন, সমস্যা পর্যালোচনা করুন এবং অনুরোধগুলি টানুন এবং আমাদের উন্নয়ন কর্মপ্রবাহকে আরও উন্মুক্ত করুন।

মুক্তি দেয়

একটানা সমাকলান

Bazelbuild/continuous-integration repository-এ Bazel-এর CI পরিকাঠামোর জন্য সবুজ দলের নির্দেশিকা পড়ুন।

একটি ইস্যু জীবনচক্র

  1. একজন ব্যবহারকারী ইস্যু টেমপ্লেট ব্যবহার করে একটি সমস্যা তৈরি করে এবং এটি পর্যালোচনা না করা উন্মুক্ত সমস্যাগুলির পুলে প্রবেশ করে।
  2. ডেভেলপার এক্সপেরিয়েন্স (DevEx) সাবটিম রোটেশনের একজন সদস্য সমস্যাটি পর্যালোচনা করেন।
    1. সমস্যাটি বাগ বা বৈশিষ্ট্যের অনুরোধ না হলে, DevEx সদস্য সাধারণত সমস্যাটি বন্ধ করে দেবে এবং ব্যবহারকারীকে স্ট্যাকওভারফ্লোতে পুনঃনির্দেশ করবে এবং প্রশ্নটির উচ্চতর দৃশ্যমানতার জন্য বেজেল-আলোচনা করবে।
    2. যদি সমস্যাটি সম্প্রদায়ের মালিকানাধীন নিয়ম ভান্ডারগুলির একটিতে থাকে, যেমন rules_apple , তাহলে DevEx সদস্য এই সমস্যাটিকে সঠিক সংগ্রহস্থলে স্থানান্তর করবে৷
    3. যদি সমস্যাটি অস্পষ্ট হয় বা তথ্য অনুপস্থিত থাকে, তাহলে চালিয়ে যাওয়ার আগে DevEx সদস্য আরও তথ্যের জন্য অনুরোধ করার জন্য ব্যবহারকারীকে সমস্যাটি ফিরিয়ে দেবেন। এটি সাধারণত ঘটে যখন ব্যবহারকারী ইস্যু টেমপ্লেট অনুসরণ করেন না।
  3. সমস্যাটি পর্যালোচনা করার পর, DevEx সদস্য সিদ্ধান্ত নেয় যে সমস্যাটির অবিলম্বে মনোযোগ প্রয়োজন কিনা। যদি তা হয়, তাহলে তারা P0 অগ্রাধিকার লেবেল এবং টিম লিডের তালিকা থেকে একজন মালিক বরাদ্দ করবে।
  4. untriaged মেম্বার রাউটিং এর জন্য অপ্রস্তুত লেবেল এবং ঠিক একটি টিম লেবেল বরাদ্দ করে।
  5. এছাড়াও DevEx সদস্য ঠিক এক type: লেবেল, যেমন type: bug বা type: feature request , সমস্যার ধরন অনুযায়ী।
  6. প্ল্যাটফর্ম-নির্দিষ্ট সমস্যার জন্য, DevEx সদস্য একটি platform: লেবেল, যেমন platform:apple ম্যাক-নির্দিষ্ট সমস্যার জন্য। এই পর্যায়ে, সমস্যাটি অপ্রকাশিত উন্মুক্ত সমস্যাগুলির পুলে প্রবেশ করে।

প্রতিটি Bazel সাবটিম তাদের মালিকানাধীন লেবেলের অধীনে সমস্ত সমস্যা বিচার করবে, বিশেষত একটি সাপ্তাহিক ভিত্তিতে। সাবটিম সমস্যাটি পর্যালোচনা করবে এবং মূল্যায়ন করবে এবং সম্ভব হলে একটি সমাধান প্রদান করবে। আপনি যদি একটি টিম লেবেলের মালিক হন তবে আরও তথ্যের জন্য এই বিভাগটি দেখুন৷

যখন একটি সমস্যা সমাধান করা হয়, এটি বন্ধ করা যেতে পারে।

একটি টান অনুরোধের জীবনচক্র

  1. একজন ব্যবহারকারী একটি টান অনুরোধ তৈরি করে।
  2. আপনি যদি Bazel টিমের একজন সদস্য হন এবং আপনার নিজের এলাকার বিরুদ্ধে PR পাঠান, তাহলে আপনার টিমের লেবেল বরাদ্দ করা এবং সেরা পর্যালোচক খোঁজার জন্য আপনি দায়ী।
  3. অন্যথায়, দৈনিক ট্রাইজের সময়, একজন DevEx সদস্য একটি টিম লেবেল এবং টিমের টেকনিক্যাল লিড (TL) রাউটিং এর জন্য বরাদ্দ করে।
    1. TL ঐচ্ছিকভাবে PR পর্যালোচনা করার জন্য অন্য কাউকে বরাদ্দ করতে পারে।
  4. নির্ধারিত পর্যালোচক PR পর্যালোচনা করেন এবং এটি অনুমোদিত বা বাদ না হওয়া পর্যন্ত লেখকের সাথে কাজ করেন।
  5. অনুমোদিত হলে, পর্যালোচক আরও পরীক্ষার জন্য Google-এর অভ্যন্তরীণ সংস্করণ নিয়ন্ত্রণ ব্যবস্থায় PR-এর প্রতিশ্রুতি(গুলি) আমদানি করে৷ যেহেতু Bazel Google-এ অভ্যন্তরীণভাবে ব্যবহৃত একই বিল্ড সিস্টেম, তাই আমাদের অভ্যন্তরীণ পরীক্ষা স্যুটের বিরুদ্ধে সমস্ত PR প্রতিশ্রুতি পরীক্ষা করতে হবে। এই কারণেই আমরা সরাসরি PRs একত্রিত করি না।
  6. যদি আমদানি করা প্রতিশ্রুতি সমস্ত অভ্যন্তরীণ পরীক্ষায় উত্তীর্ণ হয়, তাহলে প্রতিশ্রুতিটি স্কোয়াশ করা হবে এবং গিটহাবে আবার রপ্তানি করা হবে।
  7. যখন কমিট মাস্টারে একত্রিত হয়, GitHub স্বয়ংক্রিয়ভাবে PR বন্ধ করে দেয়।

আমার দল একটি লেবেল মালিক. আমার কি করা উচিৎ?

সাবটিমগুলিকে তাদের মালিকানাধীন লেবেলে সমস্ত সমস্যা ট্রাইজ করতে হবে, বিশেষত একটি সাপ্তাহিক ভিত্তিতে৷

ইস্যু

  1. আপনার টিম লেবেল এবং untriaged লেবেল দ্বারা সমস্যার তালিকা ফিল্টার করুন।
  2. সমস্যাটি পর্যালোচনা করুন।
  3. একটি অগ্রাধিকার স্তর সনাক্ত করুন এবং লেবেল বরাদ্দ করুন।
    1. যদি এটি একটি P0 হয় তবে DevEx সাবটিম দ্বারা সমস্যাটিকে ইতিমধ্যেই অগ্রাধিকার দেওয়া হতে পারে। প্রয়োজন হলে পুনরায় অগ্রাধিকার দিন।
    2. প্রতিটি সমস্যার ঠিক একটি অগ্রাধিকার লেবেল থাকা প্রয়োজন৷ যদি একটি সমস্যা P0 বা P1 হয় তবে আমরা ধরে নিই যে এটি সক্রিয়ভাবে কাজ করা হয়েছে।
  4. untriaged লেবেল সরান.

মনে রাখবেন লেবেল যোগ করতে বা সরাতে সক্ষম হওয়ার জন্য আপনাকে বেজেলবিল্ড সংস্থায় থাকতে হবে।

অনুরোধ টানুন

  1. আপনার দলের লেবেল দ্বারা পুল অনুরোধের তালিকা ফিল্টার করুন.
  2. খোলা টান অনুরোধ পর্যালোচনা করুন.
    1. ঐচ্ছিক : যদি আপনাকে পর্যালোচনার জন্য নিয়োগ করা হয় কিন্তু আপনি এটির জন্য উপযুক্ত না হন, তাহলে একটি কোড পর্যালোচনা করার জন্য উপযুক্ত পর্যালোচককে পুনরায় বরাদ্দ করুন।
  3. একটি কোড পর্যালোচনা সম্পূর্ণ করতে পুল অনুরোধ নির্মাতার সাথে কাজ করুন।
  4. পিআর অনুমোদন করুন।
  5. নিশ্চিত করুন যে সমস্ত পরীক্ষা পাস।
  6. অভ্যন্তরীণ সংস্করণ নিয়ন্ত্রণ সিস্টেমে প্যাচ আমদানি করুন এবং অভ্যন্তরীণ প্রিসবমিট চালান।
  7. অভ্যন্তরীণ প্যাচ জমা দিন. যদি প্যাচ জমা দেয় এবং সফলভাবে রপ্তানি করে, তাহলে PR GitHub দ্বারা স্বয়ংক্রিয়ভাবে বন্ধ হয়ে যাবে।

অগ্রাধিকার

অগ্রাধিকারের জন্য নিম্নলিখিত সংজ্ঞাগুলি রক্ষণাবেক্ষণকারীরা সমস্যা সমাধানের জন্য ব্যবহার করবে।

  • P0 - প্রধান ভাঙা কার্যকারিতা যা একটি Bazel রিলিজ (মাইনাস রিলিজ প্রার্থীদের) অব্যবহারযোগ্য হতে পারে, অথবা একটি ডাউনড পরিষেবা যা Bazel প্রকল্পের উন্নয়নকে মারাত্মকভাবে প্রভাবিত করে৷ এর মধ্যে রয়েছে একটি নতুন রিলিজে প্রবর্তিত রিগ্রেশন যা উল্লেখযোগ্য সংখ্যক ব্যবহারকারীকে ব্লক করে, অথবা একটি বেমানান ব্রেকিং পরিবর্তন যা ব্রেকিং চেঞ্জ নীতির সাথে সঙ্গতিপূর্ণ ছিল না। কোন ব্যবহারিক সমাধান বিদ্যমান নেই.
  • P1 - গুরুতর ত্রুটি বা বৈশিষ্ট্য যা পরবর্তী রিলিজে সমাধান করা উচিত, বা একটি গুরুতর সমস্যা যা অনেক ব্যবহারকারীকে প্রভাবিত করে (ব্যাজেল প্রকল্পের বিকাশ সহ), কিন্তু একটি বাস্তব সমাধান বিদ্যমান। সাধারণত অবিলম্বে পদক্ষেপের প্রয়োজন হয় না। বর্তমান ত্রৈমাসিকের রোডম্যাপে উচ্চ চাহিদা এবং পরিকল্পিত।
  • P2 - ত্রুটি বা বৈশিষ্ট্য যা সমাধান করা উচিত কিন্তু আমরা বর্তমানে কাজ করি না। একটি মুক্তিপ্রাপ্ত Bazel সংস্করণে মধ্যম লাইভ সমস্যা যা একটি ব্যবহারকারীর জন্য অসুবিধাজনক যা ভবিষ্যতের রিলিজে সমাধান করা প্রয়োজন এবং/অথবা একটি সহজ সমাধান বিদ্যমান।
  • P3 - পছন্দসই ছোটখাট বাগ ফিক্স বা ছোট প্রভাব সহ বর্ধিতকরণ। Bazel রোডম্যাপ বা কোনো আসন্ন প্রকাশে অগ্রাধিকার দেওয়া হয়নি, তবে সম্প্রদায়ের অবদানগুলিকে উৎসাহিত করা হয়।
  • P4 - কম অগ্রাধিকার ত্রুটি বা বৈশিষ্ট্য অনুরোধ যা বন্ধ হওয়ার সম্ভাবনা নেই। আরও ব্যবহারকারী প্রভাবিত হলে সম্ভাব্য পুনরায় অগ্রাধিকারের জন্যও খোলা রাখা যেতে পারে।
  • বরফের বাক্স
    • যে সমস্যাগুলি আমাদের কাছে মোকাবেলা করার সময় নেই এবং অবদান গ্রহণ করার সময় নেই৷ আমরা এই সমস্যাগুলি বন্ধ করে দিব যাতে বোঝা যায় যে কেউ এগুলি নিয়ে কাজ করছে না, তবে সময়ের সাথে সাথে তাদের বৈধতা নিরীক্ষণ করা চালিয়ে যাব এবং যদি যথেষ্ট লোক প্রভাবিত হয় এবং যদি আমাদের কাছে তাদের মোকাবেলা করার জন্য সংস্থান থাকে তবে সেগুলিকে পুনরুজ্জীবিত করব৷ বরাবরের মতো, বন্ধ থাকা সত্ত্বেও এই সমস্যাগুলিতে মন্তব্য করতে বা প্রতিক্রিয়া যোগ করতে নির্দ্বিধায়।

টিম লেবেল

  • team-Android : Android দলের জন্য সমস্যা
  • team-Bazel : সাধারণ বেজেল পণ্য/কৌশল সমস্যা
  • team-Build-Language : BUILD, .bzl API এবং Stardoc-এর জন্য সমস্যা।
  • team-Configurability : কনফিগারেবিলিটি টিমের জন্য সমস্যা
  • team-Core : মূল দলের জন্য সমস্যা
    • যোগাযোগ: haxorz
  • team-Documentation : ডকুমেন্টেশন দলের জন্য সমস্যা
  • team-ExternalDeps : বাহ্যিক নির্ভরতা হ্যান্ডলিং, Bzlmod, দূরবর্তী সংগ্রহস্থল, WORKSPACE ফাইল
  • team-Local-Exec : এক্সিকিউশন (স্থানীয়) দলের জন্য সমস্যা
  • team-OSS : ব্যাজেল ওএসএস টিমের সমস্যা: ইনস্টলেশন, রিলিজ প্রক্রিয়া, ব্যাজেল প্যাকেজিং, ওয়েবসাইট, ডক্স অবকাঠামো
  • team-Performance : ব্যাজেল পারফরম্যান্স দলের জন্য সমস্যা
  • team-Remote-Exec : এক্সিকিউশন (রিমোট) দলের জন্য সমস্যা
  • team-Rules-CPP : C++ নিয়মের সমস্যা, যার মধ্যে নেটিভ অ্যাপল রুল লজিক রয়েছে
  • team-Rules-Java : জাভা নিয়মের জন্য সমস্যা
    • যোগাযোগ: comius
  • team-Rules-Python : স্থানীয় পাইথন নিয়মের সমস্যা
    • যোগাযোগ: comius
  • team-Rules-Server : Bazel-এর সাথে অন্তর্ভুক্ত সার্ভার-সাইড নিয়মের সমস্যা
    • যোগাযোগ: comius
  • team-Starlark-integration : নন-এপিআই বেজেল + স্টারলার্ক ইন্টিগ্রেশন। অন্তর্ভুক্ত: ব্যাজেল কীভাবে স্টারলার্ক ইন্টারপ্রেটার, স্টারডক, বিল্টিন ইনজেকশন, ক্যারেক্টার এনকোডিং ট্রিগার করে। এতে অন্তর্ভুক্ত নয় : BUILD বা .bzl ভাষার সমস্যা।
  • team-Starlark-interpreter : স্টারলার্ক দোভাষীর জন্য সমস্যা ( java.net.starlark- এ যেকোনো কিছু)। BUILD এবং .bzl API সমস্যাগুলি (যা স্টারলার্কের সাথে ব্যাজেলের একীকরণের প্রতিনিধিত্ব করে) team-Build-Language যায়।

নতুন সমস্যাগুলির জন্য, আমরা category: * টিম লেবেলের পক্ষে লেবেল।

এখানে লেবেলের সম্পূর্ণ তালিকা দেখুন।