| Message ID | CAB0OVGp+5KTdNVecjtt3CfB1XReVzgM4u2GDBx7Rj0X6kDfW1Q@mail.gmail.com |
|---|---|
| State | Accepted |
| Headers | show |
On 28.03.2019 12:00, Carl Eugen Hoyos wrote: > Hi! > > Attached patch also simplifies the release process. > > Please comment, Carl Eugen Personally I'd prefer to keep the link to the latest release. There is already a "Download Snapshot" button on the "Get the Sources" panel. Regards, Tobias
2019-03-28 15:00 GMT+01:00, Tobias Rapp <t.rapp@noa-archive.com>: > On 28.03.2019 12:00, Carl Eugen Hoyos wrote: >> >> Attached patch also simplifies the release process. > Personally I'd prefer to keep the link to the latest release. Why? Such a link is already listed below. I always found it extremely disturbing and I realize now that it also was a (useless) maintenance burden. Carl Eugen
On 28.03.2019 15:02, Carl Eugen Hoyos wrote: > 2019-03-28 15:00 GMT+01:00, Tobias Rapp <t.rapp@noa-archive.com>: >> On 28.03.2019 12:00, Carl Eugen Hoyos wrote: >>> >>> Attached patch also simplifies the release process. > >> Personally I'd prefer to keep the link to the latest release. > > Why? Such a link is already listed below. > > I always found it extremely disturbing and I realize now > that it also was a (useless) maintenance burden. I don't want to start a snapshot-vs-release discussion. Merging the prominent "Download" button with "Download Snapshot" is also fine for me. Regards, Tobias
On Thu, Mar 28, 2019 at 12:00:39PM +0100, Carl Eugen Hoyos wrote: > Hi! > > Attached patch also simplifies the release process. > > Please comment, Carl Eugen > download | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > c16157dd6203b7d2f8adbf991030fe43ba8e79dc 0001-download-Fix-the-main-download-link-to-point-to-a-sn.patch > From cfefed3d6e67d029960f1042c20a34c8026d3fc6 Mon Sep 17 00:00:00 2001 > From: Carl Eugen Hoyos <ceffmpeg@gmail.com> > Date: Thu, 28 Mar 2019 11:59:00 +0100 > Subject: [PATCH] download: Fix the main download link to point to a snapshot. > > There is no release support, this also simplifies the release process. Well, we do try to provide security fixes for releases. So its not "no support" > --- > src/download | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/src/download b/src/download > index b760804..a90be61 100644 > --- a/src/download > +++ b/src/download > @@ -1,10 +1,10 @@ > > <div id="download"> > <div class="btn-download-wrapper"> > - <a href="https://ffmpeg.org/releases/ffmpeg-4.1.tar.bz2" class="btn btn-success"> > + <a href="https://ffmpeg.org/releases/ffmpeg-snapshot.tar.bz2" class="btn btn-success"> > <i class="fa fa-cloud-download"></i> > Download > - <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 besides, i need to make a new 4.1 release because we backported a bug thanks [...]
2019-03-28 18:31 GMT+01:00, Michael Niedermayer <michael@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). Carl Eugen
On Thu, Mar 28, 2019 at 06:47:52PM +0100, Carl Eugen Hoyos wrote: > 2019-03-28 18:31 GMT+01:00, Michael Niedermayer <michael@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 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 ... [...]
2019-03-28 20:52 GMT+01:00, Michael Niedermayer <michael@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 <michael@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... I was annoyed about the top of the download page for a very long time and only realized now that apart from being misleading, it also created a maintenance burden. Carl Eugen
On Thu, Mar 28, 2019, at 3:00 AM, Carl Eugen Hoyos wrote: > Hi! > > Attached patch also simplifies the release process. > > Please comment, Carl Eugen LGTM. I prefer if you omit the commit message as it may confuse users. We do backport to point releases and users may view that as some sort of “support”.
On Fri, Mar 29, 2019 at 01:16:41AM +0100, Carl Eugen Hoyos wrote: > 2019-03-28 20:52 GMT+01:00, Michael Niedermayer <michael@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 <michael@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 ... [...]
Michael Niedermayer wrote:
>i think we should probably make a new major release ...
+1
Best regards, Reto
On 3/29/19, Michael Niedermayer <michael@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 <michael@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 >> >> <michael@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, after all you are being paid to work full time on FFmpeg, or do I miss remember?
On Wed, Apr 10, 2019 at 05:10:53PM +0200, Paul B Mahol wrote: > On 3/29/19, Michael Niedermayer <michael@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 <michael@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 > >> >> <michael@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. [...]
On Fri, Mar 29, 2019, at 9:39 AM, Michael Niedermayer wrote: > > 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 ... Getting off-topic here, but I think some of the donated funds should be used for bounties. Otherwise, as far as I know, it seems to be mostly used for conference travel/lodging reimbursement. The downside is when money is involved things can get complicated. Who decides which bugs/feature requests get a bounty? How do we determine how much each bounty is worth? Can the same person who is involved a bounty decision also claim the same bounty? VideoLAN offers bounties (including some on libavcodec), but I don't know the details of how it is implemented. Out of pure efficiency (laziness) maybe we can copy what they do. https://wiki.videolan.org/Bounties/
On Wed, Apr 10, 2019 at 02:04:21PM -0400, Lou Logan wrote: > On Fri, Mar 29, 2019, at 9:39 AM, Michael Niedermayer wrote: > > > > 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 ... > > Getting off-topic here, but I think some of the donated funds should be used for bounties. Otherwise, as far as I know, it seems to be mostly used for conference travel/lodging reimbursement. > > The downside is when money is involved things can get complicated. Who decides which bugs/feature requests get a bounty? How do we determine how much each bounty is worth? Can the same person who is involved a bounty decision also claim the same bounty? I would suggest a simple rule that requires no decission maker and that self adjusts the value. If we assume that simple, nonsense or duplicate tickets will get fixed/closed quickly then it would be reasonable to assume that the age of a ticket is proportional to its difficulty. Also waiting does not work in this form to drive price up as waiting includes the risk that someone else will fix it. A simple dumb rule could be that we pay X cent per day of age of a ticket from when it was opened and had a reproducable testcase (not newly created) to when it is closed. Payment would be to the author of the change fixing it (if teh author wants to be paid) Also there can still be a safe guard in here for example all payment could require to be approved individually the public ML. So if someone found a way to game the system people could still object to the payment. > > VideoLAN offers bounties (including some on libavcodec), but I don't know the details of how it is implemented. Out of pure efficiency (laziness) maybe we can copy what they do. > > https://wiki.videolan.org/Bounties/ I would suggest not to require prior "registration" but rather whoever fixed it has the right to request payment within some reasonable time like 3 months after the fix is pushed With bugs its not always clear how complex a fix is. So requireing "contact first" could lead to some annoying grab-ungrab cycles on bugs and to people fixing a bug and then not getting the payment because they missed the contacting first thing. I think the risk for 2 people fixing the same bug at the same time (which then also needs to have been open since a long time to matter) feels like it would be a rare occurance The disadvantage here is of course that with a tiny bounty from the first day and no pre-registration some peole will be eligible for payment of a few cent which could be unpractical/annoying maybe a minimum of 100 euro per payout or so could fix this Thanks [...]
Am Do., 28. März 2019 um 12:00 Uhr schrieb Carl Eugen Hoyos <ceffmpeg@gmail.com>: > > Attached patch also simplifies the release process. Finally applied with the requested simplified commit message. Carl Eugen
From cfefed3d6e67d029960f1042c20a34c8026d3fc6 Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos <ceffmpeg@gmail.com> Date: Thu, 28 Mar 2019 11:59:00 +0100 Subject: [PATCH] download: Fix the main download link to point to a snapshot. There is no release support, this also simplifies the release process. --- src/download | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/download b/src/download index b760804..a90be61 100644 --- a/src/download +++ b/src/download @@ -1,10 +1,10 @@ <div id="download"> <div class="btn-download-wrapper"> - <a href="https://ffmpeg.org/releases/ffmpeg-4.1.tar.bz2" class="btn btn-success"> + <a href="https://ffmpeg.org/releases/ffmpeg-snapshot.tar.bz2" class="btn btn-success"> <i class="fa fa-cloud-download"></i> Download - <small>ffmpeg-4.1.2.tar.bz2</small> + <small>ffmpeg-snapshot.tar.bz2</small> </a> <br> <a href="#releases">More releases</a> -- 1.7.10.4