Date: Thu, 22 Oct 2020 17:35:36 +1100 From: Greg 'groggy' Lehey <grog@FreeBSD.org> To: Warner Losh <imp@bsdimp.com> Cc: Stefan Esser <se@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: [REVIEW] Re: Modernizing calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars) Message-ID: <20201022063536.GG59592@eureka.lemis.com> In-Reply-To: <CANCZdfohU3o_tQ_6ym54b-0T4wzLPAKH71nUZdHzpPe=JUM4CA@mail.gmail.com> References: <20201020035420.GA59361@eureka.lemis.com> <CANCZdfrbq54H2iCHqsD2B3_7KGOQ0AW-tY4%2BJ1irAJgrr4TdaA@mail.gmail.com> <20201021012323.GA59592@eureka.lemis.com> <ed9abe81-7282-25a0-c5ab-dbda2f2b5ee8@freebsd.org> <7312f281-cebd-0d21-cd2b-d70d15dd2220@freebsd.org> <CANCZdfqHGD1QByrYs4_Mnn0vihjM50RQEXi3dDgXd8xZ=qQGRQ@mail.gmail.com> <20201022041212.GE59592@eureka.lemis.com> <CANCZdfqe7%2B-m_yMEgNdHt2QBAk8wHhqZNKvcNEQc9mVkhd95wg@mail.gmail.com> <20201022044930.GF59592@eureka.lemis.com> <CANCZdfohU3o_tQ_6ym54b-0T4wzLPAKH71nUZdHzpPe=JUM4CA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--64j1qyTOoGvYcHb1
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
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@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@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
--64j1qyTOoGvYcHb1
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iEYEARECAAYFAl+RKDgACgkQIubykFB6QiMHLwCeITKTdCSvx53Q2Gvt7zLqrLCl
XVEAoJqb5HrtidqkYSDxmGA/zWPA1olh
=i3rb
-----END PGP SIGNATURE-----
--64j1qyTOoGvYcHb1--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20201022063536.GG59592>