4 ms·
This can't possibly have taken less to write than changing the capitalization of one letter, overriding a default, and reverting a commit (or even better, contr
by FiloSottile 9y ago
This can't possibly have taken less to write than changing the capitalization of one letter, overriding a default, and reverting a commit (or even better, contributing a config option for the desired behavior!).
And I say this not to flame about the author, but because it's a remarkable trend in the industry to complain (vocally!) about barely breaking changes in Open Source software.
There is of course the angle of "you're getting it for free, for LTS buy a commercial product", but even more interesting to me is how it condemns projects to never moving, until they feel legacy, and we have to move on to something new.
- ams6110 9y agoYeah my impression was here's a guy using a free tool that is the product of a lot of work by a lot of people and now is whining that their vision for the product isn't exactly the same as his.
- thinkfurther 9y agoIt's not about the fact that something changed, but what changed. Full text to summary is quite the change to do based on -- who knows what? What progress, what advancement do you see here? And changing the default number of items from 15 to unlimited? I mean, not 50, not 100, not 500, but infinite? I see no purpose, just pitfalls. > even more interesting to me is how it condemns projects to never moving Oh yeah. Criticize any random silly move and you're against any and all progress, ever.
- randallsquared 9y ago> Oh yeah. Criticize any random silly move and you're against any and all progress, ever. Not this person, or that person, but after you add all of the complaints together, the aggregate could be against any change at all. That isn't saying "don't change", but it does suggest that the promise of forking and fixing is not being realized, perhaps because not enough people have the combination of time, interest, and ability to do so.
- thinkfurther 9y agoRight now, people don't even have the interest to notice the good points he's making: these are dumb changes. The devs could have noticed that before making them. But instead, this guy took the trouble to write about it. Maybe he likes that more than asking a "fix" to be accepted when it's not even a bug fix, but a change they made for whatever reason. And the stuff about the two natures of RSS feed doesn't belong in commit logs anyway, it belongs on a blog... but it seems the promise of communicating ideas with blog posts has not been realized, either. He made sensible criticism, it wasn't received sensibly. Saying "submit a patch instead" is just as valid as replying "write a blog post about it instead" when someone submits a patch. He doesn't like Hugo, for these reasons. Not terribly interesting, but fair enough, and nothing is too small to be addressed on its own actual merits.
- rhblake 9y agoHugo is still at 0.x. Hasn't stabilized yet. Breaking changes are to be expected.
- thinkfurther 9y agoI ask how this weren't bad and silly changes. When we can't even discuss why we are doing what, why not get rid of version numbers, too?
- rhblake 9y agoBut there were some discussion and reasoning behind the changes. For e.g. RSS limit, see https://github.com/gohugoio/hugo/issues/3145 https://github.com/gohugoio/hugo/issues/3145. Nobody was against it, as far as I can see. If someone think it's a mistake, I guess opening an issue on GitHub (where devs can see it) would be more useful than complaining elsewhere?
- git-pull 9y ago> about barely breaking changes in Open Source software. I get the sentiment, but I'm immediately recalling times users have been spurned by projects that just didn't listen. In that light, this feels like a subjective statement. I can tell you I'm racking my brain right now trying to invoke custom sphinx-doc builders programatically. And I get absolutely zero consideration in the issue tracker. Why? Because 99% of the cases of sphinx are invocation through ReadTheDocs and the project's Makefile. They don't care whether their internals are intuitive or not. To most, it looks incredibly trivial. But I have a legitimate case to use sphinx this way, and they flip when I suggest adding an argument to insert a custom Builder. No, I have to create a side effect by inserting an extension, which registers the builder as a string, and then figure out why I'm not printing even basic debug statements. I seriously only have the intention of making life easier for others. The internals of docutils and sphinx are no simple feat to understand. Eh, other than my own personal problems, which I at least made patches for, there's gnome's spatial fiasco (https://www.osnews.com/story/7344 https://www.osnews.com/story/7344). So, every time I did a gnome install I'd go into preferences to 'fix' it. Untold others did too. I have sympathy toward open source projects not being able to change internals due to fear of introducing regressions and keeping code maintainable and (to a point) pragmatic. My point is, while there is people who pick small gripes over edge cases, there are simple little things that can cause headaches to users.
- StevePerkins 9y agoI have no quarrel with the author writing a blog post about his opinions. Also, every open source project has its complainers (paradoxically, the less money people pay, the louder they complain). No open source project survives longer than a year or two without learning to separate the signal from the noise, and tune out the outliers. What does put me off though, is the trend toward "clickbait" headlines even for personal blogs. "Why I'm Leaving X" "X Considered Harmful" "Farewell to X" "Why I Do Not Like X" I guess you just have to do this in 2017, if you want to get anyone to click your links and read your stuff. But the web feels dumber for it.
- majewsky 9y agoSerious question: If "Why I do not like X" is clickbait, what isn't?