From owner-freebsd-arch@freebsd.org Thu Oct 22 22:12:13 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id F0D3E42C726 for ; Thu, 22 Oct 2020 22:12:13 +0000 (UTC) (envelope-from grog@lemis.com) Received: from lax.lemis.com (www.lemis.com [45.32.70.18]) by mx1.freebsd.org (Postfix) with ESMTP id 4CHM6N4vYGz4Yk5; Thu, 22 Oct 2020 22:12:12 +0000 (UTC) (envelope-from grog@lemis.com) Received: from eureka.lemis.com (aussie-gw.lemis.com [167.179.139.35]) by lax.lemis.com (Postfix) with ESMTP id B293D280AF; Thu, 22 Oct 2020 22:12:05 +0000 (UTC) Received: by eureka.lemis.com (Postfix, from userid 1004) id 09E4B26359C; Fri, 23 Oct 2020 09:12:05 +1100 (AEDT) Date: Fri, 23 Oct 2020 09:12:05 +1100 From: Greg 'groggy' Lehey To: Warner Losh Cc: Stefan Esser , "freebsd-arch@freebsd.org" Subject: Re: [REVIEW] Re: Modernizing calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars) Message-ID: <20201022221205.GJ59592@eureka.lemis.com> References: <20201021012323.GA59592@eureka.lemis.com> <7312f281-cebd-0d21-cd2b-d70d15dd2220@freebsd.org> <20201022041212.GE59592@eureka.lemis.com> <20201022044930.GF59592@eureka.lemis.com> <20201022063536.GG59592@eureka.lemis.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BEa57a89OpeoUzGD" Content-Disposition: inline In-Reply-To: Organization: The FreeBSD Project Phone: +61-3-5309-0418 Mobile: +61-490-494-038. Use only as instructed. WWW-Home-Page: http://www.FreeBSD X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 User-Agent: Mutt/1.6.1 (2016-04-27) X-Rspamd-Queue-Id: 4CHM6N4vYGz4Yk5 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of grog@lemis.com has no SPF policy when checking 45.32.70.18) smtp.mailfrom=grog@lemis.com X-Spamd-Result: default: False [-2.43 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[grog]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.97)[-0.975]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[FreeBSD.org]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(0.23)[0.234]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.89)[-0.888]; SIGNED_PGP(-2.00)[]; FORGED_SENDER(0.30)[grog@FreeBSD.org,grog@lemis.com]; RCVD_NO_TLS_LAST(0.10)[]; R_SPF_NA(0.00)[no SPF record]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:20473, ipnet:45.32.64.0/19, country:US]; FROM_NEQ_ENVFROM(0.00)[grog@FreeBSD.org,grog@lemis.com]; MAILMAN_DEST(0.00)[freebsd-arch]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 22:12:14 -0000 --BEa57a89OpeoUzGD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thursday, 22 October 2020 at 7:56:57 -0600, Warner Losh wrote: > On Thu, Oct 22, 2020 at 12:35 AM Greg 'groggy' Lehey wrote: >> 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. > > It's decayed for 24 years. The issue has actually been a lack of curating > for about 5 years when the rumblings started now with no motion in 6 months > on the problem. The lack of urgency on your part doesn't make it any less a > problem. It doesn't seem to be a problem in any other project. > Calling it emotional on my part is a way to deflect from the issue: No, you're really getting yourself worked up. Sorry about that. It wasn't my intention. > these files are badly curated and should be discarded or modernized > or something in between. On which we're agreed. When you first contacted me on the subject a month ago, I wrote: On Wednesday, 23 September 2020 at 11:53:16 +1000, Greg 'groggy' Lehey wrote: > Yes, I have been thinking about it. There are arguments on both > sides. As you say, "the contentious bits". As others say, the > non-FreeBSD files are an ananchronism. They're also seriously out > of date. On the other hand, there's interesting FreeBSD stuff there > too, and I think that belongs there. Certainly calendar(1) should > stay. I wouldn't want to see FreeBSD fragment the way most Linux > distros do. (end quote) > The fact that this issue has been brought up many times, only to > have it ignored is what's getting people upset. And you still haven't produced any evidence for this. > The fact that there's no firm timeline to a fix is also troubling. To you? Or to whom? >> 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. > > Then undertake the time to fix them if you are worried. I would do so, but you're hurrying. > 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. > > We can, actually. We do it all the time for stuff whose maintenance exceeds > its benefit. But there's almost no maintenance. That's the issue. And Apple seems to be happy enough to use versions of the data files that are well over 10 years out of date. >> 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. > > Sounds like the perfect project to cleave off to allow all groups to > contribute without it becoming a partisan 'which os' affair. Exactly. That was part of my proposal. >> 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. > > The claim is that you've been ignoring concerns that have been > raised going back years, The first time I saw this mentioned was a month ago (see quote above). > and that you seem poised to continue to do so since there's no > articulated timeline. I thought I had been pretty active in the discussion. And I haven't seen any such claims. Who made them, and why aren't they involved in this discussion? But what does this have to do with me? I'm not the maintainer, though you've made that claim in the past. I simply update obviously wrong entries when I see them. So do other people, though admittedly not as often. >> 6. The "fix" involves moving the files somewhere else, without fixing >> them. > > The "fix" is to create a centralized location for all groups to > contribute and curate rather than to continue to have the efforts > diluted by segregation. That was my suggestion, but it's not the one on the table. You apparently haven't checked whether such a location doesn't already exist. I've "checked" (sent email to people I thought might be able to help), but not received a reply yet. But that's what I wrote below: >> 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. > > So your proposal is for me to do more work? You're the person who's in such a hurry. It reflects your proposal for *me* to do more work. > I'll setup the github repo, give people permissions to do the > work. Others will need to do the work. Why set up a repo until you know it's needed? >> 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? > > So now your timeline is for me to do more work? That sounds like my > timeline, not yours. Exactly. I was just turning things around. You don't like it either, and I can understand that. But suddenly the urgency seems to have gone. >> How does that sound? > > I think it sounds lousy, honestly. It's a lot of bother that you're > trying to stick me with when you've held yourself out as the > maintainer of this software. Yes, it's a lot of bother, and you've been trying to stick me with it. But I'm not the maintainer, and I never have been. The only person who has ever claimed that I'm the maintainer is you, four months ago. Even then you used the term "informal maintainer". So, where do we go from here? If, understandably, you don't want to do the work, let's try to contact the other projects (notably Linux) and find out if they already have a repository with some version of the data files. Then we could make a meta-port that installs them. 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 --BEa57a89OpeoUzGD Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAl+SA7UACgkQIubykFB6QiNPqQCdE888j3qVM3hPDRwV7PDvGzuT rKwAn1dUWH66LrkikFF1JjzY9Hp1/HHr =ZPT3 -----END PGP SIGNATURE----- --BEa57a89OpeoUzGD--