A commit that was "co-authored-by" 6+ people and has three thousand lines of code: this is a total wreck of a development workflow. This feature should have been implemented with a series of about 20 patches. Awful.
You are being downvoted, but you are entirely correct. This is also explicitly not allowed in FFmpeg, but this was pushed after many months, with no heads up on the list, no final review sign off, and with some developers expressing (and continuing to express) reservations about its quality on the list and IRC.
That's really unfortunate to hear. I'm a huge fan of Webrtc and Pion, and was very excited to get some ffmpeg integration -- hopefully some of the quality issues will be ironed out before the next ffmpeg release
There's quite some time until the next release, I believe, so it should be.
The biggest thing missing right now is NACK support, and one of the authors has said they intend to do this (along with fixing old OpenSSL version support, and supporting other libraries). Until that is done, it isn't really "prod ready", so to speak.
For some context, there has been a history of half-supported things being pushed to FFmpeg by companies or people who just need some subset of $thing, in the past, and vendors using that to sell their products with "FFmpeg isn't good enough" marketing, while the feature is either brought up to standard, or in some cases, removed, as the original authors vanish, so it's perhaps a touchy subject for us :) (and why my post was perhaps unnecessarily grumpy).
As for the git / premature push stuff, I strongly believe it is a knock-on effect of mailing list based development - the team working on this support did it elsewhere, and had a designated person send it to the list, meaning every bit of communication is garbled. But that is a whole different can of worms :D.
I mean, it probably was a branch that several people contributed commits to that was squashed prior to merge into mainline. Folks sometimes have thoughts about whether there's value in squashing or not, but it's a pretty common and sensible workflow.
Perhaps "common and technically works" would be a better way to put that (similarly for rebase). I suspect people would stop squashing if git gained the ability to tag groups of commits with topics in either a nested or overlapping manner.
> Why would anyone rather read and fix someone else code rather than writing the code themselves?
Because their own review standards are low (so they find reviewing "easy"), and/or because they can't appreciate the emotional & mental fulfillment that coding provides.
For me, the electric bike analogy works differently: it enables people to ride, regularly, who would not be able to do that with traditional bikes. That's totally fine. But electric bikes don't threaten to take away our normal bikes.
There are things that "modulate" this. Violating copyright is never right, of course, some questions are however scale, and purpose. Taking others' creative output, unlicensed, for large-scale commercial gain, is about the worst.
Agreed. Smartphones are portable, mobile computers that suck at every single aspect of being, and working as, a computer, except for mobility. They are not powerful, they are not general purpose, they are not ergonimic, they do not respect user freedom or privacy. Use such a mobile device only when you can't avoid it (i.e., when you are on the road -- when mobility is the single most important priority), and at no other time.
Smartphones are pure consumption machines, in this regard they are more Cocaine than Caffeine. They brought pleasure at an extreme cost. Their worst crime, imo, os the destruction of human relationships brought about by "social" media.
> I got into programming because I like programming, not because I like asking others to write code on my behalf and review what they come up with
oh finally someone else who didn't enter programming because, as 7-10 year old child, they were into SOLVING PRACTICAL PROBLEMS FOR PEOPLE.
> But the last fucking thing I want to do is delegate all the code writing to someone or something else
Thank God there is at least one other person that understands that the ratio between creative and reactive work is crucial for wellbeing at the job.
For crying out loud.
> but if I ever get to the point that I feel like I spend my entire day in virtual meetings with AI agents, then I'm changing careers
so am I.
> but at least I guess I got a couple of good decades out of it
Thanks for this perspective. Yes, at least we've got our memories, and the code locations and commits we recall from memory, from a distance of 10 or more years.
>. If this is what the job turns into, I'll have to find something else to do with my remaining years
> as 7-10 year old child, they were into SOLVING PRACTICAL PROBLEMS FOR PEOPLE.
Some of my fondest childhood memories are sitting in my school's resource center in front of a TRS-80, laboriously typing in some mimeographed BASIC code while wondering, "Is this the most efficient way I can increase shareholder value for the corporation?"
I'm with you two. I can work on boring problems in boring domains and enjoy the design and implementation aspect because it's inherently creative. Take away those and now my only job is the guy in Office Space who takes the requirements from the customers to the developers, if I'm lucky enough to have one at that point.
I don't want to have to change careers, as this is one that I've been working towards to some degree since I was a child. Including some intense work in college and some brutal first couple jobs where I worked hard to pick up marketable skills. Obviously the market doesn't care what I want, but I find the author of this piece to be a bit too flippant in his "but they take-rr jerbs" section. Working hard to get a well paying job only to have to start (likely near the bottom) in another career for much less pay is not something to treat lightly.
