We've used Nikola for some sites in Fedora (@maxamillion did the Koji website with it). It's packaged in Fedora, is written in Python (and thus can be extended with existing modules), and quite flexible. Would this also work?

(Python in itself isn't cumbersome for us, as it's the easiest programming language to work with)

We've used Nikola for some sites in Fedora (@maxamillion did the Koji website with it). It's packaged in Fedora, is written in Python (and thus can be extended with existing modules), and quite flexible. Would this also work?

I would say robustness and speed are more desirable than extensibility for a SSG, as well as being familiar to the people who are willing to put the porting work in :P

Though, I guess it could work.

(Python in itself isn't cumbersome for us, as it's the easiest programming language to work with)

(Python toolchain is seriously brittle and I feel like that may turn away potential contributors due to general wonk)

(Python toolchain is seriously brittle and I feel like that may turn away potential contributors due to general wonk)

We've had the opposite effect with Python. The Fedora community is heavily affiliated with Python for various historical reasons.

We simply don't have as many Perl mongers, Rubyists, Gophers, or Nodejs people as we do Pythonistas. That's not "no" to tools in other languages, but it is worth considering if we need to do customization.

We've used Nikola for some sites in Fedora (@maxamillion did the Koji website with it). It's packaged in Fedora, is written in Python (and thus can be extended with existing modules), and quite flexible. Would this also work?

(Python in itself isn't cumbersome for us, as it's the easiest programming language to work with)

I briefly looked at Nikola and I see two big problems: the doc is quite small and it doesn't mention Internationalization at all in it. To my knowledge and I researched that topic quite a lot when building the next gen kde.org website, only Hugo has a i18n support that doesn't completely suck...

Porting the websites to something more sensible would be a good idea.

Maybe, maybe not. But it would be a significant investment and given the minimal effort available for the current site, doesn't seem likely.

I don't foresee us doing this any time soon, so I'm going to close this out for now.

Note that if someone intends to take up this effort (as I did when we went from the old custom system to the Frozen-Flask setup we use now), ensure you fully understand the requirements of the site/sites before you start. I tried really hard to do that after having maintained the old system for a few years prior, and still got things wrong and missed things. Things aren't always how they seem.

Translations output needs to happen in a particular way, because of the way Apache is configured in Infrastructure. Any changes to how the files are output w.r.t. translations, needs to be coordinated with Infrastructure (and the relevant Apache config is easy to get wrong too, it involves some rewriting, etc.).

Sometimes a particular spin, or a particular arch of a spin doesn't make the compose and needs to be excluded. Sometimes, a particular artifact doesn't make the compose, but gets made shortly after, and published somewhere else (like in /pub/alt/unofficial/) and needs to have links and checksum links overridden. Sometimes IOT isn't ready when everything else is, the build needs to allow for that without blocking the release.

There's always a "better tool" and a lot of tooling discussion comes down to personal opinions. We did explore Hugo, but ultimately decided against it, because we needed more customization than it easily allowed. Further, people involved in infrastructure and releng work primarily in Python and in a pinch can make changes if ever necessary, without learning a new language.

I personally think that better effort is spent on:

• Cleaning up the current code (the current code makes it very clear where I still got things wrong, as alluded to above. You can see where things change from being "acceptably clean" to "hack because something worked differently than I realized, and I need to work around it")

• Finishing porting the sites still on the old framework into getfedora.org pages. This has been on my TODO list for a lot of months now. A lot of the work is already done, but needs to be reviewed, rebased, and pushed through.

• Automating things that are still manual parts of the release-bump process. Things like importing checksum files, adding new GPG keys, generating releases.json, and so on.