bufferbloat-net
bufferbloat-net copied to clipboard
tohojo
Hugo has a new release
Hmmm... No errors on Hugo version 0.16, but I see that version 0.18 came out in December.
Are we being pushed to upgrade?
Yeah, Hugo > 0.16 are won't build the site. See https://github.com/spf13/hugo/issues/2891
Hah. It may break - but it breaks faster than ever - rendering the whole site in 1036ms on my intel box, and 3ms or so on my pi2.
1036 msec? I bet you mean 1036 usec...
Also - I updated Toke's ticket in the Hugo issue tracker: https://github.com/spf13/hugo/issues/3026
usec, yes. hugo is amazing. I would be watching ikiwiki still processing its first file at that point....
I thought Toke's response to his original ticket #2891 was appropriate. I also have the sense that bep feels a little defensive. The changelogs go to great lengths to say how happy everyone will be with the "everything's a page" model of 0.18, making me think that he got a lot of pushback.
Depending on how grumpy I (still) feel, I may update my forum posting to ask if anyone is planning to mark those commands as unsupported in the documentation.
But... Dave's note is on point - how do we get unstuck?
Is it as simple as:
- Changing every .md in a link to "/", e.g.,
s/.md)/\// - Adding the proper path prefix to each relative link, that is, for all files in /cerowrt/wiki, prepend
/cerowrt/wiki/to the link, if it's not a full path e.g.,
[FAQ](FAQ.md) => [FAQ](/cerowrt/wiki/FAQ/) but
[Other](/bloat/wiki/Other.md) => [Other](/bloat/wiki/Other/) ?
If that's all we have to do, we only need to substitute the proper path prefix for four prefixes: cerowrt, bloat, make-wifi-fast, codel. That's not insurmountable...
It's not that I mind them dropping the feature. But a note beforehand saying "there are not resources to fix this, but we'll accept a patch" would have been nice. Stonewalling and then dropping the feature is just rude.
Now, as far as fixing it: The link changes you suggest (while turning off the parsing of relative links) would turn all the links into regular relative HTML links in the output. There are two issues with this: One, we'll have to include the site prefix (/projects), which means that if that ever changes, we'll have to do another manual update of all links on the site. And I'm not sure if it works on the local site in development mode.
But more importantly, it means that Hugo will not know that the links are links to other pages; so broken links will just turn up as 404s on the live site. To get the link checking, we'll have to use one of the template functions to generate links (see https://gohugo.io/templates/functions/#urls); and they make the source be quite a bit less Wiki-like, which is bad for usability.
So going back to my previous point: Why, exactly, do we need to upgrade?
Stonewalling and then dropping the feature is just rude.
And not updating the documentation to state that the feature is no longer operative is, too. But let's cut bep some slack, since I think we were just "one more in a series of disgruntled people" who had to make big changes to their site.
All that said, I have no need to upgrade. What's there just works. (I need to figure out how to downgrade my hugo installation on osx, but I think there's a brew incantation for that...) Can you tweak the hugo version on the server? Thanks.
You mean the CI server? Yeah, that broke, I forget why... not sure if that can be fixed. But the server that produces the live version still runs 0.16...
Ah yes, there's some dependency issue. The Go ecosystem does not have a concept of freezing versions. So I think I'll just nuke the CI stuff and rely on people testing on their own box before pushing ;)
OK with me (to nuke the CI stuff, or at least the Hugo checks). It's nice that something checks to see if the merge can happen automatically. (Or perhaps that's a github feature...)
The check for conflicts is a github feature. The CI stuff just checked if the site compiles...