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 <g...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
