On Wed, Apr 10, 2019 at 05:10:53PM +0200, Paul B Mahol wrote: > On 3/29/19, Michael Niedermayer <mich...@niedermayer.cc> wrote: > > On Fri, Mar 29, 2019 at 01:16:41AM +0100, Carl Eugen Hoyos wrote: > >> 2019-03-28 20:52 GMT+01:00, Michael Niedermayer <mich...@niedermayer.cc>: > >> > On Thu, Mar 28, 2019 at 06:47:52PM +0100, Carl Eugen Hoyos wrote: > >> >> 2019-03-28 18:31 GMT+01:00, Michael Niedermayer > >> >> <mich...@niedermayer.cc>: > >> >> > On Thu, Mar 28, 2019 at 12:00:39PM +0100, Carl Eugen Hoyos wrote: > >> >> > >> >> >> - <small>ffmpeg-4.1.2.tar.bz2</small> > >> >> >> + <small>ffmpeg-snapshot.tar.bz2</small> > >> >> > > >> >> > Iam not sure if this is wise. This would increase the burden > >> >> > for security fixes because now any fix to a bug in no release > >> >> > can be ignored. But if distros would ship random master > >> >> > checkouts everything even if its fixed an hour later could > >> >> > be relevant to some distribution > >> >> > >> >> This link will not affect any distribution, only users who need a > >> >> quick download (and report an issue afterwards). > >> > > >> > maybe there should be a button for downloading the latest release > >> > and the latest snapshot side by side > >> > >> > and certainly i see your point but users downloading the latest > >> > snapshot > >> > still will not have the latest when they report a bug. So iam not > >> > sure this would actually help. Many if not most people still would > >> > have to go and re-download > >> > >> After working on FFmpeg for some time I would say > >> users who use a release very often miss that an issue > >> was already fixed, users with a recent snapshots > >> are less likely in this situation. > >> > >> > also if release and snapshot differ much its probably time for a new > >> > major release ... > >> > not saying that makes your argument less relevant but more saying > >> > that i think we should probably make a new major release ... > >> > > > >> Given the number of open current regressions, I would > >> prefer if we fixed at least some of them before > >> making a release... > > > > yes, i prefer that as well and bugs should be fixed independant of > > there being a release ... > > and i would suggest we consider setting up some bug bounties for these > > 151 ? regressions or a subset of them. This may help to draw more > > interrest towards them ... > > You can work on those bugs,
i could, but my todo list keeps growing with things i could or want to do. but if theres any regression that i caused (and someone tells me about it) then i can try to make that one a priority ... > after all you are being paid to work > full time on FFmpeg, or do I miss remember? what ?! i wish that was the case ... but no, thats not the case and never was. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire
signature.asc
Description: PGP signature
_______________________________________________ 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".
