From owner-freebsd-arch@freebsd.org Sun Dec 16 19:21:07 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CF2C91337C0B for ; Sun, 16 Dec 2018 19:21:07 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 7A4C0937A0 for ; Sun, 16 Dec 2018 19:21:07 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id 35B8C1337C03; Sun, 16 Dec 2018 19:21:07 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 245C61337C02 for ; Sun, 16 Dec 2018 19:21:07 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 778CC93790 for ; Sun, 16 Dec 2018 19:21:06 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id wBGJL3F2092571; Sun, 16 Dec 2018 11:21:03 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id wBGJL3GH092570; Sun, 16 Dec 2018 11:21:03 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201812161921.wBGJL3GH092570@pdx.rh.CN85.dnsmgr.net> Subject: Re: A proposal for code removal prior to FreeBSD 13 In-Reply-To: <261A6437-3ECC-43FF-ADA2-EE430477BB92@lists.zabbadoz.net> To: "Bjoern A. Zeeb" Date: Sun, 16 Dec 2018 11:21:03 -0800 (PST) CC: George Neville-Neil , freebsd- X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 778CC93790 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.973,0]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; REPLY(-4.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2018 19:21:08 -0000 > On 16 Dec 2018, at 16:45, Rodney W. Grimes wrote: > > I?ll ignore the ?turning FreeBSD into change-management > procedures? part. > > > timed was removed outside of current procedure, and that should > > be corrected ASAP, > > No, it should not. There is a stable branch, with shipping releases, > and support until at least June 30, 2020, possibly longer. Your confusing "correcting the lack of deprecation notice" with "reverting the removal". As it stands now no deprecation notice has been made per 17.4 of the handbook, that is bad and wrong. The "corrections" needed are to stable/12 now, as direct commits, since it wasnt done correctly in head: 1) timed needs to spit out a message when it is invoked. 2) timed(8) needs a deprecation notice added. 3) The above should be flagged with relnotes: yes so that the 12.1 release notes can state that timed is going away in 13. > > The questions are: > (a) will the request still be relevant then? > (b) do we still want to support it then? > (c) with pkgbase hopefully coming, will it still matter or is it better > off to be ?3rd party? software? > (d) if it?s coming back, do we have a developer to care about it and > take care of the original reason that triggered the removal? I would say it was removed without proper due process and could ask for a revert, but at this time I am not, I am only asking that the proper procedures be minimally adbered to. > > > as one developer has already spoken up that > > they are using it. > > s/developer/user/ ; whether he is a developer as well is not the point. It can be, as often developers are speaking for much more than just a user, any of the develoeprs who support a large deployed base have far more pull in my book than a loan user off in the corner. > > > /bz > -- Rod Grimes rgrimes@freebsd.org