On Mon, Sep 20, 2021 at 8:52 AM Stephen Colebourne via tz <tz@iana.org> wrote:
On Mon, 20 Sept 2021 at 11:48, Eliot Lear via tz <tz@iana.org> wrote:
I think it's a bad idea to fork for a great many reasons, only a few of which are the following:
Time confusion going forward, with new inconsistencies being introduced. Implementer confusion in terms of which code base is more up-to-date; worse if the code base fragments. Fragmentation of expertise among volunteers
I fear that you drastically underestimate the effort that has been required to maintain both the code and the data.
If you read carefully, my original mail proposed forking the data - it did not propose forking the code. I imagine this would be a case where the fork would follow each commit in tzdb, including the code changes, but seeking to maintain the data set as it should be.
Speaking as a participant only: I agree with Eliot. Though I'm a relative newcomer to this particular space, I have never seen a successful fork of the nature you're describing. You make it sound simple here, but I would bank on the inevitability of some change being introduced into the original data that cannot be trivially merged into the fork. I wouldn't want to be the person responsible for sorting that out while simultaneously tracking all of the other issues the current coordinator handles on a regular basis. -MSK