[tz] Adding a "test" region?

[Robert Elz]

  From: Brian Inglis <Brian.Inglis at SystematicSw.ab.ca>
  Date: Thu, 25 Jan 2018 22:45:53 -0700
  Subject: Re: [tz] Adding a "test" region?

  | As someone else mentioned about Debian, the current release on most major
  | distributions is 2017c,

What's the point there supposed to be?  Until earlier this week 2017c
was the last announced released version - until they upgrade to what
was announced earlier this week, that is what they should be using?
(2017 was a truly remarkable year, just 3 tz versions needed!)

It is hard to imagine that you're faulting them for taking more than
2 days to get the upgrade done, nor that you're attempting to point
out that it takes more than 2 days after tzdata is released until it is
available to users.

So, what was the point?

  | As some major distributors have previously mentioned, their orgs
  | have policies that they can only use official releases from official
  | sources,

If "use" there means "release" that makes a lot of sense.  But ...

  | and do not have either the authorization or resources to test against
  | the experimental github releases.

Any organisation which claims to be a "major distributor" which doesn't
have the resources to perform tests against an upcoming release, or even
worse, prohibits that for some policy reason, should be ignored by all
of us.   That's unconscienable (and I find it hard to believe that any
such thing actually exists.)

Ignoring tzdata for a minute, do you really believe that the vendors of
software packages that run on linux, or the orgs that package linux distros
aren't testing the latest experimental linux kernels, to make sure that
nothing breaks?

  | The result is that most significant complaints are made by major
  | distributors only after official releases.

Which makes those complaints (for them) almost useless.   We get the
benefit, as when we receive the complaint (if it is a real problem and
not just some misunderstanding, or end user mistake) we get to fix the
problem.   But the distributor gets no benefit of that, as the last
official release still has the bug/problem/issue in it (which may
mean tat they cannot use it - and if they'er only allowed to use
official releases, they can't patch locally either).

Of course, "we" will eventually issue another release which will have that
issue fixed - but it is also going to have everyone else's issues
fixed, and most likely, other changes as well.   It is entirely possible
that the "major distributor" will find another issue with this release,
which they can complain about, and we can fix, but now they're running 2
releases behind, and their users start to complain - have this happen
2 or 3 more times, and their release is so ancient that no-one will trust
it any more.

No sane distributor could permit such a possibility, let alone enforce it.
Testing against known forthcoming releases (or everything they consume),
ahead of them becoming "official releases" should be mandatory for their
development/integration staff.

Insane distributors, attempting to save a few pennies by assuming that
someone else will find all the issues they would have found had they
bothered to allocate the resources for pre-release testing (of other
people's releases) deserve whatever problems they encounter after the
release is issued.   We should have no sympathy for them at all.
Nor should we adjust (in any way) our release policy, or the contents,
of the releases, and nor should we be issuing "emergency reversion"
releases to cater for their lack of foresight.

kre