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

[Warner Losh]

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:
> >
> >> 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.
>

Then you've not been paying attention.

> 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.
>

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.

> 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.
>

Well, on github, you can push changes there and accept pull requests too...

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
>