<div dir="ltr"><div dir="ltr">On Mon, Sep 20, 2021 at 8:52 AM Stephen Colebourne via tz <<a href="mailto:tz@iana.org">tz@iana.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, 20 Sept 2021 at 11:48, Eliot Lear via tz <<a href="mailto:tz@iana.org" target="_blank">tz@iana.org</a>> wrote:<br>
> I think it's a bad idea to fork for a great many reasons, only a few of which are the following:<br>
><br>
> Time confusion going forward, with new inconsistencies being introduced.<br>
> Implementer confusion in terms of which code base is more up-to-date; worse if the code base fragments.<br>
> Fragmentation of expertise among volunteers<br>
><br>
> I fear that you drastically underestimate the effort that has been required to maintain both the code and the data.<br>
<br>
If you read carefully, my original mail proposed forking the data - it<br>
did not propose forking the code. I imagine this would be a case where<br>
the fork would follow each commit in tzdb, including the code changes,<br>
but seeking to maintain the data set as it should be.<br></blockquote><div><br></div><div>Speaking as a participant only:<br><br></div><div>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.<br></div><div><br></div><div>-MSK<br></div></div></div>