[FFmpeg-devel] [RFC] Reviewing merges
michael at niedermayer.cc
Wed Apr 26 05:10:11 EEST 2017
On Tue, Apr 25, 2017 at 11:33:29AM -0300, James Almer wrote:
> On 4/24/2017 3:27 PM, Michael Niedermayer 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)
> If I'm the one merging some change that has considerable chances of
> introducing regressions, then sure.
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: Digital signature
More information about the ffmpeg-devel