3 ms·

All the functionality they removed was done in free time too. It’s literally more work to mess with them than just leave good enough alone.

lolinder 4y ago
No, it's not. It's more coding work in the short term, sure, but every feature that exists is one that has to be maintained. This is obvious in code written in a professional context, but people seem to think that open source is somehow exempt from this rule. If the feature uses shared internal apis, then that code has to be refactored if you need to make changes to those apis. If you need to update versions of dependencies, then the feature needs to be updated too. If there are bugs, at a minimum you have to do something with the bug reports for those features. Even ignoring the report has overhead in the form of extra bug reports that you never intend to fix. Marking them as "won't fix" means you have to figure out a solution for dealing with the backlash from the reporter. Then you get to the PRs from people who want to improve the feature but don't know the project well enough to really be of help. You have to either reject the PRs outright or carefully walk them through how to make them acceptable. The minimal-work way to keep a feature around is to ignore all PRs and all bug reports for that feature. Any other approach is extra overhead. But taking that approach is still in many ways worse than stripping the feature out entirely, because you're left with a feature that only sort of works some of the time, it makes your code more resistant to change than if it were gone, and you're building up a backlog of reports and PRs you never intend to fix.
ohgodplsno 4y ago
Have you never had a cross-cutting feature to change ? A new field on a core struct that needs updating everywhere ? Well consider that everything is ten times worse on an old codebase like Gnome, coupled with insane amounts of tech debts and unwanted interactions because that is the unfortunate destiny of UIs. Removing a feature might be a bit of work now, but if it avoids hours of headaches later, that's absolutely worth it.

lolinder 4y ago

No, it's not. It's more coding work in the short term, sure, but every feature that exists is one that has to be maintained. This is obvious in code written in a professional context, but people seem to think that open source is somehow exempt from this rule. If the feature uses shared internal apis, then that code has to be refactored if you need to make changes to those apis. If you need to update versions of dependencies, then the feature needs to be updated too. If there are bugs, at a minimum you have to do something with the bug reports for those features. Even ignoring the report has overhead in the form of extra bug reports that you never intend to fix. Marking them as "won't fix" means you have to figure out a solution for dealing with the backlash from the reporter. Then you get to the PRs from people who want to improve the feature but don't know the project well enough to really be of help. You have to either reject the PRs outright or carefully walk them through how to make them acceptable. The minimal-work way to keep a feature around is to ignore all PRs and all bug reports for that feature. Any other approach is extra overhead. But taking that approach is still in many ways worse than stripping the feature out entirely, because you're left with a feature that only sort of works some of the time, it makes your code more resistant to change than if it were gone, and you're building up a backlog of reports and PRs you never intend to fix.

ohgodplsno 4y ago

Have you never had a cross-cutting feature to change ? A new field on a core struct that needs updating everywhere ? Well consider that everything is ten times worse on an old codebase like Gnome, coupled with insane amounts of tech debts and unwanted interactions because that is the unfortunate destiny of UIs. Removing a feature might be a bit of work now, but if it avoids hours of headaches later, that's absolutely worth it.