[FFmpeg-devel] To be or not to be working with libav (was: [PATCHv3] On2 VP7 decoder)

[Clément Bœsch]

On Thu, Apr 10, 2014 at 07:10:57AM +0200, Vittorio Giovara wrote:
> On Mon, Apr 7, 2014 at 1:19 PM, wm4 <nfxjfg at googlemail.com> wrote:
> > On Sun, 6 Apr 2014 20:41:03 +0200
> > Vittorio Giovara <vittorio.giovara at gmail.com> wrote:
> >
> >> On Sunday, April 6, 2014, Nicolas George <george at nsup.org> wrote:
> >>
> >> > Le septidi 17 germinal, an CCXXII, Vittorio Giovara a écrit :
> >> > > The easiest solution would be to stop the daily merge and let the two
> >> > > projects live on their own
> >> >
> >> > You keep suggesting that: what good do you think that would achieve?
> >>
> >> Also Libav code is so ill received most of the times that I seriously can't
> >> figure out why this is still happening. The two projects have completely
> >> separate design approach and dev model so it's really difficult to
> >> understand, in my opinion
> >
> > I don't always understand it either. But in general, full merges are
> > seen as necessary evil within FFmpeg. The loss of control probably
> > contributes to the fact that Libav changes are seen much more
> > critically as opposed to if they had been discussed and reviewed by
> > FFmpeg developers too.
> 
> FFmpeg devs are welcome to join libav-devel and check the patches,
> propose changes and notify bugs.

Yup.

<ubitux> i can't even contribute to that
<ubitux> except saying "don't"
<ubitux> should i send revert patches?
<DonDiego> no, you should shut up or go away
<DonDiego> if you want to influence this project, contribute
<DonDiego> if you don't want to contribute, don't complain

> I'm not sure what caused so many
> people to think that Libav won't listen to (serious) development
> problems and modify patches accordingly.
> Rather than complaining in the ffmpeg-devel mailing list (where no
> Libav dev can listen)

They can. No one is banned there. Just follow FFmpeg development like most of
us do on Libav.

> for a random change introduced in Libav (and
> then merged), it would be wiser to have communication channel directly
> with the source of those changes.

> Or stop merging,

No

> but I don't think you have that communication link
> with the one who decides what to merge either.

Are you serious... ?

> 
> > What are you suggesting? What kind of collaboration? By the way, it
> > would be much easier if Libav merged everything FFmpeg does (and
> > routinely does so), because if the code is the same, there is no
> > problem in the first place.
> 
> For the benefit of the users, I would suggest to *at least* keep the
> API offer synchronized, like I explained in my previous email.
> 

We keep API synchronized the better we can already. Libav doesn't care, and
doesn't want to care except if it can breaks compat. I can quote IRC if needed.

> > I envision the following "double filtering" development process:
> >
> >    FFmpeg -> cherrypick by Libav dev -> Libav -> merge -> FFmpeg -> repeat
> >
> > This way the code will be incrementally improved by funneling a patch
> > through review and merge processes a few times.
> 
> In a normal world one could envision ffmpeg and libav as two branches,
> one for the development/hacks/quickbugfix and the other for stable
> development.

Yes, of course ffmpeg is for hacks.

[...]

-- 
Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140410/25ae2f4f/attachment.asc>