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

[Greg 'groggy' Lehey]

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:
>
>> On Wednesday, 21 October 2020 at 19:48:31 -0600, Warner Losh wrote:
>>> On Wed, Oct 21, 2020, 4:03 AM Stefan Esser <se at freebsd.org> wrote:
>>>
>>>> Am 21.10.20 um 09:15 schrieb Stefan Esser:
>>>>> Am 21.10.20 um 03:23 schrieb Greg 'groggy' Lehey:
>>>> A suggested port has been made available for review, too:
>>>>
>>>>         https://reviews.freebsd.org/D26883
>>>
>>> Modulo the stuff I left on the reviews....  I love it. I can also
>>> extract history from FreeBSDs repo.
>>
>> 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.

> Finally, it's my firm belief that the majority of developer opinion
> is that this would be better served with this split. It's been that
> way for years.  Until recently, though, the commit rate has been so
> low that people shrugged.  Now, there have been enough that it's my
> view that the community is jelled behind the split and are growing
> inpatient for its resolution.

Again, what I see is more shrugging than impatience.  So far I have
seen you pushing, and one or two asking for action (and that a while
back).  Those one or two have not responded to this thread, suggesting
that they're not overly impatient.

> So, unless you have a competing plan,

Sorry, I thought I had explained that.

> with a firm timeline,

I don't think that's important.

> I think we should allow se@ to proceed as he proposes. It is time
> limited, concrete, simple to execute and in line with other times
> we've done similar.

The only argument in favour is that it's relatively simple to migrate
further.  But once it's done, there's a great danger that things will
stay that way, and we'll just have one more wrinkle in the history.

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