[tz] Tonga returns to DST on 2016-11-06

Russ Allbery eagle at eyrie.org
Fri Nov 4 19:55:06 UTC 2016

Brian Inglis <Brian.Inglis at SystematicSw.ab.ca> writes:

> I know he does, but this is not documented anywhere, and he changed
> where the version is found, and that is not documented anywhere, whereas
> the IANA process is documented in an RFC.

> Companies are unlikely to change their processes unless changes break
> existing processes (like the version change) or changes are documented
> in an RFC, which can be presented to SOx auditors and their ilk, to
> document and justify why they spent money and changed a process, along
> with the documentation on change impact including budget,
> authorizations, and the dozens of other side efforts of production
> changes, summarized above by DG as "That doesn’t work for everyone."

A bit of a digression, but the way companies treat free software projects
and maintainers is a pet peeve of mine.

It should be obvious that the only people a company can expect to follow
any of those rules are people the company is paying or otherwise has a
contractual relationship with that requires following those rules.
Otherwise, the company should be prepared to pay one of their employees to
jump through those hoops if they want those hoops jumped through.

It's standard practice for companies who depend heavily on a free software
project to have an internal maintainer or advocate for that free software
project who will translate whatever the public maintainer does into the
form that the company needs to manage it internally, including maintaining
private branches as needed, pulling up unreleased patches as needed, and
adjusting for upstream changes that don't match the needs of the company
(or clearly advocating for compromises or modifications that work for the
entire community).  This is a cost of doing business.  My employer
certainly does this for free software we use.  It's fairly normal.

Some companies don't *want* to spend that money, and try to do it on the
cheap by not having that person or the mechanisms for importing free
software properly.  A few of them then complain at the free software
maintainer when they run into problems.  But those complaints should not
carry any more weight than the complaints of any other user, and should be
weighed against the work style, goals, and available time of the free
software maintainer.  After all, the actor in this situation that has (by
far) the most resources and hence the most ability to adopt to changes,
whether they want to or not, is the company, not the free software

Russ Allbery (eagle at eyrie.org)              <http://www.eyrie.org/~eagle/>

More information about the tz mailing list