কিছু ওপেন সোর্স প্রকল্পগুলি কেন টানার অনুরোধগুলি গ্রহণ করে না, তবে কেবল প্যাচ ফাইলগুলিতে ইমেল করছে

Question

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

Comments

"পুল রিকোয়েস্ট" কী (সন্ধানটি কখনই ব্যবহৃত হয় না এবং এটি সকল এসসিএমের পক্ষে সাধারণ নয়), আপনি মনে করেন যে "হেই, আমি আমাকে এখানে পরিবর্তন করেছিলাম!" অন্যরা চাইলে এটিকে আপনার কাছ থেকে নিয়ে নিতে এবং পর্যালোচনা করতে পারে। আপনি অফলাইনে গেলে কি এই কাজ করে? যদি তা না হয় তবে প্যাচ ইমেলগুলি পছন্দ করার পক্ষে এটি দুর্দান্ত কারণ।

— এডওয়ার্ড স্ট্রেঞ্জ

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

— জন বার্থোলোমিউ

প্যাচফায়ারগুলি সর্বজনীনভাবে সমর্থিত। টানুন অনুরোধগুলি বিক্রেতা-নির্দিষ্ট। আপনি কেন রক্ষণাবেক্ষণকারীদের এগুলি গ্রহণ করবেন বলে আশা করবেন?

— বেনামে

Answer 1

এটি আপনার টানার অনুরোধ গ্রহণের দায়িত্বে কে থাকবে তার উপর নির্ভর করতে পারে।

যদি এটি লিনাস টরভাল্ডস হয় তবে ভাল ... একটি ভাল পুরানো প্যাচই পছন্দনীয় :

আমি গিথব টান অনুরোধ করি না

গিথুব প্রাসঙ্গিক সমস্ত তথ্য ফেলে দেয়, যেমন আমাকে টানতে বলছে এমন ব্যক্তির জন্য একটি বৈধ ইমেল ঠিকানাও রয়েছে ।
ডিফস্ট্যাটটিও ঘাটতি এবং অকেজো।

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

এটি হোস্টিংয়ের পক্ষে ঠিক আছে , তবে টানার অনুরোধ এবং অনলাইন কমিট সম্পাদনা কেবল খাঁটি আবর্জনা।
আমি আমার উদ্বেগগুলি সম্পর্কে গিথুবকে বলেছি, তারা ভাবেনি তারা মাতামাতি করে, তাই আমি হাল ছেড়ে দিয়েছি। গিথুব এ বাগেরপোর্ট নির্দ্বিধায় করুন।

তিনি বিশদ:

জন্য জন্য আমাকে GitHub থেকে টান জন্য, আপনাকে প্রয়োজন:

• (ক) সত্যই টানার অনুরোধ করুন, যখন আপনি যখন টানার জন্য অনুরোধ করবেন তখন গিথুব যে ব্রেনডমেজড ক্র্যাম্প করে তা নয়:
  • আসল ব্যাখ্যা ,
  • সঠিক ইমেল ঠিকানা ,
  • যথাযথ শর্টলগ , এবং
  • সঠিক diffstat ।
• (খ) যেহেতু গিথুব পরিচয়গুলি এলোমেলো, তাই আমি টান অনুরোধটি একটি স্বাক্ষরিত ট্যাগ হওয়ার প্রত্যাশা করি , যাতে আমি প্রশ্নযুক্ত ব্যক্তির পরিচয় যাচাই করতে পারি।

গিথুব ওয়েব ইন্টারফেসের মাধ্যমে করা কমিটগুলি টানতেও আমি অস্বীকার করি।
আবার, এর কারণ হ'ল গিথুব ওয়েব ইন্টারফেসটি যেভাবে কাজ করে, সেই কমিটগুলি অবিচ্ছিন্ন খাঁটি বাজে।
GitHub সম্পন্ন করে অপরিবর্তনীয়ভাবে সম্পূর্ণভাবে অপাঠ্য বিবরণ হচ্ছে, কারণ GitHub উপার্জন কমিট জিনিস করে না কোন সহজ জিনিস যে কার্নেল মানুষ আশা একটি বার্তা কমিট থেকে:

• কোনও "প্রথম লাইনে সংক্ষিপ্ত এক-লাইনের বর্ণনা" নেই
• আপনার যে দীর্ঘ বিবরণটি টাইপ করা হয়েছে তার কোনও বুদ্ধিমান শব্দ-মোড়ানো নয়: গিথুব কমিট বার্তাগুলি একটি দীর্ঘ অপঠনযোগ্য লাইন হতে পারে (যদি তাদের কোনও বর্ণনা থাকে তবে)।
• কার্নেল জমা দেওয়ার জন্য আমাদের প্রয়োজন এমন কোনও সাইন-অফস নেই।

GitHub পারে সহজ ভাল লিখতে করতে বার্তা কমিট এবং যথাযথ "shortlogs এবং জন্য oneliner জোরদার gitk, পূর্ণ লগ পূর্ণ ব্যাখ্যা"।
তবে গিথুব তা করে না।
পরিবর্তে, গিথুব "ওয়েবে কমিট করুন" ইন্টারফেসটি হ'ল একমাত্র ভয়ঙ্কর পাঠ্য-প্রবেশের ক্ষেত্র, যাতে কোনও সুদর্শন বার্তা লেখার কোনও বুদ্ধিমান উপায় নেই।

প্রতিশ্রুতিবদ্ধ বার্তাগুলির জন্য পাঠ্য অঞ্চলে চ্যালেঞ্জ জানানো হলে:

@torvalds গিটহাব কমিট ইউআই কমিট বার্তাগুলির জন্য একটি পাঠ্য অঞ্চল সরবরাহ করে।
এটি নতুন লাইনগুলিকে সমর্থন করে এবং সুন্দর বিন্যাসিত প্রতিশ্রুতি বার্তাগুলি করা সহজ করে তোলে :)

না এটা হয় না।
এটি যা সমর্থন করে তা হ'ল দীর্ঘ লাইনগুলি লিখুন যে আপনি কতটা দীর্ঘ af
পাঠ্য অঞ্চলটি আপনার জন্য লাইন বিরতি দেয় না এবং লাইন বিরতি কোথায় যাবে তা বিচার করার আপনার কোনও উপায় নেই।

অন্য কথায়, এটি "দুর্দান্ত ফর্ম্যাট কমিট ম্যাসেজগুলি" করা সত্যিই খুব শক্ত করে তোলে।
এটি শর্টলগের জন্য তুচ্ছ "অনেলাইনার" মডেলটিও প্রয়োগ করে না , তাই প্রতিশ্রুতিবদ্ধ বার্তাগুলি প্রায়শই শর্টল্যাজে এবং গিটকে মোট ক্রেপের মতো দেখায়।

গিথুব কমিট ইউআই হওয়া উচিত

• "শর্টলগ" ওয়ান-লাইন পাঠ্য উইন্ডোটি পৃথক করুন, যাতে লোকেরা এটিকে স্ক্রু করতে না পারে।
• মানক 72-কলাম চিহ্নটিতে আসলে বুদ্ধিমান শব্দ-মোড়ানো করার কিছু উপায়।
• সাইন-অফস ইত্যাদি সম্পর্কে অনুস্মারক যা কিছু প্রকল্পের জন্য প্রকল্প-নির্দিষ্ট বা এমনকি আইনি কারণে প্রয়োজন।

Comments

বা সংক্ষিপ্ত সংস্করণ; প্রকল্পের মালিক সে / সে চাইলে চালাতে পারে। যদি তারা পরিবর্তনগুলির স্নেল মেল হার্ড কপি করার জন্য জোর দেয় তবে আপনাকে এটি জমা দিতে হবে (যেমনটি হবে তেমন প্রতিবন্ধক)।

— কেন হেন্ডারসন

যদি প্রতিশ্রুতি প্রকল্পের মালিকের প্রয়োজনীয়তা পূরণ না করে তবে তিনি চেরি-বাছাই করতে পারেন এবং তারপরে যা চান তা কমিটিকে সংশোধন করতে পারেন। অন্য কোনও বিকাশকারীদের দ্বারা প্রদত্ত যে অবদান রয়েছে তা মূল্যবান হওয়া গুরুত্বপূর্ণ। প্রকল্পের মালিক কেবল কমিট ফর্ম্যাটটি পূরণ না করার কারণে যদি অবদানগুলি সহজভাবে অস্বীকার করেন তবে এটি অত্যন্ত দুঃখের বিষয়।

— লুইকুইজ করুন

@ লিঙ্কাইজ ওপেন সোর্স প্রকল্পগুলিতে সাধারণত ম্যান পাওয়ারের অভাব থাকে hতাদের 'চেরি-পিক এবং সংশোধন' সময় বাঁচানো যায়।

— দুর্বল করুন

"দীর্ঘ রেখাগুলি লিখছেন যে আপনি কতটা দীর্ঘ af ইতিমধ্যে এটি সমাধান হয়ে গেছে বলে মনে হচ্ছে, এখন এটি আপনাকে দীর্ঘ-দীর্ঘ প্রথম লাইনের বিষয়ে কঠোরভাবে সতর্ক করে, এবং সংক্ষিপ্ত এবং বিস্তারিত বার্তার জন্য দুটি পৃথক পাঠ্য বাক্স রয়েছে।

— হেল্টনবাইকার

লিনাস গিথুব বাস্তবায়নের বিষয়ে অভিযোগ করে তবে এর অর্থ এই নয় যে সাধারণভাবে সাধারণভাবে অনুরোধ করার অনুরোধগুলি খারাপ। আসলে, একটি দুর্দান্ত ইন্টারেক্টিভ ওয়েব ইন্টারফেস যা ফাইলগুলি আমদানি / রফতানির পরিবর্তে

— গিটের