[FFmpeg-devel] [PATCH 01/16] doc/filters: document the unstability of the shorthand options notation.

Paul B Mahol onemda at gmail.com
Fri Aug 11 11:31:55 EEST 2017


On 8/11/17, Michael Niedermayer <michael at niedermayer.cc> wrote:
> On Thu, Aug 10, 2017 at 04:15:55PM +0200, Nicolas George wrote:
>> Le tridi 23 thermidor, an CCXXV, Michael Niedermayer a écrit :
>> > Please limit the notes in filters.texi and Changelog to the filters and
>> > options you intend to change.
>>
>> That would defeat the purpose. Doubly so:
>>
>> - Being free to change the options as need requires. That means any
>>   filter and any option. Not all, not many, but any.
>>
>> - Having a rule that is simple to remember instead of a long list.
>>
>> Please bring new arguments to the discussion if you want to continue it.
>
> well
> First, I dont think a single developer should declare a whole class of
> interfaces spaning the areas other developers work on unstable against
> one or more objections from them. Or if one has that right then everyone
> else should as well.
>
> I maintain several filters and clearly stated that this doc-text does not
> apply to them. None of them would benefit from breaking the
> order or inserting options in the middle.
> In fact with a unstable order there is no benefit from adding options
> in the middle, noone could reliably use the new order.
>
> as in if you link to libavfilter 99.123 you can write a:b:c , if you
> link to libavfilter 99.124 you can write a:c:b. Update your distro
> package and it could change in otherwise unchanged applications.
>
> and none of this in the example above is neccesarily a syntax error
> and gives an error message. the different order could just give
> different results. thats bad design
>
> I like to re iterate, i do not agree to declaring the option order
> of the filters i maintain as unstable.
>
> Even if we could reorder them without disadvantages,
> there is no benefit in doing so.
>
> Its trivial to change your docs/changeog patch to avoid my concern, and
> its trivial to change MAINTAINERs as well if people value declaring the
> interfaces as unstable more than a maintainer who fanatically insist on
> maintaining a stable interface in the filters he maintains.
>
> Also there is no long list, just a entry in the changelog and in the
> documentation of the specific filter which was changed.
> I think we both agree that this is a rare event. And i would argue
> it is NOT a event specific to the shorthand interface. Am i not
> correct that you would similarly change the named interface if a
> cleanup you do benefits from it ?

What about keeping old options intact?


More information about the ffmpeg-devel mailing list