subject:"Reintroducing FFmpeg to Debian"

On Thu, 14 Aug 2014 13:58:07 +0200
Stefano Sabatini stefa...@gmail.com wrote:

  If you trully want to mend ways, then you and your fellow FFmpeg
  developers should stop this constant spreading of lies, this
  defamation campaing against libav and its developers that has
  been going on for the last 3 and a half years and show at least
  the minimum respect you would show to a stranger you meet on the
  street. Until you do this, i see very little chance for a healthy
  cooperation.
 
 Please refrain from claiming other people are spreading lies,
 especially with no specific references (and this is not the place
 where to discuss such things).

Carl Eugen just recently (2014-06-22) wrote on ffmpeg-devel:
Sean supports the thieves [...]
(http://article.gmane.org/gmane.comp.video.ffmpeg.devel/179271)

Do i need to say more?

I guess i speak in the name of everyone related to libav, that
we would not mind if you kept saying that ffmpeg is better, faster,
has more features, etc. That could be at least discussed on a
technical, neutral level. What we mind are comments like that above,
targeted solely at insulting and slander individuals.
And as we can see from what Joe Neal wrote, the often repeated lie
becomes truth soon enough.


 Then you should be aware
 that the way the Libav fork was created was hostile towards FFmpeg

Actually, no. The whole thing started as getting Michael off his throne
and to stop him screwing the whole project. It was not ment to be
a fork.


Attila Kinali

-- 
I pity people who can't find laughter or at least some bit of amusement in
the little doings of the day. I believe I could find something ridiculous
even in the saddest moment, if necessary. It has nothing to do with being
superficial. It's a matter of joy in life.
-- Sophie Scholl


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140821025941.3d660cf65d862194d54da...@kinali.ch

Re: Reintroducing FFmpeg to Debian

Servus,

On Wed, 20 Aug 2014 18:43:18 +0900
Norbert Preining prein...@logic.at wrote:

 By continuing old fights, inspite of the very clearly friendly and
 open offers and suggestions byu Michael, you and others from AV continue
 simply to insult and be nasty.

Sorry, but this is not true. Yes, Michael always offers to mend ways
and to do this and that. But he never does. It's just lip service.
He didn't do it before the split and he didn't happen after the split.
Yes, the people at libav are bitter. Yes, they are angry. But how
would you feel if people would walk up to you at random OSS events
and tell you that X just told them you are the bad guy, that you
steal childrens ice cream? (Yes, this has happend)


 I am really impressed by the ability of Michael to take this without
 changing into a more inpolite tone. Which you and others from AV are
 definitely doing.

If you mean me by others, then i would like to ask where i have been
impolite.

 * AV maintainers are averse o any cooperation, and just licking their
   wounds since several years

You know, that FFmpeg and libav have been cooperating ever since the
split? FFmpeg merges all (or almost all?) patches commited to libav
without further review. libav (as a project) does not make any fuss
on that, because that's how OSS works. But you got it right that
libav people are averse to constant insults and badmouthing.



Attila Kinali

-- 
I pity people who can't find laughter or at least some bit of amusement in
the little doings of the day. I believe I could find something ridiculous
even in the saddest moment, if necessary. It has nothing to do with being
superficial. It's a matter of joy in life.
-- Sophie Scholl


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140821031650.bada75ec929aa75220c16...@kinali.ch

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

On Sat, 16 Aug 2014 17:11:29 +0200
Nicolas George geo...@nsup.org wrote:

 The most galling in this issue is that there is no clear decision behind
 this orientation. The fork's manifesto stated that everyone was equal
 amongst equals, with or without commit rights, but the people who do have
 the commit rights are few and of a common mind, they can just give the cold
 shoulder to proposed changes that do not suit their personal view of the
 project.

Err... If i counted correctly, there are currently 21 people who have
commit rights to the libav repo. If you call that few i would like
to know what you would consider as many? Also, i can asure you,
that they are not of one mind. There are many fights on how to do things
and whether a patch should go in or not. Heck, they are visible even
to someone like me, who sits at the sidelines (i'm not a developer
and have not written one line of code for libav. i dont even read
the mailinglists).


 Considering these differences in policy, I do not believe the fork can be
 merged. Speaking as someone who proposed a few of these unnecessary
 features, because they were fun or immediately useful, I would not like to
 work on a project that would reject them by principle. 

Though a program be but three lines long,
someday it will have to be maintained.
-- The Tao of Programming


Attila Kinali

-- 
I pity people who can't find laughter or at least some bit of amusement in
the little doings of the day. I believe I could find something ridiculous
even in the saddest moment, if necessary. It has nothing to do with being
superficial. It's a matter of joy in life.
-- Sophie Scholl


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140821033523.75a022d583c077c3f8bef...@kinali.ch

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

On Mon, 18 Aug 2014 13:42:36 +0200
Nicolas George geo...@nsup.org wrote:

 The reason for switching from FFmpeg to libav in the first place just after
 the fork is much simpler than that.

Yes, the reason was that Reinhard, who was the maintainer of the
ffmpeg package back then, was on the libav side after the split.

BTW: for those who do not know. Michael raised the issue of
the ffmpeg - libav switch at ubuntu back then [1]. The technical board
decided to go with the decision of the package maintainer [2,3,4].
I think most people will find [3] the most interesting, as it explains
why Reinhard thought (and still thinks) that libav was the better choice.


Attila Kinali


[1] https://lists.ubuntu.com/archives/technical-board/2011-April/000794.html
[2] http://irclogs.ubuntu.com/2011/05/19/%23ubuntu-meeting.html#t19:10
[3] https://lists.ubuntu.com/archives/technical-board/2011-May/000891.html
[4] http://irclogs.ubuntu.com/2011/06/02/%23ubuntu-meeting.html#t19:01

-- 
I pity people who can't find laughter or at least some bit of amusement in
the little doings of the day. I believe I could find something ridiculous
even in the saddest moment, if necessary. It has nothing to do with being
superficial. It's a matter of joy in life.
-- Sophie Scholl


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140821035247.c8b056da7130982bdefad...@kinali.ch

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-20 Thread Timothy Gu

Hi Attila,

I will do a small self-intro, as you most likely don't know me: I am a
high school student who mainly writes documentation for FFmpeg, but
sometimes do small code fixes and patch review (mainly related to
documentation), both for FFmpeg and Libav. I sent my first patch to
FFmpeg last year in March. I don't know much about the split, but I
have read the most important discussions on ffmpeg-devel on the split.

On Wed, Aug 20, 2014 at 6:52 PM, Attila Kinali att...@kinali.ch wrote:
On Mon, 18 Aug 2014 13:42:36 +0200
Nicolas George geo...@nsup.org wrote:

The reason for switching from FFmpeg to libav in the first place just after
the fork is much simpler than that.

Yes, the reason was that Reinhard, who was the maintainer of the
ffmpeg package back then, was on the libav side after the split.

BTW: for those who do not know. Michael raised the issue of
the ffmpeg - libav switch at ubuntu back then [1]. The technical board
decided to go with the decision of the package maintainer [2,3,4].
I think most people will find [3] the most interesting, as it explains
why Reinhard thought (and still thinks) that libav was the better choice.

Most, if not all of the reasons in [3] have been eliminated, so
bringing this up only causes more confusion.

Also, the discussion appeared during a time when FFmpeg had flamewars,
mainly from Libav developers. Because the split was just forming,
FFmpeg was not that different from Libav then. It is not fair
therefore to compare the two projects at that time. However, there are
technical advantages towards FFmpeg now.

Also, keep in mind that Debian cares about maintainable (and
maintained) code **now** more than how a project leader behaves (or
rather, behave_d_).

I will now quote and explain how Reinhard's mail does not apply to the
current FFmpeg/Libav situation.

Reinhard Tartler wrote
(https://lists.ubuntu.com/archives/technical-board/2011-May/000891.html):
On various occasions [Michael Niedermayer's] quite strict rules on code
quality and reviews doesn't seem to apply to him

This has not been the case since the split (at least within the past
year, as I joined FFmpeg last year). There are still some post-commit
oopses, but not nearly to a level that brings a discussion among
developers.

After the fork, Michael has insulted almost everyone involved with
founding Libav at least once, used libel and death threats as 'jokes',

I don't mean that I don't believe your insulting story, but there is
no public mailing list archive or IRC log or anything that supports
this. Even if Michael did these terrible things, he is certainly not
doing it now. The only insult I can find is in the thread you
mentioned https://lists.ubuntu.com/archives/technical-board/2011-May/000900.html
, which is an insult from Mans Rullgard, a former Libav developer and
former former FFmpeg developer.

but OTOH keeps merging the work done at Libav both with and without
insults.

I am interested to see any evidences to back up this statement. Note
that Michael does sometimes express disagreement with Libav commits,
but that's only because of technical issues, at least within the past
year.

Also from this quote Reinhard seems to not like the spirit of LGPL...

Interestingly, his standards and attitude to external work have
totally changed: He has committed his mplayer filter wrapper despite
predominant rejections,

This is one of the most significant sources of new filters, and one of
the reasons users (like me) use FFmpeg.

ffmpeg-mt has been merged (partially with wrong
attribution!)

I can't comment on the mistake in attribution as I was not involved in
FFmpeg during that time, and I am sure it is fixed (besides Git
history, which is unfortunately unfixable). But the only people I have
seen stripping attribution is Libav during their cleanups, and
Michael is actively restoring lost attribution:
http://git.videolan.org/?p=ffmpeg.gita=searchh=HEADst=commits=attribution

See for example
http://git.videolan.org/?p=ffmpeg.git;a=blobdiff;f=libavcodec/me_cmp.c;fp=libavcodec/dsputil.c;h=9fcc93739a7c76fea5906bae94c174de558c132b;hp=ba71a99852d8f3fbad25f8ea7b4947e18e5592cd;hb=2d60444331fca1910510038dd3817bea885c2367;hpb=a578b0407dc983aecd72028e1127062689b67089
among others.

despite various tests still failing (when running them
with more than one thread), just to name a few.

Well it doesn't fail anymore now, so this is not a viable argument now.

Now he argues that the
merged external branches make 'his' tree 'superior'.

Well, it is ;)

If you look at the git commit statistics, you'll notice that
the developers with most commits (both numbers of commits and lines of
changed code) in the last year and three years before the fork are in
the Libav camp now.

Look at http://lucy.pkh.me/ffstats/authors.html now. The following
list is sorted in number of commits.

Michael Niedermayer -- FFmpeg
Diego Biurrun -- Libav
Stefano Sabatini -- FFmpeg
Anton Khirnov -- Libav

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-19 Thread Ondřej Surý

On Sat, Aug 16, 2014, at 17:29, Thomas Goirand wrote:
 On 08/15/2014 11:53 PM, The Wanderer wrote:
  It's also something the Linux kernel is still doing, with apparent
  success.
 
 Yes, the Linux kernel is a successful project. Does this mean using a
 list for reviewing patches is a good thing? No! The workflow with a list
 is simply horrible. Using git-review and gerrit is so much better.

JFTR we have dropped gerrit in favour of gitlab (or github or bitbucket)
pull requests since gerrit was too cumbersome to use.

So, no, gerrit is no miraculous cure-all.

However I think that establishing a procedure that every patch has to
be submitted as a pull request and this pull request needs to be acked
by other developer is a good practice that can be adapted to any project
(the only exception being one-man shows).

Ondrej
-- 
Ondřej Surý ond...@sury.org
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1408437453.1734025.154279197.7c841...@webmail.messagingengine.com

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-19 Thread Ondřej Surý

On Sat, Aug 16, 2014, at 20:59, Russ Allbery wrote:
 The problem, however, is that taking security seriously, while possibly
 necessary, is not sufficient.  I'm glad that FFmpeg takes security
 seriously, but what FFmpeg needs is to *have fewer security bugs*.

JFTR the Coverity Scan results for ffmpeg looks promising:
https://scan.coverity.com/projects/54

I am not saying that we should base our decisions on Coverity Scan[1]
results, but this is one more metric that could help to weight the
decision to one or other direction. (Also this is not an advice what
should ffmpeg do...)

From the security viewpoint, I would be also interested if ffmpeg
has tests and what is current code coverage. That could help avoiding
regressions when doing security updates.

1. There are also other tools: llvm/clang scan_build, OCLint, cppcheck
(and other metrics like Cyclomatic complexity)

Cheers,
Ondrej

P.S.: libav doesn't seem to be using Coverity Scan actively:
https://scan.coverity.com/projects/106
(last scan was 4 months ago)
-- 
Ondřej Surý ond...@sury.org
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1408438231.1736622.154282345.60f00...@webmail.messagingengine.com

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-19 Thread Clément Bœsch

Hi,

On Tue, Aug 19, 2014 at 10:50:31AM +0200, Ondřej Surý wrote:
[...]
 From the security viewpoint, I would be also interested if ffmpeg
 has tests and what is current code coverage. That could help avoiding
 regressions when doing security updates.
 
 1. There are also other tools: llvm/clang scan_build, OCLint, cppcheck
 (and other metrics like Cyclomatic complexity)
 

See:
http://fate.ffmpeg.org/
http://coverage.ffmpeg.org/

[...]

Best Regards,

-- 
Clément B.


pgpxNoF329KNl.pgp
Description: PGP signature

Re: Reintroducing FFmpeg to Debian

2014-08-19 Thread Ivan Kalvachev

On 8/18/14, Moritz Mühlenhoff j...@inutil.org wrote:
Andreas Cadhalpun andreas.cadhal...@googlemail.com schrieb:
Hi Thomas,

On 18.08.2014 08:36, Thomas Goirand wrote:
There's been a very well commented technical reason stated here: the
release team don't want to deal with 2 of the same library that are
doing (nearly) the same things, with potentially the same security
issues that we'd have to fix twice rather than once.

Why is it a security problem to have FFmpeg and Libav, but apparently no
problem to have MySQL, MariaDB and PerconaDB?

Raphael Geissert already wrote that mysql/mariadb/percona will be
addressed as well; we haven't come around to since since we need to
deal with a lot of stuf and being dragged into endless discussions
on -devel is certainly not helpful.

Cheers,
Moritz

Excuse my interruption, but I intend to be a little blunt.

I think there might be a little bit of miscommunication.

You have said that security team cannot handle both FFmpeg and Libav.
Since Libav is already in Debian, this statement is assumed to mean
that you do not want to deal with FFmpeg. However this mail
http://lists.debian.org/debian-devel/2014/08/msg00060.html kind of
hints the opposite - Libav security handling is horrible and burden to
you, while FFmpeg so far is responsive and responsible.

So I would like to get a little bit more details on your priorities
and preferences. The options I could think of are:
1. Drop both Libav and FFmpeg.
2. Leave Libav in stable, keep FFmpeg out.
3. Get FFmpeg in stable, drop Libav.
4. Get both Libav and FFmpeg, under the condition that Michael is
helping with FFmpeg patching.
5. Get both Libav and FFmpeg, under the condition that Michael is
helping with FFmpeg AND Libav patching (only for jessie).
6. Something else...

Other people have said that FFmpeg should provide help and resources
to the security team. Please elaborate what more can FFmpeg do to
please you.

Best Regards
Ivan Kalvachev
iive

P.S.
I hope ftp masters are not deliberately prolonging the FFmpeg
inclusion, thinking they are doing favor to their peers from other
teams.

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/CABA=pqfwpzbxagqd-ji4y2ksa_akp+kbiwd6nucw9jbitm2...@mail.gmail.com

Re: Reintroducing FFmpeg to Debian

2014-08-19 Thread Michael Niedermayer

On Mon, Aug 18, 2014 at 12:15:10AM +0200, Clément Bœsch wrote:
 On Sun, Aug 17, 2014 at 09:14:47PM +0200, Luca Barbato wrote:
 [...]
   Ive asked [1][2] back then what policy in place was broken
  
  - you tried to commit code that was blatantly below the already lax
  quality requirements (e.g. it contained tabs, it was (and still is) hard
  to read, it contains dubious, aka security-concerning, practices), I
  told you not to commit those as-is and you blatantly ignored me and the
  others against it. I'm referring to the mplayer filters.
  
 

 Weren't mplayer filters pushed post fork?

I dont remember, they dont seem to be in the libav git history

also there are no tabs in the mplayer filters in ffmpeg, and IIRC no
security bugs in the filters have been found in them since they
where pushed. Also its hard for there to be security bugs as they
are only used when explicitly selected by the user


 
  - your interaction with whoever wasn't in full agreement with you was
  horrible, I told you for months in public and private, you seemed to
  agree just to behave in even worse way later. The interactions with Mans
  are probably the best example of this.
 
 Interactions with Måns and everyone else were also pretty terrible, to the
 point that he also left Libav in a rage quit (see #libav-devel on
 2011/09/17 for related, when he left. Michael was not here). Note that I'm
 not saying this is the reason he completely left the project.
 
  - your interaction with whoever provided infrastructure service was
  horrible[1]. As Attila already stated here[2] and here[3]
  
 
 AFAICT this has nothing to do with the policy rules in place.

There is no question i made mistakes 4 years ago, and no question
i could and should have interacted with developers in a less abrasive
way back then. Iam a technical person not a diplomat nor politican.


[...]
  - you putting in FFmpeg pretty much every patch from every branch you
  can come by, including my incomplete work from github (you did for pulse
  and segment with interesting results, hopefully you won't do that again
  anymore).
 
 Yes, with full authorship, because those were requested  needed in
 FFmpeg. Also, communication does not work with you (we FFmpeg are
 definitely ignored by most of the people on Libav); this means that
 obviously we are not going to annoy you for information or status about
 your progress. May I remind you that Michael is banned from the
 mailing-list, IRC and some of the developers repositories? Why would you
 expect him to even try to communicate with you about these contributions?

also about pulse, we did take lucas incomplete code but the current
code we use is quite different from that and has evolved alot.
The original used the simple API from pulse pulse/simple.h,
FFmpegs current code does not. Also i think our current code is more
based on work by the pulse audio developers and Lukasz Marek than
lucas original.
And theres pulse input and output support in FFmpeg, the original
code from luca and libav only support input through the simple API

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


signature.asc
Description: Digital signature

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

On 08/16/2014 11:44 PM, wm4 wrote:
 This reasoning may work when you have only a small amount of information
 to read. When you are overwhelmed with it, having different places to do
 different things is a much better approach. Sending patches to a list
 simply doesn't scale.

 Also, with a list, it's not convenient at all to point out a line in a
 patch in a mailing list. You must extract the relevant lines, cut/past
 them, and comment them. Instead, double clicking on the line of the
 patch which is displayed on a web interface is much more convenient.
 
 What? Most patches are posted inline (with git-send-email).

Even worse then! It makes it hard to copy to your local fs.

Anyway, have a look here, if you want to see how the review process works:
https://review.openstack.org/

click on any patch proposal, and see how nice the interaction is (see
patch comments, the result of jenkins unit tests, etc.). This helps a
lot with QA, for sure.

 There's nothing wrong with having discussion in those various areas, of
 course; it's probably inevitable, and it's even a good thing. It's just
 that it's a lot harder for someone not intimately involved with the
 project to follow discussion if it happens in such a variety of places,
 and there's value to be found in making sure that everything passes
 through one central (discussion-enabled) point before landing.

 Lists are good tools for discussing where a project should go, release
 goals, and so on. They aren't good tools to do patch reviews. I've used
 both, and I'm convinced of that.
 
 What we need is solving the FFmpeg/Libav split, not well-meant
 suggestions by outsiders how to change our development model.

The problem, as much as I understand it, was the review process and
enforcing policies. So it's natural to give advice on that, with a tool
which will make sure that policies are enforced. If you don't want
advices, and want to have a private discussion, then why writing to
debian-devel@l.d.o?

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53f19b3e.2080...@debian.org

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

On 08/16/2014 11:11 PM, Nicolas George wrote:
 L'octidi 28 thermidor, an CCXXII, Bálint Réczey a écrit :
 Using Gerrit and file ownersip are not mutually exclusive. Gerrit
 can be configured to automatically invite the right people for review
 based on the changed path. We recently migrated to Gerrit at the
 Wireshark project and it helps a lot in coordinating the reviews.
 
 I am afraid this discussion on Gerrit or other similar tools is pointless:
 this is trying to solve a human problem with technical means: it never
 works.

The problem was enforcing patch review policies. This technical solution
makes it possible to enforce rules. Sure, it doesn't fix the social
issue completely, but at least if you implement it, it's going to be a
way more difficult to bypass the review system, and the one who does
will really look bad, so it's very unlikely it will happen.

 [...] The fork's manifesto stated that everyone was equal
 amongst equals, with or without commit rights, but the people who do have
 the commit rights are few [...]

Really, when I read commit rights, in a collaborative process, I feel
like there's something wrong.

 It becomes bad when people not involved in the project start to suffer from
 the consequences of the fork. This is what is happening here, for two
 reasons:
 
 * distributions adopting one side of the fork for non-technical reasons;

There's been a very well commented technical reason stated here: the
release team don't want to deal with 2 of the same library that are
doing (nearly) the same things, with potentially the same security
issues that we'd have to fix twice rather than once. Now, the which
side debate is a different one, which I don't think Debian people are
interested in (at least, *I* am not): we are just suffering from the
consequences of the fork, as you wrote, and would prefer it never happened.

 * one side of the fork not caring about compatibility with the other side.
 
 Of course, these reasons are interconnected.

Yeah. If both were fully compatible, there would be no issue using one
or the other.

Thomas


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53f19ef7@debian.org

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

On 08/16/2014 11:30 PM, Nicolas George wrote:
 So what about the code? Shall the FFmpeg developers discard three years of
 work and start working on libav? Or shall the libav developers accept to
 work with the code from FFmpeg that they do not like?

FFmpeg folks should rework the code to make it acceptable for the libav
people, and libav people should relax their policy. With *both* sides
trying to work on this, it may happen. If even *only one* of the teams
find excuses to not do a step forward, it wont.

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53f1a0d3.2070...@debian.org

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

On 08/17/2014 07:41 PM, Andreas Cadhalpun wrote:
 Michael Niedermayer already volunteered to help with all security
 related problems of FFmpeg in Debian.
 So what should he do to relieve the impact on the security and release
 teams?

Let's say he would take the role of patching stuff in Stable, there
would still be double work for the release team and security team for at
least:
- Checking the packages before upload of security fixes (that's security
team work), or upload of bugfixes to proposed-updates (that's the
release team)
- Making security announces

There's nothing Michael could do to reduce that work. However, as stated
before, uploading to Sid or Experimental could be done (if the SONAME
clash gets fixed), and I don't think anyone would oppose for more
contribution in Debian, especially with correct security support!

Thomas Goirand (zigo)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53f1a270.2040...@debian.org

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-18 Thread Vincent Bernat

 ❦ 18 août 2014 14:20 +0800, Thomas Goirand z...@debian.org :

 What? Most patches are posted inline (with git-send-email).

 Even worse then! It makes it hard to copy to your local fs.

The whole email is a valid patch in this case.
-- 
Follow each decision as closely as possible with its associated action.
- The Elements of Programming Style (Kernighan  Plauger)


signature.asc
Description: PGP signature

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-18 Thread Andreas Cadhalpun


Hi Thomas,

On 18.08.2014 08:36, Thomas Goirand wrote:

There's been a very well commented technical reason stated here: the
release team don't want to deal with 2 of the same library that are
doing (nearly) the same things, with potentially the same security
issues that we'd have to fix twice rather than once.


Why is it a security problem to have FFmpeg and Libav, but apparently no 
problem to have MySQL, MariaDB and PerconaDB?


This seems quite arbitrary to me, especially since there have been 
already 36 CVEs in 2014 for MySQL [1], of which 26 apparently are also 
relevant for MariaDB [2] and PerconaDB [3], but only 7 for FFmpeg [4] 
and 8 for Libav [5] in the same time.


Best regards,
Andreas


1: https://security-tracker.debian.org/tracker/source-package/mysql-5.5
2: https://security-tracker.debian.org/tracker/source-package/mariadb-5.5
3: 
https://security-tracker.debian.org/tracker/source-package/percona-xtradb-cluster-5.5

4: https://security-tracker.debian.org/tracker/source-package/ffmpeg
5: https://security-tracker.debian.org/tracker/source-package/libav


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53f1e5f9.4030...@googlemail.com

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-18 Thread Nicolas George

Le primidi 1er fructidor, an CCXXII, Thomas Goirand a écrit :
 The problem was enforcing patch review policies.

No, it never was.

 There's been a very well commented technical reason stated here: the
 release team don't want to deal with 2 of the same library that are
 doing (nearly) the same things

That the reason for keeping only one; other have discussed the validity of
the reason.

The reason for switching from FFmpeg to libav in the first place just after
the fork is much simpler than that.

 Yeah. If both were fully compatible, there would be no issue using one
 or the other.

Are there known current cases where FFmpeg can not emulate libav?

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: Reintroducing FFmpeg to Debian

2014-08-18 Thread Moritz Mühlenhoff

Andreas Cadhalpun andreas.cadhal...@googlemail.com schrieb:
 Hi Thomas,

 On 18.08.2014 08:36, Thomas Goirand wrote:
 There's been a very well commented technical reason stated here: the
 release team don't want to deal with 2 of the same library that are
 doing (nearly) the same things, with potentially the same security
 issues that we'd have to fix twice rather than once.

 Why is it a security problem to have FFmpeg and Libav, but apparently no 
 problem to have MySQL, MariaDB and PerconaDB?

Raphael Geissert already wrote that mysql/mariadb/percona will be 
addressed as well; we haven't come around to since since we need to
deal with a lot of stuf and being dragged into endless discussions
on -devel is certainly not helpful.

Cheers,
Moritz


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/slrnlv3r0p.2f8@inutil.org

Re: Reintroducing FFmpeg to Debian

2014-08-18 Thread Andreas Cadhalpun


Hi Moritz,

On 18.08.2014 14:05, Moritz Mühlenhoff wrote:

Andreas Cadhalpun andreas.cadhal...@googlemail.com schrieb:

On 18.08.2014 08:36, Thomas Goirand wrote:

There's been a very well commented technical reason stated here: the
release team don't want to deal with 2 of the same library that are
doing (nearly) the same things, with potentially the same security
issues that we'd have to fix twice rather than once.


Why is it a security problem to have FFmpeg and Libav, but apparently no
problem to have MySQL, MariaDB and PerconaDB?


Raphael Geissert already wrote that mysql/mariadb/percona will be
addressed as well; we haven't come around to since since we need to
deal with a lot of stuf and being dragged into endless discussions
on -devel is certainly not helpful.


I don't remember Raphael Geissert writing anything about security 
concerns with having MySQL, MariaDB and PerconaDB, only that you wrote 
half a year ago, that the security team will be working with the 
release team to sort this out for jessie [1].


As I haven't seen any further discussion about this and the recent mail 
about MySQL, MariaDB and PerconaDB on debian-devel [2] indicated that 
the plan was to have all of them as alternatives, I assumed this was 
resolved.


There wouldn't be any discussion about the security of FFmpeg and Libav 
as well, if you hadn't started it [3].


Why is FFmpeg treated differently than MariaDB/PerconaDB?

Best regards,
Andreas

1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203#435
2: https://lists.debian.org/debian-devel/2014/08/msg00016.html
3: https://lists.debian.org/debian-devel/2014/02/msg00668.html


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53f1fc78.7030...@googlemail.com

Re: Reintroducing FFmpeg to Debian

2014-08-17 Thread Michael Niedermayer

On Fri, Aug 15, 2014 at 01:19:38AM +0200, Luca Barbato wrote:
 Stefano Sabatini wrote:
[...]

 The list is quite long and debunking each of the statements could take a
 lot of time.
 
 I'm going to address two historical misrepresentations:
 

 # The change of management
 
 Michael Niedermayer managed to get demoted from his leader position by
 the topmost 18[1] people involved in FFmpeg by the time due his tendency
 of not following the rules. that after weeks from being voted to stay as
 leader by 15, 5 explicitly stating their vote was conditioned by his
 behaviour and 1 definitely against him.[2]

There was a vote on the ffmpeg-devel list, everyone can recount the
votes although its probably a bit work to do given its a large thread
with lots of other discussions (the links below point to that thread)
I dont remember the exact numbers but there was a majority in
support of me in all possible variants in which one could count the
votes

That said, i dont mind if people like to see me as dictator


 
 His demotion is due to acts in full disregard of the policies in place,

Ive asked [1][2] back then what policy in place was broken
IIRC noone pointed at anything thats part of the written policy[3]
Some good suggestions where made in the discussion though.
And the policy was somewhat amended toward them [4].

In retrospect, bigger changes should have been made to the policy
if that had avoided the takeover attempt and fork, but the takeover
attempt came a bit out of the blue, at least for me and it definitely
left the feeling that there was more interrest in seizing the
opertunity for a takeover instead of discussing and amending the
policy.
Also i remember alot more discussions about whitespaces than patch
review policy from that time.


 even those enforced automatically by the svn hooks.

yes, we wanted to check in some files that would be shared between
mplayer and ffmpeg, and for ease of syncing changes between them
either tabstrailing whitespace had to be removed from mplayers side
or the svn hook in ffmpeg would have needed an exception
They where removed from mplayer in SVN rev 32789 and 32790

The commit message of 32789
Convert some tabs to whitespace to allow using MPlayer filter sourcecode in 
FFmpeg.


[...]

 
  you shouldn't be surprised that there was (and still there is) a
  perceived hostility between the two projects. If you or other Libav or
  FFmpeg developers want the two projects to collaborate more, this can
  be discussed, possibly with *specific* proposals, but again,
  debian-devel is not the right place where to discuss such things.
 

 Personally I have no problems in collaborating with anybody.

Then i think we should reunite the projects with some common
development policy most are happy with.

PS: please spare the world of these defamation attempts
and i also think we should look forward and solve the issues we have
now and not fight over what happenend 3-4 years ago or who made more
mistakes ...


[...]

[1] http://article.gmane.org/gmane.comp.video.ffmpeg.devel/118606
[2] http://article.gmane.org/gmane.comp.video.ffmpeg.devel/118652
[3] 
http://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/developer.texi;hb=f2c44ad51160da4c0c27429e874265c0dff3d117#l122
[4] 
http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=7c0460496b5eeb1713f00c00e2e61b420bb928e7

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus


signature.asc
Description: Digital signature

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-17 Thread Andreas Cadhalpun


Hi Russ,

On 16.08.2014 18:33, Russ Allbery wrote:

All the renaming and cordial co-existence in the world won't change this.
The things that would change this is for one or both projects to develop a
better security track record and a history of higher-quality code releases
that require less ongoing work in stable,


Let's just have a look at FFmpeg's security track record.
The easiest way I found to do this quantitatively, is to count the CVEs 
on FFmpegs security page [1] per year.


2011: 39
2012: 55
2013: 66

This indeed looks bad and even getting worse. But don't forget that e.g. 
in 2012 the systematic fuzzing by Jurczyk and Coldwind began.


By now, more than half of 2014 is over and so far only 5 CVEs [3] have 
been fixed in FFmpeg this year.
I must admit that I'm no security expert, but I think this shows that 
FFmpeg's security has improved a lot.



or for the people who care
deeply about this to somehow find a way to relieve the impact on those
teams in some way acceptable to those teams.


Michael Niedermayer already volunteered to help with all security 
related problems of FFmpeg in Debian.
So what should he do to relieve the impact on the security and release 
teams?



Short of that, there's clearly a need for software of this type in Debian,
and at the same time it's clearly a ton of work.  The teams involved have
indicated that they're willing (if not necessarily happy) to deal with one
version of the source base, but not two.


This still confuses me, because apparently nobody has a problem with 
having three binary compatible MySQL variants in Debian:

MySQL, MariaDB and PerconaDB [4]

Best regards,
Andreas


1: https://ffmpeg.org/security.html
2: http://j00ru.vexillium.org/?p=2211
3: The security page shows 6 CVEs, but CVE-2014-4609 and CVE-2014-4610
   are the same, once reported for Libav and once for FFmpeg.
4: https://lists.debian.org/debian-devel/2014/08/msg00016.html


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53f094d6.4070...@googlemail.com

Re: Reintroducing FFmpeg to Debian

2014-08-17 Thread Luca Barbato

On 17/08/14 10:28, Michael Niedermayer wrote:
 On Fri, Aug 15, 2014 at 01:19:38AM +0200, Luca Barbato wrote:
 Stefano Sabatini wrote:
 [...]

 The list is quite long and debunking each of the statements could take a
 lot of time.

 I'm going to address two historical misrepresentations:


 # The change of management

 Michael Niedermayer managed to get demoted from his leader position by
 the topmost 18[1] people involved in FFmpeg by the time due his tendency
 of not following the rules. that after weeks from being voted to stay as
 leader by 15, 5 explicitly stating their vote was conditioned by his
 behaviour and 1 definitely against him.[2]

 There was a vote on the ffmpeg-devel list, everyone can recount the
 votes although its probably a bit work to do given its a large thread
 with lots of other discussions (the links below point to that thread)
 I dont remember the exact numbers but there was a majority in
 support of me in all possible variants in which one could count the
 votes

I did and wrote that above, anybody is welcome to check if I miscounted
so I provided a link in the previous email, repeated here[0] for
convenience.

 Ive asked [1][2] back then what policy in place was broken

- you tried to commit code that was blatantly below the already lax
quality requirements (e.g. it contained tabs, it was (and still is) hard
to read, it contains dubious, aka security-concerning, practices), I
told you not to commit those as-is and you blatantly ignored me and the
others against it. I'm referring to the mplayer filters.

- your interaction with whoever wasn't in full agreement with you was
horrible, I told you for months in public and private, you seemed to
agree just to behave in even worse way later. The interactions with Mans
are probably the best example of this.

- your interaction with whoever provided infrastructure service was
horrible[1]. As Attila already stated here[2] and here[3]

 In retrospect, bigger changes should have been made to the policy
 if that had avoided the takeover attempt and fork, but the takeover
 attempt came a bit out of the blue, at least for me and it definitely
 left the feeling that there was more interrest in seizing the
 opertunity for a takeover instead of discussing and amending the
 policy.

I discussed with you in private for months before that and the outcome
had been none.

 Then i think we should reunite the projects with some common
 development policy most are happy with.

Given this email and the PS below doesn't seem that you want to
collaborate in any productive way.

 PS: please spare the world of these defamation attempts

People is free to check, count and sift the mailing list and git history
and form an informed opinion.

I'm sick of being depicted as traitorous swine[4] or monkey[5] or
whichever colorful expression do you use nowadays and even more annoyed
of having people thinking that must be true since we aren't answering
back to your outlandish claims.

 and i also think we should look forward and solve the issues we have
 now and not fight over what happenend 3-4 years ago or who made more
 mistakes ...

The current issue can be summarized with:
- you leveraging the trademark of FFmpeg to get more mindshare for
almost free.
- you leeching my work by leveraging git merge daily and presenting
yourself as more secure by fixing fuzz-reports and spamming CVEs.
- you putting in FFmpeg pretty much every patch from every branch you
can come by, including my incomplete work from github (you did for pulse
and segment with interesting results, hopefully you won't do that again
anymore).
- you contacting whoever brings patches in Libav. (Keiji was not happy
to remember you and we got other people quietly asking what to do of it).

[0] The vote
http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/118594 c.f. Change
of management http://lwn.net/Articles/423703/
[1] http://ffmpeg.org/pipermail/ffmpeg-devel/2010-July/088546.html
[2]
http://lists.debian.org/20140812171317.d2ce47b8da41b72e79f39...@kinali.ch
[3]
http://lists.debian.org/20140812214537.0bc793c5bbdebd8efd9f3...@kinali.ch
[4] https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2011-March/108151.html
[5] http://article.gmane.org/gmane.comp.video.ffmpeg.devel/130994


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53f0ff27.4090...@gentoo.org

Re: Reintroducing FFmpeg to Debian

2014-08-17 Thread Clément Bœsch

On Sun, Aug 17, 2014 at 09:14:47PM +0200, Luca Barbato wrote:
[...]
  Ive asked [1][2] back then what policy in place was broken
 
 - you tried to commit code that was blatantly below the already lax
 quality requirements (e.g. it contained tabs, it was (and still is) hard
 to read, it contains dubious, aka security-concerning, practices), I
 told you not to commit those as-is and you blatantly ignored me and the
 others against it. I'm referring to the mplayer filters.
 

Weren't mplayer filters pushed post fork?

 - your interaction with whoever wasn't in full agreement with you was
 horrible, I told you for months in public and private, you seemed to
 agree just to behave in even worse way later. The interactions with Mans
 are probably the best example of this.

Interactions with Måns and everyone else were also pretty terrible, to the
point that he also left Libav in a rage quit (see #libav-devel on
2011/09/17 for related, when he left. Michael was not here). Note that I'm
not saying this is the reason he completely left the project.

 - your interaction with whoever provided infrastructure service was
 horrible[1]. As Attila already stated here[2] and here[3]
 

AFAICT this has nothing to do with the policy rules in place.

[...]
  Then i think we should reunite the projects with some common
  development policy most are happy with.
 
 Given this email and the PS below doesn't seem that you want to
 collaborate in any productive way.
 

You do not display evidence of cooperation either since you started
sending mails here.

  PS: please spare the world of these defamation attempts
 
 People is free to check, count and sift the mailing list and git history
 and form an informed opinion.
 

The people being harsh on this thread in regards to Libav were, AFAIK, not
part of the FFmpeg project.

 I'm sick of being depicted as traitorous swine[4] or monkey[5] or
 whichever colorful expression do you use nowadays and even more annoyed
 of having people thinking that must be true since we aren't answering
 back to your outlandish claims.
 

The swine insult was not from Michael, and this is a personal issue
you'll have to deal with the person directly. I'm pretty sure you already
did with your swine shirts. This was also a quote from 2011, aka the date
of the fork, when everyone was pretty tense because of the takeover. Being
insulted because you miss your stabbing in the back (I know you love
that expression) is something that might be understandable.

About the monkey thing, this is obviously just a remix of the expression
patch monkey that was used in the projects since a long time ago:

https://mplayerhq.hu/pipermail/ffmpeg-devel-irc/2010-February/26.html

elenril patch monkeys are too lazy

https://mplayerhq.hu/pipermail/ffmpeg-devel-irc/2010-May/000104.html

janneg any patch monkeys around?

http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2011-February/102571.html

And then i remember when chatting with ben that he felt the commiters as
mere patch monkeys who anyone with enough time could join, but from more
chatting with actual members of the commiter team they seem to rather
think they lead ffmpeg now and have actual decission power.

[...]
 - you leeching my work by leveraging git merge daily

Welcome to the wonderful world of Open Source Luca.

  and presenting
 yourself as more secure by fixing fuzz-reports and spamming CVEs.

This is the second time you mention security in this mail. I think it
might be wise to not dig too much on the security side of Libav.
I could for example mention:

http://git.videolan.org/?p=ffmpeg.git;a=commit;h=d6af26c55

 - you putting in FFmpeg pretty much every patch from every branch you
 can come by, including my incomplete work from github (you did for pulse
 and segment with interesting results, hopefully you won't do that again
 anymore).

Yes, with full authorship, because those were requested  needed in
FFmpeg. Also, communication does not work with you (we FFmpeg are
definitely ignored by most of the people on Libav); this means that
obviously we are not going to annoy you for information or status about
your progress. May I remind you that Michael is banned from the
mailing-list, IRC and some of the developers repositories? Why would you
expect him to even try to communicate with you about these contributions?

 - you contacting whoever brings patches in Libav. (Keiji was not happy
 to remember you and we got other people quietly asking what to do of it).

The politic of Libav to alienate contributors is also well developed:

10:44:01  Xeta Are the repositories for libavformat shared between ffmpeg and 
libav in any way?
10:44:26  Xeta I've nevery really understood the difference
10:44:27 @lu_zero Xeta: ffmpeg merges everything we do and then insult us 
calling us monkeys
10:44:43  Xeta Haha, i see
10:44:46  Xeta Bastards

Our contributors also received mails from the Libav team. I don't remember
FFmpeg

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-16 Thread Nicolas George

L'octidi 28 thermidor, an CCXXII, Bálint Réczey a écrit :
 Using Gerrit and file ownersip are not mutually exclusive. Gerrit
 can be configured to automatically invite the right people for review
 based on the changed path. We recently migrated to Gerrit at the
 Wireshark project and it helps a lot in coordinating the reviews.

I am afraid this discussion on Gerrit or other similar tools is pointless:
this is trying to solve a human problem with technical means: it never
works.

Actually, I believe all this peer-review business to be a red herring. On
the FFmpeg side, most patches except the very simple ones are sent to the
mailing-list for peer-review, even patches by people with commit rights
working on their own code; they do so not because a rule states they have
too but because this is the best thing to achieve good code. On the other
hand, I remember having seen patches somewhat rushed through the mandatory
review on libav-devel and applied when someone else still had remarks; I
have not kept tabs on that though.

The real issue between the mandatory peer-review on the mailing-list is,
IMHO, control of the project orientation. Not is this patch correct? but
do we want this patch?.

If you are involved in the project, it is very obvious that both branches
have rather opposed views on the project orientation: libav has made a point
of trimming unnecessary features and rejecting new ones while FFmpeg kept
them and added some.

A few examples:

* Libav removed ffserver, FFmpeg kept it, trying to unbreak it. The commit
  message said appears simpler to write a new replacement from scratch,
  but in the meantime, users are left without the feature.

* Libav removed the framerate detection code, FFmpeg built on it to handle
  it in filtering too. I do not find them right now, but I have found a few
  files that avconv wanted to encode at an insane frame rate while ffmpeg
  correctly guessed; and right now, -vf fps does not work alone with very
  common formats in avconv.

* Libav removed the keyboard interaction (Press [q] to stop) while FFmpeg
  extended it.

Beyond these obvious cases, FFmpeg has gained quite a few features that, I
am pretty certain of it, would not have been accepted into libav: the concat
demuxer (has been called hack on the mailing-lists IIRC), the lavfi
sources made for testing, support for some obscure format through an
external library, subtitles hard-burning, etc.

The most galling in this issue is that there is no clear decision behind
this orientation. The fork's manifesto stated that everyone was equal
amongst equals, with or without commit rights, but the people who do have
the commit rights are few and of a common mind, they can just give the cold
shoulder to proposed changes that do not suit their personal view of the
project.

Considering these differences in policy, I do not believe the fork can be
merged. Speaking as someone who proposed a few of these unnecessary
features, because they were fun or immediately useful, I would not like to
work on a project that would reject them by principle. But I can recognize,
for someone who needs serious professional software, the need of working
on something driven with a firmer hand.


Having a fork is not inherently bad, and it becomes necessary when people
have different views for the orientation of the projects.

It becomes bad when people not involved in the project start to suffer from
the consequences of the fork. This is what is happening here, for two
reasons:

* distributions adopting one side of the fork for non-technical reasons;

* one side of the fork not caring about compatibility with the other side.

Of course, these reasons are interconnected.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-16 Thread Thomas Goirand

On 08/15/2014 11:53 PM, The Wanderer wrote:
 It's also something the Linux kernel is still doing, with apparent
 success.

Yes, the Linux kernel is a successful project. Does this mean using a
list for reviewing patches is a good thing? No! The workflow with a list
is simply horrible. Using git-review and gerrit is so much better.

 I for one consider it to be a much more public, transparent, and
 discoverable way to let proposed patches and the review of same be open
 to public view, compared to the way various other projects seem to do
 it.
 
 Making sure everything passes through the mailing list, and most if not
 all substantive discussion happens on the mailing list, is a lot better
 than having some discussion on the mailing lists and some on a bug
 tracker and some on IRC and some via private mail and so on. (The most
 ridiculously extreme example of this fragmentation that I know of is
 probably the Mozilla project.)

This reasoning may work when you have only a small amount of information
to read. When you are overwhelmed with it, having different places to do
different things is a much better approach. Sending patches to a list
simply doesn't scale.

Also, with a list, it's not convenient at all to point out a line in a
patch in a mailing list. You must extract the relevant lines, cut/past
them, and comment them. Instead, double clicking on the line of the
patch which is displayed on a web interface is much more convenient.

 There's nothing wrong with having discussion in those various areas, of
 course; it's probably inevitable, and it's even a good thing. It's just
 that it's a lot harder for someone not intimately involved with the
 project to follow discussion if it happens in such a variety of places,
 and there's value to be found in making sure that everything passes
 through one central (discussion-enabled) point before landing.

Lists are good tools for discussing where a project should go, release
goals, and so on. They aren't good tools to do patch reviews. I've used
both, and I'm convinced of that.

Thomas Goirand (zigo)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53ef78f4.2090...@debian.org

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-16 Thread Nicolas George

Le septidi 27 thermidor, an CCXXII, Thomas Goirand a écrit :
   If you guys could find a solution to try to work together
 again, and merge back both projects, that'd be best for everyone.

When people suggest that, I always wonder how they see that happening with
regard to the code.

In more than three years since the fork, development has continued on both
branches. Changes are continuously ported from libav to FFmpeg, but code was
also written for FFmpeg and never merged by libav. Some of this code, the
libav people have made very clear they specifically did not want it.

So what about the code? Shall the FFmpeg developers discard three years of
work and start working on libav? Or shall the libav developers accept to
work with the code from FFmpeg that they do not like?

I see neither as an option.

The only option is to make sure the users do not suffer from the fork, by
making sure they can easily use the version that is most suited for their
need without being sucked into the developers' disagreements.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-16 Thread Pau Garcia i Quiles

On Sat, Aug 16, 2014 at 5:30 PM, Nicolas George geo...@nsup.org wrote:


 The only option is to make sure the users do not suffer from the fork, by
 making sure they can easily use the version that is most suited for their
 need without being sucked into the developers' disagreements.


Can we get back on topic?

With or without libav in Debian, there are solid technical reasons to have
ffmpeg in Debian. We have both GraphicsMagick and ImageMagick (although
they parted ways in a civilized way: different library names), and we
certainly have a ton of librarys which provide very similar features.

Since before the fork, the libav developers have been sabotaging ffmpeg as
much as possible, in every combat field: library names, library versions,
taking distributions hostage (ffmpeg package that installs libav!?), etc.
This is not the way to fork anything. This is a fact. I don't care whether
Michael Nidermayer was a dictator or not. I don't care whether the
code-review rules in libav are better or worse. I don't care what the Linux
kernel does. The only thing I care about is Debian is shipping a
less-capable (i. e. less multimedia formats supported) distribution due to
this conflict.

This has to stop.

ffmpeg is not yet in Debian due to the filename clashing, which will most
certainly cause binary problems.

If libav and ffmpeg maintainers cannot reach an agreement regarding library
names and it's not possible to simply use either ffmpeg or libav
indistinctly due missing features binary compatibility, etc, the obvious
solution is that BOTH libav and ffmpeg rename their libraries in Debian. E.
g. libavcodec-ffmpeg.so and libavcodec-libav.so, etc. Maybe even use
alternatives to provide the binaries (ffmpeg, ffplay, etc). It's been done
in the past.

And before someone mentions it: I don't think it's too late. It's getting
too late because nobody with the right to act is doing anything. In the
end, our users are the ones being harmed and we are left wondering why they
are increasingly moving to other distributions or Mac OS X.

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-16 Thread wm4

On Sat, 16 Aug 2014 23:29:56 +0800
Thomas Goirand z...@debian.org wrote:

 On 08/15/2014 11:53 PM, The Wanderer wrote:
  It's also something the Linux kernel is still doing, with apparent
  success.
 
 Yes, the Linux kernel is a successful project. Does this mean using a
 list for reviewing patches is a good thing? No! The workflow with a list
 is simply horrible. Using git-review and gerrit is so much better.
 
  I for one consider it to be a much more public, transparent, and
  discoverable way to let proposed patches and the review of same be open
  to public view, compared to the way various other projects seem to do
  it.
  
  Making sure everything passes through the mailing list, and most if not
  all substantive discussion happens on the mailing list, is a lot better
  than having some discussion on the mailing lists and some on a bug
  tracker and some on IRC and some via private mail and so on. (The most
  ridiculously extreme example of this fragmentation that I know of is
  probably the Mozilla project.)
 
 This reasoning may work when you have only a small amount of information
 to read. When you are overwhelmed with it, having different places to do
 different things is a much better approach. Sending patches to a list
 simply doesn't scale.
 
 Also, with a list, it's not convenient at all to point out a line in a
 patch in a mailing list. You must extract the relevant lines, cut/past
 them, and comment them. Instead, double clicking on the line of the
 patch which is displayed on a web interface is much more convenient.

What? Most patches are posted inline (with git-send-email).
 
  There's nothing wrong with having discussion in those various areas, of
  course; it's probably inevitable, and it's even a good thing. It's just
  that it's a lot harder for someone not intimately involved with the
  project to follow discussion if it happens in such a variety of places,
  and there's value to be found in making sure that everything passes
  through one central (discussion-enabled) point before landing.
 
 Lists are good tools for discussing where a project should go, release
 goals, and so on. They aren't good tools to do patch reviews. I've used
 both, and I'm convinced of that.

What we need is solving the FFmpeg/Libav split, not well-meant
suggestions by outsiders how to change our development model.

 Thomas Goirand (zigo)
 ___
 ffmpeg-devel mailing list
 ffmpeg-de...@ffmpeg.org
 http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140816174433.1f3f496b@debian

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

Pau Garcia i Quiles pgqui...@elpauer.org writes:

 If libav and ffmpeg maintainers cannot reach an agreement regarding
 library names and it's not possible to simply use either ffmpeg or libav
 indistinctly due missing features binary compatibility, etc, the obvious
 solution is that BOTH libav and ffmpeg rename their libraries in
 Debian. E. g. libavcodec-ffmpeg.so and libavcodec-libav.so, etc. Maybe
 even use alternatives to provide the binaries (ffmpeg, ffplay,
 etc). It's been done in the past.

None of this is why libav and FFmpeg can't both be in the archive.  They
can't both be in the archive because both the release team and the
security team have said that they're not interested in trying to support
both, due to the amount of work involved.

All the renaming and cordial co-existence in the world won't change this.
The things that would change this is for one or both projects to develop a
better security track record and a history of higher-quality code releases
that require less ongoing work in stable, or for the people who care
deeply about this to somehow find a way to relieve the impact on those
teams in some way acceptable to those teams.

Short of that, there's clearly a need for software of this type in Debian,
and at the same time it's clearly a ton of work.  The teams involved have
indicated that they're willing (if not necessarily happy) to deal with one
version of the source base, but not two.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/878umobdj5@hope.eyrie.org

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-16 Thread Cyril Brulebois

Hi Russ,

Russ Allbery r...@debian.org (2014-08-16):
 None of this is why libav and FFmpeg can't both be in the archive.
 They can't both be in the archive because both the release team and
 the security team have said that they're not interested in trying to
 support both, due to the amount of work involved.

the release team only has a say on what ends up in testing (and then
in stable); it cannot, and AFAICT hasn't tried to, block ffmpeg from
entering the archive. FTP masters have the control over the archive
as a whole.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

Cyril Brulebois k...@debian.org writes:
 Russ Allbery r...@debian.org (2014-08-16):

 None of this is why libav and FFmpeg can't both be in the archive.
 They can't both be in the archive because both the release team and
 the security team have said that they're not interested in trying to
 support both, due to the amount of work involved.

 the release team only has a say on what ends up in testing (and then
 in stable); it cannot, and AFAICT hasn't tried to, block ffmpeg from
 entering the archive. FTP masters have the control over the archive
 as a whole.

Sorry, yes, good point.  I should have been clearer.  I assume the goal
was to get both into a stable release.  If people wanted to upload FFmpeg
only to unstable without propagation to testing or making it part of a
release, that's a possibly different situation with different tradeoffs
and issues involved.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87y4uo9xr1@hope.eyrie.org

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-16 Thread Ivan Kalvachev

On 8/16/14, Pau Garcia i Quiles pgqui...@elpauer.org wrote:
On Sat, Aug 16, 2014 at 5:30 PM, Nicolas George geo...@nsup.org wrote:

The only option is to make sure the users do not suffer from the fork, by
making sure they can easily use the version that is most suited for their
need without being sucked into the developers' disagreements.

Can we get back on topic?

With or without libav in Debian, there are solid technical reasons to have
ffmpeg in Debian. We have both GraphicsMagick and ImageMagick (although
they parted ways in a civilized way: different library names), and we
certainly have a ton of librarys which provide very similar features.

Since before the fork, the libav developers have been sabotaging ffmpeg as
much as possible, in every combat field: library names, library versions,
taking distributions hostage (ffmpeg package that installs libav!?), etc.
This is not the way to fork anything. This is a fact. I don't care whether
Michael Nidermayer was a dictator or not. I don't care whether the
code-review rules in libav are better or worse. I don't care what the Linux
kernel does. The only thing I care about is Debian is shipping a
less-capable (i. e. less multimedia formats supported) distribution due to
this conflict.

This has to stop.

ffmpeg is not yet in Debian due to the filename clashing, which will most
certainly cause binary problems.

If libav and ffmpeg maintainers cannot reach an agreement regarding library
names and it's not possible to simply use either ffmpeg or libav
indistinctly due missing features binary compatibility, etc, the obvious
solution is that BOTH libav and ffmpeg rename their libraries in Debian. E.
g. libavcodec-ffmpeg.so and libavcodec-libav.so, etc. Maybe even use
alternatives to provide the binaries (ffmpeg, ffplay, etc). It's been done
in the past.

AFAIK, Andreas' package uses libavcodec-ffmpeg.so .

FFmpeg configure does have option --build-suffix=_ffmpeg that would
append that suffix to library names and pkg-config files. Since
applications might have problem finding the ffmpeg libraries, the
pkg-config files should be with the old common names and this
creates a conflict in the -dev packages.

Libav and FFmpeg can coexist side by side.
There are no conflicts or overlap for binary users.

The current goal of FFmpeg is not replacing Libav.
The current goal is establishing a native presence in the most popular
distribution(s).

I'm quite sure the Security team is full of capable people who can
handle one more package.
FFmpeg takes security seriously.

The best scenario for everybody is:
1. Libav stays and all QA tested programs are not touched.
2. FFmpeg is included in a way that does not obstruct the rest of the ecosystem.
3. Optionally, programs that use _only_ FFmpeg could be included back
in Debian. Optionally.

The inclusion would allow for a real-life estimate to be done of the
FFmpeg performance, security, bug and feature wise.

Only after assessing real-life data, a final decision could be
reached, if there is still demand for such thing.

Best Regards
Ivan Kalvachev

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/CABA=pqdclh+p4kqx99gmrnu-f24wpxkfnthjwryl5dnyzue...@mail.gmail.com

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-16 Thread Bálint Réczey

Hi Nicolas,

2014-08-16 17:11 GMT+02:00 Nicolas George geo...@nsup.org:
 L'octidi 28 thermidor, an CCXXII, Bálint Réczey a écrit :
 Using Gerrit and file ownersip are not mutually exclusive. Gerrit
 can be configured to automatically invite the right people for review
 based on the changed path. We recently migrated to Gerrit at the
 Wireshark project and it helps a lot in coordinating the reviews.

 I am afraid this discussion on Gerrit or other similar tools is pointless:
 this is trying to solve a human problem with technical means: it never
 works.
I did not want to sell Gerrit over mailing-list discussion because the
work-flow is something which should be chosen by the development team
and not outsiders, but wanted to show that tools can help enforcing
some parts of the work-flow.

On the human problems vs. technical means questions I think we have
different opinions. Technical means are exceptionally great tools for
solving _some_ human problems. If the human problem is being not
satisfied with peers' behavior of not following a specific work-flow a
toll which enforces the work-flow would solve it. Making mistakes is
an other (mostly) human problem and we have lintian for example which
helps pointing them out.


 Actually, I believe all this peer-review business to be a red herring. On
 the FFmpeg side, most patches except the very simple ones are sent to the
 mailing-list for peer-review, even patches by people with commit rights
 working on their own code; they do so not because a rule states they have
 too but because this is the best thing to achieve good code. On the other
 hand, I remember having seen patches somewhat rushed through the mandatory
 review on libav-devel and applied when someone else still had remarks; I
 have not kept tabs on that though.

 The real issue between the mandatory peer-review on the mailing-list is,
 IMHO, control of the project orientation. Not is this patch correct? but
 do we want this patch?.

 If you are involved in the project, it is very obvious that both branches
 have rather opposed views on the project orientation: libav has made a point
 of trimming unnecessary features and rejecting new ones while FFmpeg kept
 them and added some.
IMO the trimming/rejecting strategy is not something which would ever
make Libav popular among developers/users and this is how we ended in
the current situation. While Libav's communicated release strategy can
attract integrators and distributions like Debian, FFmpeg attracts
developers/users of software based on Libav/FFmpeg due to more
features.
Sticking to those core strategies the two forks will compete forever
until one of them give up - which I see unlikely to happen voluntarily
- and users will keep complaining about Libav's missing features to
distributions' maintainers where FFmpeg is not packaged.

I think the best way out of this situation would be relaxing the
review requirements on Libav's side and letting not-yet-proven of
FFmpeg features in through an experimental/staging phase. If FFmpeg
devs could collaborate with them this way the two forks could be
converged and finally merged and the combined team could maintain a
lot better media library than the current forks are separately.

Cheers,
Balint


 A few examples:

 * Libav removed ffserver, FFmpeg kept it, trying to unbreak it. The commit
   message said appears simpler to write a new replacement from scratch,
   but in the meantime, users are left without the feature.

 * Libav removed the framerate detection code, FFmpeg built on it to handle
   it in filtering too. I do not find them right now, but I have found a few
   files that avconv wanted to encode at an insane frame rate while ffmpeg
   correctly guessed; and right now, -vf fps does not work alone with very
   common formats in avconv.

 * Libav removed the keyboard interaction (Press [q] to stop) while FFmpeg
   extended it.

 Beyond these obvious cases, FFmpeg has gained quite a few features that, I
 am pretty certain of it, would not have been accepted into libav: the concat
 demuxer (has been called hack on the mailing-lists IIRC), the lavfi
 sources made for testing, support for some obscure format through an
 external library, subtitles hard-burning, etc.

 The most galling in this issue is that there is no clear decision behind
 this orientation. The fork's manifesto stated that everyone was equal
 amongst equals, with or without commit rights, but the people who do have
 the commit rights are few and of a common mind, they can just give the cold
 shoulder to proposed changes that do not suit their personal view of the
 project.

 Considering these differences in policy, I do not believe the fork can be
 merged. Speaking as someone who proposed a few of these unnecessary
 features, because they were fun or immediately useful, I would not like to
 work on a project that would reject them by principle. But I can recognize,
 for someone who needs serious professional software, the need of

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-16 Thread Bálint Réczey

Hi Russ,

2014-08-16 18:59 GMT+02:00 Russ Allbery r...@debian.org:
 Cyril Brulebois k...@debian.org writes:
 Russ Allbery r...@debian.org (2014-08-16):

 None of this is why libav and FFmpeg can't both be in the archive.
 They can't both be in the archive because both the release team and
 the security team have said that they're not interested in trying to
 support both, due to the amount of work involved.

 the release team only has a say on what ends up in testing (and then
 in stable); it cannot, and AFAICT hasn't tried to, block ffmpeg from
 entering the archive. FTP masters have the control over the archive
 as a whole.

 Sorry, yes, good point.  I should have been clearer.  I assume the goal
 was to get both into a stable release.  If people wanted to upload FFmpeg
 only to unstable without propagation to testing or making it part of a
 release, that's a possibly different situation with different tradeoffs
 and issues involved.
For now the target is not stable, but unstable/experimental. Both the
Security and Release Teams could keep an RC bug on the package until
they are fine with letting it into testing.

Cheers,
Balint


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cak0odpzp7jri7zwhd5t_bh+trbtznnx139lequ-+rkwkrbw...@mail.gmail.com

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

Ivan Kalvachev ikalvac...@gmail.com writes:

 I'm quite sure the Security team is full of capable people who can
 handle one more package.

One, no, this statement is not correct.  Not because the security team is
not capable -- they are very capable -- but because they are not *full*.
You imply that the security team has tons of resources and time to spare.
Let me assure you that this is far from the case.  This isn't even the
case for security teams consisting of full-time staff paid by commercial
Linux distributions, let alone volunteers for the Debian project.

Two, the security team has already said that FFmpeg is not just one more
package, and that no, they can't handle the substantial incremental load
from adding FFmpeg without removing libav.  You may not think that should
be the case, but I'm afraid your opinion on the topic doesn't matter
unless you're finding a way to either reduce that work or add more
resources.

 FFmpeg takes security seriously.

I'm sure that it does.

The problem, however, is that taking security seriously, while possibly
necessary, is not sufficient.  I'm glad that FFmpeg takes security
seriously, but what FFmpeg needs is to *have fewer security bugs*.

This isn't about anyone's good intentions.  It's about the reality of
past, very negative experience with FFmpeg's security track record.

It's clear that efforts are underway to improve that, such as through the
fuzz testing work that Google (among others) has been doing.  That's
great, but I'm sure you can also understand that the past track record has
been sufficiently bad that everyone will continue to be leery for a while.
To change that impression, FFmpeg is going to have to substantially
improve on its past security track record and then *maintain* that new
level of security for some period of time.

Note that all of the above statements also apply to libav.  As near as I
can tell, this is not a distinguishing characteristic between the two
projects.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87fvgw9s6v@hope.eyrie.org

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-16 Thread wm4

On Sat, 16 Aug 2014 11:59:20 -0700
Russ Allbery r...@debian.org wrote:

 The problem, however, is that taking security seriously, while possibly
 necessary, is not sufficient.  I'm glad that FFmpeg takes security
 seriously, but what FFmpeg needs is to *have fewer security bugs*.

That is very valuable advice. We'll get to work right away.

 Note that all of the above statements also apply to libav.  As near as I
 can tell, this is not a distinguishing characteristic between the two
 projects.

And that's an argument against switching to FFmpeg exactly how?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140817002757.6516bd91@debian

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-16 Thread Andreas Cadhalpun

Hi,

On 16.08.2014 17:49, Pau Garcia i Quiles wrote:

On Sat, Aug 16, 2014 at 5:30 PM, Nicolas George geo...@nsup.org
mailto:geo...@nsup.org wrote:

The only option is to make sure the users do not suffer from the
fork, by
making sure they can easily use the version that is most suited for
their
need without being sucked into the developers' disagreements.

Can we get back on topic?

Yes. I have now sent the pkg-config patches to the BTS [1].

With or without libav in Debian, there are solid technical reasons to
have ffmpeg in Debian. We have both GraphicsMagick and ImageMagick
(although they parted ways in a civilized way: different library names),
and we certainly have a ton of librarys which provide very similar features.

This is also my point of view.

It would be nice, if everyone, including you, would refrain from posting
such flamebaits on debian-devel.

Please try to follow Debian's code of conduct [2].

I don't care whether Michael Nidermayer was a dictator or not. I don't
care whether the code-review rules in libav are better or worse. I don't
care what the Linux kernel does. The only thing I care about is Debian
is shipping a less-capable (i. e. less multimedia formats supported)
distribution due to this conflict.

This has to stop.

ffmpeg is not yet in Debian due to the filename clashing, which will
most certainly cause binary problems.

This is wrong, because the FFmpeg Debian packaging avoids filename
conflicts.

If libav and ffmpeg maintainers cannot reach an agreement regarding
library names and it's not possible to simply use either ffmpeg or libav
indistinctly due missing features binary compatibility, etc, the obvious
solution is that BOTH libav and ffmpeg rename their libraries in Debian.
E. g. libavcodec-ffmpeg.so and libavcodec-libav.so, etc.

This is already done in the FFmpeg Debian packages.

Maybe even use
alternatives to provide the binaries (ffmpeg, ffplay, etc). It's been
done in the past.

This is not necessary, because the Libav binaries already have different
names, avconv, avplay and so on.

And before someone mentions it: I don't think it's too late. It's
getting too late because nobody with the right to act is doing anything.
In the end, our users are the ones being harmed and we are left
wondering why they are increasingly moving to other distributions or Mac
OS X.

Indeed it's getting late, because the FFmpeg package has been waiting in
the NEW queue for more than 3 months.

Best regards,
Andreas

1:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=reintroducing-ffmpeg;users=andreas.cadhal...@googlemail.com

2: https://www.debian.org/code_of_conduct

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53efdfea.8000...@googlemail.com

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-16 Thread Derek Buitenhuis

On 8/16/2014 11:27 PM, wm4 wrote:
 That is very valuable advice. We'll get to work right away.

I've added it to my TODO:

* Don't write bugs.

- Derek


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53efdcbe.5050...@gmail.com

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

wm4 nfx...@googlemail.com writes:
 Russ Allbery r...@debian.org wrote:

 Note that all of the above statements also apply to libav.  As near as I
 can tell, this is not a distinguishing characteristic between the two
 projects.

 And that's an argument against switching to FFmpeg exactly how?

It's not.  Nor was I trying to make one.  This part of the thread was
discussing introducing FFmpeg into Debian alongside libav.

As I believe I mentioned previously, although the code base underlying
both projects has a bad past security track record, currently FFmpeg
appears to be doing somewhat better than libav.  I believe a member of the
security team made a similar observation.  So, when picking one, the
security argument seems to be at least partly in FFmpeg's favor.  That was
not my point; my point was that picking both of them is something that had
already been discussed and rejected for what to me feel like sound
reasons.

Security of course isn't the only consideration when picking one of the
two, and regardless I'm not the person who would be deciding anything.
Mostly I'm speaking up because it felt like people were going down blind
alleys arguing about things that aren't really at issue.

Note that experimental doesn't receive security support.  I may be missing
something (and here it's ftp-master that is the relevant decision-making
party), but I haven't seen any obvious reason why one shouldn't introduce
FFmpeg packages into experimental, particularly if people feel like
there's anything to be gained by seeing concrete packaging work, letting
people more easily experiment with the packages, and so forth.  Of course,
that by itself doesn't imply anything about the broader question of
replacing libav with FFmpeg or not.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/878umo81wo@hope.eyrie.org

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian