ข่าวร้าย, Emacs
(eshelyaron.com)ปัญหาของ Emacs เวอร์ชัน 30 และการกำเนิดของเวอร์ชัน fork
- มาสเตอร์บรานช์ของ Emacs เสียหายจากการเปลี่ยนแปลงครั้งใหญ่ แม้จะมีความกังวลจากทั้งผู้ใช้และนักพัฒนา
- การเปลี่ยนแปลงดังกล่าวทำให้การโต้ตอบกับรีจิสเตอร์ของ Emacs ไม่สะดวก และแม้แต่งานง่าย ๆ ก็ต้องกดคีย์เพิ่ม
- ผู้เขียนได้สร้างเวอร์ชัน fork ที่ปรับปรุงแล้วขึ้นมาเพื่อใช้งานและพัฒนาต่อ และยินดีต้อนรับผู้ที่สนใจเข้าร่วม
ความเสถียรของมาสเตอร์บรานช์ Emacs และการเปลี่ยนแปลงล่าสุด
- มาสเตอร์บรานช์ของ Emacs เป็นเวอร์ชันสำหรับพัฒนา ซึ่งมีผู้ใช้ที่ต้องการสัมผัสความคืบหน้าล่าสุดติดตามใช้งานอยู่
- ตลอดหลายปีที่ผ่านมา มาสเตอร์บรานช์มีความเสถียรมากจากความพยายามของผู้ดูแล Emacs
- แต่การเปลี่ยนแปลงล่าสุดทำให้ผู้ใช้ต้องพบกับความประหลาดใจที่ไม่น่าพอใจ
ประสบการณ์ผู้ใช้ที่แย่ลงและปฏิกิริยาของชุมชน
- การเปลี่ยนแปลงใหม่นี้ทำให้ประสบการณ์ผู้ใช้แย่ลง และมีเสียงเรียกร้องมากขึ้นให้สามารถเลือกคืนค่าพฤติกรรมเดิมที่มีประสิทธิภาพได้
- แม้สมาชิกในชุมชนจะแสดงความเห็นอย่างชัดเจน แต่ปัญหาก็ยังไม่ถูกแก้ไข เพราะท่าทีของนักพัฒนาที่ปกป้องการเปลี่ยนแปลงนี้
- ผู้ดูแลแสดงท่าทีว่าจะยืนยันการเปลี่ยนแปลงต่อไป แม้ต้องแลกกับประสบการณ์ผู้ใช้ก็ตาม
การพัฒนาเวอร์ชัน fork ใหม่และเสรีภาพของผู้ใช้
- ผู้เขียนซึ่งให้ความสำคัญกับเสรีภาพของผู้ใช้ ปฏิเสธที่จะถูกบังคับให้ยอมรับการเปลี่ยนแปลงแปลก ๆ ของ Emacs เดิม และจึงสร้างเวอร์ชัน fork ใหม่ขึ้นมา
- เวอร์ชัน fork นี้เลือกดึงมาเฉพาะการเปลี่ยนแปลงที่ดีจากมาสเตอร์บรานช์ และยังได้รับการปรับปรุงเพิ่มเติมจากการพัฒนาของผู้เขียน
- ผู้ที่สนใจเวอร์ชัน fork สามารถโคลนได้จากรีโพซิทอรีของผู้เขียน และยินดีรับทั้งความร่วมมือและข้อเสนอแนะ
ความเห็นของ GN⁺
ประเด็นสำคัญที่สุดของบทความนี้คือประสบการณ์ผู้ใช้ที่แย่ลงใน Emacs เวอร์ชัน 30 และปฏิกิริยาของชุมชนต่อเรื่องนี้ Emacs เป็นที่รักของนักพัฒนามาอย่างยาวนานจากความสามารถในการปรับแต่งและการขยายระบบได้ จึงมีความสนใจสูงว่าการเปลี่ยนแปลงเช่นนี้จะส่งผลต่อผู้ใช้อย่างไร นอกจากนี้ กระบวนการที่นักพัฒนาคนหนึ่งเพิกเฉยต่อเสียงของชุมชนและผลักดันการเปลี่ยนแปลงของตนเอง ก็เป็นกรณีศึกษาที่น่าสนใจเกี่ยวกับการตัดสินใจและวัฒนธรรมการทำงานร่วมกันในโครงการโอเพนซอร์ส บทความนี้แสดงให้เห็นอย่างชัดเจนว่าผู้ใช้ตอบสนองต่อการเปลี่ยนแปลงของซอฟต์แวร์อย่างไร และค้นหาทางออกของตนเองเมื่อจำเป็นได้อย่างไร
1 ความคิดเห็น
ความเห็นจาก Hacker News
เมื่อมีการเปลี่ยนแปลงสำคัญเกิดขึ้นใน development branch ของ Emacs และผู้ใช้บางส่วนแสดงความกังวล การเปลี่ยนแปลงนั้นจะไม่ถูกย้อนกลับทันที แต่จะมีการถกข้อดีข้อเสีย ทดลองและปรับปรุงวิธีแก้หลายแบบ และท้ายที่สุดจึงหาจุดประนีประนอมร่วมกัน
มี commit ที่เปลี่ยนวิธีการทำงานของการคัดลอกใน Emacs (หรือโดยทั่วไปเรียกว่าฟีเจอร์ "register") ซึ่งเพิ่งถูกรับเข้ามาเมื่อไม่นานนี้ ตอนนี้ Emacs จะเปิด minibuffer เพื่อแสดงสิ่งที่เกิดขึ้น และบังคับให้ผู้ใช้กด Enter เพื่อยอมรับการเปลี่ยนแปลง
จากการตรวจดู mailing list ดูเหมือนว่าจะมีตัวเลือกสำหรับย้อนพฤติกรรมนี้กลับได้
ใน Emacs ควรมองว่า muscle memory เป็นปัจจัยสำคัญที่ต้องคำนึงถึง
จากมุมมองของนักพัฒนา ผู้ใช้ที่ต้องการความเสถียรควรใช้ release branch หรือ pin commit ไว้บน master ส่วน development branch มีไว้สำหรับพัฒนาฟีเจอร์ที่ยังดำเนินอยู่ และบางครั้งการเปลี่ยนแปลงลักษณะนี้ก็อาจเกิดขึ้นได้บ่อย
ผู้เขียนมีท่าทีค่อนข้างดื้อ และชี้ว่าคนที่ใช้ฟีเจอร์นี้มีน้อยมาก การที่ผู้ดูแลซึ่งไม่ได้รับค่าตอบแทนเปลี่ยนอะไรเล็กน้อยโดยไม่ปรึกษาก่อน ไม่ควรถูกมองว่าเป็นการ "ทำลาย" master branch
แม้จะเลิกใช้ Emacs ไปแล้ว 20 ปี แต่ก็เข้าใจว่าการเปลี่ยนแปลงนี้ชวนสับสนพอสมควร และไม่เข้าใจว่าทำไม Emacs ซึ่งภูมิใจกับความเป็น "อ่างล้างจานในครัว" ถึงไม่เพิ่มตัวเลือกให้กลับไปใช้พฤติกรรมเดิม
แก่นของ Emacs คือมันเป็นแพลตฟอร์มที่ปรับแต่งได้สูงมาก ถ้าไม่ชอบพฤติกรรมของฟีเจอร์ใด ก็สามารถแก้เองได้ด้วยโค้ด Lisp ไม่กี่บรรทัด การจะ fork ทั้งโปรเจกต์เพราะการเปลี่ยนฟีเจอร์เพียงอย่างเดียวจึงไม่สมเหตุสมผล
ดูเหมือนว่าทางออกเดียวคือพยายามทำ fork/การเขียนใหม่ของ Emacs อีกครั้ง คราวนี้คงจะสำเร็จอย่างแน่นอน และก็คงจะไม่ได้ไม่เกี่ยวข้องอะไรเลย เหมือนกับทุกครั้งที่ผ่านมา
แล้วข้อโต้แย้งจาก "อีกฝั่ง" ต่อการเปลี่ยนแปลงนี้คืออะไร? การเปลี่ยนแปลงที่มีความเห็นแตกต่างกันแบบนี้มักมีเหตุผลที่สมเหตุสมผลอยู่เบื้องหลัง หรืออาจจะไม่มีก็ได้