Date: Wed, 28 Oct 2020 09:33:26 -0600 From: Warner Losh <imp@bsdimp.com> To: Stefan Esser <se@freebsd.org> Cc: Kyle Evans <kevans@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org> Subject: Re: svn commit: r367103 - head/usr.bin/calendar Message-ID: <CANCZdfrO66o4zo9Oc8DJOiv04w1d6gfGgOcgOUBiOnTfHQ1qPA@mail.gmail.com> In-Reply-To: <46d724c0-87b8-740c-777d-f699527ccb6e@freebsd.org> References: <202010281306.09SD6dgf040611@repo.freebsd.org> <CACNAnaERLh7NvWQ45FZd_s94rApwzyDpah2APP3m=VbfBZrTgg@mail.gmail.com> <784474fd-2f63-066c-eb86-cddfebd499cb@freebsd.org> <CACNAnaHsuz=1=AxdGhr7Z5avhb5J%2BMXKAhPZN_mtvCzbHoXJiA@mail.gmail.com> <46d724c0-87b8-740c-777d-f699527ccb6e@freebsd.org>
index | next in thread | previous in thread | raw e-mail
On Wed, Oct 28, 2020 at 9:09 AM Stefan Esser <se@freebsd.org> wrote: > Am 28.10.20 um 14:34 schrieb Kyle Evans: > > On Wed, Oct 28, 2020 at 8:24 AM Stefan Esser <se@freebsd.org> wrote: > >> I'm thinking about support for nested conditionals and #else in > >> calendar files, but I'm not sure about the possibility to MFC > >> such a change and I do not want to invite users to create calendar > >> files that work in -CURRENT but not in -STABLE. > > > > Unsolicited $0.02: Do whatever you feel comfortable with. It's up to > > people trying to use the new/advanced features to make sure it's > > compatible with the calendar(1) that *they* are using, and I'm having > > a hard time imagining folks using deploying additional calendar data > > in ports outside of deskutils/calendar-data which you can curate for > > stuff like that. > > I only read your reply after committing the change that allows for > recursion. > > The issue reported by Julian H. Stacey on the freebsd-stable list > made me check for the code that implements these conditions, and > I noticed that there was no #ifdef (which he had tried to use), > but it was trivial to implement. > > The man-page mentions that a restricted subset of CPP directives > is supported, and ISTR that an earlier version of the calendar > program actually forked CPP to pre-process the data files. > > This approach required a "traditional" CPP that ignored the content > of the non-directives being processed, which is no longer available. > > In a way I'm removing some of the limitations that resulted from > the switch to an internal parser for the conditions. > > If there is consensus not to introduce any new features into our > calendar program, then I'm going to revert these changes. > > I had planned to give time for a discussion about a possible > merge to -STABLE. > > I have already created a port of the calendar program as > deskutils/calendar and was planning to upgrade the port to include > these changes in -CURRENT. > > The port could be used to provide release users with these features, > if they consider them useful. > > Since the changes are fully compatible with old data files, I do > not think that a MFC was a violation of POLA. > > We do now have the calendar-data port for use in -CURRENT and it > could be used to distribute calendar files that use the new features. > > Since old calendar programs will not look into the port's data file > directory, they will continue to operate on files in the base > system. > > If the calendar program from a port is used, it will support the > features of this version and that all calendar files that take > advantage of them. > > We might hide these new features by removal from the man-page or we > could discourage their use by declaring them unportable extensions. > Honestly, I think MFCing what we've committed to date and requiring calendar-data is fine. POLA isn't violated because you have to install a new port, especially when the program that 'fails' includes that in its failure message. It's the least bad solution, and calendar isn't a critical part of the infrastructure where we have to make herculean efforts to hide any changes. It beats the old files rotting in stable. Warnerhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrO66o4zo9Oc8DJOiv04w1d6gfGgOcgOUBiOnTfHQ1qPA>