Modernizing calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars)

[Greg 'groggy' Lehey]

[Irrelevant quotations trimmed]

On Monday, 19 October 2020 at 22:46:56 -0600, Warner Losh wrote:
> On Mon, Oct 19, 2020 at 9:54 PM Greg 'groggy' Lehey <grog at freebsd.org> wrote:
>> This shows the procedural approach.  But what do we really want?  I
>> think that we should agree that we don't want to remove functionality,
>> just bring things into the 21st century.  As I see it, there are three
>> approaches:
>>
>> 1. Nobody cares enough about it, so leave it as it is.
>>
>>    Given the lack of input on the subject, this might be the best
>>    choice.  It's certainly the easiest.  But it leaves a lot of dead
>>    wood and unbalanced and incorrect content.
>
> Nah, people want the crusty old files of it gone. Trust me.

It seems that I'll have to.  Nobody else has mentioned this recently,
and we don't have enough clarity on what "crusty old files" means.

> ...
>
>> 3. Create a separate port that sucks in and maintains suitable
>>    calendar entries from *somewhere* and maintain a directory
>>    hierarchy, say /usr/local/calendar,

/usr/local/share/calendar, of course, as you mentioned elsewhere.

>>    in the same form as the current /usr/share/calendar.  Modify the
>>    calendar(1) in the tree to look at this hierarchy as well.
>>    /usr/share/calendar should remain for the few FreeBSD-related
>>    files (as far as I can tell, only calendar.freebsd).
>
> The calendar.usholiday isn't too bad. It could remain too. It's
> super short and the only tweaking needed would be when the times
> change.

That's the thin edge of the wedge.  US holidays are of interest to a
group that only partially overlaps with the FreeBSD community.

> It might make sense to do one for eu and asia too that list the
> major holidays elsewhere given how connected the world is.

And forget Africa, most of America and Australia?

> Then again, that may be a bit beyond the remit of the current system
> too, but we're a world-wide group that could easily crowd source
> this. The current calendar.holiday is way too obscure and bizarre,
> though some people like it.

That's the whole point.  Where do we draw the line?  Given that these
holidays interest more people outside the project than in, I'd think
that they should all go into the port.  And the whole idea of
alternative 3 is that the maintenance should be automatic and
external, so updating holidays should no longer be our concern.

>>    This would be my preferred approach.  The issue is identifying
>>    *somewhere*.  I've done a bit of searching on the web, and I've
>>    found lots of "on this day" sites, but nothing that would easily
>>    lend itself to conversion to calendar(1) files of the kind I'm
>>    looking for.  Input here would be welcome.
>
> Ah, that's a second problem. But let's not get bogged down in
> solving that and then fail to do the split properly.

I don't understand your haste in wanting to do this.  Until we don't
know what we're going to do, we can't do the split properly.  We've
had calendar since the beginning of time, and suddenly it seems to
need changing.  Let's agree on what we want to do first.

In the meantime, though, something else has occurred to me: at least
get buy-in from the other BSD projects.  I've just checked NetBSD,
OpenBSD, Mac OS and Ubuntu (I think) Linux, and they all have the same
structure.  They also all have the same error that I fixed in FreeBSD
a couple of days ago.  I'm pretty sure that they're in the base system
for the first three, since they're from a virgin installation.  My
guess is that they're also in the base system for Ubuntu, or whatever
version I have access to.

This issue is not important enough to take a knee-jerk approach.  I'd
rather see something that all the projects can use.  In this
connection, of course, GitHub sounds like a good potential start, but
would the OpenBSD project (for example) buy in to it?

Greg
--
Sent from my desktop computer.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20201021/c6581f59/attachment.sig>