[FFmpeg-devel] fate: Do not report side data size

[wm4]

On Thu, 9 Mar 2017 20:48:51 +0100
Michael Niedermayer <michael at niedermayer.cc> wrote:

> On Thu, Mar 09, 2017 at 07:48:53AM +0100, wm4 wrote:
> > On Thu, 9 Mar 2017 02:20:03 +0100
> > Michael Niedermayer <michael at niedermayer.cc> wrote:
> >   
> > > On Wed, Mar 08, 2017 at 11:54:59PM +0100, Hendrik Leppkes wrote:  
> > > > On Wed, Mar 8, 2017 at 3:42 PM, Ronald S. Bultje <rsbultje at gmail.com> wrote:    
> > > > > Hi,
> > > > >
> > > > > On Wed, Mar 8, 2017 at 9:31 AM, wm4 <nfxjfg at googlemail.com> wrote:
> > > > >    
> > > > >> On Wed, 8 Mar 2017 14:09:53 +0100
> > > > >> Michael Niedermayer <michael at niedermayer.cc> wrote:
> > > > >>
> > > > >> If the size printing is removed then other code should be added    
> > > > >> > to test for the size to match the correct value    
> > > > >>
> > > > >> Then it would be more reasonable to make av_packet_add_side_data()
> > > > >> check whether the size is correct for the given side data type.    
> > > > >
> > > > >
> > > > > I think you're both right here, this is a pretty good idea (for fixed-size
> > > > > side-data types).
> > > > >    
> > > > 
> > > > So how do we fix fate now? Change the datatypes to uint32_t, remove
> > > > the size print out?    
> > >   
> > > > Shouldn't keep all 32-bit fate clients broken for much longer.    
> > > 
> > > +1
> > >   
> > 
> > You're the one stopping the simple fix.  
> 
> If you or anyone belives this, you can just ask me privatly if i meant
> to object to the patch. Noone asked
> one can even ask me in public, as in "do you object to this patch
> being pushed ?"
> and to save everyone the delay and troubble the awnser is
> 
> I do NOT object to it.
> I would prefer if the final implementation would still print the size
> where it is relevant. That can be done in a seperate patch. Its
> important to fix this issue so it should not be delayed by this
> discussion (thats the long form of the "+1" above really)
> 
> But instead of asking, you publically claim that iam stoping the fix.
> that is not ok IMO

OK, so after this long, exhausting discussion that seemed to lead
nowhere, you actually were never against this patch all along. Maybe
you should be more explicit about whether you think a patch needs
requires more changes, or if it's fine to push. Because this sort
of thing seemed to happen multiple times in the past.

A patch author can't push a patch if there are still open requests for
amendments, so this should be made clear to not block application
unnecessarily.