[Nut-upsdev] [Nut-upsuser] NUT testing for v2.8.3 (hopefully imminent)

[Greg Troxel]

I'm starting down the path of testing.


There are commits in the rc tag that are not on master:

  $ git log --oneline ..v2.8.3-rc1
  3d286fb1b (tag: v2.8.3-rc1, jimklimov/pre-283-2) appveyor.yml: handle also FTY and fightwarn branches
  4e92275c1 .github/workflows/codeql.yml: handle also FTY and fightwarn branches
  504706d45 Makefile.am: nut-scanner does directly depend on clients after all
  051b49d9f Revert "Revert "NEWS.adoc, UPGRADING.adoc, docs/docinfo.xml.in: finalize text before NUT v2.8.3 release""
  70faea2af Revert "tools/gitlog2version.sh: bump NUT_VERSION_DEFAULT=2.8.3.1 for next development cycle"
  e1d399b5e include/Makefile.am: nut_version.h: propagate failure (if there ever is one) writing the temporary output
  a33fb1616 clients/Makefile.am: libupsclient-version.h: take a transactional approach to changing (or not) the file others depend on

so all in all I find this far more confusing than it needs to be.



As an aside about CM practices:

  I think when there's an RC, then it should just be on master, with the
  idea that other changes are not allowed until release.  The current
  state is more confusing than necessary.

  Running 'git branch -a', there are 66.  I realize there are probably
  reasons for some of them to exist, but there are no many that the
  noise makes it harder to understand the repository.  I suggest
  removing most of them (or parking them in a private repo if it's
  really not ok to just remove them, but they don't have significant
  continuing value).

  There's no branch in the repo for the release.  (I prefer releases
  from master with other commits banned, but if it's not that way it
  needs a release branch.)

  (I realize nut does not have release branches to be able to make micro
  releases, and I realize we could create one retrospectively if that
  turns out to be necessary.  I'm ok with that as long as releases are
  from master.)