[tz] [PATCH 2/3] Replace some zones with links when that doesn't lose non-LMT info.
rra at stanford.edu
Wed Sep 4 21:01:32 UTC 2013
Stephen Colebourne <scolebourne at joda.org> writes:
> Part of the problem is that commits to the repo form the basis of the
> permanent record of the group. IMO, if the commits are experimental,
> then they should occur first on a branch, and only be included onto the
> master branch once they are accepted. With the current way of working,
> someone in 5 years time is going to have to wade through a lot of
> rubbish over the past month to see what really happened.
I think you're reading too much into this. The use of any modern VCS for
this project at all is quite new; prior to the change of maintainer, it
was maintained in SCCS and the SCCS files were not even generally public.
There are many possible workflows with Git, and they are, to a large
extent, a matter of personal opinion and personal comfort. I probably
would have used a branch, but I might not have, and in any event I don't
think it's particularly important.
I would certainly not object if Paul decided that maintaining a high
quality commit stream with rich metadata was a maintenance standard that
he wanted to adopt for the project, but to me this is a lot more about
maintainer workflow than a vital output product of the project, and if
it's not work he wants to do, oh well. We will all certainly survive,
just as we survived just fine through years of ado using private SCCS
I think your second point here is more on point:
> Secondly, I would be less peeved if reversions were actually
> reversions. Each reversion that has occurred has been partial rather
> than complete, or has included some other unrelated change. A much
> better practice would be to revert in full, and then reapply a smaller
> change with the hope that may be more acceptable.
I do think that the way the changes were made and reverted has made it
more difficult to understand what portion of the change was reverted and
what portion of the change was not reverted.
It's fairly easy for anyone to determine the remaining changes by doing a
git diff across the relevant objects, but I do concur that using the git
revert command to back out the whole change and then applying the change
that one wants to retain as a separate change is cleaner and easier for
everyone else to understand. This has the advantage of providing a place
to put rationale for the retained change separate from rationale for the
It is, however, inconsistent with a GNU ChangeLog style of documentation
of project history, at least as I understand the ChangeLog standard. It's
much more of a "native Git" way of handling things.
> When the database moved to IANA, I argued that it should have gone to
> CLDR. They have a full technical architecture committee and a team of
> people used to dealing with complex political and i18n issues backed by
> enterprises such as IBM and Oracle. If it had gone there, the stability
> that I am calling for would have happened.
I'm very glad this didn't happen. I would have had much less respect for
and much less faith in that sort of process.
The tz database has always been a labor of love by a small number of
technical professionals acting on their own time and with their best
personal judgement. It is, in that way, either a throwback to a different
era of computing or a participant in the free software world, depending on
your preferred way of looking at things. Personally, I believe that's one
of the major reasons why it has been so successful over such a long period
> For the record, I am not objecting to every change, I am objecting to
> every change that actively deletes data in a way that can be observed by
> a consumer, unless such a change is a clear enhancement.
It is certainly within your right to make that objection. I personally
disagree with you, and am taking this opportunity to say so. I do not
believe that is the correct standard to use when deciding on changes. I
prefer the standard that has been used by Paul, ado, kre, and others in
the past, which takes into account stability, accuracy of data,
proliferation of zones, and ease of future maintenance to arrive at a
criteria with more nuance than that.
The policy that I'm speaking up to advocate for is that the people doing
the work should have the most weight in deciding on the strategy that's
the most effective. They're the ones bearing the burden of the work, and
they're also the ones with the most experience with the data and the most
understanding of which data points are significant and which are not.
This, like most software projects, is as much art as science; subjective
judgements matter, and are the path to increased quality and consistency
when the same judgement is consistently applied.
Putting aside the issues around tzselect and geopolitical sorting for the
moment, most of the other changes that have happened recently would
probably have never been noticed by anyone who wasn't reading the commit
stream for the project. There seems to be quite a tempest in a teapot
here, at least from my perspective.
> I don't consider a request for stability to be a hostile takeover, but I
> do consider some of the proposed commits to be far in excess of what is
> acceptable to me.
I hope you can understand why I find phrases like "far in excess of what
is acceptable to me" to be hostile and confrontational, and not helpful in
reaching a collaborative consensus. That's a bargaining tactic in a
hostile negotiation, which I would really hope we could avoid.
Russ Allbery (rra at stanford.edu) <http://www.eyrie.org/~eagle/>
More information about the tz