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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrO66o4zo9Oc8DJOiv04w1d6gfGgOcgOUBiOnTfHQ1qPA>