[FFmpeg-devel] [libav-devel] [PATCH 3/6] avutil: delay removal of the PIX_FMT_* flags

[wm4]

On Sun, 9 Aug 2015 17:54:55 +0200
Andreas Cadhalpun <andreas.cadhalpun at googlemail.com> wrote:

> Hi,
> 
> On 09.08.2015 12:57, Ronald S. Bultje wrote:
> > Yeah, I'm with this. Andreas, the correct fix is to update applications,
> > even if that means vendor-specific patches in Debian. These are
> > exceptionally trivial patches that you can generate using fairly trivial
> > sed scripting.
> 
> The problem is not that creating patches for these two API changes was
> difficult, but that these affect the majority of API users.

They had time. (And maybe you shouldn't look at old releases.)

> > The same goes for other easily scriptable changes. These APIs are gone and
> > I don't want them back.
> 
> What is your problem with keeping the trivial compatibility layers for
> another year?

Because it already has been years. How long more? Will we still have
PIX_FMT defines in 2020? Why would you expect any of the downstreams to
care if they realize they effectively don't have to care about
deprecations?

And while these things may be trivial, they add up. Think of every
little compat hack as a speed bump when a developer tries to fix a bug,
optimize something, or add a new feature.

But most importantly, never removing any deprecations makes us feel
like we'll never be able to fix this goddamn mess we got us into. Why
bother cleaning up anything if everything stays forever anyway? Might
as well go and contribute to a nicer codebase, while the downstreams
complain about the bad API.

No, we don't want such a situation.

How is this so hard to understand?

> On 09.08.2015 13:00, Ronald S. Bultje wrote:
> > Again, I'm with this. Babies learn to walk and talk in 2 years, we can't
> > figure out how to sed a handful of packages in Debian in 2 years?
> 
> It is *not* just a handful of packages, but the majority of them.
> If anyone had sent these a patch a year ago, most probably we wouldn't have
> a problem now.

But they were deprecated years ago? What the hell are you complaining
about again?

And again, why do you think your patch for adding the Libav wiki
contents to the docs will change anything? Downstreams who didn't
update their code AFTER YEARS obviously don't care, and won't care. How
can you not understand that we don't want stagnation just because some
downstreams are stale, indifferent, and inactive?

And if such trivial things generate so much discussion, how can we ever
hope to make huge API changes? Which, btw., are necessary because
downstreams (rightfully) complain about bad APIs.

Your actions here are not exactly helpful. Why don't you go bother
these downstream projects that they should fix their code for things
that were announced for YEARS? Why are we the bad guys here?

> Keeping these two trivial APIs about halves the number of affected packages.
> Removing them will create a huge amount of busywork for distributions, but
> no real benefit for anyone.

So you're just worried to have too much work. Well, it's your job. It's
not our job to care about stale downstreams. If they don't want our
newer stuff, they can keep using old copies or something.

Or will you stop dropping packages in Debian because a handful of users
are opposed?

> It will also bring us a bad reputation for not providing a stable enough API.

We've provided a pretty stable API. And we've announced such changes for
YEARS.

> > Scriptable API changes are out and stay out. Just script a patch in Debian.
> > I can help you scripting it together if you can't figure it out yourself
> > (something like find . -name *.[ch] -exec sed -i -e
> > 's|PIX_FMT_|AV_PIX_FMT|g' {} \; and then a similar version for this change)
> > should do the trick.
> 
> This script will miss some cases (*.cpp) and wreck all sorts of havoc
> (AV_AV_PIX_FMT_*). But don't waste your time improving this script.

So your sed changes are bad and thus us developers have to live in
agony. Such a lame excuse.

> If you want to help, please document how avpicture_deinterlace
> can be replaced in practice, that is in a project that doesn't use
> libavfilter yet.

There are examples for using libavfilter.

And if they're such lazy, bad programmers that they can't do it, they
can just copy the avpicture_deinterlace implementation from libavcodec
and use that.

> I'm also keen on getting rid of old API, but gratuitously breaking the
> majority of API users is a really bad idea.
> Instead, let's remove FF_API_MISSING_SAMPLE, which never had a use case
> for other projects, or fix ffserver, so that the last public ff* symbols
> can go from libavformat.
> 
> Best regards,
> Andreas
> _______________________________________________
> libav-devel mailing list
> libav-devel at libav.org
> https://lists.libav.org/mailman/listinfo/libav-devel