[Ffmpeg-devel] Re: Re: volunteer for patching pal8 in libswscale

[Karl H. Beckers]

Am Donnerstag, den 08.03.2007, 11:05 +0100 schrieb
ffmpeg-devel-request at mplayerhq.hu:
> Date: Thu, 08 Mar 2007 10:46:54 +0100
> From: Guillaume Poirier <gpoirier at mplayerhq.hu>
> Subject: Re: [Ffmpeg-devel] volunteer for patching pal8 in libswscale
> To: FFmpeg development discussions and patches
>         <ffmpeg-devel at mplayerhq.hu>
> Message-ID: <45EFDB8E.9050803 at mplayerhq.hu>
> Content-Type: text/plain; charset=ISO-8859-1
> [...]
> Your patch was inline. I don't bother trying to apply inline patches
> as they always get mangled by mail clients.
> 
> Please resend as attachment, preferably to the original thread where
> you sent the original patch.
> 
> Guillaume 

Hi,

the other patch I did submit as an attachment, but it has not been
approved, I suppose ...


...
I was just about to make some suggestions for adding a more procedural
description of patch submission (like who does what when, 1. submission
following rules a, b, c, 2. approval by X, 3. application by Y, etc.).
Rereading the thread around the difficulty of tracking patches, makes
this seem a bad time to do it.
Putting a defect tracking system in place will surely help a lot, esp.
when patch submitters are afraid their patches will just go unnoticed in
a mail queue and disappear if nobody feels addressed. With a defect
tracker I personally feel more comfortably that a bug or patch will not
get lost. Even if it is very low priority and never gets fixed/included
because there's always other things to do, it can still be referenced,
people will see it, people can download the patch and apply it to their
own copy of the source, etc.

I would just like to make the point that when documenting the guidelines
for defect/patch submission with a new system, the docs should not just
contain the static stuff (like what a patch should look like, etc.) but
also a few words on the process to set people's expectations right.

Short term, I'd like to suggest moving the following sentences from the
"Mailing Lists" page to the "Reporting Bugs" page:

"If you send us a patch, please make it a unified diff (diff -u),
everything else is unusable. For more detailed guidelines, have a look
at the MPlayer patch guidelines most of what is written there applies to
FFmpeg as well."
"Attached patches should not have application/octet-stream as
mime-type."
(Even the second sentence is redundant if you have read the mplayer
patch guideline, but you need to find it first. It needs some big,
blinking text on the "Reporting Bugs" page with "please DO read this
before submitting a patch".)


My 2 cents,

Karl.