[FFmpeg-devel] [RFC] libavfilter audio framework - split patches

[Stefano Sabatini]

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.

Regards.