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