Update ffmpeg in F24 to 3.1.x ?

[Sérgio Basto]

On Qui, 2016-10-13 at 10:01 +0200, Nicolas Chauvet wrote:
> 2016-10-12 2:49 GMT+02:00 Sérgio Basto <sergio at serjux.com>:
> > 
> > Hi,
> > Nicolas, ask me to bring this discussion to the mailing list .
> > Nicolas sorry for the delay , I had a big cold, I'm ok now (it just
> > an
> > excuse :) )
> > 
> > OK, all story is in
> > https://bugzilla.rpmfusion.org/show_bug.cgi?id=4260
> > and in https://bugzilla.rpmfusion.org/show_bug.cgi?id=4145
> > 
> > and we have 48 packages depends on ffmpeg-libs.
> > 
> > First, ABI changes of ffmpeg 3.0.x to 3.1.x ?
> > "There are no SONAME changes, only new symbols added to the
> > libraries,
> > so they're backwards compatible and no rebuild of dependencies
> > should
> > be required" . "mpv will break" .
> > 
> > My arguments, I read today
> > http://fedoraproject.org/wiki/Updates_Policy#All_other_updates and
> > it
> > have one exceptions list, we have some items that can be applied to
> > this case, like :
> > 
> > - The update doesn't change ABI/API and nothing needs to be rebuilt
> > against the new version. (almost)
> > 
> > - The update fixes serious bugs that many fedora users are
> > encountering.
> Where thoses serious bugs was reported ? Is there upstream reports ?
> What I would expect instead are more features instead, (and even some
> features was removed such as libdcadec)
> So despite there is no ABI changes, there are some behavior changes.
> 
> > 
> > ffmpeg-3.0 is a major version that had short duration, it was the
> > first
> > version of an major version (3.0.x), so we expect have more bugs,
> > also
> > vlc now requires ffmpeg 3.1.x and we have to maintain it about more
> > 9
> > months (F24 be an fresh version also counts).
> I don't understand what you mean by "we expect to have more bugs..",
> so a little history:
> 
> Previously ffmpeg upstream didn't provide maintained branches at all.
> If one distro packager wanted a rebase to a newer snapshot from
> master, there are probably some API changes and very often ABI
> changes
> (along with new bugs and features mixed). Also if one wanted to
> report
> and issue upstream, the first step was to test with a recent git
> snapshot. Most likely that our stable ffmpeg packages was contains
> known upstream bugs that was unfixed because of that.
> So the way we used to have a stabilized version was to periodically
> check for api/abi snapshot, get the last commit before an abi break
> and stick to this version with adding only patches and backports from
> our user base reported issues. On a fedora development cycle, we
> updated the newer api/abi snapshot, rebuild (and more likely patch)
> all dependent applications and try to fix regression and feedbacks
> from our rawhide users.
> 
> This was lot of packager work about testing, patching, bisecting for
> finding regression and all. And probably that job was done across all
> ffmpeg package maintainers. So really see that having maintained
> branches upstream as an enormous improvement.
> Here the proposition seems to ask to withdraw all that and only pick
> the last stable release everywhere. So this sounds to me that we are
> going backward on the highway.
> 
> I would also notice, that our stabilization process was very little
> in
> the f24 development timeframe, because of the infra issues we had
> passed. So I'm expect to have a better stabilization process with f25
> and hopes to have lot of feedbacks from branches/rawhide users while
> keeping users stable. (There is probably already lot of issue related
> to f24 -> f25 system-upgrade migrations).
> 
> Now that was rather general about our stabilization process, but now
> from a more specific analysis on ffmpeg 3.0x and 3.1x maintained
> branches, I see the same kind of fixes between branches. I think
> there
> is just normal bugfix . So not having 3.1x only means missing the 3.1
> specific features. So It's probably safe from ffmpeg itslef
> perpective.

Don't agree with this premise, they have 3.0x , because they must have
it, IMHO.

I choose +1 because, although we don't have any major bug, but and if
we find one ? will be much more complicate to fix it (we have vlc that
is not much stable) and what upstream will say first ? "please update
to 3.1x". So with this scenario and in this time frame, for me, is
better have F24 and F25 with same ffmpeg, is better for testing,
everybody test the same thing, if some bug is found, we are in last
release, could be fixed more easily. 
He should have better stability and functionality with 3.1x, we have
some assurance that 3.1x is quiet stable. So, IMHO we are wasting time
(test time) using ffmpeg 3.0x in F24. 

> > 
> > I hope have one decision, quickly and close this subject (update
> > ffmpeg
> > in F24 to 3.1.x ? ).
> So the question is do we update 3.1x in f24 ?, my vote is the
> following:
> +0
> It means I don't agree with the proposition, but I won't hold it
> either.
> instead, I expect that people that want this proposition are actively
> working on testing the package update and doing the needed QA in
> cooperation with each package maintainer if needed.

Counting +1 , Dominik , Leigh , me , Vasiliy, Kevin ?

Counting -1 , Julian , Michael (but said that kodi (16.1) works well
with 3.1x )

> I also note that I'm way too much busy with internal infra issue to
> back this update and the eventual regressions

Here is where I miss bodhi, to control the updates that go to stable,
and hold on some in testing ... 

> (on a side note I would like to have a my ffmpeg-nonfree patches
> reviewed/merged before any backport to f24 - rfbz#4243)

So what I propose this weekend is study and query the packages that
wasn't modified since last mass (ffmpeg) rebuild, those may merged from
F25 to F24 directly and see the list of packages that have been
modified since, to evaluate what we should do and how many packages
are. 
I think we can perform the mass rebuild (or not) just in F24 without
touching F25 and rawhide. 


Thanks,
-- 
Sérgio M. B.