การอัพเดทซอฟต์แวร์โอเพ่นซอร์สเมื่อไม่มีตัวเลือกการอัพเกรดหรือไม่?


13

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

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

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

ในสายตาของพวกเขาเพราะการเปลี่ยนแปลงรหัสนี้ทำโดยเราเพียงเพื่อการใช้งานของเรามันจะต้องเป็นส่วนหนึ่งของฐานรหัสของเราซึ่งหมายความว่าแทนที่จะแนะนำซอฟต์แวร์โอเพ่นซอร์สเป็นการพึ่งพาบุคคลที่สามเราต้องแนะนำมันเป็นโครงการใหม่และรวม การสร้างอัตโนมัติในกระบวนการสร้างของเรา

สำหรับฉันฉันคิดว่านี่เป็นสิ่งที่ผิดเนื่องจากเราจะดึงรหัสของพวกเขาจากแหล่งเก็บข้อมูลการควบคุมแหล่งข้อมูลลงในเราและเราจะสูญเสียประวัติหลังการเปลี่ยนแปลงรหัสใด ๆ ที่เกิดขึ้นก่อนหน้านั้น ดูเหมือนว่าบางสิ่งที่ซับซ้อนเกินไปสำหรับการเปลี่ยนรหัสเล็ก ๆ ที่ต้องทำ

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


1
โปรดแจ้งให้เราทราบหากคุณคิดว่าคำถามนั้นไม่สร้างสรรค์หรือสามารถปรับปรุงได้
maple_shaft

หากคุณไม่สามารถอัปเดตเครื่องมือที่รวมอยู่ในซอฟต์แวร์ของคุณสิ่งที่คุณทำได้คือแก้ไขเครื่องมือเพื่อแก้ไขข้อบกพร่อง สิ่งสำคัญคือต้องไม่อัปเดตเครื่องมือหากหมายถึงการเปลี่ยนรหัสของคุณเอง
Ramhound

คำตอบ:


12

หากคุณไม่สามารถใช้รุ่นที่ใหม่กว่าที่ไม่มีปัญหาที่คุณประสบอยู่ตัวเลือกเดียวที่คุณต้องทำก็คือ

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


ฉันอยู่ในตำแหน่งของคุณแล้วตัวเลือก 2 (สร้างทางแยกที่กำหนดเอง) มักเป็นโซลูชันที่น่าพึงพอใจที่สุดที่มีอยู่ นั่นคือชีวิตเมื่อต้องจัดการกับห้องสมุดโอเพ่นซอร์สโดยเฉพาะอย่างยิ่งสิ่งที่วิวัฒนาการอย่างรวดเร็วและมีนิสัยไม่ดีที่จะทำลายความเข้ากันได้ระหว่างการเผยแพร่ย้อนหลัง (ซึ่งจากประสบการณ์ของฉันเป็นเหตุผลที่พบได้บ่อยที่สุด
สำหรับไลบรารี่ OSS มากกว่าสองสามตัวมันทำให้ฉันและทีมฉันเป็นส่วนหนึ่งของการห่อคำสั่งรอบ ๆ และทั้งหมดและเข้าถึงการทำงานของไลบรารี่ของบุคคลที่สามผ่านทางการห่อหุ้มเหล่านั้น ด้วยวิธีนี้ถ้าเราต้องการแทนที่ไลบรารี่ของบุคคลที่สามด้วยเวอร์ชันที่แตกต่างกันมากจนรหัสของเราพังทลายการเปลี่ยนแปลงอย่างน้อยก็ จำกัด อยู่ในเสื้อคลุมนั้น มันไม่ใช่วิธีที่ดีที่สุด (เพิ่มรหัสสามารถเพิ่มความซับซ้อนและประสิทธิภาพด้านต้นทุน) แต่บางครั้งก็เป็นวิธีเดียวที่จะรักษาความมีสติ


! ที่น่าสนใจ ฉันไม่เคยพิจารณาความเป็นไปได้ของการห่อห้องสมุดเพื่อช่วย decoupling ขอบคุณสำหรับข้อมูลของคุณ!
maple_shaft

wrappers เป็นความคิดที่ดีถ้าคุณใช้มันจากตารางหนึ่ง หากคุณใช้ไลบรารีโดยตรงการสลับไปใช้ wrapper ทั่วไปจะต้องมีการเปลี่ยนโครงสร้างใหม่และทดสอบรหัสจำนวนมากอีกครั้ง
Blrfl

1
@Blrfl ใช่นั่นเป็นเหตุผลว่าทำไมจึงไม่ใช่ขั้นตอนที่ต้องดำเนินการเบา ๆ แต่ในกรณีอย่างน้อยหนึ่งกรณีเรามีห้องสมุดบุคคลที่สาม (OSS) เปลี่ยนแพคเกจและชื่อคลาสทั้งหมดระหว่างการเผยแพร่เล็กน้อย 2 รายการและไม่มีการขอความช่วยเหลือ แต่ต้องนำมาใช้ ด้วยวิธีนี้เราได้รับการพิสูจน์ในอนาคตเช่นเดียวกับการแก้ไขปัญหาที่ทำให้เกิดความต้องการใช้เวอร์ชันใหม่
jwenting

@ jwenting: เห็นด้วยอย่างแน่นอน ฉันทำสิ่งเดียวกันกับ Boost เพราะในขณะที่การใช้งานบางอย่างของพวกเขาดีอินเตอร์เฟซสามารถป้าน และพวกเขาก็มักจะเปลี่ยนแปลงสิ่งต่าง ๆ บ่อยครั้งเช่นกัน
Blrfl

2
โปรดทราบว่า Linux ดิสทริบิวชันบางตัวสามารถรักษา“ ส้อม” ของซอฟต์แวร์ได้อย่างมีประสิทธิภาพโดยการแบ็กอัพแพตช์ความปลอดภัยไปยังรีลีสก่อนหน้า
liori

6

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

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


3

ไม่มีอะไรผิดปกติกับการทำเช่นนั้นตราบใดที่ทุกคนสามารถลดต้นทุนผลประโยชน์และความเสี่ยง

... การแก้ไขดูเหมือนง่ายพอที่จะแก้ไขรหัสด้วยตัวเอง

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

... ผู้ว่าต้องการที่จะโต้แย้งในกรณีที่เกือบจะเป็นความคิดที่ไม่ดีเพราะมันมีความเสี่ยงและมีความซับซ้อนที่ยุ่งยาก

มันเป็นความคิดที่ไม่ดีถ้าคุณไม่มีคนสับที่จะจัดการโค้ดของคนอื่นโดยแยกแยะระบุปัญหาและเขียนวิธีแก้ไข นั่นเป็นความจริงไม่ว่าจะเป็นรหัสใน บริษัท หรือบุคคลที่สาม ความแตกต่างเพียงอย่างเดียวคือไม่ว่ามันจะถูกโยนข้ามห้องเล็ก ๆ หรือผนังอาคารก่อนที่มันจะตกลงบนตัก

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

... การเปลี่ยนแปลงรหัสทำได้โดยเรา ... มันจะต้องเป็นส่วนหนึ่งของฐานรหัสของเรา ... เราจะต้องแนะนำมันเป็นโครงการใหม่และรวมการสร้างอัตโนมัติในกระบวนการสร้างของเรา

หากคุณกำลังแก้ไขโปรแกรมแก้ไขนั้นเป็นส่วนหนึ่งของรหัสของคุณเองซึ่งหมายความว่าคุณต้องทำให้เป็นส่วนหนึ่งของกระบวนการของคุณ สิ่งนี้ไม่ได้แตกต่างไปจากการเพิ่มรหัส 100% ให้กับระบบของคุณ ปฏิบัติต่อการแจกจ่ายของบุคคลที่สามเป็นที่เคารพสักการะและนำไปใส่ในโมดูลเหมือนกับซอร์สโค้ด แพทช์ที่คุณเขียนจะถูกเก็บไว้ในไฟล์แยกและนำไปใช้เป็นส่วนหนึ่งของกระบวนการสร้าง ด้วยวิธีนี้คุณจะไปจากแหล่งที่มาที่สะอาดไปยังแหล่งที่ได้รับการแก้ไขไปยังผลิตภัณฑ์ที่สร้างขึ้นและสามารถแสดงสิ่งที่เกิดขึ้นได้อย่างแน่นอน (ผู้คนบางคนแกะแพทช์มือแพ็คใหม่และเก็บไว้ในการควบคุมเวอร์ชันนั่นแย่มาก)

... เราจะดึงรหัสของพวกเขาจากแหล่งเก็บข้อมูลการควบคุมของพวกเขาเป็นของเราและเราสูญเสียประวัติหลังการเปลี่ยนแปลงรหัสใด ๆ ...

หากคุณกำลังรักษาห้องสมุดบุคคลที่สามเป็นการพึ่งพาบุคคลที่สามคุณไม่มีประวัตินั้นเริ่มต้นด้วยและคุณจะไม่สูญเสียอะไรเลย หากคุณมีการเข้าถึงที่เก็บของบุคคลที่สามอย่างต่อเนื่องคุณสามารถปรึกษาที่คุณต้องการ การเผยแพร่ของบุคคลที่สามควรได้รับการปฏิบัติเหมือนเป็น amorphous blobs ที่คุณตรวจสอบในระบบของคุณเองโดยไม่เปลี่ยนแปลง หากคุณต้องการดูการเปลี่ยนแปลงระหว่างรุ่นที่คุณกำลังใช้และรุ่นที่ใหม่กว่าคุณสามารถทำเช่นนั้นได้และหากคุณต้องการให้มี patch เป็นเวอร์ชันเก่าที่รวมการเปลี่ยนแปลงที่คุณต้องการ

ดูเหมือนว่าบางสิ่งที่ซับซ้อนเกินไปสำหรับการเปลี่ยนรหัสเล็ก ๆ ที่ต้องทำ

หากกระบวนการสร้างของคุณมีความซับซ้อนเพียงพอการเพิ่มสิ่งนี้ไม่ควรยากกว่าการเพิ่มรหัสของคุณเอง มีแรงงานจำนวนเล็กน้อยในการทำให้ถึงจุดที่กระบวนการแกะ / แพ็ค / สร้างเป็นอัตโนมัติ แต่เมื่อทำเสร็จแล้วจะทำตลอดไป อาจมีข้อบกพร่องหนึ่งข้อในขณะนี้ แต่อาจมีอีกยี่สิบในอนาคต หากมีคุณจะมีความสุขมากขึ้นที่คุณวางรากฐานเพื่อรองรับสิ่งเหล่านี้ในตอนนี้เพราะมันจะทำให้การทำงานต่อไปของคุณมีน้อยลง 19 ข้อ


2

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

หากโครงการโอเพนซอร์สที่สงสัยอนุญาตให้มีส่วนร่วมแก้ไขข้อบกพร่องของคุณพอร์ตกลับไปยังพื้นที่เก็บข้อมูล นั่นคือถ้าคุณใช้เวอร์ชัน 1.5.2 และเวอร์ชันที่เสถียรในปัจจุบันคือ 1.6.1 ให้ส่ง patch เป็น 1.5.2 หากได้รับการนำไปใช้คุณสามารถดึงแหล่งข้อมูลคงที่โดยตรงจากที่เก็บ (อาจเป็นรุ่น 1.5.3) และทำให้ทุกคนมีความสุข

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

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