From: Brian Inglis <Brian.Inglis@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