From owner-svn-src-head@freebsd.org Wed Oct 28 15:33:39 2020 Return-Path: Delivered-To: svn-src-head@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 A90254498C3 for ; Wed, 28 Oct 2020 15:33:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CLszl023hz4H61 for ; Wed, 28 Oct 2020 15:33:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x836.google.com with SMTP id i7so3821834qti.6 for ; Wed, 28 Oct 2020 08:33:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZxRtkF4flx2dY/owH+2w8R0tEfYw1Bu4yYajKn/KHc4=; b=VJD+K080jfp+8cPTV4iW2Aci4A516e8C4ian+IRARWS3hsMRCVpMFes5aC84qPgLOj qYeH+aUs/IxYilqg7cy4Ap+yizcppXrbJJ5CQKT8EWZX9wpETyAQC+IBpg1ICts0fnWI El4NrujnGy4Ri2Z84Zb7ZOtRiSVyQ5JcvabE+6N78UG4gdHwnoJ+6ABC7ArjwNKNMzKI IwInjszNJnpolj03Q5UgQqRSvol56zK3/TpF4xxKwgzlmL/jsyHg1PWrDQag/ls0xovn /kzevKRPeOW7no0uVW2r7vebh0JbONYQxs0UsrtlYMenmCUrPrP9KzHAbGXrIrFml8St ZjUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZxRtkF4flx2dY/owH+2w8R0tEfYw1Bu4yYajKn/KHc4=; b=NtbkFRbzwhrdeQ8W/iXiiXU1Pd4b+3Xq6Gm5zwlteS1ODP55fnWhz/Qade3XYEKyQd LW4guG/jIXMtLIN+oN+M/+KA6M3l+o/4HfSETQAhsU85YPR2ULu1e9CvFk0eQtlpIjO+ 7A/DTzRTx4UrcMr5CBt50+OX2EHwDHOKYDliaA52dgo4iYhkGMgHW/Zf9EBG8Scn7N7p GIxtYbVz04IM6mDmVEqFZ6oKPAaa8NIl+t1OjO+5MXjqOsvGcF+Qx2OST2v0FbccpEOB EWAwYwkxQ6nJvTwKQUlCiyIuLZC150wkDQ/mesOesB/Bex5AFWnVt7pan2J5ShCPyzVr a2tQ== X-Gm-Message-State: AOAM530AIW1pmM1LfZ8WzBwI2XQjMURBkfZvs5nJuWBIhAYnyw40MRfY SL86EBtNXrpxmGqoxqKHsjwwWdn3fUxLqyW9oStl0g== X-Google-Smtp-Source: ABdhPJxNgdePEIM6+ors0DAkFGqodLicU9DHJfNGZYjwlNHAOkm76AJXJD82hfz1WD9QiXCRWGU5RWBKAuUSqungvHM= X-Received: by 2002:aed:2f67:: with SMTP id l94mr7606503qtd.101.1603899217743; Wed, 28 Oct 2020 08:33:37 -0700 (PDT) MIME-Version: 1.0 References: <202010281306.09SD6dgf040611@repo.freebsd.org> <784474fd-2f63-066c-eb86-cddfebd499cb@freebsd.org> <46d724c0-87b8-740c-777d-f699527ccb6e@freebsd.org> In-Reply-To: <46d724c0-87b8-740c-777d-f699527ccb6e@freebsd.org> From: Warner Losh Date: Wed, 28 Oct 2020 09:33:26 -0600 Message-ID: Subject: Re: svn commit: r367103 - head/usr.bin/calendar To: Stefan Esser Cc: Kyle Evans , src-committers , svn-src-all , svn-src-head X-Rspamd-Queue-Id: 4CLszl023hz4H61 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=VJD+K080; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::836) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-1.92 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-1.002]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.06)[0.060]; NEURAL_HAM_LONG(-0.98)[-0.975]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[svn-src-head@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::836:from]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; MAILMAN_DEST(0.00)[svn-src-head]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 15:33:39 -0000 On Wed, Oct 28, 2020 at 9:09 AM Stefan Esser wrote: > Am 28.10.20 um 14:34 schrieb Kyle Evans: > > On Wed, Oct 28, 2020 at 8:24 AM Stefan Esser 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