Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FFmpeg 5.0

github.com

Post reply on HN
Print view View original

11–20 of 31 posts

Re: FFmpeg 5.0

#11

Post by shmerl »

dmw_ng wrote: post #10
shmerl wrote: post #8

Earlier quoted context omitted.

Except it is broke. I'm not motivated to deal with Trac even if I want to submit a bug report. So the above argument is not addressing the situation. Making bug reporting a better experience is in the interest of the project. I find Debian bug reports a similarly annoying experience becasue it's so archaic. I.e. I deal with it, but I can totally understand if someone is turned off by the experience and simply avoids…

Making code contribution a better experience is in the interests of the project, making it easier to report bugs is not such a clear win. Consumption-centric interactions are a modern concept originally popularized by the structure of the GitHub UI. Gamifying project popularity and making it easy for users to report bugs nobody is paying to have fixed has almost nothing to do with the actual task of developing softwa…

Elitist approach to bug reporting is wrong, at least that's my opinion. Unless project maintainers indeed don't care about bug reports and just do whatever. But then it's more arrogance than actual benefit to the user.

I think more projects suffer from under reporting of bugs than from too many bugs reported.

And if no one is fixing bugs, then the above doesn't matter anyway.

Re: FFmpeg 5.0

#13

Post by mataug »

shmerl wrote: post #11
dmw_ng wrote: post #10

Earlier quoted context omitted.

Making code contribution a better experience is in the interests of the project, making it easier to report bugs is not such a clear win. Consumption-centric interactions are a modern concept originally popularized by the structure of the GitHub UI. Gamifying project popularity and making it easy for users to report bugs nobody is paying to have fixed has almost nothing to do with the actual task of developing softwa…

Elitist approach to bug reporting is wrong, at least that's my opinion. Unless project maintainers indeed don't care about bug reports and just do whatever. But then it's more arrogance than actual benefit to the user. I think more projects suffer from under reporting of bugs than from too many bugs reported. And if no one is fixing bugs, then the above doesn't matter anyway.

Given the limited resource at the disposal of an open source project team, they need to pick their battles carefully to produce the most value with the least resources.

For a mature project such as FFmpeg, migrating to a new bug tracking system may produce some value to a small set of people who are reporting bugs, but for the vast majority of FFmpeg users, it produces no value.

So in this particular case it seems like they are willing to sacrifice the convenience of a small subset of users in the interest of the whole user community.

This applies to many mature and long running projects.

Re: FFmpeg 5.0

#14

Post by shmerl »

mataug wrote: post #13
shmerl wrote: post #11

Earlier quoted context omitted.

Elitist approach to bug reporting is wrong, at least that's my opinion. Unless project maintainers indeed don't care about bug reports and just do whatever. But then it's more arrogance than actual benefit to the user. I think more projects suffer from under reporting of bugs than from too many bugs reported. And if no one is fixing bugs, then the above doesn't matter anyway.

Given the limited resource at the disposal of an open source project team, they need to pick their battles carefully to produce the most value with the least resources. For a mature project such as FFmpeg, migrating to a new bug tracking system may produce some value to a small set of people who are reporting bugs, but for the vast majority of FFmpeg users, it produces no value. So in this particular case it seems li…

They can choose whatever priorities of course, but I'd disagree that it's not impacting anyone besides a small portion of the users. Discouraging bug reports reduces quality for everyone.

Those who report bugs might be a smaller portion, but projects need them I'd argue way more than those who use and never report anything to them.

Re: FFmpeg 5.0

#15

Post by dmw_ng »

shmerl wrote: post #14
mataug wrote: post #13

Earlier quoted context omitted.

Given the limited resource at the disposal of an open source project team, they need to pick their battles carefully to produce the most value with the least resources. For a mature project such as FFmpeg, migrating to a new bug tracking system may produce some value to a small set of people who are reporting bugs, but for the vast majority of FFmpeg users, it produces no value. So in this particular case it seems li…

They can choose whatever priorities of course, but I'd disagree that it's not impacting anyone besides a small portion of the users. Discouraging bug reports reduces quality for everyone. Those who report bugs might be a smaller portion, but projects need them I'd argue way more than those who use and never report anything to them.

I'd encourage browsing their Trac for context.. the handful of regular contributors definitely don't need any extra bug reporters

Re: FFmpeg 5.0

#16

Post by Youden »

mig39 wrote: post #12
gregoriol wrote: post #4

So... what is so much different about it from 4.x?

Did you click the link?

Not the parent but the link is quite opaque. I'd really like it if someone more familiar with the project could explain what these changes mean, which ones are exciting and why and whether there were any interesting challenges that were overcome.

Re: FFmpeg 5.0

#17

Post by bryanrasmussen »

shmerl wrote: post #6
bryanrasmussen wrote: post #5

Earlier quoted context omitted.

don't know Trac, but can you import your history from it into Gitlab?

Haven't looked into it, but in the worst case making some custom tool would do it.

Ok maybe, but maybe the devs wouldn't feel that was that great a user of their time which might already be limited by other obligations.

But I guess someone else has already done it https://451.sh/post/tracboat/

Re: FFmpeg 5.0

#18

Post by camgunz »

shmerl wrote: post #11
dmw_ng wrote: post #10

Earlier quoted context omitted.

Making code contribution a better experience is in the interests of the project, making it easier to report bugs is not such a clear win. Consumption-centric interactions are a modern concept originally popularized by the structure of the GitHub UI. Gamifying project popularity and making it easy for users to report bugs nobody is paying to have fixed has almost nothing to do with the actual task of developing softwa…

Elitist approach to bug reporting is wrong, at least that's my opinion. Unless project maintainers indeed don't care about bug reports and just do whatever. But then it's more arrogance than actual benefit to the user. I think more projects suffer from under reporting of bugs than from too many bugs reported. And if no one is fixing bugs, then the above doesn't matter anyway.

You're being really ungenerous here, saying their bug tracking system is "broken", their use of it is "elitist", they "don't care about bug reports" and they're guilty of "arrogance". I don't think you can substantiate any of this just from the fact that they use Trac.

You (well, maybe not you, but one) can also imagine all kinds of counter-arguments (not that I know if any of these are true or not):

- Devs would rather spend their time on development

- No one is inspired to move the system over

- They have automations or conventions built on Trac

- Their super users (prolific users, testers, and engineers) are all used to Trac

- People use RSS feeds (Trac has lots of RSS feeds) to stay informed or build other tools, which would all have to be migrated and might have incompatible formats

I encourage you to be more open-minded about the way others choose to work. We shouldn't overemphasize homogeneity in work processes. I also encourage you to be more generous with the words you choose.

Re: FFmpeg 5.0

#19

Post by fmorel »

Youden wrote: post #16
mig39 wrote: post #12

Earlier quoted context omitted.

Did you click the link?

Not the parent but the link is quite opaque. I'd really like it if someone more familiar with the project could explain what these changes mean, which ones are exciting and why and whether there were any interesting challenges that were overcome.

Indeed. At work, I find that doing a little bit of curation on the merged PRs makes for more much readable & relevant release notes.
Post reply on HN