I never thought NeoVim could be a good hedge against a SPOF (I always thought of it more in terms of modernizing the codebase), but seems like it’s a useful way of looking at it.
At 54:00 someone asked how Christian looked at the decision-making policy difference between vim and neovim, and why most patches were merged by Christian. Christian said that maintainer merging patches was welcome, but it seemed that other maintainers did not feel comfortable doing that.
Christian said that maintainer merging patches was welcome, but it seemed that other maintainers did not feel comfortable doing that.
I noticed something similar in other projects, for example in Debian. Volunteer “nominal” maintainers (in the Maintainer or Uploaders fields) are often reluctant to merge patches, especially drive-by patches, even if other team members reviewed these patches positively.
My hunch is that, in widely used projects without full-time maintainers, nobody wants to take the heat for a patch that breaks something, especially if it breaks something obscure that is outside the common codepaths but used by someone in a vocal minority. This is an issue in particular for volunteers maintainers that dedicate something like “one hour every Saturday” to the project. A breakage means either keeping the project broken for one week (and getting hate mail in the meantime) or working on fixing the issue during their non-volunteer time (for example, instead of spending time with their families or attending to their job duties).
To avoid breakages one should test a lot. But these old projects have little automated testing, so “testing” often means manual testing. And maintainers are either busy with other things or the manual testing procedure is just too cumbersome (e.g., it requires a certain chroot that is currently out of date and the maintainer forgot how to update it, or sshing into a box with a weird architecture).
This is the main thing that is driving me towards languages with strong compile-time assurances. Languages like Haskell or Rust where “if it compiles it works” reduces the burden, the cognitive load, and the fear that volunteer maintainers experience when merging patches.
He said there is no one working on a GTK4 interface. He wouldn’t know it because I haven’t upstreamed much yet, but I have been working on this off. This is a good reminder that I should start upstreaming patches and I should keep a better eye on the GTK issues that have been reported.
…which reminds me. The reason I’ve been avoiding Neovim (Lack of :gui for popping a terminal Vim in my Yakuake out into a separate window without having to restart Vim) is going to become less and less valuable to me as a KDE user who hates how Inkscape just gained a more GNOME-ish context menu through no fault of their own.
I’ll have to allocate some time to try out GTK-free Neovim frontends.
In fairness to the GTK devs, I should publish a correction.
Apparently (2), while their hand is being forced by what GTK 4 removes, the Inkscape devs were partly responsible in that the change was caused by moving from GtkMenu from GtkPopover while still on GTK 3 as part of preparations for porting to GTK 4.
While I haven’t had time to figure out what I need to add to get rid of the hide/show animation yet, this addition to ~/.config/gtk-3.0/gtk.css will get rid of the rounded corners and drop shadow and the actual move to GTK 4 will apparently bring back the ability for them to request that submenus be actual submenus instead of an animated transition to new contents on the top-level context menu.
Some notes
I never thought NeoVim could be a good hedge against a SPOF (I always thought of it more in terms of modernizing the codebase), but seems like it’s a useful way of looking at it.
Agreed.
At 54:00 someone asked how Christian looked at the decision-making policy difference between vim and neovim, and why most patches were merged by Christian. Christian said that maintainer merging patches was welcome, but it seemed that other maintainers did not feel comfortable doing that.
I noticed something similar in other projects, for example in Debian. Volunteer “nominal” maintainers (in the
MaintainerorUploadersfields) are often reluctant to merge patches, especially drive-by patches, even if other team members reviewed these patches positively.My hunch is that, in widely used projects without full-time maintainers, nobody wants to take the heat for a patch that breaks something, especially if it breaks something obscure that is outside the common codepaths but used by someone in a vocal minority. This is an issue in particular for volunteers maintainers that dedicate something like “one hour every Saturday” to the project. A breakage means either keeping the project broken for one week (and getting hate mail in the meantime) or working on fixing the issue during their non-volunteer time (for example, instead of spending time with their families or attending to their job duties).
To avoid breakages one should test a lot. But these old projects have little automated testing, so “testing” often means manual testing. And maintainers are either busy with other things or the manual testing procedure is just too cumbersome (e.g., it requires a certain chroot that is currently out of date and the maintainer forgot how to update it, or sshing into a box with a weird architecture).
This is the main thing that is driving me towards languages with strong compile-time assurances. Languages like Haskell or Rust where “if it compiles it works” reduces the burden, the cognitive load, and the fear that volunteer maintainers experience when merging patches.
He said there is no one working on a GTK4 interface. He wouldn’t know it because I haven’t upstreamed much yet, but I have been working on this off. This is a good reminder that I should start upstreaming patches and I should keep a better eye on the GTK issues that have been reported.
…which reminds me. The reason I’ve been avoiding Neovim (Lack of
:guifor popping a terminal Vim in my Yakuake out into a separate window without having to restart Vim) is going to become less and less valuable to me as a KDE user who hates how Inkscape just gained a more GNOME-ish context menu through no fault of their own.I’ll have to allocate some time to try out GTK-free Neovim frontends.
In fairness to the GTK devs, I should publish a correction.
Apparently (2), while their hand is being forced by what GTK 4 removes, the Inkscape devs were partly responsible in that the change was caused by moving from
GtkMenufromGtkPopoverwhile still on GTK 3 as part of preparations for porting to GTK 4.While I haven’t had time to figure out what I need to add to get rid of the hide/show animation yet, this addition to
~/.config/gtk-3.0/gtk.csswill get rid of the rounded corners and drop shadow and the actual move to GTK 4 will apparently bring back the ability for them to request that submenus be actual submenus instead of an animated transition to new contents on the top-level context menu.Noble goal.
I’m still somewhat angry at Neovim 0.10 which broke all my syntax highlightings. It’s one of the reason I switched back to Vim.