[tz] Preparing to fork tzdb

[Tom Lane]

Stephen Colebourne via tz <tz at iana.org> writes:
> On Mon, 20 Sept 2021 at 11:48, Eliot Lear via tz <tz at iana.org> wrote:
>> I would suggest an alternative: the policy of this group is set in an RFC, and that RFC can be updated if there is consensus in this community to do so.  If the community doesn't like the policy, it can change it, and continue to gain the benefit of one another.

> Right now there is effectively a schedule gun being held to our heads
> - if we do not act a new release will come out with the disputed
> changes in it.

Indeed, and at that point it would pretty much be a fait accompli,
because reverting the changes later would create an even huger mess.

As far as the RFC (BCP 175) goes, I'll just quote it:

>> 5.  Appealing Database Decisions
>> 
>>    The TZ Coordinator makes decisions based on expertise, as well as
>>    with guidance from the TZ mailing list.  If a member of the community
>>    has a concern with an individual decision made by the TZ Coordinator
>>    with regard to the TZ database, the individual shall proceed as
>>    follows:
>> 
>>    1.  Attempt to resolve the concern directly with the TZ Coordinator.
>> 
>>    2.  If a resolution cannot be reached directly with the TZ
>>        Coordinator, express the concern to the community and attempt to
>>        achieve rough consensus regarding a resolution on the TZ mailing
>>        list.  The Area Directors of the IETF Applications Area may at
>>        their discretion attempt to guide the members of the community to
>>        rough consensus.
>> 
>>    3.  As a last resort, if a resolution cannot be reached on the TZ
>>        mailing list, appeal to the IESG for a resolution.  The appellant
>>        must show that the decision made by the TZ Coordinator (a) was
>>        materially in error and (b) has caused material harm.  In its
>>        deliberations regarding an appeal, the IESG shall weigh all the
>>        evidence presented to it and use its best judgment in determining
>>        a resolution.

Seems to me that we have failed at step 1, and that to the extent that
there is any community consensus per step 2, it is against this set
of changes.  So per process we ought to move on to step 3.  (This should
have been done months ago, likely, but everyone was hoping for a less
unfriendly outcome.)  The problem now is that there is no time for any
such appeal.  We need 2021b now, and if it comes out with these changes,
the only way for people to retain stability of the data is to fork.

(I suppose for a lot of us, the least painful choice is to sit on
2021a for awhile, ignoring the Apia changes.)

			regards, tom lane