5 ms·

See also: The VLC bug that incorrectly applies right crops as left crops [1]. This bug report is from 2023, however the bug has existed as long as VLC has as fa

See also: The VLC bug that incorrectly applies right crops as left crops [1]. This bug report is from 2023, however the bug has existed as long as VLC has as far as I know. I'm always surprised to see bugs like this where an extremely easy to test part of the spec just seemingly isn't tested and ends up as a bug that never gets fixed until many years later. [0]: https://code.videolan.org/videolan/vlc/-/issues/28279 https://code.videolan.org/videolan/vlc/-/issues/28279

pwdisswordfishy 11mo ago
Compare also: https://trac.ffmpeg.org/ticket/11279 https://trac.ffmpeg.org/ticket/11279 https://trac.ffmpeg.org/ticket/11284 https://trac.ffmpeg.org/ticket/11284
moron4hire 11mo ago
I firmly believe every product team needs to be split in two: one half works on the issue of highest importance, the other works on the easiest issues. If only to avoid the embarrassment of easy to fix bugs that were passed over for eons just because they weren't priority-high.
- silon42 11mo ago
  Also, people in the first team should also alternate hard/complicated issues with easy fixes.
- Avamander 11mo ago
  I don't this makes business sense in general. I do however think that there are quite a few bugs that might be triaged as "easy" but if worked on would reveal much more serious problems. Which is why some random selection of "easy" issues should make it to work queues.
  - ozim 11mo ago
    Makes business sense if you want to fill in developers down time - instead of waiting for CR or QA feedback pick up small bug. Working on two or more big features at the same time is not possible. But throwing in some pebbles and dev can take on it.
  - moron4hire 11mo ago
    The business sense! Would someone please think of the business! I've yet to find a business that really, truly knows what it wants. Whatever is "good for the business case" today could change overnight after the President reads some cockamamie article in Harvard Business Review, and again in two weeks after the CEO spends a weekend in Jackson Hole.
- coldpie 11mo ago
  There's something to this, although I think the idea needs some refinement. Anyone who's worked on a real software product knows that the "easy" bugs usually aren't actually easy (or else they would've been fixed already!). The way I've seen it implemented at a small company I worked at before was to explicitly endorse the "20% time" idea that Google made famous, where you may choose your own priorities for a fraction of your working time regardless of the bug tracker priority order. Even if in practice you don't actually have that spare time allocated in your schedule, it does give you some cover to tell your manager why you are prioritizing little UI papercuts over product features this week.
  - embedding-shape 11mo ago
    > Anyone who's worked on a real software product knows that the "easy" bugs usually aren't actually easy (or else they would've been fixed already!). Well, could be many reasons, "priorities" is usually the reason I see as the top reason for things like that to not be fixed immediately, rather than "we looked into it and it was hard". Second most popular reason is "workaround exists", and then after that probably something like "looks easy but isn't". I think the solution would be to stop consider "easy-but-isn't" as easy bugs, even if they might appear so. So the "easy bugs" team would have their worklog, and if they discover one of those bugs weren't actually easy and would need large changes, reject it and push it somewhere else, and start working on something that is actually easy instead.
  - seba_dos1 11mo ago
    > Anyone who's worked on a real software product knows that the "easy" bugs usually aren't actually easy (or else they would've been fixed already!). Not really. It's hard to see the difference from the outside without actually digging into it first, but in my experience while there's plenty of "easy" bugs that aren't actually easy, there's also plenty of easy bugs that are actually easy and that apparently everyone else assumed they're not, or else they would have been fixed already :P
    - ryandrake 11mo ago
      Easy bugs might exist at small and medium size companies, but when you are a $1T+ company, there is no such thing as an easy fix. Your change could have unforeseen side effects that take down some critical revenue-generating service that causes us to lose $millions. It's got to go through multiple code reviews, have unit and integration tests written, be able to show those test passing more than once, it may need to get reviewed by legal, it may need to get reviewed by security and privacy teams. And tons of other process overhead I'm not even recalling. Just getting a one-liner from an engineer's fingertips properly deployed into production could take months. Whether or not you fix a bug weighs on the scale against the cost of all of the above things, the cost of time, the cost of these people's attention, and the opportunity cost of them doing something else. And these costs tend to not scale with the size of the pull request. They're fixed costs that have to be paid no matter how small an issue is. I work at a BigCo, and occasionally get comments from developer friends about "Hey, why doesn't BigCo fix this obvious bug I reported! It's simple! Why are you guys so incompetent??" I look at the bug internally, and it's either 1. got a huge internal comment chain showing it's not as simple as an outsider would think, or 2. it's indeed trivial, but the effort to fix it does not outweigh the costs I outlined above.
- arkh 11mo ago
  I feel like with opensource projects those kind of "easy to fix but not priority" bugs are a really nice way to keep the door open to new contributors. You're a new coder and would like to help a project, if possible a big one for your resume? Here are something to get started.
  - seba_dos1 11mo ago
    Yeah, people really underestimate how many low hanging fruits are left there to reach for even in fairly popular projects. Don't just assume that "surely someone must have tried to fix this already", it's not always the case.
- ozim 11mo ago
  We do priority high stuff in sprint planning. Non prio bug fixes can be dragged in by devs when the are out of sprint tasks or need to switch context to unfold thoughts. You cannot just push high prio stuff on people. Business gets their predictable workload done bonus stuff like things team wants to fix gets of course second seat but it has its place.
- lukan 11mo ago
  That will be great popcorn stuff to watch from the outside I think. Or tragic, but I rather see drama than joy with this approach. The main thing with bugfixing is, that it can affect a whole lot of other areas, or introduce completely new bugs. So both teams then fighting over changes .. Now a really trivial bug with no side effects, sure thing, no issue, but like a sibling commentor has said, the really trivial bugs are usually fixed already. And quick fixes of seemingly trivial things can induce a world of pain for someone else. In other words, I think project management and prioritising things remain hard, with no magic bullets solutions avaiable. (But I wpuld also prefer a stronger emphasis on quality control in general, vs new feature)

pwdisswordfishy 11mo ago

Compare also: https://trac.ffmpeg.org/ticket/11279 https://trac.ffmpeg.org/ticket/11279 https://trac.ffmpeg.org/ticket/11284 https://trac.ffmpeg.org/ticket/11284

moron4hire 11mo ago

I firmly believe every product team needs to be split in two: one half works on the issue of highest importance, the other works on the easiest issues. If only to avoid the embarrassment of easy to fix bugs that were passed over for eons just because they weren't priority-high.

silon42 11mo ago
Also, people in the first team should also alternate hard/complicated issues with easy fixes.
Avamander 11mo ago
I don't this makes business sense in general. I do however think that there are quite a few bugs that might be triaged as "easy" but if worked on would reveal much more serious problems. Which is why some random selection of "easy" issues should make it to work queues.
- ozim 11mo ago
  Makes business sense if you want to fill in developers down time - instead of waiting for CR or QA feedback pick up small bug. Working on two or more big features at the same time is not possible. But throwing in some pebbles and dev can take on it.
- moron4hire 11mo ago
  The business sense! Would someone please think of the business! I've yet to find a business that really, truly knows what it wants. Whatever is "good for the business case" today could change overnight after the President reads some cockamamie article in Harvard Business Review, and again in two weeks after the CEO spends a weekend in Jackson Hole.
coldpie 11mo ago
There's something to this, although I think the idea needs some refinement. Anyone who's worked on a real software product knows that the "easy" bugs usually aren't actually easy (or else they would've been fixed already!). The way I've seen it implemented at a small company I worked at before was to explicitly endorse the "20% time" idea that Google made famous, where you may choose your own priorities for a fraction of your working time regardless of the bug tracker priority order. Even if in practice you don't actually have that spare time allocated in your schedule, it does give you some cover to tell your manager why you are prioritizing little UI papercuts over product features this week.
- embedding-shape 11mo ago
  > Anyone who's worked on a real software product knows that the "easy" bugs usually aren't actually easy (or else they would've been fixed already!). Well, could be many reasons, "priorities" is usually the reason I see as the top reason for things like that to not be fixed immediately, rather than "we looked into it and it was hard". Second most popular reason is "workaround exists", and then after that probably something like "looks easy but isn't". I think the solution would be to stop consider "easy-but-isn't" as easy bugs, even if they might appear so. So the "easy bugs" team would have their worklog, and if they discover one of those bugs weren't actually easy and would need large changes, reject it and push it somewhere else, and start working on something that is actually easy instead.
- seba_dos1 11mo ago
  > Anyone who's worked on a real software product knows that the "easy" bugs usually aren't actually easy (or else they would've been fixed already!). Not really. It's hard to see the difference from the outside without actually digging into it first, but in my experience while there's plenty of "easy" bugs that aren't actually easy, there's also plenty of easy bugs that are actually easy and that apparently everyone else assumed they're not, or else they would have been fixed already :P
  - ryandrake 11mo ago
    Easy bugs might exist at small and medium size companies, but when you are a $1T+ company, there is no such thing as an easy fix. Your change could have unforeseen side effects that take down some critical revenue-generating service that causes us to lose $millions. It's got to go through multiple code reviews, have unit and integration tests written, be able to show those test passing more than once, it may need to get reviewed by legal, it may need to get reviewed by security and privacy teams. And tons of other process overhead I'm not even recalling. Just getting a one-liner from an engineer's fingertips properly deployed into production could take months. Whether or not you fix a bug weighs on the scale against the cost of all of the above things, the cost of time, the cost of these people's attention, and the opportunity cost of them doing something else. And these costs tend to not scale with the size of the pull request. They're fixed costs that have to be paid no matter how small an issue is. I work at a BigCo, and occasionally get comments from developer friends about "Hey, why doesn't BigCo fix this obvious bug I reported! It's simple! Why are you guys so incompetent??" I look at the bug internally, and it's either 1. got a huge internal comment chain showing it's not as simple as an outsider would think, or 2. it's indeed trivial, but the effort to fix it does not outweigh the costs I outlined above.
arkh 11mo ago
I feel like with opensource projects those kind of "easy to fix but not priority" bugs are a really nice way to keep the door open to new contributors. You're a new coder and would like to help a project, if possible a big one for your resume? Here are something to get started.
- seba_dos1 11mo ago
  Yeah, people really underestimate how many low hanging fruits are left there to reach for even in fairly popular projects. Don't just assume that "surely someone must have tried to fix this already", it's not always the case.
ozim 11mo ago
We do priority high stuff in sprint planning. Non prio bug fixes can be dragged in by devs when the are out of sprint tasks or need to switch context to unfold thoughts. You cannot just push high prio stuff on people. Business gets their predictable workload done bonus stuff like things team wants to fix gets of course second seat but it has its place.
lukan 11mo ago
That will be great popcorn stuff to watch from the outside I think. Or tragic, but I rather see drama than joy with this approach. The main thing with bugfixing is, that it can affect a whole lot of other areas, or introduce completely new bugs. So both teams then fighting over changes .. Now a really trivial bug with no side effects, sure thing, no issue, but like a sibling commentor has said, the really trivial bugs are usually fixed already. And quick fixes of seemingly trivial things can induce a world of pain for someone else. In other words, I think project management and prioritising things remain hard, with no magic bullets solutions avaiable. (But I wpuld also prefer a stronger emphasis on quality control in general, vs new feature)