Hi Ronald On Mon, Sep 18, 2017 at 09:11:39AM -0400, Ronald S. Bultje wrote: > Hi Michael, > > On Sun, Sep 17, 2017 at 8:15 PM, Michael Niedermayer <mich...@niedermayer.cc > > wrote: > > > Iam happy to follow what the community prefers. > > > > Some don't like it, some don't care. I think everyone would be happy (and
I belive you did not ask the community. if so you cannot know what people prefer. I think you extrapolate from 3 people who have been very vocal about this to the whole community. > thus the sum of happiness would increase) if you changed this to ff_dlog() > or something along those lines. Why do you keep arguing with me and not poll the community? Iam happy to do what the majority prefers, but i do not know what the majority prefers. > > You say you want to code, so why not take the path of least resistance and > move on? If this is about changing one error message in one patch. Ill just change it because id like to push this bugfix and argumentation with you is quite time consuming and was so far in this case fruitless. But the project should not be run by "its the path of least resistance to comply with what i demand" if OTOH what you want is establishing a rule about error messages. No, one cannot do that without 1. writing the rule down 2. polling the comunity about it 3. including the rule in the policy so everyone, including new developers know about it. This is a matter that needs a community decission first. Also the codebase would become incresingly inconsistent without this being agreed on by all and written down. > Is this just about being right? no, its very possible i and or you are wrong. > Or do you really believe it's > important to display an error message while fuzzing? no. Its important when the user hits a bug/issue. Developers can rebuild the tree with any debug flag, a user generally cannot. But i belive we fundamentally disagree here. The ones hit hardest with a wide spread removial of error messages from the binary in a user build are probably the people dealing with bug reports. Its interresting to note that the people pushing for this removial have quite some overlap with who has in the past attacked our most active developer on the bug tracker. Iam sure its just a coincidence but its still chilling to realize this. > Or do you have actual > evidence that this is an error path that will often occur in real-world > files and where the provided error message helps our users resolve the > issue that their valid (non-fuzzed, real-world) file is not playing back? That yes, though its a very seperate thing. And part of what i meant with "disagreeing" with you. This error message here would trigger on a truncated frame/file. Truncated files are common in the real world for all kinds of reasons. This was found by a fuzzer but its not specific to fuzzing Also, i very much would like to end this discussion, its a huge waste of time for everyone. If you dont want to have a community wide rule and dont want to ask people outside of the group who dont like how error messages are currently handled, then please stop asking me to change code. Thank you [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML.
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
