[FFmpeg-devel] Reintroducing FFmpeg to Debian

[Bálint Réczey]

Hi,

2014-08-15 14:20 GMT+02:00 Michael Niedermayer <michaelni at gmx.at>:
> On Fri, Aug 15, 2014 at 02:53:09PM +0800, Thomas Goirand wrote:
>> On 08/14/2014 11:59 PM, The Wanderer wrote:
>> > On 08/14/2014 11:27 AM, Thomas Goirand wrote:
>> >
>> >> On 08/13/2014 07:53 AM, Kieran Kunhya wrote:
>> >
>> >> On 08/13/2014 06:30 AM, Michael Niedermayer wrote:
>> >
>> >>> Also ive offered my resignation in the past. I do still offer to
>> >>> resign from the FFmpeg leader position, if it resolves this split
>> >>> between FFmpeg and Libav and make everyone work together again.
>> >
>> >> Why not just take the offer, and move on?
>> >
>> > Probably because of the condition he attached to it, which also dates
>> > back to the arguments preceding the original split:
>> >
>> >>> The part i insist on though is that everyone must be able to work
>> >>> on their code without people uninvolved in that specific parts
>> >>> maintaince or authorship being able to block their work.
>> >
>> > In other words, as I think I understand it from the discussion back
>> > then: people not involved with a particular area of the code can't NACK
>> > the work of someone who is working on it, and someone who works on a
>> > particular area of the code doesn't have to wait on review of people who
>> > aren't involved with that area of the code.
>> >
>> > Since one of the motivations of the people behind the libav side of the
>> > split seems, IIRC, to have been "no code gets in without having been
>> > reviewed by someone other than the author", this was apparently deemed
>> > an unacceptable condition.
>>
>> Hum... Well, to me, what's important is that the code gets
>> peer-reviewed.
>
> Yes, the tricky part in FFmpeg and Libav in relation to this is that
> theres quite a bit of code that is only well understood by a single
> person even if you would combine both projects together.
> So if that person posts a patch for review, theres noone who could
> do a real review
This situation is not totally unique to FFmpeg/Libav. IMO in this
real-life situation peers can do a best-effort review and people doing
so would sooner or later will get familiar with those parts of the
code as well.
In case of a widely used library like this the biggest issue is
breaking the ABI or modifying the ABI in a way which does not align
with the team's vision about the ABI roadmap. That type of change can
be pointed out by less experienced developers, too.
Internal regressions in the code can be easily fixed even if they are
not discovered during testing and enter the release.

>
>
>> Setting-up something like gerrit may help, as it can be
>> setup in a way that review becomes mandatory. Then discussing who's
>> core-reviewer and can approve this or that part of the code can be setup
>> within gerrit. This should be discussed, and setup based on technical merit.
>
> Not commenting about gerrit as i dont have experience with it, but
> FFmpeg currently uses a simple file in main ffmpeg git that lists
> which part is maintained by whom, and these developers would in the
> rare case of a dispute have the final say in each area.
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.

Cheers,
Balint

>
> OTOH, Libav early deleted their forked version of this file, and
> iam not aware of any replacement. But others should explain how it
> works in Libav ...
>
>
>>
>> Having a NACK review is often disappointing. It goes the wrong way if
>> there's only a NACK with no comments on how to improve things, so that
>> the code becomes acceptable.
>
>> Absolutely everyone should *always* be able
>> to leave comments, be it positive or negative.
>
> yes, i fully agree and this also was always so in FFmpeg. In that
> sense everyone is welcome to subscribe to ffmpeg-devel and review and
> comment patches. That of course includes Libav developers and everyone
> else. And more reviewers would also certainly help, so yeah anyone
> reading this and wanting to help review patches, you are welcome!
>
> Thanks
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> it is not once nor twice but times without number that the same ideas make
> their appearance in the world. -- Aristotle