1 poin oleh GN⁺ 2023-10-09 | 1 komentar | Bagikan ke WhatsApp
  • Homebrew/homebrew-core PR #139538 adalah perubahan yang menambahkan peringatan pengguna pada formula terraform karena perubahan lisensi HashiCorp, serta memberi tahu bahwa formula tersebut dapat dinonaktifkan suatu saat nanti
  • Alasan perubahan ini adalah bahwa setelah perubahan lisensi, terraform tidak akan lagi menerima pembaruan versi di homebrew-core, dengan fokus agar pengguna menyadari hal ini saat memasangnya
  • Dalam proses peninjauan, dibahas pengecualian versi bahwa rilis mendatang sebelum 1.6.0 mungkin dapat diterima, meskipun ada kemungkinan rilis seperti itu tidak akan ada
  • Setelah pembersihan dependensi, PR kembali siap ditinjau pada 4 April 2024, dan diperbarui dengan commit terraform: deprecate and add caveat untuk mencerminkan masukan agar menghapus frasa berbentuk masa depan
  • Perubahan final digabungkan ke master Homebrew melalui merge queue pada 5 April 2024 sebagai commit 4782218, dan PR penghentian terraform terkait #168090 juga digabungkan

Penghentian formula terraform dan penambahan peringatan

  • Tujuan PR #139538 adalah memberi tahu pengguna bahwa karena perubahan lisensi HashiCorp, pembaruan versi terraform tidak lagi dilakukan di homebrew-core
  • Penjelasan awalnya mengarah pada pemberitahuan kepada pengguna bahwa “formula ini dapat dinonaktifkan suatu saat nanti”
  • Target perubahan adalah Formula/terraform.rb, dan kemudian path file ditampilkan sebagai Formula/t/terraform.rb
  • PR diberi label seperti formula deprecated, busl-license, go, dan maintainer feedback

Diskusi terkait versi dan lisensi

  • Selama peninjauan, muncul pendapat bahwa dari rilis mendatang terraform, versi sebelum 1.6.0 mungkin dapat diterima
    • Namun, turut disampaikan kemungkinan bahwa rilis seperti itu mungkin tidak akan benar-benar ada
  • Deskripsi PR menjadikan fakta bahwa setelah perubahan lisensi tidak ada lagi pembaruan versi di homebrew-core sebagai dasar perubahan
  • Pesan commit berikutnya memuat maksud bahwa “karena perubahan lisensi, tidak akan ada lagi pembaruan versi di homebrew-core, sehingga formula ini akan dinonaktifkan suatu saat nanti”

Alur review dan penerapan perubahan

  • PR dibuka pada 14 Agustus 2023, dan beberapa maintainer meninjau perubahan pada Formula/terraform.rb
  • Pada 6 September 2023, ada ping yang meminta penerapan masukan review, dan penulis menyatakan bahwa masukan tersebut sudah diterapkan
  • Pada 7 September 2023, MikeMcQuaid menyetujui perubahan, tetapi PR dihapus dari merge queue karena kegagalan pemeriksaan status
  • Pada 20 September 2023, chenrui333 juga menyetujui perubahan
  • Pada 23 Februari 2024, PR ditandai sebagai draft

Pembersihan dependensi dan PR terkait

  • Pada 13 Maret 2024, commit cdktf: deprecate merujuk PR ini
    • Pesan commit tersebut menyatakan bahwa cdktf menggunakan terraform yang akan segera dihentikan
    • Dijelaskan bahwa itu adalah salah satu formula terakhir yang menghalangi penghentian terraform
    • Tertulis bahwa cdktf diunduh lebih dari 700 kali per bulan, dan meskipun di-host di org GitHub HashiCorp, tidak terdampak perubahan lisensi BUSL
  • Sebagai PR terkait, cdktf: deprecate #166001 telah digabungkan
  • Pada 3 April 2024, atlantis: vendor terraform #167948 merujuk PR ini dan telah digabungkan

Penyelesaian akhir dan penggabungan

  • Pada 4 April 2024, penulis memberi tahu bahwa “semua dependensi sudah ditangani, jadi sekarang sudah oke” dan mengubah PR menjadi siap ditinjau
  • p-linnane memberi masukan bahwa karena situasi tersebut sudah terjadi, ungkapan masa depan dapat dihapus
  • Penulis menerapkannya, lalu memperbarui branch dengan commit terraform: deprecate and add caveat 1c7b99b
  • p-linnane, MikeMcQuaid, dan chenrui333 menyetujui perubahan final
  • Pada 5 April 2024, PR digabungkan ke master Homebrew melalui merge queue sebagai commit 4782218
  • Pada hari yang sama, terraform: deprecate and add caveat #168090 juga dirujuk sebagai PR yang telah digabungkan

1 komentar

 
GN⁺ 2023-10-09
Komentar di Hacker News
  • Hal pentingnya adalah paket-paket dependensi tidak langsung dihentikan, tetapi ditahan dulu untuk melihat apakah bisa diganti dengan alternatif
    Misalnya, program yang bergantung pada Terraform kemungkinan besar bisa memakai OpenTofu sebagai pengganti
    Sayangnya, sepertinya tidak akan ada alternatif open source untuk Vault, Consul, dan Nomad. Khususnya Nomad, dulu itu produk yang bagus sampai HashiCorp berhenti berinvestasi di dalamnya, tetapi sekarang setelah menjadi sumber tertutup, rasanya nyaris tidak mungkin akan diadopsi—sampai terasa lucu

    • Kalau ada yang memulai fork publik Vault, saya ingin berkontribusi saat ada waktu
      Tambahan: https://github.com/hashicorp/vault/graphs/contributors?from=...
    • Saya cukup suka Nomad. Bahkan lebih ringan daripada k3s, dan sangat cocok untuk proyek-proyek beranggaran rendah saya
      Agak disayangkan melihat arahnya jadi seperti ini
    • Ambisi Nomad untuk menjalankan segala hal di dunia ini terlalu berlebihan. Pada akhirnya ia tidak pernah benar-benar meluas, dan untuk menyiapkannya juga perlu Consul
      Docker Swarm adalah solusi yang lebih sederhana dan lebih baik daripada Nomad, serta sudah tertanam di Docker Engine sendiri
    • Jujur saja, produk-produk HashiCorp secara umum memang sangat bagus. Hanya saja menurut saya mereka mengalami sindrom bergerak terlalu cepat
      Mereka memaksakan IPO, dan sebagian besar kekurangan belakangan ini bisa ditelusuri kembali ke upaya menaikkan harga saham
      HashiCorp pada masa awal itu hebat. Mereka adalah penjaga open source, dan terlihat seperti Red Hat atau Canonical yang sedang naik daun. Produk-produknya terobosan, dan menambahkan nilai luar biasa pada ekosistem open source. Namun ketika Terraform meledak besar, produk-produk lain ikut menarik perhatian, dan perusahaan itu menjadi terlalu terkenal
      Setelah IPO, terlihat jelas bahwa mereka mengejar uang dan pelanggan enterprise dengan segala cara
      Terraform sendiri setelah versi 1 terasa seperti berada dalam mode pemeliharaan. Terraform provider sering rusak, dan menurut saya di lingkungan produksi provider harus dikunci sampai versi patch. Dalam beberapa tahun terakhir, pembaruan patch kecil pun beberapa kali menimbulkan masalah. Mereka juga terkenal mulai menolak kontribusi open source yang tidak punya nilai bisnis bagi HashiCorp. Sejak Terraform mencapai v1, hampir semua perhatian tampaknya mengarah ke Terraform Cloud dan Terraform Enterprise. Di HashiConf, setiap presentasi terasa seperti propaganda yang mendorong produk-produk ini, dan sekarang sepertinya hanya itu yang mereka pedulikan
      Nomad untuk sementara waktu adalah produk yang sangat diharapkan HashiCorp, tetapi tampaknya ditinggalkan di pinggir jalan dalam proses mengejar dominasi pasar enterprise. Mungkin setelah mereka menyadari sebagian besar enterprise sudah all-in ke Kubernetes, sementara Nomad lebih berguna bagi startup yang bergerak cepat
      Vault adalah alat yang sangat bagus, terutama di ranah open source. Namun dalam beberapa tahun terakhir, mereka sangat memisahkan versi open source Vault dari versi berlisensi, dan versi open source mulai terasa seperti beban bagi HashiCorp. Tahun lalu, saat perusahaan kami serius mempertimbangkan migrasi ke Vault dan berbicara dengan HashiCorp, mereka memperlakukan solusi open source yang di-host sendiri seperti versi uji coba dari “Vault yang sebenarnya”, dan memang terasa begitu. Hampir untuk setiap masalah yang kami temui saat konfigurasi, jawabannya kira-kira “di versi enterprise itu baik-baik saja”
      Secara keseluruhan, mereka mundur dan hanya menyisakan upaya minimum yang diperlukan untuk mendukung versi open source dari produk-produknya, dan sudah cukup lama menjadi perusahaan yang sepenuhnya berfokus pada enterprise. Mereka perlu menghasilkan uang, jadi tidak bisa hanya disalahkan, tetapi saya tak bisa tidak terpikir pada Red Hat dan Canonical sebagai contoh seperti apa HashiCorp bisa saja menjadi
      Sekarang rasanya seperti orang tua yang menyaksikan anaknya tidak mewujudkan seluruh potensinya. Sebagian besar tampak karena keserakahan atau ambisi berlebihan. Saat memikirkan HashiCorp, yang terlintas adalah kalimat “saya tidak marah, hanya kecewa.” Saya berharap OpenTofu bisa mengisi kekosongan Terraform. Untuk Vault, kami sudah melewatinya dan memakai alat manajemen rahasia dari penyedia cloud besar. Jauh kurang saya sukai, tetapi lebih murah dan tidak serumit itu. Sebagai pengganti Nomad kami memakai Kubernetes, dan karena itu sudah menjadi standar, tidak masalah. Saya akan baik-baik saja, tetapi saya kecewa pada HashiCorp
    • Apakah Nomad benar-benar menjadi sumber tertutup?
  • HashiCorp memelihara tap mereka sendiri
    https://github.com/hashicorp/homebrew-tap
    https://www.hashicorp.com/blog/announcing-hashicorp-homebrew...

  • Mengapa begitu? Bukankah Homebrew hanya package manager? Saya tidak paham kenapa lisensi nonbebas harus membatasi penyertaan tool HashiCorp
    Atau apakah memang ada kebijakan bahwa hanya perangkat lunak bebas yang boleh disertakan?
    Sunting: ternyata memang ada pedoman yang cukup ketat: https://docs.brew.sh/License-Guidelines

    • Homebrew punya kebijakan untuk hanya menyertakan perangkat lunak bebas [1]
      “Kami hanya menerima formula di homebrew/core yang menggunakan lisensi Debian Free Software Guidelines, atau yang dirilis sebagai domain publik sesuai pedoman DFSG untuk perangkat lunak domain publik”
      [1]: https://docs.brew.sh/License-Guidelines
    • Homebrew bukan sekadar package manager
      Ia adalah perangkat lunak bernama brew, yaitu package manager, tetapi juga repositori paket homebrew-core yang tersambung secara default. Repositori paket ini dikelola dengan hati-hati dan hanya menerima lisensi open source
      Anda bebas men-tap repositori apa pun yang diinginkan dengan brew, tetapi PR ini hanya membahas repositori core
    • Ini hanya sebagian benar
      Secara default, Homebrew mendukung dua repositori, homebrew/core dan homebrew/casks, atau dalam istilah Homebrew, men-tap keduanya
      Core hanya menerima perangkat lunak bebas, dibangun langsung oleh pengembang Homebrew, dan dipasang ke lokasi seperti /opt/homebrew. Casks menerima hampir apa saja, termasuk perangkat lunak komersial dan perangkat lunak tanpa kode sumber. Perangkat lunak seperti ini biasanya diunduh langsung dari pihak pengembang dan dipasang ke lokasi yang diinginkan, umumnya /Applications
  • Saya suka layanan yang disediakan Homebrew, tetapi Terraform adalah salah satu pengecualian yang lebih baik dikelola di luar brew. Saat ini menurut saya tf-switch adalah opsi paling populer
    Terraform sering kali perlu dikunci ke versi tertentu karena bisa berbahaya jika file state tidak sengaja diperbarui. Tentu saja, pembaruan Terraform memang jauh tidak serepot masa sebelum 1.0

    • Saya memakai rtx, alias rust asdf https://github.com/jdx/rtx. Bisa memasang berbagai bahasa dengan satu tool, dan juga menangani variabel lingkungan proyek seperti direnv
    • Benar. Yang terbaik adalah mengelolanya di dalam MacPorts, yang memungkinkan memasang paket versi tertentu dan beralih dengan mudah
    • Untuk memasang beberapa versi Terraform, tfenv juga bisa digunakan lewat Homebrew
  • Sebagai gantinya bisa masuk ke cask. Secara praktis dampaknya tidak terlalu besar

    • Benar. Kalau HashiCorp ingin terus mendistribusikannya lewat Homebrew, cask sudah cukup memungkinkan. Namun sepertinya itu tidak akan terjadi. Selama beberapa tahun terakhir mereka sudah menganjurkan untuk memasang binary secara langsung dari server, dan dokumentasi instalasi Terraform juga sudah beberapa waktu memakai cara itu
      Dampak yang lebih besar ada pada tool lain yang bergantung pada Terraform, seperti terlihat di sini: https://github.com/Homebrew/homebrew-core/pull/139538#pullre...
      Tool seperti atlantis dan infracost juga bergantung pada Terraform sehingga ikut dihapus. Jadi distribusi tool-tool kecil seperti itu akan menjadi sedikit lebih sulit. Untungnya di thread itu disebutkan bahwa mereka menahannya agar dependensi bisa diganti dengan alternatif atau dihapus sepenuhnya begitu OpenTofu stabil. Namun menurut saya dampak sebenarnya ada pada tool-tool pendukung seperti ini
  • Homebrew memang sangat berguna, tetapi juga punya pilihan desain yang aneh. Kenapa memasang Python khusus yang baru? Dan kenapa Python itu harus yang terbaru?
    Namun karena setiap formula harus menentukan versi Python, pada praktiknya versinya juga tidak selalu yang terbaru, dan muncullah formula dengan berbagai macam versi yang ditentukan. Saya tidak paham kenapa tidak memakai Python sistem seperti package manager lain. Python yang sudah terpasang sudah terlalu banyak; tidak perlu satu lagi. Terutama saat harus memasang paket pip agar sesuatu berjalan dengan benar, ini jadi makin membingungkan

    • Saya tidak bermaksud membela bahkan pilihan yang paling aneh, tetapi memakai Python sistem biasanya menimbulkan lebih banyak masalah. macOS sekarang sudah tidak punya Python sistem
      Gunakan seperti ini:
      pythonX.Y -m pip install foo
      Untuk menghilangkan ambiguitas, Anda juga bisa memakai alias. Untuk proyek kerja, pyenv dan virtual environment bagus digunakan
  • Ini terlihat seperti keputusan politis. Ada banyak paket di Homebrew yang tidak akan lagi mendapat pembaruan, tetapi tidak dihentikan

    • Formula yang tidak diperbarui karena upstream tidak merilis versi baru berbeda dari formula yang tidak bisa lagi menerima pembaruan baru di Homebrew karena lisensinya bukan lagi open source
      Bagian Homebrew yang bukan Cask mensyaratkan lisensi open source, dan kasus ini termasuk yang kedua
    • Ini terpisah dari apakah paketnya mati atau tidak. Pengguna bisa memperkirakan bahwa Homebrew tidak akan secara ajaib membuat pembaruan yang tidak ada di upstream
      Sebaliknya, jika pembaruan ada tetapi Homebrew secara hukum tidak bisa mendistribusikannya, sehingga pengguna bisa memasang versi lama dan rentan, maka layak untuk memperingatkan pengguna
    • Homebrew Core hanya berisi aplikasi dengan lisensi open source, tepatnya lisensi yang kompatibel dengan Debian Free Software Guidelines. GPL, Apache, BSD, MIT, dan sejenisnya termasuk di dalamnya
      https://wiki.debian.org/DFSGLicenses#DFSG-compatible_License...