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

[Warner Losh]

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:
> >>> [...]
> >>>> 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.
> >>>
> >>> Are we taling about the calendar binary or the calendar files?
> >>>
> >>> IMHO, the calendar binary could stay in base but be modified to
> >>> scan directories in e.g. /usr/local/share/calendar/ and ports
> >>> could provide these calendar files.
> >>
> >> I have created a Phabricator review for the proposed change:
> >>
> >>         https://reviews.freebsd.org/D26882
> >>
> >> This is just an enabler for calendar files in a directory that
> >> can be maintained by means of a port.
> >>
> >> 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. They can pull from github
easily enough. 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.

This issue has been simmering for years, but has flared up in the last 6
months. In that time no progress has been made. And it has no impact on the
data source issue: that can be handled at whatever pace other groups want
to come together.

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.

So, unless you have a competing plan, with a firm timeline, 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.

Warner

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
>