คุณมีส่วนร่วมกับ Patch ใน Drupal อย่างไร


10

กระบวนการที่เหมาะสมในการมีส่วนร่วมกับ Patch ใน Drupal คืออะไร

สมมติว่าผมพบข้อผิดพลาดใน Drupal หลักแก้ไขได้และสร้างแพทช์ ฉันจะส่งมันได้อย่างไร

หากข้อผิดพลาดอยู่ใน Drupal 7 ฉันต้องแก้ไขใน Drupal 8 และส่งสองชุดหรือไม่ สิ่งนี้ยังใช้กับข้อบกพร่องเอกสาร / การปรับปรุง?

แพตช์ทั้งหมดต้องใช้การทดสอบหน่วยหรือไม่


3
ในขณะนี้ฉันกำลังมองหาคำตอบสมมติว่าฉันมีบัญชีใน drupal.org รู้วิธีใช้ git รู้วิธีตรวจสอบ core และรู้วิธีสร้าง git patches เมื่อเรามีคำตอบที่ดีเราสามารถใส่คำอธิบายหรือเพิ่มคำตอบเพื่อร่างกระบวนการนี้
mpdonadio

เนื่องจากนี่เป็นการตอบสนองต่อปัญหาที่ผู้ดูแลระบบหลักยกมาที่meta.drupal.stackexchange.com/questions/2325การประกาศเรื่องการประกาศจะถูกบังคับใช้ เราต้องการบทสรุปที่ดีของกระบวนการโดยเฉพาะอย่างยิ่งเกี่ยวกับคำถามข้างต้น คำตอบที่เพิ่งลิงก์ไปยังหน้าอื่น ๆ จะถูกลดระดับลงและ / หรือถูกลบ ฉันหวังว่าคำถามนี้จะทำหน้าที่เป็นแหล่งข้อมูลที่เราสามารถชี้ผู้ใช้ DA เมื่อพวกเขาพบปัญหากับแกนกลาง
mpdonadio

คำตอบ:


6

หากข้อผิดพลาดอยู่ใน Drupal 7 ฉันต้องแก้ไขใน Drupal 8 และส่งสองชุดหรือไม่

หากข้อผิดพลาดอยู่ในรุ่นที่ได้รับการพัฒนา (ในกรณีนี้ Drupal 8) และรุ่นก่อนหน้า (Drupal 7) ดังนั้นข้อผิดพลาดควรได้รับการแก้ไขเวอร์ชันที่พัฒนาแล้วในปัจจุบันก่อนจากนั้นในเวอร์ชันก่อนหน้า

หากข้อผิดพลาดไม่ปรากฏในรุ่นที่พัฒนาล่าสุดเช่นข้อผิดพลาดสำหรับฟังก์ชั่นที่ถูกลบหรือมีการเปลี่ยนแปลงแล้วควรแก้ไขให้สำหรับรุ่นก่อนที่จะพัฒนาในปัจจุบัน

เวิร์กโฟลว์ที่ตามมาคือ:

  • ขั้นแรกจะมีการสร้างแพตช์และส่งความเห็นสำหรับเวอร์ชันล่าสุดแม้ว่าจะยังอยู่ระหว่างการพัฒนา (เช่นในกรณีของ Drupal 8)
  • เมื่อแพทช์นั้นถูกนำไปใช้กับ Drupal แล้วแพทช์ที่ใช้กับเวอร์ชันก่อนหน้าจะถูกสร้างขึ้นและส่งเพื่อรับการตรวจสอบ

คุณสามารถสร้างแพตช์สำหรับ Drupal สองรุ่นในเวลาเดียวกัน แต่เนื่องจาก Patch สำหรับ Drupal รุ่นล่าสุดอาจต้องการการเปลี่ยนแปลงจึงเป็นการดีกว่าที่จะทำงานกับ Patch สำหรับเวอร์ชันที่พัฒนาแล้วในปัจจุบัน อาจมีการเปลี่ยนแปลง

ดูเพิ่มเติม: นโยบายย้ายกลับ

สิ่งนี้ยังใช้กับข้อบกพร่องเอกสาร / การปรับปรุง?

ใช่. นอกจากนี้ในกรณีนี้หากเวอร์ชันที่พัฒนาขึ้นในปัจจุบันลบฟังก์ชั่น / วิธีการที่เอกสารอ้างอิงหมายถึงต้องมีการแก้ไขแพตช์สำหรับเวอร์ชันก่อนหน้า

แพตช์ทั้งหมดต้องใช้การทดสอบหน่วยหรือไม่

หากแพทช์มีไว้สำหรับเอกสารก็ไม่จำเป็นต้องทำการทดสอบ บอททดสอบที่ทำงานบนhttp://qa.drupal.orgตรวจสอบรหัส Drupal หลังจากนำแพตช์ไปใช้ หากแพทช์แนะนำข้อผิดพลาดทางไวยากรณ์ (ตัวอย่างเช่นเนื่องจากความคิดเห็นถูกปิดก่อนที่จำเป็น) จากนั้นบอททดสอบจะรายงานข้อผิดพลาดเกี่ยวกับแพทช์ก่อนที่จะทำการทดสอบ

หากแพทช์มีไว้สำหรับคุณสมบัติใหม่ก็จำเป็นต้องทำการทดสอบ

หากแพตช์คือการแก้ไขข้อผิดพลาดอาจต้องทำการทดสอบจากผู้ดูแลหากยังไม่มีการทดสอบที่ตรวจสอบคุณสมบัติเฉพาะ โดยทั่วไปการทดสอบจำเป็นต้องหลีกเลี่ยงการแนะนำข้อผิดพลาดเดียวกันอีกครั้งเมื่อมีการเปลี่ยนแปลงรหัสเดียวกันในอนาคต หากข้อผิดพลาดเป็นเพียงตัวแปรที่เริ่มต้นแล้ว แต่ไม่เคยใช้จากฟังก์ชั่น / วิธีดังนั้นโอกาสในการทดสอบก็ไม่จำเป็น


ปัญหาเดียวกันนี้มีแพตช์สำหรับหลายคอร์ได้ไหม
mpdonadio

1
หากปัญหานี้เกิดขึ้นกับมากกว่าหนึ่งรุ่นมันสามารถมีโปรแกรมแก้ไขสำหรับทุกรุ่นที่สนใจ
kiamlaluno

เป็นกรณีที่ส่งแพตช์ D8 มาก่อนหรือไม่และเป็นเวอร์ชั่น D7 อยู่เสมอหรือไม่ หรือมีกรณีที่ส่งทั้งสองอย่างในเวลาเดียวกันมีความเหมาะสม?
mpdonadio

คุณสามารถส่งแพตช์สำหรับรุ่นที่แตกต่างกันสองแบบ แต่แพทช์ที่ใช้ครั้งแรกนั้นสำหรับเวอร์ชันล่าสุด เป็นการดีกว่าที่จะสร้าง patch ก่อนสำหรับเวอร์ชั่นล่าสุดเนื่องจาก patch อาจต้องมีการเปลี่ยนแปลง
kiamlaluno

3

หน้าทุกโครงการใน drupal.org มีแท็บ "การควบคุมเวอร์ชัน" ที่ด้านบน มันไม่เพียงให้ภาพรวมที่ยอดเยี่ยมของตัวเลือกที่เก็บรหัสทั้งหมดสำหรับโครงการเฉพาะตัวอย่างคำสั่ง git ทั้งหมดยังได้รับการปรับแต่งให้เหมาะกับโครงการ คุณสามารถเปลี่ยนเป็นเวอร์ชันที่ต้องการได้ด้วยเช่นกัน

สำหรับ Drupal core คุณจะพบหน้านั้นในhttp://drupal.org/project/drupal/git-instructions

จากนั้นเมื่อคุณสร้างแพตช์ของคุณคุณก็แค่แนบไฟล์แพตช์กับปัญหาที่อธิบายสิ่งที่คุณทำแพทช์

สิ่งสำคัญสองประการที่ควรชี้ให้เห็นก็คือเพื่อให้แน่ใจว่าแพตช์นั้นลงท้ายด้วย ".patch" และเพื่อตั้งสถานะเป็น "ต้องการการตรวจสอบ" สิ่งนี้เพื่อให้ testbot จะสังเกตเห็นและรันการทดสอบโดยอัตโนมัติ

รหัสใหม่จะต้องมาพร้อมกับการทดสอบเสมอ

โปรดทราบว่านี่เป็นไปได้ที่จะปิดโดยโครงการและบางคนทำ สำหรับแกน Drupal มันเปิดอยู่ดังนั้นทุกโปรแกรมจะถูกทดสอบ

คุณสามารถค้นหาข้อมูลเพิ่มเติมได้ที่http://drupal.org/contribute/development


เป็นการเริ่มต้นที่ดี
mpdonadio
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.