upstream for contrib/tzcode/stdtme?

[Philip Paeps]

On 2018-08-12 20:36:23 (+0800), Philip Paeps wrote:

> On 2018-08-12 20:23:23 (+0800), Eitan Adler wrote:
>
>> On Mon, 18 Jun 2018 at 10:08, John Baldwin <jhb at freebsd.org> wrote:
>>>
>>> On 6/15/18 4:09 PM, Eitan Adler wrote:
>>>> On 15 June 2018 at 11:31, John Baldwin <jhb at freebsd.org> wrote:
>>>>
>>>>> I think this second approach is actually a better plan and is not 
>>>>> quite what you
>>>>> were suggesting.
>>>>>
>>>>> That is, import the vendor bits corresponding to our existing code 
>>>>> first into
>>>>> the vendor area,
>>>>
>>>>> then svn cp our existing files from libc, zic, etc. into the
>>>>> contrib/stdtime tree in the correct layout and do a single 'svn 
>>>>> merge --record-only'
>>>>> merge to initialize the vendor mergeinfo.
>>>>> At that point you should be able to
>>>>> svn diff contrib/stdtime against the vendor/stdtime/dist to 
>>>>> determine what local
>>>>> changes we have and start to think about them.
>>
>> Coming back to this. In r337683 and r337684 I imported a recent copy
>> of of TZDB. I was unable to find a copy of the 2010n distribution in
>> the original layout.
>
> That's because we split up the tzcode in our vendor area (for reasons 
> I've never understood).  As far as I know, there is no 1:1 mapping 
> from any tzcode distribution to what we have in our repository.
>
>> The next step, if I understand, is to do the following:
>> cd /srv/srv/freebsd/svn/head/contrib
>> mkdir tzdb
>> cd tzdb
>> svn cp ../tzcode/stdtime/* .
>> svn cp ../tzcode/zic/* .
>> svn cp ../tzdata/* .
>> svn ci
>> (the above ignores duplicated files, but that's just expanding the
>> wildcards appropriately).
>>
>> After that:
>> svn merge --record-only '^/vendor/tzdb' .
>>
>> At this point we'll be able to diff contrib/tzdb and vendor/tzdb to
>> show the most current vendor code compared our, modified old code.
>>
>> Is this correct? Is this the optimal plan?
>
> I would really (really!) want to keep tzdata separate from tzcode and 
> not make it any more difficult to update tzdata (which happens 
> distressingly often).
>
> tzdata imports/updates are currently not a problem.  And it's nice to 
> be able to simply issue an errata notice only updating the zoneinfo 
> files without touching the tzcode.
>
> The IANA tzdata project also distributes tzdata and tzcode separately. 
>  If you wanted to update tzcode, you could do it independently of 
> tzdata.

I just noticed you've already committed this import.

In case you're not actively following the tz mailing list, you may have 
missed that every release of tzdb comes with lots of minor but annoying 
code changes in addition to the data changes we actually want to 
distribute as quickly as possible.

Currently, updating the tzdata is a fairly mechanical process of 
updating vendor/tzdata and doing a couple of svn copies to contrib.  If 
we started tracking the combined tzdb rather than tzcode and tzdata 
separately, issuing errata notices for timezone updates becomes 
practically impossible.

Updating the zoneinfo files in an errata patch is non-controversial, 
certainly compared to often seemingly arbitrary changes to the subtle 
code that manipulates the representation of time.  It makes no sense to 
import these together or attempt to maintain them as one vendor tree.  
That is why the tzcode and tzdata tarballs exist separately in addition 
to the combined tzdb tarball.

As requested on the src-commits list: please import tzcode separately 
and leave tzdata alone.

Thank you.

Philip

-- 
Philip Paeps
Senior Reality Engineer
Ministry of Information