Am 27.10.23 um 15:38 schrieb Kieran Kunhya:
On Fri, 27 Oct 2023 at 03:23, Thilo Borgmann via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:
Am 27.10.23 um 03:28 schrieb Kieran Kunhya:
Hi,
On Thu, 26 Oct 2023 at 12:41, Thilo Borgmann via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:
Of course. FFmpeg has a donations account. So the money is already there
and
already used for the reimbursement requests. Whatever we spent it for
needs to
be decided by the community. Spending more money instead of just watch
it
growing is a good thing. That this will lead to more "disaster" is an
assumption
without basis. Even if this does happen and fails, its still better than
not
having even tried.
Reimbursement requests for clearly defined things like travel costs with
receipts, or hardware that the project owns is in no way comparable to
consulting work, contracts, statements of work etc. And the current
swscale
proposal is far from this too.
Yes, of course they are different. Most importantly sponsored development
needs
to be agreed upon beforehand. That does not imply sponsored work is not
clearly
defined. I miss your argument about why it can't be done in this.
Do you seriously think this project will have a sudden outbreak of
professionalism and suddenly start producing detailed contracts and
statements of work?
The current level appear appealing enough to try and see.
It'll end up being a few lines on the mailing list.
Just your pessimistic assumption.
Also, you just advertised FFmpeg and asked for more financial support in
your
talk at Demuxed [1] - so I figure your prefered way of doing that would
be
to
channel money into some company without the community being involved?
Actually if you watched the presentation, I said big companies need to
support maintenance (not the same as bounties) of FFmpeg by hiring
employees to work full time as they do with Linux Kernel maintainers. Or
failing that they can donate to the community - but as you know well the
numbers we have are not enough to hire full time maintainers.
I'm totally fine with you asking big companies to hire devs for FFmpeg
maintenance. That does not relate to my question, though. Do I assume
correctly
that your prefered way of doing that would be to channel money into some
company
without the community being involved?
Contractually yes, this is a better solution. It allows the company to be
in charge of delivery of the maintenance work with a contract behind it.
Do you seriously think big companies will suddenly hand over money to the
community that's got weekly drama around it?
This point was raised to me by a big company that shall remain nameless at
Demuxed.
There is no need for a company to put money in before they are happy with the
community response. If there is no history of such a procedure, uncertainty will
remain. Just another reason to try implementing it.
And companies not liking the procedure in general have several other options
left.
Agreement via mailing list for money is a recipe for disaster. What we
need
are clear statements of work that are voted on by TC.
That's not the purpose of the TC. We of course need to have a good way of
approving or disapproving proposals and of course we need these to be
clearly
defined. I again miss to see your argument why that shall not be possible
on the
ML - everyone on this list knows where your suspicion comes from but
again,
without even having tried, it's just your assumption and should IMHO not
stopping us from trying to implement such a procedure.
The mailing list isn't the be all and end all of all communications and
decision making in the world. History shows it's atrocious for making
decisions.
Many people make valid and succinct points that are outright ignored,
whoever writes the longest wall of text (often with conspiratorial
ramblings that I'm sure go down well with potential donors) seems to get
the most attention (i.e quantity vs quality).
Don't blame mailing lists. It's just the tool we currently use, if we switch to
s.th. else, than it is that. The problem will always exist no matter the tool -
except you want no public access to it. The point is that it goes over FFmpeg's
channel of communication where all project-wide things are discussed and
eventually decided.
Lots of people have left the project (e.g Derek) because of the toxicity of
this mailing list. Even the Linux Kernel realised their mailing list was
toxic and changed.
It's again not the mailing list why they left, but the toxic behaviour from
people using it. Nothing changes in that regard, no matter the tool.
We can't even agree on patch reviews, throwing money into the mix is
throwing gasoline into the fire.
Being in conflict about a patch is completely different to conflict about
some
feature we might want. And no, not everything is as controversial as SDR
or gets
controversial just because it would be sponsored. You think there would
have
been real and non-resolvable opposition against bringing multi-threading
into
ffmpeg.c? You assume a proposed sponsored AV2 decoder will raise such
opposition?
However, since I agree with you that there will be different oppinions,
why
would you think that a e.g. a vote/committee or whatever we will choose
could
not resolve how we deal with these cases?
A conflict over a patch would lead to lack of payment which would enflame
the situation more.
I don't see why this is difficult to understand.
The same is true for any coorporate approach if the patch is meant and payed for
to land in FFmpeg master.
Yes, I would say a proposed AV2 decoder would be a bad idea since it would
be better to build one on top of dav1d.
AV2 will likely have a lot of similarities to AV1.
Maybe not the best example then but I see no point regarding the discussion.
The introduction of money into the voting process isn't exactly a great
idea.
And why is that? How else do you want this community to decide about its money
if it doesn't happen by a vote?
And since you also advertised explicitly for FFlabs - what is your
relation
to
FFlabs? I own 25% of that company and I am not aware of any
relationship.
You
just did advertise FFlabs because... FFlabs exists? FFlabs is a company
co-owned
by some FFmpeg developers, it's not FFmpeg nor can it represent it or
act
on its
behalf.
I linked to the consulting page and also to FFlabs which as far as I know
is the only company offering an SLA on FFmpeg.
If others existed I would have included them.
Nothing wrong about bringing attention to ff.org/consulting or FFlabs.
My question is what your relationship with FFlabs is?
Since you say you are a shareholder, I don't understand the need for this
performative and insulting question you obviously know the answer to.
I don't see why you receive this as insulting. Feel free to ignore.
Like I said, if Collabora or Igalia or Redhat or provided an SLA for FFmpeg
I would have included them.
I neither blame you for just listing FFlabs nor not listing anything else.
That is not why I asked about your FFlabs relationship.
As soon as we pay developers via SPI it can become a good zero-trust
environment
for donators to offer tasks & money to FFmpeg and handle the money flow
via SPI.
The donators can be sure that their issues are handled properly in the
project
(on the ML) and do not flow away into some other sink and the developers
can be
sure to get their money from SPI because the offer is public and backed
by
the
FFmpeg SPI account. Sounds like a quite trustworthy and most importantyl
transparent way to handle things and build up trust in potential
donators
that
the money they spent actually end up with FFmpeg.
Do you really think the way SPI funding is managed currently matches your
description?
That's exactly the point, to find a procedure that works for sponsored
work.
Stefano approves by saying "Approved on my side, pending Michael's
approval."
That won't change because SPI demands it. Done. We can change the names
Stefano
and Michael into whatever, but that's it.
Ok, so you agree it's not actually community driven?
No, it is community driven.
> This is not at all a community driven process where one person can veto
> everything.
What needs to be setup, is a procedure to find FFmpeg's decision about it.
Who transports it to and approves it towards SPI is completely
uninmportant
because it cannot be done against the will of FFmpeg - and yes, SPI checks.
Also blocking by a single individual cannot be done already, doesn't even
matter
if it's Michael or Stefano.
I am not able to parse this paragraph.
Not a single person can veto everything.
Not a single person can approve everything.
I don't think developers should be paid via SPI for this reason.
I think supporting FFmpeg developers via SPI fits perfectly into what we
have
SPI for in the first place - an independant entity that handles the
community
funds with absolute objectivity and no intrinsic interest whatsoever. In
contrast to any company, including (my own-ish) FFlabs.
If there is disagreement (which will be inevitable) SPI will not step in.
Only if non-resolvable. If we setup a procedure, that is solved.
There are a million more important things that don't have a procedure right
now.
These million other things are irrelevant for this discussion.
Some thing's missing procedures is no argument for not creating the procedures
for another thing.
Money is only going to make our current ML drama situation worse.
Circling again. I think everyone long enough on this list agrees with you
that
we have drama potential on almost everything here. However, CC & TC
instanciation proved that we have a way of putting an end to the drama.
We haven't even managed to elect a new TC to even make a decision on
anything.
The same as above. Not managing some thing is no reason not to manage another
thing.
So why don't you want to give it a try at least?
Because it's clearly going to make a bad situation worse.
I don't agree. And you have no argument why nor history to point to, it is your
opinion that the behaviour will, as you say, clearly get worse.
-Thilo
_______________________________________________
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".
