Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
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. 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.
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. With Gerrit, it's
possible to comment directly in the patch, which helps going in the
Of course, a technical solution will not solve all social issues, but it
may improve the workflow and process, and avoid frictions.
I hope this helps,
Thomas Goirand (zigo)