Date: Wed, 22 Aug 2018 09:08:09 -0700 (PDT) From: "Rodney W. Grimes" <freebsd@pdx.rh.CN85.dnsmgr.net> To: Matthew Macy <mmacy@freebsd.org> Cc: rgrimes@freebsd.org, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r338172 - Now deprecating DRM Message-ID: <201808221608.w7MG89vW085118@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <CAPrugNqFM593ytbkGRPdJVVqW62CnQ6G3eCynwwjBBgPLpYs0Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > Could you please create a stable/11 deprecation change. > > > > What does that entail other than an update to UPDATING in stable/11? I see some others have answered on this, so I'll just summarize. 1) Calls to gone_in should be added to the stable/11 drm modules so that when they are loaded a message informs the user of the deprecation. Please be sure to tag this commit with Relnotes: Y 2) No note is needed in UPDATING, as there is not any action for the user to take in stable/11, the UPDATING note was done in head, which is correct. 3) If for some reason you make another DRM removal related commit to head please add a tag for Relnotes: Y as this needs to be in the 12.0 release notes too. Thats all I can think of right now, as a future request, and IMHO, all deprecations should have a formal review process, no mater who approved it. There are just so many bits and pieces that need done to make sure these work smoothly as possible. For example, the gone_in stuff was desinged so that should of been the first commit, in ^head, and then merged to stable/11. All commits adding gone_in should be tagged with relnotes Y so good notification goes out. Desirably these gone-in's should be in existing for a full point release, so that we do not abondon uses that was not considered, this DRM one seems to have rather serious impacts on a couple of users. I think this deprecation is a rather serious deviation from the stated policy, in that 0 notification was made, core IMHO, has overstepped some boundaries in that respect. These policies are promises to the downstream consumers, and violating them is very poor planning. -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201808221608.w7MG89vW085118>