Stephen Colebourne <scolebourne@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 files. 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 original change. 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 of time.
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@stanford.edu) <http://www.eyrie.org/~eagle/>