[Nut-upsdev] updating the NUT website

[Charles Lepple]

On Jun 13, 2016, at 8:10 PM, hyouko at gmail.com wrote:
> 
>> I will try to remember to update the list of unsupported characters.
> 
> Done.

Thanks!

>> Hmm, I will have to look at some of the dependencies - the "Last updated" dates aren't getting modified. (I am just doing a "make" (all) rather than "make dist" since I don't have a new NUT tarball or the GPG key.)
> 
> What do we want to do with 'Last updated' and 'Version' in footers?
> I mean, when not working in a virgin repo, it may happen that targets
> are newer than prerequisites and therefore not rebuilt... which leaves
> us with mixed dates (not a big problem, after all) and versions (which
> annoy me the most).

Hmm, this is starting to get complicated.

To me, the value of the version information is greatest on the web versions of the man pages and configuration info, where you can see at a glance whether the online documentation corresponds to the installed version. It is less important (although distracting when wrong) on the other "glue" pages (news, etc.)

That said, a last-updated date is useful to get an idea of how old a page is, and if that date got bumped just because the rest of the site was updated... meh.

As a side note, I do wish there was an easier way to identify the set of source Asciidoc files for a given HTML file. Then, the last-updated date could reflect the age of the content of the file.

> Plus, at the moment, pages built directly by 'nut-website' get their
> version from the last tag in NUT (minus the additional infos about the
> commit, e.g. 2.7.4), protocols don't get any version at all (but their
> own, if set), while pages under 'nut' submodule get their version from
> NUT's 'configure.ac' (e.g. 2.7.4.1).

I am fine with having no version on the protocols, but if it is easier to match the other components, no arguments here.

If we are going with a rolling update process on the website, we might as well use the configure.ac version (or even something like the output of "git describe", as is done in the Buildbot website builder, and as you mention below).

> If I recall correctly, in a previous topic you mentioned reproducible
> builds and proposed to save version in a file.
> With that in mind, I think we could do something like this:
> - in 'nut-website' repo: store the output of `git describe --tags`
> (done on 'nut' submodule, without removing commit infos) in a
> git-ignored file, but only if that file doesn't exist or version is
> not the same, and then add that file as a prerequisite to every file:
> each page will then get the same (most recent NUT) version but its own
> timestamp and it will only be rebuilt when version changes,
> - in 'nut' repo: do the same for builds between releases, while for
> tarballs do not store commit infos and add a second prerequisite file
> (or maybe we could use the same file) with the timestamp: then if this
> timestamp exists, pages will use it, otherwise (i.e. non-tarball
> builds) they'll get their own.

Here's the link that inspired that discussion back in February: https://wiki.debian.org/ReproducibleBuilds/About

I think there are two slightly different drivers for this: packagers want to be able to build the same version of software at two different times and get identical results, and we are looking to simplify the timestamp for the website. Note that the website isn't currently packaged in Debian.

I think your proposal would cover that, but I just wanted to clarify the reasoning.

> 
>> I like the looks of the source-package branch. I don't think I have enough experience with submodules to say what I would prefer, so I'll leave that up to you. Let me know if you'd like help with anything else.
> 
> I've created two new repositories for source and package archives,
> added them as submodules of 'nut-website', rebased and merged that
> branch and updated all submodules.
> 
> I was about to push the freshly built files to
> 'networkupstools.github.io' repo, but came across a file Arno added to
> the repo while publishing 2.7.4 (67a4c0e), but that we lack in
> 'nut-website' repo:
> https://github.com/networkupstools/networkupstools.github.io/blob/master/protocols/snmp/BESTPOWER-MIB.mib
> It's not listed in 'ups-protocols.txt', either, but it seems to be the
> real match for 'bestpower-mib.c' (see how '.1.3.6.1.4.1.2947.1.1.8.0'
> is mapped to 'manufacturing date', while
> http://powerquality.eaton.com/Support/Software-Drivers/Downloads/connectivity-firmware/bestpwr2.mib
> -which appears to be a newer revision of that file- lists that as
> 'installation date').
> What should we do with it?
> Arno?

Pinging Arno again...

-- 
Charles Lepple
clepple at gmail