[FFmpeg-devel] Bug Tracker Etiquette is Unacceptable

[Reimar Döffinger]

On Fri, Feb 28, 2014 at 01:58:51PM +0000, JULIAN GARDNER wrote:
> Ditto. Ive lost count on how many times I sat in disbelief when i tried to change something to make it more spec compliant and was told that I was reading the spec wrong!! English is my 1st language, and the specs I use I have based the last 15 years of my professional career on conforming to. 

Sorry, but that is IMHO not comparable.
There were at least 2 people (including me) 100% certain that the spec
did not say what you said it does.
What do you expect to happen when two (core?) developers say one thing and
one person (especially with for us essentially unverifiable credentials)
says another thing?
Also, nobody said your proposal was wrong (it was applied after all),
but that your argument for it did not make sense to us.
There were lots of different ways to argue for it, which from my point
of view took quite some prodding from my side for you to do.
I just hope this will be a one-time thing, because I can't see what
I can do differently/better when I after all arguing still am 100%
certain your argument is wrong.

> 2. Wrong mailing list (usually 1st reply from when mentioning a bug/problem), why would a user, not a developer be interested in a bug/failure

I think you misunderstand the purpose of the way the mailing
lists are separated.
The developer mailing list is for all developers, which have
every right not to care and not wanting to be "bothered" with
bug reports.
Those that do want to deal with them can subscribe to the other
lists or the bug tracker.
People subscribed to the users lists are either interested
in bug/problem reports or at least waiting for an answer.
So yes, the expectation is that most of the users subscribed
to lists are in fact interested in bugs.

> 3. Will break older versions of ffmpeg, even though I tried to fix something that was wrong as per the PUBLISHED SPEC, eg dvbsubtitles clut, dvb section filtering

What is the problem? We _never_ want to break things.
If it is the _only_ way to fix a spec compliance issue
we have to, but most of the time it is possible to both
fix compliance and keep compatibility so I see absolutely
nothing wrong in taking extra time to try to achieve that.

So sorry for the frustration, and I am sure there is room
for improvement, but I am afraid some of your frustrations
specifically were kind of justified.

Regards,
Reimar Döffinger