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

[Greg 'groggy' Lehey]

On Wednesday, 21 October 2020 at 22:54:39 -0600, Warner Losh wrote:
> On Wed, Oct 21, 2020, 10:49 PM Greg 'groggy' Lehey <grog at freebsd.org> wrote:
>
>> On Wednesday, 21 October 2020 at 22:23:08 -0600, Warner Losh wrote:
>>> On Wed, Oct 21, 2020, 10:12 PM Greg 'groggy' Lehey <grog at freebsd.org> wrote:
>>>
>>>> The change to calendar(1) looks fine, but I have my issues with the
>>>> port.  It seems that we're not alone.  On the one hand, both Apple and
>>>> Linux have used our data files for their packages, so removing the
>>>> data files would violate POLA.  On the other hand, Apple, Linux,
>>>> NetBSD and OpenBSD are maintaining their own versions of these files,
>>>> along with calendar(1).  My guess is that Linux has them hidden on
>>>> GitHub.  I'm trying to find out where they maintain the files (can any
>>>> Linuxheads help?), so that we can come to a general agreement about
>>>> how to maintain them.  This could include removing calendar(1) from
>>>> the tree entirely and installing from a port.  Once again I'm
>>>> concerned about jumping the gun.
>>>
>>> Where we pull them from doesn't affect that.
>>
>> But where other people pull them from *is* relevant.
>>
>>> They can pull from github easily enough.
>>
>> Once they know, yes.  But maybe they already have it on GitHub.
>>
>>> And our users can install a port easily enough. It's done all the
>>> time, so wouldn't be that surprising even from that perspective.
>>
>> First they need to know that they have to install a port to get what
>> they got automatically in the past.
>>
>>> This issue has been simmering for years, but has flared up in the
>>> last 6 months.
>>
>> I haven't seen any flare.
>
> Then you've not been paying attention.
>
>>> So, unless you have a competing plan,
>>
>> Sorry, I thought I had explained that.
>
> It seemed less a firm plan than a sketch.
>
>> with a firm timeline,
>>
>> I don't think that's important.
>
> And that is the problem.

What I see is a somewhat emotional response without clear reasoning.
FWIW, yes, I've been paying attention, and saving all relevant emails.
My proposal is about as good as it goes without input from other
projects.  And nobody has explained why 24 years is OK, but suddenly 6
months is too long.

In principle se@'s proposal is good.  But my concern is
that then the matter will be forgotten, and the problem will be left
half fixed.

Let's summarize:

1.  We have an program from 4BSD with old, mouldy data files that have
    outlived their purpose.

2.  But we can't just discard them without finding a better
    alternative.

3.  Not just FreeBSD, but also Linux and Mac OS use these files, and
    they appear to get them from us.  NetBSD and OpenBSD also have
    variants on these files, including errors that I've fixed over the
    years.

4.  Unnamed people in the FreeBSD project are upset about the
    continuing presence of our version of these files in the FreeBSD
    tree.

5.  There are claims that it has to be fixed Right Now, with no delay.

6.  The "fix" involves moving the files somewhere else, without fixing
    them.

What I see is an opportunity.  We should get the other projects on
board and agree on a central repository for all projects.  Probably
this would be GitHub, as you have suggested.  But maybe there's one
there already, and if we want to get the other projects on board, we
should discuss it with them.

So why not just accept se@'s proposal?  It has the obvious advantages
of making sense and silencing the spirits which are tormenting you.
My concern is that it will then be forgotten, and we will miss the
opportunity to unify the data.

So: a concrete proposal.

1.  We accept se@'s split as a first step.

2.  You personally agree to follow up with the other projects and
    ensure that the data will end up on an OS-neutral platform from
    which all projects can draw their data.

3.  You agree to do this with a firm timeline.  Since it seems that 6
    months is too long, how about by the end of 2020?

You're still involved with NetBSD and OpenBSD, right?  That should
make things easier.  I'll happily chase up the Linux people, and
presumably there are people here who can get Apple involved, if
they're still interested.

How does that sound?

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/20201022/fc71130b/attachment.sig>