Kabar Buruk, Emacs
(eshelyaron.com)Masalah pada Emacs versi 30 dan lahirnya versi fork
- Cabang master Emacs rusak akibat perubahan besar, meskipun ada kekhawatiran dari pengguna dan pengembang.
- Perubahan tersebut membuat interaksi dengan register Emacs menjadi tidak praktis, dan bahkan untuk tugas sederhana dibutuhkan penekanan tombol tambahan.
- Sebuah versi fork yang diperbaiki sedang dibuat untuk digunakan dan dikembangkan, dan partisipasi dari siapa pun yang tertarik sangat disambut.
Stabilitas cabang master Emacs dan perubahan terbaru
- Cabang master Emacs adalah versi pengembangan, yang diikuti oleh pengguna yang ingin merasakan perkembangan terbaru.
- Dalam beberapa tahun terakhir, berkat upaya para pemelihara Emacs, cabang master sangat stabil.
- Namun, perubahan terbaru membuat pengguna mengalami kejutan yang tidak menyenangkan.
Penurunan pengalaman pengguna dan reaksi komunitas
- Perubahan baru tersebut menurunkan pengalaman pengguna, dan suara yang meminta pemulihan perilaku lama yang lebih efisien sebagai opsi pun makin menguat.
- Meskipun pendapat anggota komunitas sudah jelas, masalah ini tidak terselesaikan karena sikap pengembang yang membela perubahan tersebut.
- Para pemelihara menunjukkan sikap tetap mempertahankan perubahan itu meskipun harus mengorbankan pengalaman pengguna.
Pengembangan versi fork baru dan kebebasan pengguna
- Penulis, yang menganggap kebebasan pengguna penting, menolak dipaksa menerima perubahan aneh pada Emacs yang ada dan membuat versi fork baru.
- Versi fork ini hanya mengambil perubahan-perubahan baik dari cabang master secara selektif, dan juga ditingkatkan lewat pengembangan oleh penulis.
- Orang-orang yang tertarik pada versi fork ini dapat melakukan clone dari repositori penulis, dan kolaborasi serta saran sangat diterima.
Pendapat GN⁺
Hal terpenting dalam tulisan ini adalah penurunan pengalaman pengguna yang terjadi pada Emacs versi 30 dan reaksi komunitas terhadapnya. Emacs telah lama dicintai di kalangan pengembang karena kemampuan kustomisasi dan ekstensibilitasnya, sehingga perhatian terhadap bagaimana perubahan ini memengaruhi pengguna menjadi tinggi. Selain itu, proses seorang pengembang yang mengabaikan pendapat komunitas dan tetap memaksakan perubahannya memberi contoh menarik tentang pengambilan keputusan dan budaya kolaborasi dalam proyek open source. Tulisan ini dengan baik menunjukkan bagaimana pengguna bereaksi terhadap perubahan perangkat lunak dan, bila perlu, mencari solusi mereka sendiri.
1 komentar
Opini Hacker News
Ketika ada perubahan besar di branch pengembangan Emacs dan sebagian pengguna menyampaikan kekhawatiran, perubahan itu tidak langsung dibatalkan. Kelebihan dan kekurangannya didiskusikan, berbagai solusi diimplementasikan dan disempurnakan, lalu pada akhirnya dicari titik kompromi.
Sebuah commit yang mengubah cara kerja penyalinan di Emacs (atau fungsi yang lebih umum disebut sebagai "register") baru-baru ini diterima. Sekarang Emacs membuka minibuffer yang menunjukkan apa yang terjadi, lalu meminta pengguna menekan tombol Enter untuk menerima perubahan.
Setelah meninjau mailing list, tampaknya ada opsi untuk membatalkan perilaku ini.
Dalam Emacs, memori otot harus dianggap sebagai pertimbangan yang penting.
Dari sudut pandang pengembang, pengguna yang menginginkan stabilitas sebaiknya memakai branch rilis atau mengunci commit di master. Branch pengembangan dipakai untuk mengembangkan fitur yang masih berjalan, dan perubahan seperti ini kadang bisa cukup sering terjadi.
Sikap penulis terlihat agak keras kepala, dan ditunjukkan bahwa sangat sedikit orang yang memakai fitur ini. Perubahan kecil yang dilakukan seorang maintainer sukarela tanpa berkonsultasi terlebih dahulu seharusnya tidak dianggap sebagai tindakan yang "merusak" branch master.
Sudah 20 tahun sejak meninggalkan Emacs, tetapi perubahan ini tetap terasa cukup membingungkan. Sulit dipahami mengapa Emacs, yang bangga sebagai "bak cuci piring dapur", tidak menambahkan opsi untuk kembali ke perilaku sebelumnya.
Inti Emacs adalah bahwa ia merupakan platform yang sangat bisa dikustomisasi; jika perilaku suatu fitur tidak disukai, pengguna bisa memperbaikinya sendiri dengan beberapa baris kode Lisp. Tidak masuk akal mem-fork seluruh proyek hanya karena satu perubahan fitur.
Satu-satunya solusi tampaknya adalah mencoba fork/reimplementasi Emacs sekali lagi. Kali ini pasti akan berhasil, dan seperti semua yang lain, sama sekali tidak akan tidak relevan.
Apa argumen dari "pihak lain" terkait perubahan ini? Perubahan yang memunculkan opini seperti ini biasanya punya alasan yang masuk akal di baliknya. Atau mungkin juga tidak.