[tz] make error

[Brian Inglis]

On 2023-11-17 20:32, Philip Paeps via tz wrote:
> On 2023-11-18 03:20:41 (+0800), Paul Eggert via tz wrote:
>> On 2023-11-17 00:30, Robert Elz wrote:
>>> future version probably ought to be
>>> rather distant future, not next year sometime (or even the next few years
>>> after that).
>>
>> Good point. From what we know now, 2029 might be a good year to do it, as RHEL 
>> 7 ELS ends June 2028. I installed the attached proposed patch. We can of 
>> course delay until after 2029 as more info becomes known.
> 
> I think it's reasonable to expect everyone to have a C99 compiler by 2029.  The 
> standard will turn 30 years old that year.  Even the most tenacious long-term 
> support systems will have run out of support by then.  Moreover: the poor souls 
> stuck with maintaining those systems will have ample experience installing newer 
> compilers on them.
> 
> Nobody will accuse the tz project of being hasty.  Especially since we're giving 
> 5+ years notice.
> 
>>> It might be worth adding a "common issues" file
>>
>> Yes, GNU Emacs does something like this, with its etc/PROBLEMS file (currently 
>> 4412 lines).
>>
>> Currently TZDB puts this sort of thing in Makefile, which discusses the C89 
>> issue along with dozens of similar porting issues. Evidently Makefile isn't 
>> always being read; this is not surprising as it has hundreds of lines of 
>> comments.
>>
>> Not sure that a separate PROBLEMS file (which would also have hundreds of 
>> lines) would always be read either. To some extent we'll always be stuck 
>> getting email saying "this doesn't work for me" by people who haven't had time 
>> to read the relevant documentation, regardless of where that documentation is.
>>
>> For what it's worth, the Emacs etc/PROBLEMS file contains a long list of 
>> problems most of which nobody ever runs into nowadays, and hardly anybody 
>> reads the file.
> 
> I agree that a separate file pointing out PROBLEMS won't encourage anyone to 
> read it.  Guy's suggestion, elsewhere in this thread, to add a pointer to the 
> Makefile in the README is a good idea.  At least README has a fighting chance of 
> being read ... the clue is in the name. :-)

Perhaps some document named something like idk FAQ? could point those with 
questions about policies, rules, zones, and data to Theory; processes to the 
RFC; building and code to the Makefile?

People with questions often look for a FAQ and posters and contributors have 
requested one be written to respond to the questions often asked on the list.
A small start in that direction could encourage patches to head off long threads.

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry