search

tohojo / bufferbloat-net

The source repository for the bufferbloat.net web site
https://www.bufferbloat.net
Other
53 stars 32 forks source link

Hugo has a new release #24

Open dtaht opened 7 years ago

dtaht commented 7 years ago

and complains a lot when generating the site.

richb-hanover commented 7 years ago

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?

tohojo commented 7 years ago

Yeah, Hugo > 0.16 are won't build the site. See https://github.com/spf13/hugo/issues/2891

dtaht commented 7 years ago

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.

richb-hanover commented 7 years ago

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

dtaht commented 7 years ago

usec, yes. hugo is amazing. I would be watching ikiwiki still processing its first file at that point....

tohojo commented 7 years ago

Well, opening another issue did not help, exactly... :/

dtaht commented 7 years ago

I don't blame bep for being testy. But how do we un-break things?

richb-hanover commented 7 years ago

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:

  1. Changing every .md in a link to "/", e.g., s/.md)/\//
  2. 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...

tohojo commented 7 years ago

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?

richb-hanover commented 7 years ago

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.

tohojo commented 7 years ago

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...

tohojo commented 7 years ago

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 ;)

richb-hanover commented 7 years ago

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...)

tohojo commented 7 years ago

The check for conflicts is a github feature. The CI stuff just checked if the site compiles...