[FFmpeg-devel] lavc: remove the QOA decoder

Its author not only failed to add any tests, as is required by the
development rules, but continues to actively refuse to do so.

Untested decoders are worse than useless, so remove it.
---
 Changelog              |   2 +-
 libavcodec/Makefile    |   1 -
 libavcodec/allcodecs.c |   1 -
 libavcodec/qoadec.c    | 170 -----------------------------------------
 4 files changed, 1 insertion(+), 173 deletions(-)
 delete mode 100644 libavcodec/qoadec.c

What a nice narrative.

Yes, remove this decoder.

And keep two sonic decoders at same time of questionable code quality,
functionality and what not.

> On Dec 2, 2023, at 7:53 AM, Anton Khirnov <anton@khirnov.net> wrote:
> 
> Its author not only failed to add any tests, as is required by the
> development rules, but continues to actively refuse to do so.
> 
> Untested decoders are worse than useless, so remove it.

While I agree that decoders (among other things) need tests this seems like an unfortunate outcome from an end user perspective. There are QOA samples at https://qoaformat.org/samples/ and presumably someone else could add some tests for it if the author can't be bothered. Can we hold off on this for a couple of days? If nobody else can add a test I can try to do so but I'll need a couple of days to figure it out.

- Cosmin

On Sat, Dec 2, 2023 at 7:20 PM Cosmin Stejerean via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:

>
>
> > On Dec 2, 2023, at 7:53 AM, Anton Khirnov <anton@khirnov.net> wrote:
> >
> > Its author not only failed to add any tests, as is required by the
> > development rules, but continues to actively refuse to do so.
> >
> > Untested decoders are worse than useless, so remove it.
>
> While I agree that decoders (among other things) need tests this seems
> like an unfortunate outcome from an end user perspective. There are QOA
> samples at https://qoaformat.org/samples/ and presumably someone else
> could add some tests for it if the author can't be bothered. Can we hold
> off on this for a couple of days? If nobody else can add a test I can try
> to do so but I'll need a couple of days to figure it out.
>

Its not hard to add/write test, and even its easy to upload test sample to
server, but last time I did it people complained of too big samples.
So I learned my lesson.


>
> - Cosmin
>
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>

Anton Khirnov (12023-12-02):
> Its author not only failed to add any tests, as is required by the
> development rules, but continues to actively refuse to do so.
> 
> Untested decoders are worse than useless, so remove it.

Only tested manually ≠ untested.

A code that works is better than no code at all.

We are not libav, we do not remove code just because the Great Dictator
says so. If you really really want this decoder to have a test, you can
write add it yourself.

Rejected.

Hi,

On Sat, 2 Dec 2023, at 19:55, Paul B Mahol wrote:
> Its not hard to add/write test, and even its easy to upload test sample to
> server, but last time I did it people complained of too big samples.

What is too big a sample?
What's the problem with large samples?
What is the documented official limit?

jb

On Mon, Dec 4, 2023 at 1:53 PM Nicolas George <george@nsup.org> wrote:

> Anton Khirnov (12023-12-02):
> > Its author not only failed to add any tests, as is required by the
> > development rules, but continues to actively refuse to do so.
> >
> > Untested decoders are worse than useless, so remove it.
>
> Only tested manually ≠ untested.
>
> A code that works is better than no code at all.
>
> We are not libav, we do not remove code just because the Great Dictator
> says so. If you really really want this decoder to have a test, you can
> write add it yourself.
>

It's almost 2024, when will you be able to drop it?

Vittorio Giovara (12023-12-04):
> It's almost 2024, when will you be able to drop it?

Never. When will YOU be able to drop bickering about parts of the code
that do no harm and do not bother you?

On Tue, Dec 5, 2023 at 2:45 AM Nicolas George <george@nsup.org> wrote:

> Vittorio Giovara (12023-12-04):
> > It's almost 2024, when will you be able to drop it?
>
> Never. When will YOU be able to drop bickering about parts of the code
> that do no harm and do not bother you?
>

I'm not bickering, we're having a discussion on a mailing list (aka the
point of having a list in the first place) -- also, having someone in one
of the largest mailing lists promoting a development model that does not
actively include testing as part of the bare minimum process to accept the
patch/review is harming the whole generation of developers.
Please stop saying nonsense, or do it with a bit more kindness without
bringing up dead projects, and I'll stop answering you.
Believe me I want this more than you do.
Cheers

Vittorio Giovara (12023-12-05):
> I'm not bickering,

That is exactly what you do.

> actively include testing as part of the bare minimum process to accept the
> patch/review is harming the whole generation of developers.

I agree that Paul's attitude is utterly toxic to the project, but
Anton's attitude of removing features is way worse. At least Paul almost
only pollutes his own code.

As for harming a whole generation, it is the same vague argument used by
everybody to condemn anything they do not like, like homosexuality for
example, and that argument is always the same level of bullshit.

On Tue, Dec 5, 2023 at 9:59 AM Nicolas George <george@nsup.org> wrote:

> Vittorio Giovara (12023-12-05):
> > I'm not bickering,
>
> That is exactly what you do.
>

And you are not? The view must be great from that glass house

> actively include testing as part of the bare minimum process to accept the
> > patch/review is harming the whole generation of developers.
>
> I agree that Paul's attitude is utterly toxic to the project, but
> Anton's attitude of removing features is way worse. At least Paul almost
> only pollutes his own code.
>

Your attitude for "omgfeatures" is also pretty toxic, there are heaps of
literature about feature creep and how important it is to remove dead code.


> As for harming a whole generation, it is the same vague argument used by
> everybody to condemn anything they do not like, like homosexuality for
> example, and that argument is always the same level of bullshit.
>

Uhhh, but maybe I'm just misinterpreting your message, but that looks like
a very ignorant comparison.

Vittorio Giovara (12023-12-05):
> Your attitude for "omgfeatures" is also pretty toxic, there are heaps of
> literature about feature creep and how important it is to remove dead code.

You should read said literature before quoting it, you would learn the
difference between more features and feature creep: creeping features
make it harder to maintain core features.

So, can you prove that this QOA decoder makes it harder to maintain the
framework of FFmpeg? No, you cannot.

> Uhhh, but maybe I'm just misinterpreting your message, but that looks like
> a very ignorant comparison.

It is not ignorant at all, you show exactly the same argument structure.

Homophobes cannot prove homosexuality causes objective and immediate
harm to anybody.

You cannot prove that Paul's code causes objective and immediate harm to
the project.

So homophobes resort to invoking a vague harm to society / youth /
whatever.

So you resort to invoking a vague harm to a generation.

You do it because you have a strong intuition that it is true.

Homophobes have a strong intuition that it is true too.

But intuition without arguments has no place in a debate, it cannot
convince anybody.

And your intuition is just as wrong as the homophobes'.

In this instance, your intuition is wrong because it applies to FFmpeg
what it knows about professional projects — open or closed source —
whereas FFmpeg is not a professional project but a Libre Software
projects whose most talented contributors work for fun.

In a professional project, the time and effort of developers is limited
and must be focused on useful things. In a project like FFmpeg, the time
and effort that talented developers invest in the project grows as they
can work on fun tasks, even when said tasks are of limited usefulness.

A sure way of killing a project like FFmpeg is to prevent people from
working on the things they find fun and try to force them to do useful
things instead, either by outright rejecting if you have the authority
or by drowning them with bickering and demands, like you did with
Michael and like you just ran Paul out.

Good job.

On 12/2/2023 12:53 PM, Anton Khirnov wrote:
> Its author not only failed to add any tests, as is required by the
> development rules, but continues to actively refuse to do so.
> 
> Untested decoders are worse than useless, so remove it.
> ---
>   Changelog              |   2 +-
>   libavcodec/Makefile    |   1 -
>   libavcodec/allcodecs.c |   1 -
>   libavcodec/qoadec.c    | 170 -----------------------------------------
>   4 files changed, 1 insertion(+), 173 deletions(-)
>   delete mode 100644 libavcodec/qoadec.c

As there are tests now afaics, this patch can be withdrawn.

I ain't reading all of that
Happy for you
Or sorry that happened

On Wed, Dec 6, 2023 at 3:47 PM Nicolas George <george@nsup.org> wrote:

> Vittorio Giovara (12023-12-05):
> > Your attitude for "omgfeatures" is also pretty toxic, there are heaps of
> > literature about feature creep and how important it is to remove dead
> code.
>
> You should read said literature before quoting it, you would learn the
> difference between more features and feature creep: creeping features
> make it harder to maintain core features.
>
> So, can you prove that this QOA decoder makes it harder to maintain the
> framework of FFmpeg? No, you cannot.
>
> > Uhhh, but maybe I'm just misinterpreting your message, but that looks
> like
> > a very ignorant comparison.
>
> It is not ignorant at all, you show exactly the same argument structure.
>
> Homophobes cannot prove homosexuality causes objective and immediate
> harm to anybody.
>
> You cannot prove that Paul's code causes objective and immediate harm to
> the project.
>
> So homophobes resort to invoking a vague harm to society / youth /
> whatever.
>
> So you resort to invoking a vague harm to a generation.
>
> You do it because you have a strong intuition that it is true.
>
> Homophobes have a strong intuition that it is true too.
>
> But intuition without arguments has no place in a debate, it cannot
> convince anybody.
>
> And your intuition is just as wrong as the homophobes'.
>
> In this instance, your intuition is wrong because it applies to FFmpeg
> what it knows about professional projects — open or closed source —
> whereas FFmpeg is not a professional project but a Libre Software
> projects whose most talented contributors work for fun.
>
> In a professional project, the time and effort of developers is limited
> and must be focused on useful things. In a project like FFmpeg, the time
> and effort that talented developers invest in the project grows as they
> can work on fun tasks, even when said tasks are of limited usefulness.
>
> A sure way of killing a project like FFmpeg is to prevent people from
> working on the things they find fun and try to force them to do useful
> things instead, either by outright rejecting if you have the authority
> or by drowning them with bickering and demands, like you did with
> Michael and like you just ran Paul out.
>
> Good job.
>
> --
>   Nicolas George
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>

Quoting James Almer (2023-12-06 21:49:45)
> On 12/2/2023 12:53 PM, Anton Khirnov wrote:
> > Its author not only failed to add any tests, as is required by the
> > development rules, but continues to actively refuse to do so.
> > 
> > Untested decoders are worse than useless, so remove it.
> > ---
> >   Changelog              |   2 +-
> >   libavcodec/Makefile    |   1 -
> >   libavcodec/allcodecs.c |   1 -
> >   libavcodec/qoadec.c    | 170 -----------------------------------------
> >   4 files changed, 1 insertion(+), 173 deletions(-)
> >   delete mode 100644 libavcodec/qoadec.c
> 
> As there are tests now afaics, this patch can be withdrawn.

Of course, actually pushing it was never the point of this patch.

tis 2023-12-05 klockan 08:44 +0100 skrev Nicolas George:
> Vittorio Giovara (12023-12-04):
> > It's almost 2024, when will you be able to drop it?
> 
> Never. When will YOU be able to drop bickering about parts of the
> code
> that do no harm and do not bother you?

Technical debt concerns everyone

/Tomas

Tomas Härdin (12023-12-19):
> Technical debt concerns everyone

There is no technical debt. There is never a technical debt from
something that can be removed at an instant notice and that some are
considering removing now.

Learn from the Dread Pirate Roberts: always put off stupid things until
the next day.

tis 2023-12-19 klockan 15:02 +0100 skrev Nicolas George:
> Tomas Härdin (12023-12-19):
> > Technical debt concerns everyone
> 
> There is no technical debt. There is never a technical debt from
> something that can be removed at an instant notice and that some are
> considering removing now

I'm not even sure what this is trying to say, but every line of code
carries with it a non-zero maintenance burden

> Learn from the Dread Pirate Roberts

Brag about your criminal enterprise and get busted by cops?

/Tomas

Tomas Härdin (12023-12-20):
> I'm not even sure what this is trying to say, but every line of code
> carries with it a non-zero maintenance burden

Sure, if you want. But for some parts of FFmpeg, like the one we are
discussing, the maintenance burden is so small that we wasted ten time
as much energy having this discussion. I congratulate you on an
efficient use of developers resources.

> Brag about your criminal enterprise and get busted by cops?

You do not even know the classics?

On Wed, Dec 20, 2023 at 05:57:40PM +0100, Tomas Härdin wrote:
> tis 2023-12-19 klockan 15:02 +0100 skrev Nicolas George:
[...]
> [...] , but every line of code
> carries with it a non-zero maintenance burden

Assuming you mean with "non-zero" a "larger than zero" maintenance burden

then we can proof this to be false

First we need to define what you mean by "maintenance burden" ?
There are a few ways this could be defined
A. the absolute number of hours all developers need to spend to maintain
some sort of stable quality

B. the number of hours on average a FFmpeg developers need to spend to
maintain some sort of stable quality

(A favors 9 hours over 10 hours even if the 10 hour case has 2 devlopers
 available but the 9 has only 1. While B favors the 10/2 over 9/1)

C. the number of hours of work noone really wants to do, FFmpeg developers need
to spend to maintain some sort of stable quality
(again we can do this as all or per developer)
(the idea of C is that we count work that people dont like to do with more weight)

(and there are many more ways to define it ...)

Now the sketch of a proof :)

Consider all the code related to "--help"
code related to printing the version and build. Code printing where to
send bugreports/samples.
Also all formating maybe ;)

or even some random check here or there.

The "maintenance burden" in all definitions will worsen as the code
becomes less readable, less well documented or as things related to
maintaince are removed

But its more than just this i think.
* If you remove code that some comnpany or major user needs, and who pays for
  maintaince than removial of even complex and hard to maintain code can
  actually be negative and similarly adding complex code can actually be
  positive maintaince wise. IF it also results in additional resources
  becoming available for maintaince. (this can be a developers time or
  a companies money or other)

* In the same light both merging and spliting code can have an impact on
  maintenance burden. For example if you have a group of developers who are
  unable to work together, them spliting up in 2 forks and a 3rd merging their
  work together avoiding their inability to agree can reduce burden on both
  OTOH if 2 groups can join and work together the sharing of resources and such
  can free up time and reduce maintaince burden

What iam trying to say is, the maintaince burden resulting from a change
is complex

In this specific case here we have a patch proposing the removial of a decoder
missing a test.
Its easy to say the burden is less when the decoder is removed
But its author recently left the project too

[...]

ons 2023-12-20 klockan 20:11 +0100 skrev Michael Niedermayer:
> On Wed, Dec 20, 2023 at 05:57:40PM +0100, Tomas Härdin wrote:
> > tis 2023-12-19 klockan 15:02 +0100 skrev Nicolas George:
> [...]
> > [...] , but every line of code
> > carries with it a non-zero maintenance burden
> 
> Assuming you mean with "non-zero" a "larger than zero" maintenance
> burden
> 
> then we can proof this to be false

Doubt

> What iam trying to say is, the maintaince burden resulting from a
> change
> is complex

Indeed

> In this specific case here we have a patch proposing the removial of
> a decoder
> missing a test.
> Its easy to say the burden is less when the decoder is removed
> But its author recently left the project too

This is one problem. But the careless attitude to shoving more features
into the codebase is far more serious. Every line of code is a CVE
waiting to happen. Apparently this is a difficult thing to grasp for
some contributors. It's an attitude I expect only from junior
developers.

Ensuring C code is correct and safe is *hard*. I have spent time
formally verifying embedded C code for spaceflight. The lessons learned
from this has made me supremely suspicious of cowboy coding.

I have raised this issue multiple times in this project to no avail. I
do not expect things to change.

/Tomas

On Thu, Dec 21, 2023 at 8:43 PM Tomas Härdin <git@haerdin.se> wrote:

> ons 2023-12-20 klockan 20:11 +0100 skrev Michael Niedermayer:
> > On Wed, Dec 20, 2023 at 05:57:40PM +0100, Tomas Härdin wrote:
> > > tis 2023-12-19 klockan 15:02 +0100 skrev Nicolas George:
> > [...]
> > > [...] , but every line of code
> > > carries with it a non-zero maintenance burden
> >
> > Assuming you mean with "non-zero" a "larger than zero" maintenance
> > burden
> >
> > then we can proof this to be false
>
> Doubt
>
> > What iam trying to say is, the maintaince burden resulting from a
> > change
> > is complex
>
> Indeed
>
> > In this specific case here we have a patch proposing the removial of
> > a decoder
> > missing a test.
> > Its easy to say the burden is less when the decoder is removed
> > But its author recently left the project too
>
> This is one problem. But the careless attitude to shoving more features
> into the codebase is far more serious. Every line of code is a CVE
> waiting to happen. Apparently this is a difficult thing to grasp for
> some contributors. It's an attitude I expect only from junior
> developers.
>
> Ensuring C code is correct and safe is *hard*. I have spent time
> formally verifying embedded C code for spaceflight. The lessons learned
> from this has made me supremely suspicious of cowboy coding.
>
> I have raised this issue multiple times in this project to no avail. I
> do not expect things to change.
>

Say what serious feature you contributed ? - Nothing.

Paul B Mahol (12023-12-21):
> Say what serious feature you contributed ? - Nothing.

I did not want to say it, but since it is now in the open: Not nothing:
negative. His naysaying discouraged me from working further on the
built-in documentation system.

On Thu, Dec 21, 2023 at 3:31 PM Nicolas George <george@nsup.org> wrote:

> Paul B Mahol (12023-12-21):
> > Say what serious feature you contributed ? - Nothing.
>
> I did not want to say it, but since it is now in the open: Not nothing:
> negative. His naysaying discouraged me from working further on the
> built-in documentation system.
>

Oh so you know how it feels!

On Thu, Dec 21, 2023 at 3:05 PM Paul B Mahol <onemda@gmail.com> wrote:

> On Thu, Dec 21, 2023 at 8:43 PM Tomas Härdin <git@haerdin.se> wrote:
>
> > ons 2023-12-20 klockan 20:11 +0100 skrev Michael Niedermayer:
> > > On Wed, Dec 20, 2023 at 05:57:40PM +0100, Tomas Härdin wrote:
> > > > tis 2023-12-19 klockan 15:02 +0100 skrev Nicolas George:
> > > [...]
> > > > [...] , but every line of code
> > > > carries with it a non-zero maintenance burden
> > >
> > > Assuming you mean with "non-zero" a "larger than zero" maintenance
> > > burden
> > >
> > > then we can proof this to be false
> >
> > Doubt
> >
> > > What iam trying to say is, the maintaince burden resulting from a
> > > change
> > > is complex
> >
> > Indeed
> >
> > > In this specific case here we have a patch proposing the removial of
> > > a decoder
> > > missing a test.
> > > Its easy to say the burden is less when the decoder is removed
> > > But its author recently left the project too
> >
> > This is one problem. But the careless attitude to shoving more features
> > into the codebase is far more serious. Every line of code is a CVE
> > waiting to happen. Apparently this is a difficult thing to grasp for
> > some contributors. It's an attitude I expect only from junior
> > developers.
> >
> > Ensuring C code is correct and safe is *hard*. I have spent time
> > formally verifying embedded C code for spaceflight. The lessons learned
> > from this has made me supremely suspicious of cowboy coding.
> >
> > I have raised this issue multiple times in this project to no avail. I
> > do not expect things to change.
> >
>
> Say what serious feature you contributed ? - Nothing.
>

Contributions to the process that makes us code better and keep higher
quality code are welcome.
Let's not fall into the trap of "no commits therefore your opinion is
invalid" way of thinking which only a fool would follow.

Vittorio Giovara (12023-12-21):
> Oh so you know how it feels!

I am not surprised to see your animosity against me is stronger than
your care about the project.

On Thu, Dec 21, 2023 at 5:22 PM Nicolas George <george@nsup.org> wrote:

> Vittorio Giovara (12023-12-21):
> > Oh so you know how it feels!
>
> I am not surprised to see your animosity against me is stronger than
> your care about the project.
>

Not sure what gave you the idea, but I have no animosity towards you and I
appreciate your technical feedback when you share it.

What surprises me is that you feel discouraged by the same treatment you
have towards others in other discussions: it's been an actual concern of
mine that your long paragraphs of empty text and sometimes toxic messages
may have discouraged many people and companies to work on the project. All
I hope is that we can all communicate better in 2024 and be able to work
together.

Fwiw I'm glad you and Paul agree on something at least, though, let's
remember, the topic is a simple "new decoders should come with tests" and
its objections seem an odd hill to die on.
Cheers

Vittorio Giovara (12023-12-21):
> Not sure what gave you the idea

Mails like this one for example. The lack of self-awareness is
hilarious.

On Thu, Dec 21, 2023 at 5:41 PM Nicolas George <george@nsup.org> wrote:

> Vittorio Giovara (12023-12-21):
> > Not sure what gave you the idea
>
> Mails like this one for example. The lack of self-awareness is
> hilarious.
>

I agree, I hope you can work on your lack of self-awareness.

Vittorio Giovara (12023-12-21):
> I agree, I hope you can work on your lack of self-awareness.

Oh, the “Ah ?… Et moi, Cyrano-Savinien-Hercule De Bergerac.” comeback.
You're really scrapping the bottom of the barrel, aren't your.

On Thu, Dec 21, 2023 at 6:14 PM Nicolas George <george@nsup.org> wrote:

> Vittorio Giovara (12023-12-21):
> > I agree, I hope you can work on your lack of self-awareness.
>
> Oh, the “Ah ?… Et moi, Cyrano-Savinien-Hercule De Bergerac.” comeback.
> You're really scrapping the bottom of the barrel, aren't your.
>

No, I'm just pointing out the obvious, but there is none so deaf as those
who will not hear.

Anyway the offtopic has been gone long enough, no point in continuing this
dead branch of a resurrected thread.
For real, no harm feelings, thanks for this pleasant and fruitful exchange.

On Thu, Dec 21, 2023 at 05:37:58PM -0500, Vittorio Giovara wrote:
> On Thu, Dec 21, 2023 at 5:22 PM Nicolas George <george@nsup.org> wrote:
> 
> > Vittorio Giovara (12023-12-21):
> > > Oh so you know how it feels!
> >
> > I am not surprised to see your animosity against me is stronger than
> > your care about the project.
> >
> 
> Not sure what gave you the idea, but I have no animosity towards you and I
> appreciate your technical feedback when you share it.
> 

> What surprises me is that you feel discouraged by the same treatment you
> have towards others in other discussions: [...]

I think many people who feel discouraged by someones treatment, have
done similar to others.


> All
> I hope is that we can all communicate better in 2024 and be able to work
> together.

i strongly agree, i hope that too :)

I wanted to quote epictetus, but as i googled i found this, which is
a bit more elaborate
https://www.reddit.com/r/Stoicism/comments/afacdz/when_you_are_offended_at_any_mans_fault_epictetus/

maybe a good guiding principle for 2024 ?

thx

[...]

On Thu, Dec 21, 2023 at 08:43:16PM +0100, Tomas Härdin wrote:
> ons 2023-12-20 klockan 20:11 +0100 skrev Michael Niedermayer:
> > On Wed, Dec 20, 2023 at 05:57:40PM +0100, Tomas Härdin wrote:
> > > tis 2023-12-19 klockan 15:02 +0100 skrev Nicolas George:
> > [...]
> > > [...] , but every line of code
> > > carries with it a non-zero maintenance burden
> > 
> > Assuming you mean with "non-zero" a "larger than zero" maintenance
> > burden
> > 
> > then we can proof this to be false
> 
> Doubt

ok
i seem to have said, "we". So lets do this together :)

heres an example (code by Dave Burton, not by me)

int main(int b,char**i){long long n=B,a=I^n,r=(a/b&a)>>4,y=atoi(*++i),_=(((a^n/b)*(y>>T)|y>>S)&r)|(a^r);printf("%.8s\n",(char*)&_);}

clang -include stdio.h -include stdlib.h -Wall -Weverything -pedantic -DB=6945503773712347754LL -DI=5859838231191962459LL -DT=0 -DS=7 -o prog prog.c

try
./prog 1
./prog 2
./prog 3
...

Can you think of a way to add some lines of code to this that makes it more maintainable ?

if yes, then i think you proofed that adding code can reduce maintaince burden

thx

[...]

Hi Paul,
Quoting Paul B Mahol (2023-12-21 21:05:18)
> Say what serious feature you contributed ? - Nothing.

this is a personal attach. Personal attacks are not allowed on this
mailing list. Please refrain from them in the future.

On Fri, Dec 22, 2023 at 7:28 AM Anton Khirnov <anton@khirnov.net> wrote:

> Hi Paul,
> Quoting Paul B Mahol (2023-12-21 21:05:18)
> > Say what serious feature you contributed ? - Nothing.
>
> this is a personal attach. Personal attacks are not allowed on this
> mailing list. Please refrain from them in the future.
>

Sorry to personally attach you, but best coding cowboy in current FFmpeg is
you.


>
> --
> Anton Khirnov
> (CC member)
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>

On 12/21/2023 5:05 PM, Paul B Mahol wrote:
> On Thu, Dec 21, 2023 at 8:43 PM Tomas Härdin <git@haerdin.se> wrote:
> 
>> ons 2023-12-20 klockan 20:11 +0100 skrev Michael Niedermayer:
>>> On Wed, Dec 20, 2023 at 05:57:40PM +0100, Tomas Härdin wrote:
>>>> tis 2023-12-19 klockan 15:02 +0100 skrev Nicolas George:
>>> [...]
>>>> [...] , but every line of code
>>>> carries with it a non-zero maintenance burden
>>>
>>> Assuming you mean with "non-zero" a "larger than zero" maintenance
>>> burden
>>>
>>> then we can proof this to be false
>>
>> Doubt
>>
>>> What iam trying to say is, the maintaince burden resulting from a
>>> change
>>> is complex
>>
>> Indeed
>>
>>> In this specific case here we have a patch proposing the removial of
>>> a decoder
>>> missing a test.
>>> Its easy to say the burden is less when the decoder is removed
>>> But its author recently left the project too
>>
>> This is one problem. But the careless attitude to shoving more features
>> into the codebase is far more serious. Every line of code is a CVE
>> waiting to happen. Apparently this is a difficult thing to grasp for
>> some contributors. It's an attitude I expect only from junior
>> developers.
>>
>> Ensuring C code is correct and safe is *hard*. I have spent time
>> formally verifying embedded C code for spaceflight. The lessons learned
>> from this has made me supremely suspicious of cowboy coding.
>>
>> I have raised this issue multiple times in this project to no avail. I
>> do not expect things to change.
>>
> 
> Say what serious feature you contributed ? - Nothing.

First of all, this was completely uncalled for. Second, mxf support in 
lavf is pretty much thanks to him.

Hi Nicolas

On Thu, Dec 21, 2023 at 09:31:00PM +0100, Nicolas George wrote:
> Paul B Mahol (12023-12-21):
> > Say what serious feature you contributed ? - Nothing.
> 
> I did not want to say it, but since it is now in the open: Not nothing:
> negative.

Just because someone attacks someone else doesnt make it ok to
join an attack/insult/...

Not only is it bad for the person being attacked (and we all have
been at the receiving end of attacks too)

But theres also the issue that companies avoid interacting with
the FFmpeg community, and avoid contributing thus because of these
threads that devolve a bit.


> His naysaying discouraged me from working further on the
> built-in documentation system.

Thats bad, what can we do about this ?
I think all developers should be able to work on any part they want to.
Of course if there are disagreements then compromise or TC decission
may be needed.

thx

[...]

fre 2023-12-22 klockan 10:09 -0300 skrev James Almer:
> On 12/21/2023 5:05 PM, Paul B Mahol wrote:
> > On Thu, Dec 21, 2023 at 8:43 PM Tomas Härdin <git@haerdin.se>
> > wrote:
> > 
> > > ons 2023-12-20 klockan 20:11 +0100 skrev Michael Niedermayer:
> > > > On Wed, Dec 20, 2023 at 05:57:40PM +0100, Tomas Härdin wrote:
> > > > > tis 2023-12-19 klockan 15:02 +0100 skrev Nicolas George:
> > > > [...]
> > > > > [...] , but every line of code
> > > > > carries with it a non-zero maintenance burden
> > > > 
> > > > Assuming you mean with "non-zero" a "larger than zero"
> > > > maintenance
> > > > burden
> > > > 
> > > > then we can proof this to be false
> > > 
> > > Doubt
> > > 
> > > > What iam trying to say is, the maintaince burden resulting from
> > > > a
> > > > change
> > > > is complex
> > > 
> > > Indeed
> > > 
> > > > In this specific case here we have a patch proposing the
> > > > removial of
> > > > a decoder
> > > > missing a test.
> > > > Its easy to say the burden is less when the decoder is removed
> > > > But its author recently left the project too
> > > 
> > > This is one problem. But the careless attitude to shoving more
> > > features
> > > into the codebase is far more serious. Every line of code is a
> > > CVE
> > > waiting to happen. Apparently this is a difficult thing to grasp
> > > for
> > > some contributors. It's an attitude I expect only from junior
> > > developers.
> > > 
> > > Ensuring C code is correct and safe is *hard*. I have spent time
> > > formally verifying embedded C code for spaceflight. The lessons
> > > learned
> > > from this has made me supremely suspicious of cowboy coding.
> > > 
> > > I have raised this issue multiple times in this project to no
> > > avail. I
> > > do not expect things to change.
> > > 
> > 
> > Say what serious feature you contributed ? - Nothing.
> 
> First of all, this was completely uncalled for. Second, mxf support
> in 
> lavf is pretty much thanks to him.

I will add that Baptiste is mostly to thank for it. But I'd prefer if
it were replaced by bmxlib. This would allow concentrating MXF dev
effort on a single project. But already at the concept stage there has
been opposition to this.

/Tomas

Tomas Härdin (12023-12-24):
> But I'd prefer if it were replaced by bmxlib.

Yes, we know that you have not understood that the raison d'être of
FFmpeg is to IMPLEMENT natively all multimedia formats and protocols and
the utility code they need, not be a mere collection of wrappers.

On 12/24/2023 9:12 AM, Nicolas George wrote:
> Tomas Härdin (12023-12-24):
>> But I'd prefer if it were replaced by bmxlib.
> 
> Yes, we know that you have not understood that the raison d'être of
> FFmpeg is to IMPLEMENT natively all multimedia formats and protocols and
> the utility code they need, not be a mere collection of wrappers.

Can you please stop with the personal attacks? You gain nothing, and the 
entire discussion just goes down the drain.
This mail should have simply been about stating that native modules are 
always preferred over external dependencies.

sön 2023-12-24 klockan 13:12 +0100 skrev Nicolas George:
> Tomas Härdin (12023-12-24):
> > But I'd prefer if it were replaced by bmxlib.
> 
> Yes, we know that you have not understood that the raison d'être of
> FFmpeg is to IMPLEMENT natively all multimedia formats and protocols
> and
> the utility code they need, not be a mere collection of wrappers.

Nah, NIH is bad. It is a waste of labour power. It cuts down on hammock
time.

/Tomas

On Sun, Dec 24, 2023 at 3:33 PM Tomas Härdin <git@haerdin.se> wrote:

> sön 2023-12-24 klockan 13:12 +0100 skrev Nicolas George:
> > Tomas Härdin (12023-12-24):
> > > But I'd prefer if it were replaced by bmxlib.
> >
> > Yes, we know that you have not understood that the raison d'être of
> > FFmpeg is to IMPLEMENT natively all multimedia formats and protocols
> > and
> > the utility code they need, not be a mere collection of wrappers.
>
> Nah, NIH is bad. It is a waste of labour power. It cuts down on hammock
> time.
>

Yes, you are always correct, not.

Tomas Härdin (12023-12-24):
> Nah, NIH is bad.

Then you need to find a different project. FFmpeg exists because a
genius hacker decided to NIH a MPEG software decoder.

On Sun, Dec 24, 2023 at 04:11:30PM +0100, Nicolas George wrote:
> Tomas Härdin (12023-12-24):
> > Nah, NIH is bad.
> 
> Then you need to find a different project. FFmpeg exists because a
> genius hacker decided to NIH a MPEG software decoder.

Please stop attacking Tomas!

FFmpeg exists because many people, many who have different
views work together.

About MXF i agree with you and disagree with Tomas but that can be
stated in a technical way without offending anyone.

And just recently Tomas helped with jpeg2000, you can find the patches
he reviewed ...

theres absolutely no sense in this personal attack on others!

PS (off topic): if you want everyone to work on one MXF codebase, everyone is
welcome to join FFmpeg :)

thx

PS: we have christmess (and happy christmess btw to everyone)
12-24 is not holmgang ;)

[...]

On Sun, Dec 24, 2023 at 6:22 PM Michael Niedermayer <michael@niedermayer.cc>
wrote:

> On Sun, Dec 24, 2023 at 04:11:30PM +0100, Nicolas George wrote:
> > Tomas Härdin (12023-12-24):
> > > Nah, NIH is bad.
> >
> > Then you need to find a different project. FFmpeg exists because a
> > genius hacker decided to NIH a MPEG software decoder.
>
> Please stop attacking Tomas!
>
> FFmpeg exists because many people, many who have different
> views work together.
>
> About MXF i agree with you and disagree with Tomas but that can be
> stated in a technical way without offending anyone.
>
> And just recently Tomas helped with jpeg2000, you can find the patches
> he reviewed ...
>
> theres absolutely no sense in this personal attack on others!
>
> PS (off topic): if you want everyone to work on one MXF codebase, everyone
> is
> welcome to join FFmpeg :)
>

Merry Christmas !


>
> thx
>
> PS: we have christmess (and happy christmess btw to everyone)
> 12-24 is not holmgang ;)
>
> [...]
>
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Rewriting code that is poorly written but fully understood is good.
> Rewriting code that one doesnt understand is a sign that one is less smart
> than the original author, trying to rewrite it will not make it better.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>

On 12/21/23 21:32, Michael Niedermayer wrote:
> 
> Can you think of a way to add some lines of code to this that makes it more maintainable ?
> 
> if yes, then i think you proofed that adding code can reduce maintaince burden
> 
> thx
> 

This is clearly not the point here. The point is that an in-house module 
has to be maintained, and removing that module removes the maintenance 
burden. An international obfuscated C contest entry isn't really on-topic.

- Leo Izen (Traneptora)

On Mon, Dec 25, 2023 at 11:22:40AM -0600, Leo Izen wrote:
> On 12/21/23 21:32, Michael Niedermayer wrote:
> > 
> > Can you think of a way to add some lines of code to this that makes it more maintainable ?
> > 
> > if yes, then i think you proofed that adding code can reduce maintaince burden
> > 
> > thx
> > 
> 
> This is clearly not the point here. The point is that an in-house module has
> to be maintained, and removing that module removes the maintenance burden.
> An international obfuscated C contest entry isn't really on-topic.

You snipped the whole discussion this was a reply to and argue in a different
context. The claim was:

> > > [...] , but every line of code
> > > carries with it a non-zero maintenance burden

And the text you replied to was part of sketching a proof that the
claim was false.

If you make a different claim, yes, you need a different proof.

So what is the new claim ?
"The point is that an in-house module has
 to be maintained, and removing that module removes the maintenance burden."

This is true, IF you ignore that "removing that module" has lead to loss of
developers, should lead to loss of users and also a higher burden on the
end user, who then may have to compile various external dependancies
and maintain these with security updates. OR maybe the end user would
have to choose between 2 forks depending in what feature she wants.

If one, for sake of argument would say the removial of any module would
be good, then the optimum is 0 modules.
Thats clearly not optimal so that would be abusrd

So we know removial cannot always be optimal. That also means it must be
a good thing sometimes to have what you call additional "maintenance burden"

thx

[...]

Hi Nicolas,

On Thu, Dec 21, 2023 at 3:31 PM Nicolas George <george@nsup.org> wrote:

> Paul B Mahol (12023-12-21):
> > Say what serious feature you contributed ? - Nothing.
>
> I did not want to say it, but since it is now in the open: Not nothing:
> negative. His naysaying discouraged me from working further on the
> built-in documentation system.
>

The CC deems some of your statements in this thread (here: "Not nothing:
negative", and later on: "Then you need to find a different project.") to
be personal attacks, in violation of our code of conduct. The CC requests
that you stop such behaviour at once and refrain from it in the future.
Remember that the CC has the option to take away mailinglist privileges.

Unanimously signed,
The CC illuminati (Anton, James, Jean-Baptiste, Michael, Ronald)

Paul,

On Thu, Dec 21, 2023 at 3:05 PM Paul B Mahol <onemda@gmail.com> wrote:

> Say what serious feature you contributed ? - Nothing.
>

the CC requests that you please refrain from attacking fellow FFmpeg
contributors ("what serious feature [have] you contributed? - Nothing") on
the mailinglist.

Signed unanimously,
the CC illuminati (Anton, James, Jean-Baptiste, Michael, Ronald)

On Tue, Dec 26, 2023 at 11:20 PM Ronald S. Bultje <rsbultje@gmail.com>
wrote:

> Paul,
>
> On Thu, Dec 21, 2023 at 3:05 PM Paul B Mahol <onemda@gmail.com> wrote:
>
> > Say what serious feature you contributed ? - Nothing.
> >
>
> the CC requests that you please refrain from attacking fellow FFmpeg
> contributors ("what serious feature [have] you contributed? - Nothing") on
> the mailinglist.
>

I object here to your dictatorship trolling.

Your are selectively picking what to comment and censor.

Your cowboy show is over!


>
> Signed unanimously,
> the CC illuminati (Anton, James, Jean-Baptiste, Michael, Ronald)
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>

On 12/26/2023 7:40 PM, Paul B Mahol wrote:
> On Tue, Dec 26, 2023 at 11:20 PM Ronald S. Bultje <rsbultje@gmail.com>
> wrote:
> 
>> Paul,
>>
>> On Thu, Dec 21, 2023 at 3:05 PM Paul B Mahol <onemda@gmail.com> wrote:
>>
>>> Say what serious feature you contributed ? - Nothing.
>>>
>>
>> the CC requests that you please refrain from attacking fellow FFmpeg
>> contributors ("what serious feature [have] you contributed? - Nothing") on
>> the mailinglist.
>>
> 
> I object here to your dictatorship trolling.
> 
> Your are selectively picking what to comment and censor.

What did the phrase Ronald quoted add to the conversation? Do you 
consider that being civil? Because pretty much no one does.
Why can't people discuss and exchange opinions without talking shit to 
each other?

This ML has a very bad reputation because things like that are rampant, 
so it has to stop. How will anyone want to contribute if the threat of 
being shit talked for no reason is always looming?

On Wed, Dec 27, 2023 at 12:53 AM James Almer <jamrial@gmail.com> wrote:

>
> On 12/26/2023 7:40 PM, Paul B Mahol wrote:
> > On Tue, Dec 26, 2023 at 11:20 PM Ronald S. Bultje <rsbultje@gmail.com>
> > wrote:
> >
> >> Paul,
> >>
> >> On Thu, Dec 21, 2023 at 3:05 PM Paul B Mahol <onemda@gmail.com> wrote:
> >>
> >>> Say what serious feature you contributed ? - Nothing.
> >>>
> >>
> >> the CC requests that you please refrain from attacking fellow FFmpeg
> >> contributors ("what serious feature [have] you contributed? - Nothing")
> on
> >> the mailinglist.
> >>
> >
> > I object here to your dictatorship trolling.
> >
> > Your are selectively picking what to comment and censor.
>
> What did the phrase Ronald quoted add to the conversation? Do you
> consider that being civil? Because pretty much no one does.
> Why can't people discuss and exchange opinions without talking shit to
> each other?
>
> This ML has a very bad reputation because things like that are rampant,
> so it has to stop. How will anyone want to contribute if the threat of
> being shit talked for no reason is always looming?
>

Talk with Thardin, cowboy coding subtle calling and triggering begin with
that entity mails.


> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>