[FFmpeg-devel] [RFC] Reviewing merges

[wm4]

On Mon, 24 Apr 2017 20:27:45 +0200
Michael Niedermayer <michael at niedermayer.cc> wrote:

> On Mon, Apr 24, 2017 at 11:23:16AM -0300, James Almer wrote:
> > On 4/23/2017 11:07 PM, Michael Niedermayer wrote:  
> > > Hi all
> > > 
> > > Should changes ported from libav (what we call merges) be reviewed
> > > before being pushed?  
> > 
> > The lot of merges are simple things like "Fix this bug that was already
> > fixed in ffmpeg months ago", "K&R", etc. Lately we are even no-oping a
> > good amount of them as they don't even apply.  
> 
> > Only a small set of merges are big API changes, and those are always
> > handled by more than one developer, either by reviewing the changes,
> > testing them or by helping getting the thing working. And of course, any
> > bug that was not caught before pushing is fixed afterwards.
> > In fact, it should be noted that if they are initially skipped for
> > requiring more thought and for blocking unrelated merges, when we get
> > them working at a latter point we always send them to the ML instead of
> > simply pushing them.  
> 
> yes
> 
> could you send more changes to the ML instead of just ones
> initially skiped ? (and of course i dont mean trivial / clearly correct
> stuff)
> 
> More eyes may catch more issues also i belive its important that we
> all see the changes being done, we all have to maintain the code
> which interacts with these changes.

Sorry, from you I've mostly seen weird command lines failing (and the
devs had to find out themselves whether they were legitimate failures).
From "eyes catching issues" I'd expect something more concrete, like
pointing out errors in the code or fixing them.

> 
> [...]
> 
> > We have recently been able to go through six hundred or so commits in a
> > month or two this way after being stuck for the longest time by a few of
> > those big API changes. If we start requiring every commit to go through
> > a review process on the ML then we will never catch up with the backlog.
> > In short, things as they are right now are smooth. Changing it will only
> > make this slower.  
> 
> Maybe, but is merging more faster also better for FFmpeg ?

Oh come on, the merge backlog we had almost meant that we were giving
up on merging, causing huge problems to various people (including
myself).

> I did not analyze the bugs on our bug tracker but subjectivly the
> number of regressions seems much larger than a year or 2 ago.

Because you're not doing the merges yourself anymore, which means that
things you test might result in a regression? When you were doing the
merges, you probably did this before you merged, meaning you'd of
course not find as many regressions after the merge.

Now that's what I call bias.

> and i just yesterday found 2 issues in a merge (which you fixed)

So where's the problem?

> 
> > 
> > That aside, may i ask what prompted this question? Did someone complain
> > to you privately? No merge recently seems to have broken anything that
> > hasn't been already fixed, beyond one threading bug that's being
> > investigated right now, so i wonder why ask this now.  
> 
> It was on my mind since a long time. I guess the recent surge of merges
> and the uneasiness of doing the 3.3 release in the middle kind of was
> bringing it up into relevance again.

Well, you insisted on a release at this time.

> Before that with the merges falling behind, multiple libav developers
> did sent patches to ffmpeg-devel which passed through review on our
> codebase before application. The merges restarting stoped this it
> seems.

Uh, what.

> I strongly belive that libav developers sending patches to ffmpeg
> and thus the author of a change testing it on top of ffmpeg results
> in better code than if its merged by a 3rd party.

You know what would be even better? If there were only a single project
on which Libav and FFmpeg developer worked.