[FFmpeg-devel] Democratization work in progress draft v2

[James Almer]

On 2/1/2025 6:53 PM, Michael Niedermayer wrote:
> Hi James
> 
> On Sat, Feb 01, 2025 at 10:30:21AM -0300, James Almer wrote:
>> On 1/31/2025 9:49 PM, Michael Niedermayer wrote:
>>> Hi James
>>>
>>> On Fri, Jan 31, 2025 at 12:44:50PM -0300, James Almer wrote:
>>>> On 1/31/2025 11:58 AM, Nicolas George wrote:
>>>>> Niklas Haas (12025-01-30):
>>> [...]
>>>>> On the other hand, I believe this whole plan is a bad idea.
>>>> Yes, it is a bad idea. We have had the current system in place for about
>>>> five years now, and besides one or two CC assemblages being inefficient, it
>>>
>>> Do you remember this suggested addition to the FAQ ?
>>> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2025-January/338186.html
>>>
>>> It seems you dont remember it even though this was posted just a few days ago
>>> I knew this is needed to be put in the FAQ ;(
>>
>> I saw it, and i think that patch is anything but objective and completely
>> unacceptable. You're stating your opinion and discrediting a system in an
>> official document in the project's repository itself of all places. Do you
>> not see how absurd that is?
> 
> The system is absurd

The system is fine. One CC was inefficient and it bothered you to the 
point you want to start everything from scratch. It's not reasonable.

, the text points this out in a mocking/ironic way.
> If you want me to reword this in a dry formal way, i can submit such a patch?
> 
> If not, how do you suggest we move forward here ?
> We can replace the GA by a system that is not vulnerable

I ask again, do you have any reason other than an hypothetical scenario 
to think the GA is vulnerable? Or can you mention a point during the 
last five years where any such a vulnerability was taken advantage of?

Shit happened with xz, and now every contributor in FOSS is a suspect? 
You handle the releases, including git tags and tarballs. There's no way 
something like that could happen here. And unlike the people that 
infiltrated that project, everyone here who's active and has access to 
some part of the infrastructure has a very public presence online and 
most even offline in plenty of events and conventions. Not to mention, 
nothing the GA could vote for would even remotely result in someone 
being able to do something like the xz tarball hijack.

If commit access is something you worry about, once we move to 
Gitlab/Forgejo, we can limit the people with MR merging permissions to 
strictly only those in Maintainers. And release/tagging can be further 
limited to only you, to keep things as is.

> We can treat the GA more as guidance and not a final authority

This is trying to declare that an agreed upon system in place will no 
longer be valid because you're not satisfied with how one part of it 
behaved. And if the GA becomes guidance, who or what will be the final 
authority? If it turns out to be a "who", then we'd not be dealing with 
a community managed project anymore.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20250202/5a913f8a/attachment.sig>