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

[Gordon Bergling]

On Tue, Oct 20, 2020 at 10:00:06AM -0600, Warner Losh wrote:
> On Tue, Oct 20, 2020, 6:28 AM Shawn Webb <shawn.webb at hardenedbsd.org> wrote:
> 
> > 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 <grog at freebsd.org>
> > > wrote:
> > >
> > > > This discussion, from a month ago, seems to have died a death.  First
> > I'll
> > > > summarize what imp@ says:
> > > >
> > > > On Wednesday, 23 September 2020 at  9:18:27 -0600, Warner Losh wrote:
> > > > >
> > > > > 1. I'll do for calendar what I did for CTM. We'll split it out into
> > 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 against
> > 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 other
> > > > 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 functionality,
> > > > just bring things into the 21st century.  As I see it, there are three
> > > > 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 seems
> > > >    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 current
> > > >    /usr/share/calendar.  Modify the calendar(1) in the tree to look at
> > > >    this hierarchy as well.  /usr/share/calendar should remain for the
> > > >    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."
> >
> 
> It's trivial to extract, though... so there's no need to argue to have the
> best of both worlds.
> 
> 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.
> 
> Warner

Very well written! Thank you!

--Gordon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 618 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20201020/f58822f1/attachment.sig>