From owner-freebsd-arch@freebsd.org Tue Oct 20 16:06:53 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 E227D4343EA for ; Tue, 20 Oct 2020 16:06:53 +0000 (UTC) (envelope-from gbe@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CFz5n5lswz4Shd; Tue, 20 Oct 2020 16:06:53 +0000 (UTC) (envelope-from gbe@freebsd.org) Received: from localhost (p4fd3a1f5.dip0.t-ipconnect.de [79.211.161.245]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gbe) by smtp.freebsd.org (Postfix) with ESMTPSA id 22B0C23C7E; Tue, 20 Oct 2020 16:06:53 +0000 (UTC) (envelope-from gbe@freebsd.org) Date: Tue, 20 Oct 2020 18:06:52 +0200 From: Gordon Bergling To: Warner Losh Cc: Shawn Webb , Greg 'groggy' Lehey , freebsd-arch@freebsd.org Subject: Re: Modernizing calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars) Message-ID: <20201020160652.GA42096@lion.0xfce3.net> References: <20200923134334.czblcl2ppyxjnigs@mutt-hbsd> <20201020035420.GA59361@eureka.lemis.com> <20201020122844.terxqb75dyvb4zqc@mutt-hbsd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6TrnltStXW4iwmi0" Content-Disposition: inline In-Reply-To: X-Url: X-Operating-System: FreeBSD 12.2-STABLE amd64 X-Host-Uptime: 6:03PM up 5 days, 23:52, 5 users, load averages: 0.27, 0.21, 0.22 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: Tue, 20 Oct 2020 16:06:54 -0000 --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 20, 2020 at 10:00:06AM -0600, Warner Losh wrote: > On Tue, Oct 20, 2020, 6:28 AM Shawn Webb wro= te: >=20 > > On Mon, Oct 19, 2020 at 10:46:56PM -0600, Warner Losh wrote: > > > On Mon, Oct 19, 2020 at 9:54 PM Greg 'groggy' Lehey > > > wrote: > > > > > > > This discussion, from a month ago, seems to have died a death. Fir= st > > I'll > > > > summarize what imp@ says: > > > > > > > > On Wednesday, 23 September 2020 at 9:18:27 -0600, Warner Losh wrot= e: > > > > > > > > > > 1. I'll do for calendar what I did for CTM. We'll split it out in= to > > its > > > > own > > > > > git repo. git filter-patch is straight-forward to use, but has a > > number > > > > of > > > > > caveats with the imperfect github mirror we have. I'll do it agai= nst > > the > > > > > beta cgit mirror and write up the process since I'm pretty sure > > people > > > > will > > > > > want to replicate it in the future. > > > > > 2. Delete the contentious bits (details to follow) > > > > > 3. Adjust the build (since calendar uses cpp to build up its > > databases) > > > > > 4. Prune the new repo to just the contentious bits into that repo > > (likely > > > > > under github.com/freebsd/calendar, like we've done for CTM and ot= her > > > > things) > > > > > 5. Create a port you can optionally install > > > > > 6. Adjust calendar to work when things are there (or not there) > > > > > 7. Remove the contentious bits from FreeBSD... > > > > > > > > This shows the procedural approach. But what do we really want? I > > > > think that we should agree that we don't want to remove functionali= ty, > > > > just bring things into the 21st century. As I see it, there are th= ree > > > > approaches: > > > > > > > > 1. Nobody cares enough about it, so leave it as it is. > > > > > > > > Given the lack of input on the subject, this might be the best > > > > choice. It's certainly the easiest. But it leaves a lot of dead > > > > wood and unbalanced and incorrect content. > > > > > > > > > > Nah, people want the crusty old files of it gone. Trust me. > > > > > > > > > > 2. Move the non-FreeBSD related stuff into a port. This is imp@'s > > > > approach above. As you can see, it's rather involved, and it se= ems > > > > to me that we shouldn't be doing this sort of thing until we've > > > > moved the project to git and the dust has settled. It also > > > > complicates maintenance, and it doesn't address the dead wood and > > > > dubious content. > > > > > > > > > > It's actually not all that involved. I've done it before for CTM and = it's > > > about 1/2 hour of work to pull all the history along. 0 hours of work= if > > > you don't care about the history. It actually goes hand in hand with = #3 > > > below. > > > > > > > > > > 3. Create a separate port that sucks in and maintains suitable > > > > calendar entries from *somewhere* and maintain a directory > > > > hierarchy, say /usr/local/calendar, in the same form as the curr= ent > > > > /usr/share/calendar. Modify the calendar(1) in the tree to look= at > > > > this hierarchy as well. /usr/share/calendar should remain for t= he > > > > few FreeBSD-related files (as far as I can tell, only > > > > calendar.freebsd). > > > > > > > > > > Yea, I think you're right. The FreeBSD one is the interesting bit to = the > > > project, and there's enough people that have .calendar files to make = it > > > interesting to stay in base. Were it not for this FreeBSD connection, > > maybe > > > it could just live entirely in ports. Calendar has been around since = 7th > > > Edition Unix, so there's history there as well, though that seems less > > > important these days. > > > > Note that the history of the calendar files is retained in the src > > repo, so nothing there is lost with regards to tracing the history > > to "back in old country." > > >=20 > It's trivial to extract, though... so there's no need to argue to have the > best of both worlds. >=20 > But the bigger point I'm making is that the calendar.freebsd file is more > central to the project and there has been a large desire expressed to keep > that bit in base. >=20 > Warner Very well written! Thank you! --Gordon --6TrnltStXW4iwmi0 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEEYbWI0KY5X7yH/Fy4OQX2V8rP09wFAl+PCv5fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDYx QjU4OEQwQTYzOTVGQkM4N0ZDNUNCODM5MDVGNjU3Q0FDRkQzREMACgkQOQX2V8rP 09y5BQf9Fo1fQheCdccnE5QvoxgJQDSxsVHBYYZE9L1sG21OsmeepGvfsaMAKm+b dJamD0xt824/aYN6n5EAwxLp2Ijwu+o5sH+/ESknZfRH5DZ4I/9e+2SCXakhLQJR kmDpE2eHLBzUs0QllK9/bUljUtZ/skh4o8UsqgIYjw4ukK+iPHMhusGGPeaVpxbw gYSwuBKpl+JgoxjTJyvKa5oZjTfAMRF9sYsI1bSa+TXmDQRo/HnBBDuPXwZy61uY pNRzMRLsENWbJ1q49Z8vYpwM1i4LffujUqcwMBUWyt1QLs+4N5Vax1q6U6Q2RqZG RPQBJUEPYiqlfNBYjYBz2MiJdg8gFA== =SYr8 -----END PGP SIGNATURE----- --6TrnltStXW4iwmi0--