diff mbox

[FFmpeg-devel] download: Fix the release link

Message ID CAB0OVGp+5KTdNVecjtt3CfB1XReVzgM4u2GDBx7Rj0X6kDfW1Q@mail.gmail.com
State New
Headers show

Commit Message

Carl Eugen Hoyos March 28, 2019, 11 a.m. UTC
Hi!

Attached patch also simplifies the release process.

Please comment, Carl Eugen

Comments

Tobias Rapp March 28, 2019, 2 p.m. UTC | #1
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
Carl Eugen Hoyos March 28, 2019, 2:02 p.m. UTC | #2
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
Tobias Rapp March 28, 2019, 2:52 p.m. UTC | #3
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
Michael Niedermayer March 28, 2019, 5:31 p.m. UTC | #4
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

[...]
Carl Eugen Hoyos March 28, 2019, 5:47 p.m. UTC | #5
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
Michael Niedermayer March 28, 2019, 7:52 p.m. UTC | #6
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 ...

[...]
Carl Eugen Hoyos March 29, 2019, 12:16 a.m. UTC | #7
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
Lou Logan March 29, 2019, 2:40 a.m. UTC | #8
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”.
Michael Niedermayer March 29, 2019, 5:39 p.m. UTC | #9
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 ...


[...]
Reto Kromer April 7, 2019, 5:34 a.m. UTC | #10
Michael Niedermayer wrote:

>i think we should probably make a new major release ...

+1

Best regards, Reto
Paul B Mahol April 10, 2019, 3:10 p.m. UTC | #11
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?
Michael Niedermayer April 10, 2019, 3:41 p.m. UTC | #12
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.



[...]
Lou Logan April 10, 2019, 6:04 p.m. UTC | #13
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/
Michael Niedermayer April 12, 2019, 1:49 p.m. UTC | #14
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

[...]
diff mbox

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.
---
 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