On Wed, Oct 28, 2020 at 9:09 AM Stefan Esser <s...@freebsd.org> wrote:
> Am 28.10.20 um 14:34 schrieb Kyle Evans: > > On Wed, Oct 28, 2020 at 8:24 AM Stefan Esser <s...@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 _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
