Re: [FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.

[Thilo Borgmann]

Am 28.03.16 um 12:14 schrieb Hendrik Leppkes:
> On Mon, Mar 28, 2016 at 12:05 PM, Marton Balint  wrote:
>>
>> On Mon, 28 Mar 2016, Hendrik Leppkes wrote:
>>
>>> People that don't speak up at all may approve silently (or at least
>>> not disapprove), someone that raised issues should give an explicit
>>> OK/Nevermind/whatever, agreeing with you or withdrawing his
>>> complaints, there is no "silent" option there.
>>
>>
>> This seems unreasonable, beacuse this way a silent person can block a patch
>> forever, which is not optimal.
>>
>> What I usually do is after a week of silence if I feel that I addressed the
>> concerns, or there is no known way to improve the patch, I send one last
>> ping explicitly stating that I will apply the patch soon. (whithin 1-2
>> days). And if the silence remains, I apply it.
>>
> 
> If you send a mail explicitly stating that and the intention to move
> forward if no further feedback arrives, then its usually fine. Didn't
> happen here though.

"ping":http://article.gmane.org/gmane.comp.video.ffmpeg.devel/211969
"don't like":  http://article.gmane.org/gmane.comp.video.ffmpeg.devel/211970
"what to do?": http://article.gmane.org/gmane.comp.video.ffmpeg.devel/211971
-silence-

Ok, or not, whatever.

My actions were not ideal either and I regret it. In the future I will be more
sensible for pending people. And maybe wm4 might consider not to wait for others
to squeeze his concerns out of him.

I don't see any actions in bad faith. Let's go back to work everyone, please.

-Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.

[wm4]

On Mon, 28 Mar 2016 12:05:10 +0200 (CEST)
Marton Balint  wrote:

> On Mon, 28 Mar 2016, Hendrik Leppkes wrote:
> 
> > People that don't speak up at all may approve silently (or at least
> > not disapprove), someone that raised issues should give an explicit
> > OK/Nevermind/whatever, agreeing with you or withdrawing his
> > complaints, there is no "silent" option there.  
> 
> This seems unreasonable, beacuse this way a silent person can block a 
> patch forever, which is not optimal.
> 
> What I usually do is after a week of silence if I feel that I addressed 
> the concerns, or there is no known way to improve the patch, I send 
> one last ping explicitly stating that I will apply the patch soon. 
> (whithin 1-2 days). And if the silence remains, I apply it.
> 

In any case I agree that my behavior wasn't ideal. I was thinking more
along the lines that I didn't really care, but someone really should
have cared. I didn't want this issue to be overlooked at least.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.

[Hendrik Leppkes]

On Mon, Mar 28, 2016 at 12:05 PM, Marton Balint  wrote:
>
> On Mon, 28 Mar 2016, Hendrik Leppkes wrote:
>
>> People that don't speak up at all may approve silently (or at least
>> not disapprove), someone that raised issues should give an explicit
>> OK/Nevermind/whatever, agreeing with you or withdrawing his
>> complaints, there is no "silent" option there.
>
>
> This seems unreasonable, beacuse this way a silent person can block a patch
> forever, which is not optimal.
>
> What I usually do is after a week of silence if I feel that I addressed the
> concerns, or there is no known way to improve the patch, I send one last
> ping explicitly stating that I will apply the patch soon. (whithin 1-2
> days). And if the silence remains, I apply it.
>

If you send a mail explicitly stating that and the intention to move
forward if no further feedback arrives, then its usually fine. Didn't
happen here though.

 - Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.

[Marton Balint]

On Mon, 28 Mar 2016, Hendrik Leppkes wrote:


People that don't speak up at all may approve silently (or at least
not disapprove), someone that raised issues should give an explicit
OK/Nevermind/whatever, agreeing with you or withdrawing his
complaints, there is no "silent" option there.


This seems unreasonable, beacuse this way a silent person can block a 
patch forever, which is not optimal.


What I usually do is after a week of silence if I feel that I addressed 
the concerns, or there is no known way to improve the patch, I send 
one last ping explicitly stating that I will apply the patch soon. 
(whithin 1-2 days). And if the silence remains, I apply it.


Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.

[Hendrik Leppkes]

On Mon, Mar 28, 2016 at 12:10 AM, Thilo Borgmann  wrote:
> Am 26.03.16 um 01:49 schrieb Hendrik Leppkes:
>> On Sat, Mar 26, 2016 at 1:12 AM, Thilo Borgmann  
>> wrote:

 When you go from talking about a developers concerns to just pushing,
 then how else do you think someone should feel?
>>>
>>> You are again ignoring what I did and what I've written in the previous
>>> mails to explain what I did and why I did it.
>>> Basically you're just repeating that in your opinion I "just pushed". As
>>> long as you don't explain why you think that way with respect to what
>>> I've written there will be no progress in this discussion.
>>> That's a pity because we both are obviously thinking that this is an
>>> important topic. Unfortunately, I think I did what you demand - I pinged
>>> after there was a significant silence after the last review.
>>> It is on you to prove me wrong for convincing me that I made a mistake
>>> by pushing too early.
>>
>> None of the posts in this thread are a ping, all I see is back and
>> forth between two developers.
>> A ping would generally explictily ask for further feedback after a
>> time of silence, or anything like that, I don't see that here. For all
>> I knew, you were waiting for a response from wm4 on the last mail, it
>> was only a few days ago afterall.
>
> Yes there was a ping and obviously at least wm4 himself thinks so, too.
> Go ahead and tell me that wm4 replying to it a minute a minute later
> has happened by chance and not because of my ping.

Did you switch to private mails in the middle of the patch review?
Because I certainly see nothing of this sort.
There is two mails from wm4, one as a response to the original mail
with the initial concerns, and one days after one of your mails, no
response within minutes anywhere from him.

>
>
>> This way, it would be clear to everyone reading, and someone else
>> might comment, instead I was thinking wm4 gave criticism, and this
>> would be hashed out before its pushed, especially since the general
>> rule is that when a developer has an issue with a patch, it shouldn't
>> be pushed until he was convinced otherwise or the patch adjusted, if
>> appropriate.
>
> What is exactly what has happened. From my viewpoint at least. Obviously
> wm4 and you don't think that not replying anymore leads to silent
> approval - I do. This seems to be what we are talking about.

People that don't speak up at all may approve silently (or at least
not disapprove), someone that raised issues should give an explicit
OK/Nevermind/whatever, agreeing with you or withdrawing his
complaints, there is no "silent" option there.

You seem to assume a lot about your fellow developers, maybe we can
just agree that you'll be more explicit in the future and assume less
to know what others might mean or want?

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.

[Thilo Borgmann]

Am 26.03.16 um 01:49 schrieb Hendrik Leppkes:
> On Sat, Mar 26, 2016 at 1:12 AM, Thilo Borgmann  
> wrote:
>>>
>>> When you go from talking about a developers concerns to just pushing,
>>> then how else do you think someone should feel?
>>
>> You are again ignoring what I did and what I've written in the previous
>> mails to explain what I did and why I did it.
>> Basically you're just repeating that in your opinion I "just pushed". As
>> long as you don't explain why you think that way with respect to what
>> I've written there will be no progress in this discussion.
>> That's a pity because we both are obviously thinking that this is an
>> important topic. Unfortunately, I think I did what you demand - I pinged
>> after there was a significant silence after the last review.
>> It is on you to prove me wrong for convincing me that I made a mistake
>> by pushing too early.
> 
> None of the posts in this thread are a ping, all I see is back and
> forth between two developers.
> A ping would generally explictily ask for further feedback after a
> time of silence, or anything like that, I don't see that here. For all
> I knew, you were waiting for a response from wm4 on the last mail, it
> was only a few days ago afterall.

Yes there was a ping and obviously at least wm4 himself thinks so, too.
Go ahead and tell me that wm4 replying to it a minute a minute later
has happened by chance and not because of my ping.


> This way, it would be clear to everyone reading, and someone else
> might comment, instead I was thinking wm4 gave criticism, and this
> would be hashed out before its pushed, especially since the general
> rule is that when a developer has an issue with a patch, it shouldn't
> be pushed until he was convinced otherwise or the patch adjusted, if
> appropriate.

What is exactly what has happened. From my viewpoint at least. Obviously
wm4 and you don't think that not replying anymore leads to silent
approval - I do. This seems to be what we are talking about.

After wm4's first response, I answered with stating my motivation and
concerns about the alternatives that came to mind.
Then he was silent. This I would already call to be sorted out.
After my ping he basically repeated his statement and remained silent
again although I explicitly asked him for his suggestions this time.
This is what you call in the middle of discussion?

If we were actually sorting something out I would never have pushed
anything but that was just not the case. If that would have been the
case, don't you think there would already be a tremendous shitstorm
going down on me?


> This also doesn't answer the question that this patch was never
> excplicitly OK'ed.

From my point of view it was implicitly OK'ed after the last review of
patch 2 and ongoing silence after my ping.

-Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.

[Thilo Borgmann]

Am 27.03.16 um 15:53 schrieb wm4:
> On Sat, 26 Mar 2016 01:12:17 +0100
> Thilo Borgmann  wrote:
> 
>> Am 25.03.16 um 21:12 schrieb wm4:
>>> On Fri, 25 Mar 2016 19:41:40 +0100
>>> Thilo Borgmann  wrote:
>>>   
 Am 25.03.16 um 18:48 schrieb Hendrik Leppkes:  
> On Fri, Mar 25, 2016 at 6:26 PM, Thilo Borgmann  
> wrote:
>> Am 25.03.16 um 17:56 schrieb Hendrik Leppkes:
>>> On Fri, Mar 25, 2016 at 5:48 PM, Thilo Borgmann 
>>>  wrote:
 Am 22.03.16 um 12:20 schrieb Thilo Borgmann:
> Am 22.03.16 um 11:45 schrieb wm4:
>> On Sun, 13 Mar 2016 21:00:23 +0100
>> Thilo Borgmann  wrote:
>>
>>> Am 13.03.16 um 15:08 schrieb wm4:
 On Sat, 12 Mar 2016 15:13:21 +0100
 Thilo Borgmann  wrote:

> From a1d9ce388c69eabb256e6b351c2acd36d7f4076e Mon Sep 17 00:00:00 
> 2001
> From: Thilo Borgmann 
> Date: Sat, 12 Mar 2016 14:52:17 +0100
> Subject: [PATCH 1/2] lavu/dict: Add new flag to allow multiple 
> equal keys.
> [...]

 Changing the semantics of AVDictionary just like this seems rather
 questionable...
>>>
>>> It changes nothing for existing code, just adds a new feature. I 
>>> don't
>>> think it hurts anyone or anything...
>>
>> It only breaks basic assumptions about a basic data type...
>
> Although I don't share your thought about breaking a basic data type 
> with that,
> what would you suggest instead?

 Pushed for no further suggestions and nobody else objected.

>>>
>>> Just pushing without addressing concerns is not the way we usually try
>>> to work here, just saying.
>>
>> I think I have quite a good idea about the usual way we try to handle
>> things here and I think I've addressed his concerns.
>
> If by addressing you mean disagreeing with the concern and doing nothing. 
>

 Not at all. I proposed alternatives (alternatives which I don't like
 much but anyway) and I explicitly asked for his suggestions. Means, I
 actually tried to satisfy his concerns. Thus, I can't understand that
 you are saying I've ignored anything.

  
>> He didn't like it which is of course ok. He did not continue discussing
>> it nor did he proposed any alternative. He also did not pick up any of
>> my thoughts. He also did not explicitly state that he thinks that it is
>> not ok to apply it. He said it "seems rather questionable". Without
>> further discussion (what I tried) and nobody else complaining about it,
>> what do you think would be more appropriate than to wait for quite a
>> long time until continuing?
>>
>> The usual way for him to prevent me pushing it would just have been to
>> ask me to wait and I would have waited. Have you checked the dates of
>> the replies and what I wrote before accusing me to just ignore concerns?
>>
>
> Timing makes no difference. Its the only review you got, so even if
> you ignore that, you didn't even get a "OK" from anyone else, which
> for generic API should be mandatory.

 I can't see why you accuse me ignoring something again.

  
> The least that would have been appropriate would be to ping the patch
> asking for further comments, instead of just practically saying "I'm
> done waiting and just pushing"
>
> Not everyone has the time to answer within a day, so if someone
> expressed a concern, the least one could do before pushing is asking
> again, everything else feels rather disingenuous.

 First concern about this was stated on 13th.
 After my reply, there was silence for nine days.
 What would have been your assumption about his concerns after my reply?
 Mine was that he considers this not to be as critical enough for further
 discussion - means he might still dislike having multikey dictionaries
 but sees no reason in struggling about it.

 I pinged the patch again on 22nd, and it took about one minute for wm4
 to address his concerns again. However, after me asking for his
 suggestions there was again silence for days. Also note that he did not
 stated his concerns more specifically than before.

 So I waiting for around 12 days (including a ping) to get a more
 specific remark, counter-proposal, discussion or anything else than a
 basic concern. During that time wm4 was active and very well capable of
 immediate reply. Thus I assume that his attitude about this patch is not
 as 

Re: [FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.

[wm4]

On Sat, 26 Mar 2016 01:12:17 +0100
Thilo Borgmann  wrote:

> Am 25.03.16 um 21:12 schrieb wm4:
> > On Fri, 25 Mar 2016 19:41:40 +0100
> > Thilo Borgmann  wrote:
> >   
> >> Am 25.03.16 um 18:48 schrieb Hendrik Leppkes:  
> >>> On Fri, Mar 25, 2016 at 6:26 PM, Thilo Borgmann  
> >>> wrote:
>  Am 25.03.16 um 17:56 schrieb Hendrik Leppkes:
> > On Fri, Mar 25, 2016 at 5:48 PM, Thilo Borgmann 
> >  wrote:
> >> Am 22.03.16 um 12:20 schrieb Thilo Borgmann:
> >>> Am 22.03.16 um 11:45 schrieb wm4:
>  On Sun, 13 Mar 2016 21:00:23 +0100
>  Thilo Borgmann  wrote:
> 
> > Am 13.03.16 um 15:08 schrieb wm4:
> >> On Sat, 12 Mar 2016 15:13:21 +0100
> >> Thilo Borgmann  wrote:
> >>
> >>> From a1d9ce388c69eabb256e6b351c2acd36d7f4076e Mon Sep 17 00:00:00 
> >>> 2001
> >>> From: Thilo Borgmann 
> >>> Date: Sat, 12 Mar 2016 14:52:17 +0100
> >>> Subject: [PATCH 1/2] lavu/dict: Add new flag to allow multiple 
> >>> equal keys.
> >>> [...]
> >>
> >> Changing the semantics of AVDictionary just like this seems rather
> >> questionable...
> >
> > It changes nothing for existing code, just adds a new feature. I 
> > don't
> > think it hurts anyone or anything...
> 
>  It only breaks basic assumptions about a basic data type...
> >>>
> >>> Although I don't share your thought about breaking a basic data type 
> >>> with that,
> >>> what would you suggest instead?
> >>
> >> Pushed for no further suggestions and nobody else objected.
> >>
> >
> > Just pushing without addressing concerns is not the way we usually try
> > to work here, just saying.
> 
>  I think I have quite a good idea about the usual way we try to handle
>  things here and I think I've addressed his concerns.
> >>>
> >>> If by addressing you mean disagreeing with the concern and doing nothing. 
> >>>
> >>
> >> Not at all. I proposed alternatives (alternatives which I don't like
> >> much but anyway) and I explicitly asked for his suggestions. Means, I
> >> actually tried to satisfy his concerns. Thus, I can't understand that
> >> you are saying I've ignored anything.
> >>
> >>  
>  He didn't like it which is of course ok. He did not continue discussing
>  it nor did he proposed any alternative. He also did not pick up any of
>  my thoughts. He also did not explicitly state that he thinks that it is
>  not ok to apply it. He said it "seems rather questionable". Without
>  further discussion (what I tried) and nobody else complaining about it,
>  what do you think would be more appropriate than to wait for quite a
>  long time until continuing?
> 
>  The usual way for him to prevent me pushing it would just have been to
>  ask me to wait and I would have waited. Have you checked the dates of
>  the replies and what I wrote before accusing me to just ignore concerns?
> 
> >>>
> >>> Timing makes no difference. Its the only review you got, so even if
> >>> you ignore that, you didn't even get a "OK" from anyone else, which
> >>> for generic API should be mandatory.
> >>
> >> I can't see why you accuse me ignoring something again.
> >>
> >>  
> >>> The least that would have been appropriate would be to ping the patch
> >>> asking for further comments, instead of just practically saying "I'm
> >>> done waiting and just pushing"
> >>>
> >>> Not everyone has the time to answer within a day, so if someone
> >>> expressed a concern, the least one could do before pushing is asking
> >>> again, everything else feels rather disingenuous.
> >>
> >> First concern about this was stated on 13th.
> >> After my reply, there was silence for nine days.
> >> What would have been your assumption about his concerns after my reply?
> >> Mine was that he considers this not to be as critical enough for further
> >> discussion - means he might still dislike having multikey dictionaries
> >> but sees no reason in struggling about it.
> >>
> >> I pinged the patch again on 22nd, and it took about one minute for wm4
> >> to address his concerns again. However, after me asking for his
> >> suggestions there was again silence for days. Also note that he did not
> >> stated his concerns more specifically than before.
> >>
> >> So I waiting for around 12 days (including a ping) to get a more
> >> specific remark, counter-proposal, discussion or anything else than a
> >> basic concern. During that time wm4 was active and very well capable of
> >> immediate reply. Thus I assume that his attitude about this patch is not
> >> as bad as insisting not to apply.
> >>
> >> I 

Re: [FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.

[Hendrik Leppkes]

On Sat, Mar 26, 2016 at 1:12 AM, Thilo Borgmann  wrote:
>>
>> When you go from talking about a developers concerns to just pushing,
>> then how else do you think someone should feel?
>
> You are again ignoring what I did and what I've written in the previous
> mails to explain what I did and why I did it.
> Basically you're just repeating that in your opinion I "just pushed". As
> long as you don't explain why you think that way with respect to what
> I've written there will be no progress in this discussion.
> That's a pity because we both are obviously thinking that this is an
> important topic. Unfortunately, I think I did what you demand - I pinged
> after there was a significant silence after the last review.
> It is on you to prove me wrong for convincing me that I made a mistake
> by pushing too early.

None of the posts in this thread are a ping, all I see is back and
forth between two developers.
A ping would generally explictily ask for further feedback after a
time of silence, or anything like that, I don't see that here. For all
I knew, you were waiting for a response from wm4 on the last mail, it
was only a few days ago afterall.

This way, it would be clear to everyone reading, and someone else
might comment, instead I was thinking wm4 gave criticism, and this
would be hashed out before its pushed, especially since the general
rule is that when a developer has an issue with a patch, it shouldn't
be pushed until he was convinced otherwise or the patch adjusted, if
appropriate.

This also doesn't answer the question that this patch was never
excplicitly OK'ed.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.

[Thilo Borgmann]

Am 25.03.16 um 21:59 schrieb Hendrik Leppkes:
> On Fri, Mar 25, 2016 at 7:41 PM, Thilo Borgmann  
> wrote:
>> Am 25.03.16 um 18:48 schrieb Hendrik Leppkes:
>>> On Fri, Mar 25, 2016 at 6:26 PM, Thilo Borgmann  
>>> wrote:
 Am 25.03.16 um 17:56 schrieb Hendrik Leppkes:
> On Fri, Mar 25, 2016 at 5:48 PM, Thilo Borgmann  
> wrote:
>> Am 22.03.16 um 12:20 schrieb Thilo Borgmann:
>>> Am 22.03.16 um 11:45 schrieb wm4:
 On Sun, 13 Mar 2016 21:00:23 +0100
 Thilo Borgmann  wrote:

> Am 13.03.16 um 15:08 schrieb wm4:
>> On Sat, 12 Mar 2016 15:13:21 +0100
>> Thilo Borgmann  wrote:
>>
>>> From a1d9ce388c69eabb256e6b351c2acd36d7f4076e Mon Sep 17 00:00:00 
>>> 2001
>>> From: Thilo Borgmann 
>>> Date: Sat, 12 Mar 2016 14:52:17 +0100
>>> Subject: [PATCH 1/2] lavu/dict: Add new flag to allow multiple 
>>> equal keys.
>>> [...]
>>
>> Changing the semantics of AVDictionary just like this seems rather
>> questionable...
>
> It changes nothing for existing code, just adds a new feature. I don't
> think it hurts anyone or anything...

 It only breaks basic assumptions about a basic data type...
>>>
>>> Although I don't share your thought about breaking a basic data type 
>>> with that,
>>> what would you suggest instead?
>>
>> Pushed for no further suggestions and nobody else objected.
>>
>
> Just pushing without addressing concerns is not the way we usually try
> to work here, just saying.

 I think I have quite a good idea about the usual way we try to handle
 things here and I think I've addressed his concerns.
>>>
>>> If by addressing you mean disagreeing with the concern and doing nothing.
>>
>> Not at all. I proposed alternatives (alternatives which I don't like
>> much but anyway) and I explicitly asked for his suggestions. Means, I
>> actually tried to satisfy his concerns. Thus, I can't understand that
>> you are saying I've ignored anything.
>>
>>
 He didn't like it which is of course ok. He did not continue discussing
 it nor did he proposed any alternative. He also did not pick up any of
 my thoughts. He also did not explicitly state that he thinks that it is
 not ok to apply it. He said it "seems rather questionable". Without
 further discussion (what I tried) and nobody else complaining about it,
 what do you think would be more appropriate than to wait for quite a
 long time until continuing?

 The usual way for him to prevent me pushing it would just have been to
 ask me to wait and I would have waited. Have you checked the dates of
 the replies and what I wrote before accusing me to just ignore concerns?

>>>
>>> Timing makes no difference. Its the only review you got, so even if
>>> you ignore that, you didn't even get a "OK" from anyone else, which
>>> for generic API should be mandatory.
>>
>> I can't see why you accuse me ignoring something again.
> 
> I didn't, I just stated that noone ever OKed your patch.
> 
>>
>>
>>> The least that would have been appropriate would be to ping the patch
>>> asking for further comments, instead of just practically saying "I'm
>>> done waiting and just pushing"
>>>
>>> Not everyone has the time to answer within a day, so if someone
>>> expressed a concern, the least one could do before pushing is asking
>>> again, everything else feels rather disingenuous.
>>
>> First concern about this was stated on 13th.
>> After my reply, there was silence for nine days.
>> What would have been your assumption about his concerns after my reply?
>> Mine was that he considers this not to be as critical enough for further
>> discussion - means he might still dislike having multikey dictionaries
>> but sees no reason in struggling about it.
> 
> I wouldn't make assumptions, I would explicitly ask.

Sorry I missed that in my previous answer.

I asked: "Although I don't share your thought about breaking a basic
data type with that, what would you suggest instead?"

Maybe this is not explicit enough. Maybe silence form wm4 on that
question was not explicit enough.

-Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.

[Thilo Borgmann]

Am 25.03.16 um 21:59 schrieb Hendrik Leppkes:
> On Fri, Mar 25, 2016 at 7:41 PM, Thilo Borgmann  
> wrote:
>> Am 25.03.16 um 18:48 schrieb Hendrik Leppkes:
>>> On Fri, Mar 25, 2016 at 6:26 PM, Thilo Borgmann  
>>> wrote:
 Am 25.03.16 um 17:56 schrieb Hendrik Leppkes:
> On Fri, Mar 25, 2016 at 5:48 PM, Thilo Borgmann  
> wrote:
>> Am 22.03.16 um 12:20 schrieb Thilo Borgmann:
>>> Am 22.03.16 um 11:45 schrieb wm4:
 On Sun, 13 Mar 2016 21:00:23 +0100
 Thilo Borgmann  wrote:

> Am 13.03.16 um 15:08 schrieb wm4:
>> On Sat, 12 Mar 2016 15:13:21 +0100
>> Thilo Borgmann  wrote:
>>
>>> From a1d9ce388c69eabb256e6b351c2acd36d7f4076e Mon Sep 17 00:00:00 
>>> 2001
>>> From: Thilo Borgmann 
>>> Date: Sat, 12 Mar 2016 14:52:17 +0100
>>> Subject: [PATCH 1/2] lavu/dict: Add new flag to allow multiple 
>>> equal keys.
>>> [...]
>>
>> Changing the semantics of AVDictionary just like this seems rather
>> questionable...
>
> It changes nothing for existing code, just adds a new feature. I don't
> think it hurts anyone or anything...

 It only breaks basic assumptions about a basic data type...
>>>
>>> Although I don't share your thought about breaking a basic data type 
>>> with that,
>>> what would you suggest instead?
>>
>> Pushed for no further suggestions and nobody else objected.
>>
>
> Just pushing without addressing concerns is not the way we usually try
> to work here, just saying.

 I think I have quite a good idea about the usual way we try to handle
 things here and I think I've addressed his concerns.
>>>
>>> If by addressing you mean disagreeing with the concern and doing nothing.
>>
>> Not at all. I proposed alternatives (alternatives which I don't like
>> much but anyway) and I explicitly asked for his suggestions. Means, I
>> actually tried to satisfy his concerns. Thus, I can't understand that
>> you are saying I've ignored anything.
>>
>>
 He didn't like it which is of course ok. He did not continue discussing
 it nor did he proposed any alternative. He also did not pick up any of
 my thoughts. He also did not explicitly state that he thinks that it is
 not ok to apply it. He said it "seems rather questionable". Without
 further discussion (what I tried) and nobody else complaining about it,
 what do you think would be more appropriate than to wait for quite a
 long time until continuing?

 The usual way for him to prevent me pushing it would just have been to
 ask me to wait and I would have waited. Have you checked the dates of
 the replies and what I wrote before accusing me to just ignore concerns?

>>>
>>> Timing makes no difference. Its the only review you got, so even if
>>> you ignore that, you didn't even get a "OK" from anyone else, which
>>> for generic API should be mandatory.
>>
>> I can't see why you accuse me ignoring something again.
> 
> I didn't, I just stated that noone ever OKed your patch.
> 
>>
>>
>>> The least that would have been appropriate would be to ping the patch
>>> asking for further comments, instead of just practically saying "I'm
>>> done waiting and just pushing"
>>>
>>> Not everyone has the time to answer within a day, so if someone
>>> expressed a concern, the least one could do before pushing is asking
>>> again, everything else feels rather disingenuous.
>>
>> First concern about this was stated on 13th.
>> After my reply, there was silence for nine days.
>> What would have been your assumption about his concerns after my reply?
>> Mine was that he considers this not to be as critical enough for further
>> discussion - means he might still dislike having multikey dictionaries
>> but sees no reason in struggling about it.
> 
> I wouldn't make assumptions, I would explicitly ask.
> 
>>
>> I pinged the patch again on 22nd, and it took about one minute for wm4
>> to address his concerns again. However, after me asking for his
>> suggestions there was again silence for days. Also note that he did not
>> stated his concerns more specifically than before.
>>
>> So I waiting for around 12 days (including a ping) to get a more
>> specific remark, counter-proposal, discussion or anything else than a
>> basic concern. During that time wm4 was active and very well capable of
>> immediate reply. Thus I assume that his attitude about this patch is not
>> as bad as insisting not to apply.
>>
>> I still really can't see a "I'm done waiting and just pushing" attitude
>> from my side.
>>
> 
> When you go from talking about a developers concerns to just pushing,
> then how else do you think someone should feel?

You are again ignoring what I did and what 

Re: [FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.

[Thilo Borgmann]

Am 25.03.16 um 21:12 schrieb wm4:
> On Fri, 25 Mar 2016 19:41:40 +0100
> Thilo Borgmann  wrote:
> 
>> Am 25.03.16 um 18:48 schrieb Hendrik Leppkes:
>>> On Fri, Mar 25, 2016 at 6:26 PM, Thilo Borgmann  
>>> wrote:  
 Am 25.03.16 um 17:56 schrieb Hendrik Leppkes:  
> On Fri, Mar 25, 2016 at 5:48 PM, Thilo Borgmann  
> wrote:  
>> Am 22.03.16 um 12:20 schrieb Thilo Borgmann:  
>>> Am 22.03.16 um 11:45 schrieb wm4:  
 On Sun, 13 Mar 2016 21:00:23 +0100
 Thilo Borgmann  wrote:
  
> Am 13.03.16 um 15:08 schrieb wm4:  
>> On Sat, 12 Mar 2016 15:13:21 +0100
>> Thilo Borgmann  wrote:
>>  
>>> From a1d9ce388c69eabb256e6b351c2acd36d7f4076e Mon Sep 17 00:00:00 
>>> 2001
>>> From: Thilo Borgmann 
>>> Date: Sat, 12 Mar 2016 14:52:17 +0100
>>> Subject: [PATCH 1/2] lavu/dict: Add new flag to allow multiple 
>>> equal keys.
>>> [...]  
>>
>> Changing the semantics of AVDictionary just like this seems rather
>> questionable...  
>
> It changes nothing for existing code, just adds a new feature. I don't
> think it hurts anyone or anything...  

 It only breaks basic assumptions about a basic data type...  
>>>
>>> Although I don't share your thought about breaking a basic data type 
>>> with that,
>>> what would you suggest instead?  
>>
>> Pushed for no further suggestions and nobody else objected.
>>  
>
> Just pushing without addressing concerns is not the way we usually try
> to work here, just saying.  

 I think I have quite a good idea about the usual way we try to handle
 things here and I think I've addressed his concerns.  
>>>
>>> If by addressing you mean disagreeing with the concern and doing nothing.  
>>
>> Not at all. I proposed alternatives (alternatives which I don't like
>> much but anyway) and I explicitly asked for his suggestions. Means, I
>> actually tried to satisfy his concerns. Thus, I can't understand that
>> you are saying I've ignored anything.
>>
>>
 He didn't like it which is of course ok. He did not continue discussing
 it nor did he proposed any alternative. He also did not pick up any of
 my thoughts. He also did not explicitly state that he thinks that it is
 not ok to apply it. He said it "seems rather questionable". Without
 further discussion (what I tried) and nobody else complaining about it,
 what do you think would be more appropriate than to wait for quite a
 long time until continuing?

 The usual way for him to prevent me pushing it would just have been to
 ask me to wait and I would have waited. Have you checked the dates of
 the replies and what I wrote before accusing me to just ignore concerns?
  
>>>
>>> Timing makes no difference. Its the only review you got, so even if
>>> you ignore that, you didn't even get a "OK" from anyone else, which
>>> for generic API should be mandatory.  
>>
>> I can't see why you accuse me ignoring something again.
>>
>>
>>> The least that would have been appropriate would be to ping the patch
>>> asking for further comments, instead of just practically saying "I'm
>>> done waiting and just pushing"
>>>
>>> Not everyone has the time to answer within a day, so if someone
>>> expressed a concern, the least one could do before pushing is asking
>>> again, everything else feels rather disingenuous.  
>>
>> First concern about this was stated on 13th.
>> After my reply, there was silence for nine days.
>> What would have been your assumption about his concerns after my reply?
>> Mine was that he considers this not to be as critical enough for further
>> discussion - means he might still dislike having multikey dictionaries
>> but sees no reason in struggling about it.
>>
>> I pinged the patch again on 22nd, and it took about one minute for wm4
>> to address his concerns again. However, after me asking for his
>> suggestions there was again silence for days. Also note that he did not
>> stated his concerns more specifically than before.
>>
>> So I waiting for around 12 days (including a ping) to get a more
>> specific remark, counter-proposal, discussion or anything else than a
>> basic concern. During that time wm4 was active and very well capable of
>> immediate reply. Thus I assume that his attitude about this patch is not
>> as bad as insisting not to apply.
>>
>> I still really can't see a "I'm done waiting and just pushing" attitude
>> from my side.
> 
> You were adding weird new public API just to internally parse some
> really weird syntax. I hoped other would voice their concern too, but
> nobody did, so who cares, I guess.

Which means my assumption about your attitude to this patch was not
totally wrong. Also 

Re: [FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.

[Hendrik Leppkes]

On Fri, Mar 25, 2016 at 7:41 PM, Thilo Borgmann  wrote:
> Am 25.03.16 um 18:48 schrieb Hendrik Leppkes:
>> On Fri, Mar 25, 2016 at 6:26 PM, Thilo Borgmann  
>> wrote:
>>> Am 25.03.16 um 17:56 schrieb Hendrik Leppkes:
 On Fri, Mar 25, 2016 at 5:48 PM, Thilo Borgmann  
 wrote:
> Am 22.03.16 um 12:20 schrieb Thilo Borgmann:
>> Am 22.03.16 um 11:45 schrieb wm4:
>>> On Sun, 13 Mar 2016 21:00:23 +0100
>>> Thilo Borgmann  wrote:
>>>
 Am 13.03.16 um 15:08 schrieb wm4:
> On Sat, 12 Mar 2016 15:13:21 +0100
> Thilo Borgmann  wrote:
>
>> From a1d9ce388c69eabb256e6b351c2acd36d7f4076e Mon Sep 17 00:00:00 
>> 2001
>> From: Thilo Borgmann 
>> Date: Sat, 12 Mar 2016 14:52:17 +0100
>> Subject: [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal 
>> keys.
>> [...]
>
> Changing the semantics of AVDictionary just like this seems rather
> questionable...

 It changes nothing for existing code, just adds a new feature. I don't
 think it hurts anyone or anything...
>>>
>>> It only breaks basic assumptions about a basic data type...
>>
>> Although I don't share your thought about breaking a basic data type 
>> with that,
>> what would you suggest instead?
>
> Pushed for no further suggestions and nobody else objected.
>

 Just pushing without addressing concerns is not the way we usually try
 to work here, just saying.
>>>
>>> I think I have quite a good idea about the usual way we try to handle
>>> things here and I think I've addressed his concerns.
>>
>> If by addressing you mean disagreeing with the concern and doing nothing.
>
> Not at all. I proposed alternatives (alternatives which I don't like
> much but anyway) and I explicitly asked for his suggestions. Means, I
> actually tried to satisfy his concerns. Thus, I can't understand that
> you are saying I've ignored anything.
>
>
>>> He didn't like it which is of course ok. He did not continue discussing
>>> it nor did he proposed any alternative. He also did not pick up any of
>>> my thoughts. He also did not explicitly state that he thinks that it is
>>> not ok to apply it. He said it "seems rather questionable". Without
>>> further discussion (what I tried) and nobody else complaining about it,
>>> what do you think would be more appropriate than to wait for quite a
>>> long time until continuing?
>>>
>>> The usual way for him to prevent me pushing it would just have been to
>>> ask me to wait and I would have waited. Have you checked the dates of
>>> the replies and what I wrote before accusing me to just ignore concerns?
>>>
>>
>> Timing makes no difference. Its the only review you got, so even if
>> you ignore that, you didn't even get a "OK" from anyone else, which
>> for generic API should be mandatory.
>
> I can't see why you accuse me ignoring something again.

I didn't, I just stated that noone ever OKed your patch.

>
>
>> The least that would have been appropriate would be to ping the patch
>> asking for further comments, instead of just practically saying "I'm
>> done waiting and just pushing"
>>
>> Not everyone has the time to answer within a day, so if someone
>> expressed a concern, the least one could do before pushing is asking
>> again, everything else feels rather disingenuous.
>
> First concern about this was stated on 13th.
> After my reply, there was silence for nine days.
> What would have been your assumption about his concerns after my reply?
> Mine was that he considers this not to be as critical enough for further
> discussion - means he might still dislike having multikey dictionaries
> but sees no reason in struggling about it.

I wouldn't make assumptions, I would explicitly ask.

>
> I pinged the patch again on 22nd, and it took about one minute for wm4
> to address his concerns again. However, after me asking for his
> suggestions there was again silence for days. Also note that he did not
> stated his concerns more specifically than before.
>
> So I waiting for around 12 days (including a ping) to get a more
> specific remark, counter-proposal, discussion or anything else than a
> basic concern. During that time wm4 was active and very well capable of
> immediate reply. Thus I assume that his attitude about this patch is not
> as bad as insisting not to apply.
>
> I still really can't see a "I'm done waiting and just pushing" attitude
> from my side.
>

When you go from talking about a developers concerns to just pushing,
then how else do you think someone should feel?
Timing is your only reason to push today, you even explain yourself by
quoting dates and everything, so how can I see it as anything else?

- Hendrik
___
ffmpeg-devel 

Re: [FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.

[wm4]

On Fri, 25 Mar 2016 19:41:40 +0100
Thilo Borgmann  wrote:

> Am 25.03.16 um 18:48 schrieb Hendrik Leppkes:
> > On Fri, Mar 25, 2016 at 6:26 PM, Thilo Borgmann  
> > wrote:  
> >> Am 25.03.16 um 17:56 schrieb Hendrik Leppkes:  
> >>> On Fri, Mar 25, 2016 at 5:48 PM, Thilo Borgmann  
> >>> wrote:  
>  Am 22.03.16 um 12:20 schrieb Thilo Borgmann:  
> > Am 22.03.16 um 11:45 schrieb wm4:  
> >> On Sun, 13 Mar 2016 21:00:23 +0100
> >> Thilo Borgmann  wrote:
> >>  
> >>> Am 13.03.16 um 15:08 schrieb wm4:  
>  On Sat, 12 Mar 2016 15:13:21 +0100
>  Thilo Borgmann  wrote:
>   
> > From a1d9ce388c69eabb256e6b351c2acd36d7f4076e Mon Sep 17 00:00:00 
> > 2001
> > From: Thilo Borgmann 
> > Date: Sat, 12 Mar 2016 14:52:17 +0100
> > Subject: [PATCH 1/2] lavu/dict: Add new flag to allow multiple 
> > equal keys.
> > [...]  
> 
>  Changing the semantics of AVDictionary just like this seems rather
>  questionable...  
> >>>
> >>> It changes nothing for existing code, just adds a new feature. I don't
> >>> think it hurts anyone or anything...  
> >>
> >> It only breaks basic assumptions about a basic data type...  
> >
> > Although I don't share your thought about breaking a basic data type 
> > with that,
> > what would you suggest instead?  
> 
>  Pushed for no further suggestions and nobody else objected.
>   
> >>>
> >>> Just pushing without addressing concerns is not the way we usually try
> >>> to work here, just saying.  
> >>
> >> I think I have quite a good idea about the usual way we try to handle
> >> things here and I think I've addressed his concerns.  
> > 
> > If by addressing you mean disagreeing with the concern and doing nothing.  
> 
> Not at all. I proposed alternatives (alternatives which I don't like
> much but anyway) and I explicitly asked for his suggestions. Means, I
> actually tried to satisfy his concerns. Thus, I can't understand that
> you are saying I've ignored anything.
> 
> 
> >> He didn't like it which is of course ok. He did not continue discussing
> >> it nor did he proposed any alternative. He also did not pick up any of
> >> my thoughts. He also did not explicitly state that he thinks that it is
> >> not ok to apply it. He said it "seems rather questionable". Without
> >> further discussion (what I tried) and nobody else complaining about it,
> >> what do you think would be more appropriate than to wait for quite a
> >> long time until continuing?
> >>
> >> The usual way for him to prevent me pushing it would just have been to
> >> ask me to wait and I would have waited. Have you checked the dates of
> >> the replies and what I wrote before accusing me to just ignore concerns?
> >>  
> > 
> > Timing makes no difference. Its the only review you got, so even if
> > you ignore that, you didn't even get a "OK" from anyone else, which
> > for generic API should be mandatory.  
> 
> I can't see why you accuse me ignoring something again.
> 
> 
> > The least that would have been appropriate would be to ping the patch
> > asking for further comments, instead of just practically saying "I'm
> > done waiting and just pushing"
> > 
> > Not everyone has the time to answer within a day, so if someone
> > expressed a concern, the least one could do before pushing is asking
> > again, everything else feels rather disingenuous.  
> 
> First concern about this was stated on 13th.
> After my reply, there was silence for nine days.
> What would have been your assumption about his concerns after my reply?
> Mine was that he considers this not to be as critical enough for further
> discussion - means he might still dislike having multikey dictionaries
> but sees no reason in struggling about it.
> 
> I pinged the patch again on 22nd, and it took about one minute for wm4
> to address his concerns again. However, after me asking for his
> suggestions there was again silence for days. Also note that he did not
> stated his concerns more specifically than before.
> 
> So I waiting for around 12 days (including a ping) to get a more
> specific remark, counter-proposal, discussion or anything else than a
> basic concern. During that time wm4 was active and very well capable of
> immediate reply. Thus I assume that his attitude about this patch is not
> as bad as insisting not to apply.
> 
> I still really can't see a "I'm done waiting and just pushing" attitude
> from my side.

You were adding weird new public API just to internally parse some
really weird syntax. I hoped other would voice their concern too, but
nobody did, so who cares, I guess.

I guess I'm ok with this, because it means I can easily get in my own
low quality changes as well.
___

Re: [FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.

[Thilo Borgmann]

Am 25.03.16 um 18:48 schrieb Hendrik Leppkes:
> On Fri, Mar 25, 2016 at 6:26 PM, Thilo Borgmann  
> wrote:
>> Am 25.03.16 um 17:56 schrieb Hendrik Leppkes:
>>> On Fri, Mar 25, 2016 at 5:48 PM, Thilo Borgmann  
>>> wrote:
 Am 22.03.16 um 12:20 schrieb Thilo Borgmann:
> Am 22.03.16 um 11:45 schrieb wm4:
>> On Sun, 13 Mar 2016 21:00:23 +0100
>> Thilo Borgmann  wrote:
>>
>>> Am 13.03.16 um 15:08 schrieb wm4:
 On Sat, 12 Mar 2016 15:13:21 +0100
 Thilo Borgmann  wrote:

> From a1d9ce388c69eabb256e6b351c2acd36d7f4076e Mon Sep 17 00:00:00 2001
> From: Thilo Borgmann 
> Date: Sat, 12 Mar 2016 14:52:17 +0100
> Subject: [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal 
> keys.
> [...]

 Changing the semantics of AVDictionary just like this seems rather
 questionable...
>>>
>>> It changes nothing for existing code, just adds a new feature. I don't
>>> think it hurts anyone or anything...
>>
>> It only breaks basic assumptions about a basic data type...
>
> Although I don't share your thought about breaking a basic data type with 
> that,
> what would you suggest instead?

 Pushed for no further suggestions and nobody else objected.

>>>
>>> Just pushing without addressing concerns is not the way we usually try
>>> to work here, just saying.
>>
>> I think I have quite a good idea about the usual way we try to handle
>> things here and I think I've addressed his concerns.
> 
> If by addressing you mean disagreeing with the concern and doing nothing.

Not at all. I proposed alternatives (alternatives which I don't like
much but anyway) and I explicitly asked for his suggestions. Means, I
actually tried to satisfy his concerns. Thus, I can't understand that
you are saying I've ignored anything.


>> He didn't like it which is of course ok. He did not continue discussing
>> it nor did he proposed any alternative. He also did not pick up any of
>> my thoughts. He also did not explicitly state that he thinks that it is
>> not ok to apply it. He said it "seems rather questionable". Without
>> further discussion (what I tried) and nobody else complaining about it,
>> what do you think would be more appropriate than to wait for quite a
>> long time until continuing?
>>
>> The usual way for him to prevent me pushing it would just have been to
>> ask me to wait and I would have waited. Have you checked the dates of
>> the replies and what I wrote before accusing me to just ignore concerns?
>>
> 
> Timing makes no difference. Its the only review you got, so even if
> you ignore that, you didn't even get a "OK" from anyone else, which
> for generic API should be mandatory.

I can't see why you accuse me ignoring something again.


> The least that would have been appropriate would be to ping the patch
> asking for further comments, instead of just practically saying "I'm
> done waiting and just pushing"
> 
> Not everyone has the time to answer within a day, so if someone
> expressed a concern, the least one could do before pushing is asking
> again, everything else feels rather disingenuous.

First concern about this was stated on 13th.
After my reply, there was silence for nine days.
What would have been your assumption about his concerns after my reply?
Mine was that he considers this not to be as critical enough for further
discussion - means he might still dislike having multikey dictionaries
but sees no reason in struggling about it.

I pinged the patch again on 22nd, and it took about one minute for wm4
to address his concerns again. However, after me asking for his
suggestions there was again silence for days. Also note that he did not
stated his concerns more specifically than before.

So I waiting for around 12 days (including a ping) to get a more
specific remark, counter-proposal, discussion or anything else than a
basic concern. During that time wm4 was active and very well capable of
immediate reply. Thus I assume that his attitude about this patch is not
as bad as insisting not to apply.

I still really can't see a "I'm done waiting and just pushing" attitude
from my side.

-Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.

[Hendrik Leppkes]

On Fri, Mar 25, 2016 at 6:26 PM, Thilo Borgmann  wrote:
> Am 25.03.16 um 17:56 schrieb Hendrik Leppkes:
>> On Fri, Mar 25, 2016 at 5:48 PM, Thilo Borgmann  
>> wrote:
>>> Am 22.03.16 um 12:20 schrieb Thilo Borgmann:
 Am 22.03.16 um 11:45 schrieb wm4:
> On Sun, 13 Mar 2016 21:00:23 +0100
> Thilo Borgmann  wrote:
>
>> Am 13.03.16 um 15:08 schrieb wm4:
>>> On Sat, 12 Mar 2016 15:13:21 +0100
>>> Thilo Borgmann  wrote:
>>>
 From a1d9ce388c69eabb256e6b351c2acd36d7f4076e Mon Sep 17 00:00:00 2001
 From: Thilo Borgmann 
 Date: Sat, 12 Mar 2016 14:52:17 +0100
 Subject: [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal 
 keys.

 ---
  libavutil/dict.c | 5 -
  libavutil/dict.h | 5 +++--
  2 files changed, 7 insertions(+), 3 deletions(-)

 diff --git a/libavutil/dict.c b/libavutil/dict.c
 index 8bb65a1..70c0184 100644
 --- a/libavutil/dict.c
 +++ b/libavutil/dict.c
 @@ -70,9 +70,12 @@ int av_dict_set(AVDictionary **pm, const char *key, 
 const char *value,
  int flags)
  {
  AVDictionary *m = *pm;
 -AVDictionaryEntry *tag = av_dict_get(m, key, NULL, flags);
 +AVDictionaryEntry *tag = NULL;
  char *oldval = NULL, *copy_key = NULL, *copy_value = NULL;

 +if (!(flags & AV_DICT_MULTIKEY)) {
 +tag = av_dict_get(m, key, NULL, flags);
 +}
  if (flags & AV_DICT_DONT_STRDUP_KEY)
  copy_key = (void *)key;
  else
 diff --git a/libavutil/dict.h b/libavutil/dict.h
 index b0aa784..c589bcd 100644
 --- a/libavutil/dict.h
 +++ b/libavutil/dict.h
 @@ -76,6 +76,7 @@
  #define AV_DICT_DONT_OVERWRITE 16   ///< Don't overwrite existing 
 entries.
  #define AV_DICT_APPEND 32   /**< If the entry already exists, 
 append to it.  Note that no
delimiter is added, the strings 
 are simply concatenated. */
 +#define AV_DICT_MULTIKEY   64   /**< Allow to store several equal 
 keys in the dictionary */

  typedef struct AVDictionaryEntry {
  char *key;
 @@ -118,8 +119,8 @@ int av_dict_count(const AVDictionary *m);
   *
   * @param pm pointer to a pointer to a dictionary struct. If *pm is 
 NULL
   * a dictionary struct is allocated and put in *pm.
 - * @param key entry key to add to *pm (will be av_strduped depending 
 on flags)
 - * @param value entry value to add to *pm (will be av_strduped 
 depending on flags).
 + * @param key entry key to add to *pm (will either be av_strduped or 
 added as a new key depending on flags)
 + * @param value entry value to add to *pm (will be av_strduped or 
 added as a new key depending on flags).
   *Passing a NULL value will cause an existing entry to be 
 deleted.
   * @return >= 0 on success otherwise an error code <0
   */
>>>
>>> Changing the semantics of AVDictionary just like this seems rather
>>> questionable...
>>
>> It changes nothing for existing code, just adds a new feature. I don't
>> think it hurts anyone or anything...
>
> It only breaks basic assumptions about a basic data type...

 Although I don't share your thought about breaking a basic data type with 
 that,
 what would you suggest instead?
>>>
>>> Pushed for no further suggestions and nobody else objected.
>>>
>>
>> Just pushing without addressing concerns is not the way we usually try
>> to work here, just saying.
>
> I think I have quite a good idea about the usual way we try to handle
> things here and I think I've addressed his concerns.

If by addressing you mean disagreeing with the concern and doing nothing.

>
> He didn't like it which is of course ok. He did not continue discussing
> it nor did he proposed any alternative. He also did not pick up any of
> my thoughts. He also did not explicitly state that he thinks that it is
> not ok to apply it. He said it "seems rather questionable". Without
> further discussion (what I tried) and nobody else complaining about it,
> what do you think would be more appropriate than to wait for quite a
> long time until continuing?
>
> The usual way for him to prevent me pushing it would just have been to
> ask me to wait and I would have waited. Have you checked the dates of
> the replies and what I wrote before accusing me to just ignore concerns?
>

Timing makes no difference. Its the only review you got, so even if
you ignore that, you didn't even get a "OK" from 

Re: [FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.

[Thilo Borgmann]

Am 25.03.16 um 17:56 schrieb Hendrik Leppkes:
> On Fri, Mar 25, 2016 at 5:48 PM, Thilo Borgmann  
> wrote:
>> Am 22.03.16 um 12:20 schrieb Thilo Borgmann:
>>> Am 22.03.16 um 11:45 schrieb wm4:
 On Sun, 13 Mar 2016 21:00:23 +0100
 Thilo Borgmann  wrote:

> Am 13.03.16 um 15:08 schrieb wm4:
>> On Sat, 12 Mar 2016 15:13:21 +0100
>> Thilo Borgmann  wrote:
>>
>>> From a1d9ce388c69eabb256e6b351c2acd36d7f4076e Mon Sep 17 00:00:00 2001
>>> From: Thilo Borgmann 
>>> Date: Sat, 12 Mar 2016 14:52:17 +0100
>>> Subject: [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal 
>>> keys.
>>>
>>> ---
>>>  libavutil/dict.c | 5 -
>>>  libavutil/dict.h | 5 +++--
>>>  2 files changed, 7 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/libavutil/dict.c b/libavutil/dict.c
>>> index 8bb65a1..70c0184 100644
>>> --- a/libavutil/dict.c
>>> +++ b/libavutil/dict.c
>>> @@ -70,9 +70,12 @@ int av_dict_set(AVDictionary **pm, const char *key, 
>>> const char *value,
>>>  int flags)
>>>  {
>>>  AVDictionary *m = *pm;
>>> -AVDictionaryEntry *tag = av_dict_get(m, key, NULL, flags);
>>> +AVDictionaryEntry *tag = NULL;
>>>  char *oldval = NULL, *copy_key = NULL, *copy_value = NULL;
>>>
>>> +if (!(flags & AV_DICT_MULTIKEY)) {
>>> +tag = av_dict_get(m, key, NULL, flags);
>>> +}
>>>  if (flags & AV_DICT_DONT_STRDUP_KEY)
>>>  copy_key = (void *)key;
>>>  else
>>> diff --git a/libavutil/dict.h b/libavutil/dict.h
>>> index b0aa784..c589bcd 100644
>>> --- a/libavutil/dict.h
>>> +++ b/libavutil/dict.h
>>> @@ -76,6 +76,7 @@
>>>  #define AV_DICT_DONT_OVERWRITE 16   ///< Don't overwrite existing 
>>> entries.
>>>  #define AV_DICT_APPEND 32   /**< If the entry already exists, 
>>> append to it.  Note that no
>>>delimiter is added, the strings 
>>> are simply concatenated. */
>>> +#define AV_DICT_MULTIKEY   64   /**< Allow to store several equal 
>>> keys in the dictionary */
>>>
>>>  typedef struct AVDictionaryEntry {
>>>  char *key;
>>> @@ -118,8 +119,8 @@ int av_dict_count(const AVDictionary *m);
>>>   *
>>>   * @param pm pointer to a pointer to a dictionary struct. If *pm is 
>>> NULL
>>>   * a dictionary struct is allocated and put in *pm.
>>> - * @param key entry key to add to *pm (will be av_strduped depending 
>>> on flags)
>>> - * @param value entry value to add to *pm (will be av_strduped 
>>> depending on flags).
>>> + * @param key entry key to add to *pm (will either be av_strduped or 
>>> added as a new key depending on flags)
>>> + * @param value entry value to add to *pm (will be av_strduped or 
>>> added as a new key depending on flags).
>>>   *Passing a NULL value will cause an existing entry to be 
>>> deleted.
>>>   * @return >= 0 on success otherwise an error code <0
>>>   */
>>
>> Changing the semantics of AVDictionary just like this seems rather
>> questionable...
>
> It changes nothing for existing code, just adds a new feature. I don't
> think it hurts anyone or anything...

 It only breaks basic assumptions about a basic data type...
>>>
>>> Although I don't share your thought about breaking a basic data type with 
>>> that,
>>> what would you suggest instead?
>>
>> Pushed for no further suggestions and nobody else objected.
>>
> 
> Just pushing without addressing concerns is not the way we usually try
> to work here, just saying.

I think I have quite a good idea about the usual way we try to handle
things here and I think I've addressed his concerns.

He didn't like it which is of course ok. He did not continue discussing
it nor did he proposed any alternative. He also did not pick up any of
my thoughts. He also did not explicitly state that he thinks that it is
not ok to apply it. He said it "seems rather questionable". Without
further discussion (what I tried) and nobody else complaining about it,
what do you think would be more appropriate than to wait for quite a
long time until continuing?

The usual way for him to prevent me pushing it would just have been to
ask me to wait and I would have waited. Have you checked the dates of
the replies and what I wrote before accusing me to just ignore concerns?

-Thilo


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.

[Hendrik Leppkes]

On Fri, Mar 25, 2016 at 5:48 PM, Thilo Borgmann  wrote:
> Am 22.03.16 um 12:20 schrieb Thilo Borgmann:
>> Am 22.03.16 um 11:45 schrieb wm4:
>>> On Sun, 13 Mar 2016 21:00:23 +0100
>>> Thilo Borgmann  wrote:
>>>
 Am 13.03.16 um 15:08 schrieb wm4:
> On Sat, 12 Mar 2016 15:13:21 +0100
> Thilo Borgmann  wrote:
>
>> From a1d9ce388c69eabb256e6b351c2acd36d7f4076e Mon Sep 17 00:00:00 2001
>> From: Thilo Borgmann 
>> Date: Sat, 12 Mar 2016 14:52:17 +0100
>> Subject: [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal 
>> keys.
>>
>> ---
>>  libavutil/dict.c | 5 -
>>  libavutil/dict.h | 5 +++--
>>  2 files changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavutil/dict.c b/libavutil/dict.c
>> index 8bb65a1..70c0184 100644
>> --- a/libavutil/dict.c
>> +++ b/libavutil/dict.c
>> @@ -70,9 +70,12 @@ int av_dict_set(AVDictionary **pm, const char *key, 
>> const char *value,
>>  int flags)
>>  {
>>  AVDictionary *m = *pm;
>> -AVDictionaryEntry *tag = av_dict_get(m, key, NULL, flags);
>> +AVDictionaryEntry *tag = NULL;
>>  char *oldval = NULL, *copy_key = NULL, *copy_value = NULL;
>>
>> +if (!(flags & AV_DICT_MULTIKEY)) {
>> +tag = av_dict_get(m, key, NULL, flags);
>> +}
>>  if (flags & AV_DICT_DONT_STRDUP_KEY)
>>  copy_key = (void *)key;
>>  else
>> diff --git a/libavutil/dict.h b/libavutil/dict.h
>> index b0aa784..c589bcd 100644
>> --- a/libavutil/dict.h
>> +++ b/libavutil/dict.h
>> @@ -76,6 +76,7 @@
>>  #define AV_DICT_DONT_OVERWRITE 16   ///< Don't overwrite existing 
>> entries.
>>  #define AV_DICT_APPEND 32   /**< If the entry already exists, 
>> append to it.  Note that no
>>delimiter is added, the strings 
>> are simply concatenated. */
>> +#define AV_DICT_MULTIKEY   64   /**< Allow to store several equal 
>> keys in the dictionary */
>>
>>  typedef struct AVDictionaryEntry {
>>  char *key;
>> @@ -118,8 +119,8 @@ int av_dict_count(const AVDictionary *m);
>>   *
>>   * @param pm pointer to a pointer to a dictionary struct. If *pm is NULL
>>   * a dictionary struct is allocated and put in *pm.
>> - * @param key entry key to add to *pm (will be av_strduped depending on 
>> flags)
>> - * @param value entry value to add to *pm (will be av_strduped 
>> depending on flags).
>> + * @param key entry key to add to *pm (will either be av_strduped or 
>> added as a new key depending on flags)
>> + * @param value entry value to add to *pm (will be av_strduped or added 
>> as a new key depending on flags).
>>   *Passing a NULL value will cause an existing entry to be 
>> deleted.
>>   * @return >= 0 on success otherwise an error code <0
>>   */
>
> Changing the semantics of AVDictionary just like this seems rather
> questionable...

 It changes nothing for existing code, just adds a new feature. I don't
 think it hurts anyone or anything...
>>>
>>> It only breaks basic assumptions about a basic data type...
>>
>> Although I don't share your thought about breaking a basic data type with 
>> that,
>> what would you suggest instead?
>
> Pushed for no further suggestions and nobody else objected.
>

Just pushing without addressing concerns is not the way we usually try
to work here, just saying.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.

[Thilo Borgmann]

Am 22.03.16 um 12:20 schrieb Thilo Borgmann:
> Am 22.03.16 um 11:45 schrieb wm4:
>> On Sun, 13 Mar 2016 21:00:23 +0100
>> Thilo Borgmann  wrote:
>>
>>> Am 13.03.16 um 15:08 schrieb wm4:
 On Sat, 12 Mar 2016 15:13:21 +0100
 Thilo Borgmann  wrote:
   
> From a1d9ce388c69eabb256e6b351c2acd36d7f4076e Mon Sep 17 00:00:00 2001
> From: Thilo Borgmann 
> Date: Sat, 12 Mar 2016 14:52:17 +0100
> Subject: [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.
>
> ---
>  libavutil/dict.c | 5 -
>  libavutil/dict.h | 5 +++--
>  2 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/libavutil/dict.c b/libavutil/dict.c
> index 8bb65a1..70c0184 100644
> --- a/libavutil/dict.c
> +++ b/libavutil/dict.c
> @@ -70,9 +70,12 @@ int av_dict_set(AVDictionary **pm, const char *key, 
> const char *value,
>  int flags)
>  {
>  AVDictionary *m = *pm;
> -AVDictionaryEntry *tag = av_dict_get(m, key, NULL, flags);
> +AVDictionaryEntry *tag = NULL;
>  char *oldval = NULL, *copy_key = NULL, *copy_value = NULL;
>  
> +if (!(flags & AV_DICT_MULTIKEY)) {
> +tag = av_dict_get(m, key, NULL, flags);
> +}
>  if (flags & AV_DICT_DONT_STRDUP_KEY)
>  copy_key = (void *)key;
>  else
> diff --git a/libavutil/dict.h b/libavutil/dict.h
> index b0aa784..c589bcd 100644
> --- a/libavutil/dict.h
> +++ b/libavutil/dict.h
> @@ -76,6 +76,7 @@
>  #define AV_DICT_DONT_OVERWRITE 16   ///< Don't overwrite existing 
> entries.
>  #define AV_DICT_APPEND 32   /**< If the entry already exists, 
> append to it.  Note that no
>delimiter is added, the strings 
> are simply concatenated. */
> +#define AV_DICT_MULTIKEY   64   /**< Allow to store several equal 
> keys in the dictionary */
>  
>  typedef struct AVDictionaryEntry {
>  char *key;
> @@ -118,8 +119,8 @@ int av_dict_count(const AVDictionary *m);
>   *
>   * @param pm pointer to a pointer to a dictionary struct. If *pm is NULL
>   * a dictionary struct is allocated and put in *pm.
> - * @param key entry key to add to *pm (will be av_strduped depending on 
> flags)
> - * @param value entry value to add to *pm (will be av_strduped depending 
> on flags).
> + * @param key entry key to add to *pm (will either be av_strduped or 
> added as a new key depending on flags)
> + * @param value entry value to add to *pm (will be av_strduped or added 
> as a new key depending on flags).
>   *Passing a NULL value will cause an existing entry to be 
> deleted.
>   * @return >= 0 on success otherwise an error code <0
>   */  

 Changing the semantics of AVDictionary just like this seems rather
 questionable...  
>>>
>>> It changes nothing for existing code, just adds a new feature. I don't
>>> think it hurts anyone or anything...
>>
>> It only breaks basic assumptions about a basic data type...
> 
> Although I don't share your thought about breaking a basic data type with 
> that,
> what would you suggest instead?

Pushed for no further suggestions and nobody else objected.

-Thilo

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.

[Thilo Borgmann]

Am 22.03.16 um 11:45 schrieb wm4:
> On Sun, 13 Mar 2016 21:00:23 +0100
> Thilo Borgmann  wrote:
> 
>> Am 13.03.16 um 15:08 schrieb wm4:
>>> On Sat, 12 Mar 2016 15:13:21 +0100
>>> Thilo Borgmann  wrote:
>>>   
 From a1d9ce388c69eabb256e6b351c2acd36d7f4076e Mon Sep 17 00:00:00 2001
 From: Thilo Borgmann 
 Date: Sat, 12 Mar 2016 14:52:17 +0100
 Subject: [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.

 ---
  libavutil/dict.c | 5 -
  libavutil/dict.h | 5 +++--
  2 files changed, 7 insertions(+), 3 deletions(-)

 diff --git a/libavutil/dict.c b/libavutil/dict.c
 index 8bb65a1..70c0184 100644
 --- a/libavutil/dict.c
 +++ b/libavutil/dict.c
 @@ -70,9 +70,12 @@ int av_dict_set(AVDictionary **pm, const char *key, 
 const char *value,
  int flags)
  {
  AVDictionary *m = *pm;
 -AVDictionaryEntry *tag = av_dict_get(m, key, NULL, flags);
 +AVDictionaryEntry *tag = NULL;
  char *oldval = NULL, *copy_key = NULL, *copy_value = NULL;
  
 +if (!(flags & AV_DICT_MULTIKEY)) {
 +tag = av_dict_get(m, key, NULL, flags);
 +}
  if (flags & AV_DICT_DONT_STRDUP_KEY)
  copy_key = (void *)key;
  else
 diff --git a/libavutil/dict.h b/libavutil/dict.h
 index b0aa784..c589bcd 100644
 --- a/libavutil/dict.h
 +++ b/libavutil/dict.h
 @@ -76,6 +76,7 @@
  #define AV_DICT_DONT_OVERWRITE 16   ///< Don't overwrite existing entries.
  #define AV_DICT_APPEND 32   /**< If the entry already exists, 
 append to it.  Note that no
delimiter is added, the strings are 
 simply concatenated. */
 +#define AV_DICT_MULTIKEY   64   /**< Allow to store several equal 
 keys in the dictionary */
  
  typedef struct AVDictionaryEntry {
  char *key;
 @@ -118,8 +119,8 @@ int av_dict_count(const AVDictionary *m);
   *
   * @param pm pointer to a pointer to a dictionary struct. If *pm is NULL
   * a dictionary struct is allocated and put in *pm.
 - * @param key entry key to add to *pm (will be av_strduped depending on 
 flags)
 - * @param value entry value to add to *pm (will be av_strduped depending 
 on flags).
 + * @param key entry key to add to *pm (will either be av_strduped or 
 added as a new key depending on flags)
 + * @param value entry value to add to *pm (will be av_strduped or added 
 as a new key depending on flags).
   *Passing a NULL value will cause an existing entry to be deleted.
   * @return >= 0 on success otherwise an error code <0
   */  
>>>
>>> Changing the semantics of AVDictionary just like this seems rather
>>> questionable...  
>>
>> It changes nothing for existing code, just adds a new feature. I don't
>> think it hurts anyone or anything...
> 
> It only breaks basic assumptions about a basic data type...

Although I don't share your thought about breaking a basic data type with that,
what would you suggest instead?

Add an almost redundant AVMultiDictionary data type or rename AVDictionary to 
that?
Or an error-prone implementation within the filter?
These seem to be worse alternatives in my eyes.

-Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.

[wm4]

On Sun, 13 Mar 2016 21:00:23 +0100
Thilo Borgmann  wrote:

> Am 13.03.16 um 15:08 schrieb wm4:
> > On Sat, 12 Mar 2016 15:13:21 +0100
> > Thilo Borgmann  wrote:
> >   
> >> From a1d9ce388c69eabb256e6b351c2acd36d7f4076e Mon Sep 17 00:00:00 2001
> >> From: Thilo Borgmann 
> >> Date: Sat, 12 Mar 2016 14:52:17 +0100
> >> Subject: [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.
> >>
> >> ---
> >>  libavutil/dict.c | 5 -
> >>  libavutil/dict.h | 5 +++--
> >>  2 files changed, 7 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/libavutil/dict.c b/libavutil/dict.c
> >> index 8bb65a1..70c0184 100644
> >> --- a/libavutil/dict.c
> >> +++ b/libavutil/dict.c
> >> @@ -70,9 +70,12 @@ int av_dict_set(AVDictionary **pm, const char *key, 
> >> const char *value,
> >>  int flags)
> >>  {
> >>  AVDictionary *m = *pm;
> >> -AVDictionaryEntry *tag = av_dict_get(m, key, NULL, flags);
> >> +AVDictionaryEntry *tag = NULL;
> >>  char *oldval = NULL, *copy_key = NULL, *copy_value = NULL;
> >>  
> >> +if (!(flags & AV_DICT_MULTIKEY)) {
> >> +tag = av_dict_get(m, key, NULL, flags);
> >> +}
> >>  if (flags & AV_DICT_DONT_STRDUP_KEY)
> >>  copy_key = (void *)key;
> >>  else
> >> diff --git a/libavutil/dict.h b/libavutil/dict.h
> >> index b0aa784..c589bcd 100644
> >> --- a/libavutil/dict.h
> >> +++ b/libavutil/dict.h
> >> @@ -76,6 +76,7 @@
> >>  #define AV_DICT_DONT_OVERWRITE 16   ///< Don't overwrite existing entries.
> >>  #define AV_DICT_APPEND 32   /**< If the entry already exists, 
> >> append to it.  Note that no
> >>delimiter is added, the strings are 
> >> simply concatenated. */
> >> +#define AV_DICT_MULTIKEY   64   /**< Allow to store several equal 
> >> keys in the dictionary */
> >>  
> >>  typedef struct AVDictionaryEntry {
> >>  char *key;
> >> @@ -118,8 +119,8 @@ int av_dict_count(const AVDictionary *m);
> >>   *
> >>   * @param pm pointer to a pointer to a dictionary struct. If *pm is NULL
> >>   * a dictionary struct is allocated and put in *pm.
> >> - * @param key entry key to add to *pm (will be av_strduped depending on 
> >> flags)
> >> - * @param value entry value to add to *pm (will be av_strduped depending 
> >> on flags).
> >> + * @param key entry key to add to *pm (will either be av_strduped or 
> >> added as a new key depending on flags)
> >> + * @param value entry value to add to *pm (will be av_strduped or added 
> >> as a new key depending on flags).
> >>   *Passing a NULL value will cause an existing entry to be deleted.
> >>   * @return >= 0 on success otherwise an error code <0
> >>   */  
> > 
> > Changing the semantics of AVDictionary just like this seems rather
> > questionable...  
> 
> It changes nothing for existing code, just adds a new feature. I don't
> think it hurts anyone or anything...

It only breaks basic assumptions about a basic data type...

> > Are you sure you don't want a list instead?  
> 
> AVDictionary serves the purpose perfectly and already handles all the
> key value seperation, parsing and error resilience... do we have a list
> container ready to do that?
> I'm not happy to use a deprecated thing either but AVTree seems not to
> be ready yet (parsing from string, keeping insertion order of keys even
> when rebalancing and most importantly enumeration (sequentially search
> for keys) seems not to be ready for multiple keys - although the tree
> itself can handle mutliple equal keys). This is why I decided to go with
> adding a new flag to the AVDictionary rather than doing it with AVTree
> nearly from scratch...

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.

[Thilo Borgmann]

Am 13.03.16 um 15:08 schrieb wm4:
> On Sat, 12 Mar 2016 15:13:21 +0100
> Thilo Borgmann  wrote:
> 
>> From a1d9ce388c69eabb256e6b351c2acd36d7f4076e Mon Sep 17 00:00:00 2001
>> From: Thilo Borgmann 
>> Date: Sat, 12 Mar 2016 14:52:17 +0100
>> Subject: [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.
>>
>> ---
>>  libavutil/dict.c | 5 -
>>  libavutil/dict.h | 5 +++--
>>  2 files changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavutil/dict.c b/libavutil/dict.c
>> index 8bb65a1..70c0184 100644
>> --- a/libavutil/dict.c
>> +++ b/libavutil/dict.c
>> @@ -70,9 +70,12 @@ int av_dict_set(AVDictionary **pm, const char *key, const 
>> char *value,
>>  int flags)
>>  {
>>  AVDictionary *m = *pm;
>> -AVDictionaryEntry *tag = av_dict_get(m, key, NULL, flags);
>> +AVDictionaryEntry *tag = NULL;
>>  char *oldval = NULL, *copy_key = NULL, *copy_value = NULL;
>>  
>> +if (!(flags & AV_DICT_MULTIKEY)) {
>> +tag = av_dict_get(m, key, NULL, flags);
>> +}
>>  if (flags & AV_DICT_DONT_STRDUP_KEY)
>>  copy_key = (void *)key;
>>  else
>> diff --git a/libavutil/dict.h b/libavutil/dict.h
>> index b0aa784..c589bcd 100644
>> --- a/libavutil/dict.h
>> +++ b/libavutil/dict.h
>> @@ -76,6 +76,7 @@
>>  #define AV_DICT_DONT_OVERWRITE 16   ///< Don't overwrite existing entries.
>>  #define AV_DICT_APPEND 32   /**< If the entry already exists, 
>> append to it.  Note that no
>>delimiter is added, the strings are 
>> simply concatenated. */
>> +#define AV_DICT_MULTIKEY   64   /**< Allow to store several equal keys 
>> in the dictionary */
>>  
>>  typedef struct AVDictionaryEntry {
>>  char *key;
>> @@ -118,8 +119,8 @@ int av_dict_count(const AVDictionary *m);
>>   *
>>   * @param pm pointer to a pointer to a dictionary struct. If *pm is NULL
>>   * a dictionary struct is allocated and put in *pm.
>> - * @param key entry key to add to *pm (will be av_strduped depending on 
>> flags)
>> - * @param value entry value to add to *pm (will be av_strduped depending on 
>> flags).
>> + * @param key entry key to add to *pm (will either be av_strduped or added 
>> as a new key depending on flags)
>> + * @param value entry value to add to *pm (will be av_strduped or added as 
>> a new key depending on flags).
>>   *Passing a NULL value will cause an existing entry to be deleted.
>>   * @return >= 0 on success otherwise an error code <0
>>   */
> 
> Changing the semantics of AVDictionary just like this seems rather
> questionable...

It changes nothing for existing code, just adds a new feature. I don't
think it hurts anyone or anything...

> Are you sure you don't want a list instead?

AVDictionary serves the purpose perfectly and already handles all the
key value seperation, parsing and error resilience... do we have a list
container ready to do that?
I'm not happy to use a deprecated thing either but AVTree seems not to
be ready yet (parsing from string, keeping insertion order of keys even
when rebalancing and most importantly enumeration (sequentially search
for keys) seems not to be ready for multiple keys - although the tree
itself can handle mutliple equal keys). This is why I decided to go with
adding a new flag to the AVDictionary rather than doing it with AVTree
nearly from scratch...

-Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel