Skip site navigation (1)Skip section navigation (2)
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>