[FFmpeg-devel] [PATCH]lavf/rawenc: Add a G.729 muxer
nfxjfg at googlemail.com
Wed May 18 16:24:53 CEST 2016
On Wed, 18 May 2016 10:05:41 -0400
compn <tempn at mi.rr.com> wrote:
> On Wed, 18 May 2016 14:10:57 +0200
> Paul B Mahol <onemda at gmail.com> wrote:
> > On 5/18/16, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:
> > > Hi!
> > >
> > > Attached patch allows to mux raw G.729 as supported by our G.729
> > > demuxer.
> > >
> > > Please comment, Carl Eugen
> > >
> > Please attach actual patch with commit log message.
> commit message is in the subj of the email i thought.
People often use git send-email, which puts the first line of the
commit message into the email subject field.
The main usefulness of proper patches is that we can actually see what
commit message he's going to use. For example, compare
They're both the same patch. But the message is very different. The
mail is pretty detailed. It gives a proper explanation why this change
is needed, a way to reproduce it, a link to the upstream bug report,
and even some analysis about past behavior (including useful git
hashes). The commit... contains nothing. The subject is useless and can
be derived from the code changes. The debian bug reference isn't a link
and has to be manually retrieved.
If you're hunting for a regression, and pinpoint this commit as a cause
for the regression, you will be very annoyed and you will waste time on
trying to understand the issue and reproducing it. You could try finding
the mail in the mailing list archive, but this is additional work too.
If the commit message subject is even similar to the mail's subject
(they could be very different).
Last but not least, a proper git-format-patch is easier to apply.
That's why it's important. But he keeps ignoring our requests to change
this, mostly because he disrespects us for working with his sworn
Now you explain to me why we should tolerate this.
More information about the ffmpeg-devel