On Tue, 07 Nov 2017 23:36:28 +0100, Takashi Sakamoto wrote: > > On Nov 7 2017 16:59, Takashi Iwai wrote: > > On Tue, 07 Nov 2017 01:34:02 +0100, > > Takashi Sakamoto wrote: > >> > >>>> This commit deprecates some APIs related to the dimension information. They > >>>> are planned to be removed in a development period for Linux kernel v4.21. > >>> > >>> IMO, the version to deprecate the feature may depend on LTS kernel > >>> version. 4.21 looks OK, but we may shift it. > >> > >> I still get no merit of your suggestion. Do you mean that the removal > >> of ABI should be done in several releases before target LTS will be > >> actually released, to produce stable ABI? If so, we need to estimate > >> the timing of next LTS. However, it's hard because for recent LTS we > >> got no official announcement from stable maintainers till LTS version > >> of Linux kernel is actually released. At least, I won't work with such > >> uncertain estimations. > > > > The feature removal isn't what we can guarantee at a certain kernel > > version. As long as we have a real (not theoretical) user, it > > shouldn't be dropped. It's still unwritten "no regression" rule. > > > > That said, we may announce and prepare / plan the deprecation, but we > > can't define the exact kernel version in general. And considering LTS > > release is one of the decision factors. > > If it comes from a general theory, I'm willing to follow it. > > But in this case, we can be optimistic. As you know, the minor feature > is just used in drivers/software related to models produced by Echo > Digital Audio corp. The other probability is usage by user-defined > control element set on any userspace application. As my recent work > declared, this feature has been long-abandoned and no application > exists (if such application exists, developers have already found such > bugs which I've fixed recently before I worked...). > > If the feature were used by majority, it would be more difficult to > deprecate/remove it, and we need to be deliberate. Depending on cases, > deprecation is impossible itself. But this feature is quite minor and > got little popularity. Practically, we can safely remove the minor > feature in any timing after modified version of echoaudio stuffs are > disseminated. My proposed schedule takes 6 kernel releases for it. In > the schedule, v4.21 release is the deadline of the feature, but if > you'd like to keep the deadline undecided for such theory/rule, I have > no objection to it. To me, deprecation of this feature for future > removal is more important to avoid developers' misuses to which I > addressed, than actual removal. I have no objection of removal of API in alsa-lib, but my concern is that unnecessary announcement of the exact kernel version as if it's an ultimately fixed deadline. It's rather a "hopefully working" deadline, and we don't need to show it in alsa-lib side. We can update the comment once after it's really deprecated, if any. thanks, Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
