Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: "Jonatas L. Nogueira via ffmpeg-devel" <ffmpeg-devel@ffmpeg.org>
To: Vittorio Giovara <vittorio.giovara@gmail.com>
Cc: "Jonatas L. Nogueira" <jesusalva@spi-inc.org>,
	FFmpeg development discussions and patches
	<ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [RFC] Vote STF/SPI 2024-02
Date: Thu, 1 Feb 2024 16:42:34 -0300
Message-ID: <CALE=2=89t310sWrTZ6sz-YXv+oG3BgJ2gYswwrUx-0JKdv3A=Q@mail.gmail.com> (raw)
In-Reply-To: <CABLWnS8R7azZ5paPZcHF_0jWD2OSwZJrF+--EQSfvQmMWrCMNw@mail.gmail.com>

> The same of course should apply to any other future funding, it must be
either the community (via GA) or a third party setting up the sponsorship.

I honestly didn't understood this part. Maybe because I'm not involved with
FFmpeg internal workings and policies, but could you clarify the exact
differences, here? (How it would work, etc.)

As for the other part of the request, I can't comment on the inclusion or
not of the restriction as that's still FFmpeg internal policies, but from
SPI side, we try to avoid having the liaison approving their own expenses
when it could indeed pose such risk (so if it's a purchase of hardware for
example, there's no need as there are already two other peers reviewing
it). Although usually liaisons avoid such situations on their own and often
provide additional documentation in those cases. This avoids neatly
conflicts of interest, as far as someone approving their own expense goes.
I'm not sure why blocking them from participating altogether would be
necessary, it sounds a bit like an intent to be a punishment and I really
think in such case it should be dealt with separately.

As Michael said, STF expect the procedure to be fair, a restriction which
might look like a witch hunt could be refused regardless of the actual
reason, so in my opinion there are two better ways to make such restriction
and have a better chance of STF accepting it.

1. if Michael, Thilo and me received a penalty from FFmpeg which prevents
them (us?) from doing contractor work for FFmpeg instead of approving the
contract work with restrictions on who can participate, that would remain
fair and be better documented altogether. As another poll, it would also
ensure a right for defense and a well documented motivation. STF would be
more likely to accept in such form. It also maintains the discussion over
sponsorship impartial.

2. Another alternative is making a permanent governance that whoever
procures sponsorships are not able to participate on them. This would
almost definitely be accepted by STF and address better the concerns,
although it might severely hinder FFmpeg capability to procure sponsorships
in future as it serves as a strong incentive to NOT seek sponsorships in
future (and is the main reason why some projects or entities make similar
rules).

Both alternatives should be considered fair by STF unless you really mess
them up, so don't let their demand for fairness to escalate into a "you
must let Jonatas to participate or no money for you!" or similar nonsense.

Of course, if they voluntarily renounce the right to participate that's an
entirely different story. Anyone can do that, but that's entirely up to
them and trying to coerce them into doing so (or not doing so) would be
really frowned upon.

Att.,

Jonatas L. Nogueira (“Jesusalva”)

On Thu, Feb 1, 2024, 14:46 Vittorio Giovara <vittorio.giovara@gmail.com>
wrote:

>
>
> On Thu, Feb 1, 2024 at 5:29 AM Michael Niedermayer <michael@niedermayer.cc>
> wrote:
>
>> Hi all
>>
>> To do the STF/SPI thing properly, and make sure we do what the Community
>> wants.
>> We should do this vote: (unless lots of people reply and say we should
>> skip the vote)
>> (i am also CCing jonatan to make sure the option in the vote actually ask
>> the GA the
>>  right question)
>>
>> The vote description will be as follows:
>> The STF/SPI has suggested us to submit an Application / Scope of work
>> before their february meeting.
>> There are about 2 weeks left.
>> The minimum grant is 150 000 €
>> The next STF meeting is expected to be in may. If we submit in february
>> and are not selected
>> we can probably try again in may. Which would increase our chances
>> If we do not submit in february we can probably submit in may.
>> There is no guarantee that money will be available in may, for example
>> between october 2023
>> and february 2024 no funds where available AFAIK.
>> Wiki page is here:
>> https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024
>>
>>
>> Option A. The Application and Scope of Work from the WIKI shall be
>> submitted to STF/SPI before the february 2024 meeting, disagreements in it
>> shall be decided by the TC. To achieve continuity, submission shall be done
>> by the same person as previous if possible.
>>
>> Option B. No Application and Scope of Work shall be submitted in february
>> 2024
>>
>
> Since all objections and requests for more time have been ignored, and
> this is happening anyway, can we add a small amendment for the sake of
> transparency and for avoiding any conflict of interest? Whoever was
> involved with the STF/SPI talks cannot be the recipient of the sponsorship.
> The same of course should apply to any other future funding, it must be
> either the community (via GA) or a third party setting up the sponsorship.
>
> I'm aware that would exclude Micheal, Thilo, and technically Jonatas, but
> at this point it's the only way I can see this move forward in any
> direction.
>
> Jonatas any feedback on this possibility?
> Thank you
> --
> Vittorio
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

  parent reply	other threads:[~2024-02-01 19:42 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-01  4:29 Michael Niedermayer
2024-02-01 17:45 ` Vittorio Giovara
     [not found]   ` <686A824A-CF8F-4D38-ADFA-C84362DE866F@cosmin.at>
2024-02-01 17:49     ` Cosmin Stejerean via ffmpeg-devel
2024-02-01 19:13   ` Michael Niedermayer
2024-02-01 19:42   ` Jonatas L. Nogueira via ffmpeg-devel [this message]
2024-02-01 21:04     ` Michael Niedermayer
2024-02-01 20:10   ` Rémi Denis-Courmont
2024-02-06 15:14     ` Vittorio Giovara
2024-02-03  3:37 ` Michael Niedermayer
2024-02-03 12:13   ` Stefano Sabatini
2024-02-04  0:42   ` Michael Niedermayer
2024-02-04 10:11     ` Paul B Mahol
2024-02-11 12:38     ` Michael Niedermayer

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='CALE=2=89t310sWrTZ6sz-YXv+oG3BgJ2gYswwrUx-0JKdv3A=Q@mail.gmail.com' \
    --to=ffmpeg-devel@ffmpeg.org \
    --cc=jesusalva@spi-inc.org \
    --cc=vittorio.giovara@gmail.com \
    /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