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