Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: "Rémi Denis-Courmont via ffmpeg-devel" <ffmpeg-devel@ffmpeg.org>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Cc: "Rémi Denis-Courmont" <remi@remlab.net>
Subject: [FFmpeg-devel] Re: [RFC] Funded Task Ideas
Date: Thu, 06 Nov 2025 21:42:13 +0200
Message-ID: <6652250.2jxk8BG5qF@basile.remlab.net> (raw)
In-Reply-To: <aQxe5puEVg4JOWb9@phare.normalesup.org>

Le torstaina 6. marraskuuta 2025, 10.40.06 Itä-Euroopan normaaliaika Nicolas 
George via ffmpeg-devel a écrit :
> Rémi Denis-Courmont (HE12025-11-04):
> 
> > From a technical standpoint, that seems very agreeable indeed. But at
> > the same time, it sounds unreasonable to expect that of a bounty
> > claimant.
> 
> Can you elaborate why you think that? We set the rules.

Sure, "we set the rules" in theory, but...

A bounty is supposed to consist of a fairly well defined job at a predefined 
fixed price. If the bounty claimant has to get into a potentially complex, 
potentially long, if not inconclusive, design discussion, then that's not 
really a well defined job.

So the use of the bounty system will discourage people who would otherwise 
have the time and expertise, but understand the dangerous implications. And, 
then there would be those who "did not see it coming" so to say, and try to 
implement the bounty anyway, most likely without consulting. Exactly what you 
(rightfully) don't want.


More involved work should have a proper SoW, and someone tracking the progress 
on the asking side. Unfortunately, I don't suppose that SPI would be able and 
willing to handle it that way. We've already been through that argument in the 
STF context.

Another option is for the design to be set before the bounty as Timo suggests. 
Or maybe that's the same thing if you treat the SoW as a legalese embodiment 
of the design.

-- 
Rémi Denis-Courmont
Suomen Uusimaa



_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

  parent reply	other threads:[~2025-11-06 19:42 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-14  2:40 [FFmpeg-devel] " Michael Niedermayer via ffmpeg-devel
2025-10-14 19:16 ` [FFmpeg-devel] " Michael Niedermayer via ffmpeg-devel
2025-10-14 20:35 ` Michael Niedermayer via ffmpeg-devel
2025-10-14 22:28 ` Timo Rothenpieler via ffmpeg-devel
2025-10-14 22:52   ` Michael Niedermayer via ffmpeg-devel
2025-10-15  4:39     ` Kieran Kunhya via ffmpeg-devel
2025-10-15  8:31       ` Nicolas George via ffmpeg-devel
2025-10-16  9:28         ` Kieran Kunhya via ffmpeg-devel
2025-10-16 11:20         ` Michael Niedermayer via ffmpeg-devel
2025-10-30 19:42           ` Nicolas George via ffmpeg-devel
2025-11-01 23:09             ` Michael Niedermayer via ffmpeg-devel
2025-11-18 19:40               ` Nicolas George via ffmpeg-devel
2025-10-15 14:53 ` Nicolas George via ffmpeg-devel
2025-10-16 11:59   ` Michael Niedermayer via ffmpeg-devel
2025-11-01 23:38 ` Niklas Haas via ffmpeg-devel
2025-11-02  0:50   ` Timo Rothenpieler via ffmpeg-devel
2025-11-02  2:09   ` Michael Niedermayer via ffmpeg-devel
2025-11-03 17:44     ` Niklas Haas via ffmpeg-devel
2025-11-04 19:39       ` Nicolas George via ffmpeg-devel
2025-11-04 20:36         ` Rémi Denis-Courmont via ffmpeg-devel
2025-11-06  8:40           ` Nicolas George via ffmpeg-devel
2025-11-06 14:51             ` Timo Rothenpieler via ffmpeg-devel
2025-11-07 14:00               ` Nicolas George via ffmpeg-devel
2025-11-06 19:42             ` Rémi Denis-Courmont via ffmpeg-devel [this message]
2025-11-05 15:28   ` Lynne via ffmpeg-devel
2025-11-19 18:31 ` ff--- via ffmpeg-devel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6652250.2jxk8BG5qF@basile.remlab.net \
    --to=ffmpeg-devel@ffmpeg.org \
    --cc=remi@remlab.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git