[FFmpeg-devel] [RFC] libavfilter audio framework - split patches
Fri Jul 16 18:26:47 CEST 2010
On date Friday 2010-07-16 00:58:57 -0700, S.N. Hemanth Meenakshisundaram encoded:
> On 07/15/2010 04:52 AM, S.N. Hemanth Meenakshisundaram wrote:
>> On 07/14/2010 07:51 AM, Michael Niedermayer wrote:
>>> On Wed, Jul 14, 2010 at 04:45:39PM +0200, Michael Niedermayer wrote:
>>>> On Tue, Jul 13, 2010 at 02:38:16AM -0700, S.N. Hemanth Meenakshisundaram wrote:
>>>>> Stefano Sabatini wrote:
>>>> doesnt apply to svn
>>> to elaborate on this, we need patches that apply to svn.
>>> you can send a patch series so that patch n depends on patches 0..n-1
>>> to be applied before it.
>>> but if patch x (x<n) is changed due to discussions all later patches
>>> must be rebased on the new code. We dont apply bad patches and then
>>> apply fixes on top.
> The doxy changes were interfering with applying of patch to avfilter.h
> Am sending the series of patches again with the changes pointed out
> earlier. These applied directly to SVN revision 24040 which is the one
> used by soc libavfilter repo. Tested with valgrind and by manually
> modifying SDL specs for different sample/channel formats.
> The changes were;
> 1. Separate variable naming & functional changes.
> 2. Put all enum to int changes in one patch
> 3. Fix af_resample to use separate primary and duplicate pointers so
> that uninit etc is easier.
> This first patch is variable and function renaming.
Another request from me, I see there are tons of patches in these days
on ffmpeg-devel+ffmpeg-soc, so I'm a little overwhelmed, and managing
all of them is getting a little scary.
I ask you to send new patches as *separate* threads. There is a
wonderful feature of git, which is git send-email, which helps to make
things a lot smoother.
You write your patches series, then use git format-patch to create one
patch for each commit. Then you use git send-email PATCH to send the
mail. The command will generate a new thread, with a subject based on
the commit message.
The nice thing about this is that the tester/applier can directly
apply the patch to his own branch using git am, and the comment is
integrated in the patch itself.
That's way better than have a huge thread with many interleaved
patches, so that it is difficult to say which one has been
applied/reviewed/applied without navigating the whole tree.
More information about the ffmpeg-devel