Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Vittorio Giovara <vittorio.giovara@gmail.com>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] Democratization
Date: Fri, 31 Jan 2025 01:14:07 +0100
Message-ID: <CABLWnS_g38EMr+bRsERVB8awS7o7e-pSdhb6w23qQzBXMNrotw@mail.gmail.com> (raw)
In-Reply-To: <DM8P223MB0365BC45268F6230DC47D400BAE92@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM>

On Fri, Jan 31, 2025 at 12:22 AM Soft Works <
softworkz-at-hotmail.com@ffmpeg.org> wrote:

> > That does not mean it would be worth trying something different. I
> > already
> > listed the incidents I've just seen happen before my eyes in this
> > mailing
> > list and these are not fun incidents. Ideally there should be some
> > guarantee beyond Micheal's word not to repeat them again. What you're
> > saying is "this is how it has always been, therefore we should just
> > accept
> > it", which is unfair, especially to the most active contributors.
>
> I'm not saying you should accept it because "this is how it has always
> been".
> I'm saying you should accept it because the project has a private
> ownership which "is how it has always been".
> This has been clear ever since and for all contributors. The project
> doesn't own the code - you are free to fork at any time and run your own
> thing. But there's nothing from which you could derive any right to demand
> for a change of ownership, neither is there any basis on which you could
> demand any "guarantees" regarding the owner's actions.
>

I think you are missing the point that there is no scenario in which the
drama/protest/bullying/you-name-it will stop, if the current situation
doesn't change. Either Micheal needs to step up as leader of the project
and stop the pretense of democracy, or he lets the community use the
governance that he himself established. This half assed system is
unsurvivable, and the only thing that is being requested is establishing a
process, not transferring control or conspiracy or stuff like that. Please
just stop judging the cover by its book, and try to read some of the
contents.


> > Once again, you are invited to the fosdem meeting and see for
> > yourself what
> > the community really wants.
>
> FOSDEM != "the community"
>

FOSDEM = a good chunk of the community that is interested in the health
enough to travel several kilometers and discuss for hours of the situation
and possible solutions instead of enjoying the conference they wanted to
attend

Way more representative than some people talking in this thread

> This "community" in its current form and appearance and the way it is
> > > represented by its members is fundamentally incapable of leading
> > and
> > > executing control over a project like ffmpeg.
> > > I'm aware that there are projects where this is working, same as
> > I've seen
> > > projects where all members are pretty much on the same line and
> > when
> > > there's a committee with a handful of members, persons leave, other
> > persons
> > > join, but that doesn't change anything because they all share the
> > same
> > > ideas and plans and all are working together hand-in-hand.
> > >
> >
> > This is like your opinion man.
>
> Yes, this is my opinion and it gets confirmed almost any other day when
> reading the ML. That a deeply divided community cannot be given control
> over a project like ffmpeg is just common sense imo, even though I respect
> that you have a different opinion.
>

I don't understand how you don't see that the community is divided
*exactly* because there is no clear control.
And I'm sorry that your opinion is going in the opposite direction, but I
personally don't think there should be a system that favors some people and
not others (insert the list of incidents that you didn't even bother
checking).

> > There are others who are watching this ML from a distance and
> > thinking
> > > about the same - just silently.
> > > We don't know figures, but nobody should think it would be a sure
> > thing
> > > that all "non-buddies" would want and vote for a community
> > ownership.
> >
> > Including people who would like to join the community but are
> > horrified by how things are.
>
> The type of e-mails you are sending to the ML making a substantial part of
> those most "horrifying things".
>

No? The type of emails I am sending are bothering you, that's why you spend
4 times as many words to reply to me. If it makes you happy, believe me I
am _not_ having fun going over and over the same points. But I am also done
with the BS that you seem to spread for whatever reason.


> > And it's 2025, nobody will join a project where the leader can ban at
> will
>
> Hardly anybody cares about that, because nobody wants to write a mail like
> the one you did and, then building up a big drama show around the fact that
> it has been moderated.
>

NO! How can you say something like that! I want these incidents to be
resolved - people need to be held accountable for what they do and what
they say.
You complain that I post the list of incidents too many times, I complain
that these incidents are still pending, and seeking resolution!
Otherwise people can do whatever they want without repercussions, it's pure
chaos and anarchy. Even in a dictatorship there are logical repercussions,
this feels more like kindergarten!

*That* is enough motivation to fight for change and *having a process*.


> I think the procedure wasn't okay, but I also think that the e-mail wasn't
> okay, so ideally it should have been moderated by an established procedure,
> yet the outcome would have been the same, that's why I don't share the
> excitement expressed by some others.
>
> > hussle sponsors
>
> No new contributor will care about that.
>

If you don't care about that, it's your problem, but you shouldn't defend a
system that allows for that tho, it's called collusion.


> > > Finally, there are also contributors who don't care about
> > community,
> > > membership or influence - they just want to get their code merged
> > without
> > > trouble. Will they vote for a community governance where every
> > little nit
> > > from someone will require to conduct a vote on it?
> > >
> >
> > Another "what if" of an unlikely scenario
>
> Unlikely? That applies to all those contributors who I met in the past
> years, tried to make a contribution and walked away with the conclusion
> that it's pointless and not worth trying ever again in the future!
>
> > in the unlikely case of conflict we have a TC that does what you
> describe when needed.
> > I'm sure you understand 5 people have an easier time managing a case
> than the whole community.
>
> This it totally ineffective. The current reality (especially for
> non-established contributors) is often something like this:
>
>
> - You make a submission
>   - Either nobody ever reacts
>   - Or:
>     - ffMember1 says "no" to A and B
>     - ffMember2 says "no" to C
> - Of course nobody told you what to do instead, so you need
>   to "guess" what they want and make an updated submission with
>   changes A1, B1 and C1
>   - Then
>     - ffMember1 says "no" to B1 (nothing against A1)
>     - ffMember2 says "no" to C1 and now also D
>     - ffMember3 says "no" to A1 and E
> - Next guessing to address issues with A2, B2, C2, D1 and E1
>   - Then
>     - ffMember1 says nothing
>     - ffMember2 says nothing
>     - ffMember3 says "no" E1 and now also G
> - Next guessing to address issues: E2 and G1
>   - Then
>     - ffMember1 says nothing
>     - ffMember2 says nothing
>     - ffMember3 says nothing
> - You bump, you ping - no response
> - You bump and ping
>     - ffMember1 says "I have told you that B1 is "no" and A1 is "no"
>       (has never reviewed A2 and B2)
>     - ffMember3 says "like ffMember1 said, as long you don't fix A1,
>       it can't be merged"
>       (even though he had asked for A2 and seemingly accepted A2 by not
>       mentioning it on the next review)
> - Now you stand there without even having a clue what to do to satisfy
>   everyone. If you are keen, you might ask again what to do instead, but
>   while you can get lots of responses for the "no"s, you rarely get
>   responses on the "how then?" questions, probably because ffMemberX
>   is too afraid of seeing an ffMemberY contradicting.
>
> And then the contributor should contact the TC?
>
> - First of all, most don't even know about its existence
> - If one knows about its existence, one might still not know how to
> contact it
> - And finally, you don't even know exactly which question/request to make
> to the TC
>   - It's not like you want X and somebody else wants Y
>   - It's rather like some said no to A, A1, nobody said something to A2
> and you would happily do A3 or A4 or A5 or A6 - because you don't care but
> you are tired of guessing
>
>
> What an external contributor wants instead is this:
>
> - You make a submission
>   - Maintainer says
>     - A needs to be done like A1
>     - B needs to be done like B1
>   - PersonInCharge  says
>     - C needs to be done like C1
>     - D needs to be done like D1
> - You make changes A1, B1, C1, D1
>   - Maintainer LGTM
>   - PersonInCharge says C1 should better be like C2
> - You make changes C2
>   - PersonInCharge says LGTM
> - Merged + Done
>
>
> Hardly any external contributor is interested in any committees or having
> the community voting about their contributions. They just want to get
> attention and be told what to do to get their code into a form that it will
> get merged - as simple as that.
>

So you're disagreeing with Micheal that every contributor should get a vote.
Good, something we agree on :)


> Before calling for a vote, they will rather give up and walk away. But in
> case they already made a few contributions and are entitled to vote, they
> will surely not vote for something which makes their contribution process
> even more complicated, lengthy and unpredictable.
>

In general dismissing something because it's complicated is not a good view
of any developer.

Let's Calculate
>
> - Remainder = "The Commnunity"
>   - minus "Michael's Buddies"
>   - minus members like me who don't consider the community
>     capable of managing the project
>   - minus members working for the industry
>   - minus occasional contributors without interest in the project
>   - minus all those who have other reasons against community
>     ownership
>
> Conclusions
>
> - It is not valid to make any claims like
>   "The Community wants the project to be owned by the community"
> - It is not even valid to make any claims like
>   "The majority of the Community wants the project to be owned by the
> community"
>

- It is not valid to make made up math and trying to prove a point
- It is not even valid to butt in in a discussion without having any idea
what is going on and lacking knowledge on what led to the current situation
- It is not even more so valid to spam the mailing list with overly long
emails which take a long time to debunk and divert the attention from
actual important work (like porting to gitlab)


> The latter isn't valid because we don't have figures, so we just can't
> know.
> For me, it doesn't look there's a majority for it, just a few people
> asking for it very loudly.
>

Sorry this is an uninformed opinion, the "other side" also sees a few
people asking very loudly to keep things as they are.
Do I need to post the list of incidents again so that you may inform
yourself and decide what you would have done if you were in the shoes of
someone affected negatively by the current system? Or are my emails the
problem, while other people directly causing contributions to leave the
project are just fine?


> Besides that, it's already clear that this won't happen, even when a
> majority would want it, so it's probably more productive to accept that and
> rather participate in the suggestions that Michael is making, keeping in
> mind that he isn't obliged to do this at all.
>

That's fine, it means that the "unfriendly emails" will continue.
-- 
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".

  reply	other threads:[~2025-01-31  0:14 UTC|newest]

Thread overview: 113+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20250102141731.GR4991@pb2>
     [not found] ` <20250102163807.GB7285@haasn.xyz>
     [not found]   ` <20250114170615.GD4991@pb2>
     [not found]     ` <eafdd773-0055-4619-b1e2-bf4d4266ee4e@gmail.com>
     [not found]       ` <20250117173914.GN4991@pb2>
     [not found]         ` <f5f57e16-8f34-4836-9b46-f31a753dd990@gmail.com>
2025-01-20  1:28           ` Michael Niedermayer
2025-01-20  6:21             ` Kieran Kunhya via ffmpeg-devel
2025-01-20 15:45 ` Soft Works
2025-01-20 16:15   ` Marth64
2025-01-20 16:38     ` Marth64
2025-01-21  0:36       ` Michael Niedermayer
2025-01-24 19:36         ` Rémi Denis-Courmont
2025-01-24 21:02           ` Nicolas George
2025-01-25  6:21             ` Rémi Denis-Courmont
2025-01-25  7:55           ` Vittorio Giovara
2025-01-25 20:26           ` Michael Niedermayer
2025-01-25 21:08             ` Rémi Denis-Courmont
2025-01-25 21:39             ` Rémi Denis-Courmont
2025-01-25 22:13               ` Marth64
2025-01-25 23:23               ` Kieran Kunhya via ffmpeg-devel
2025-01-25 22:40             ` Marth64
2025-01-26 15:06               ` Michael Niedermayer
2025-01-26 15:11                 ` Kieran Kunhya via ffmpeg-devel
2025-01-26 16:35                 ` Rémi Denis-Courmont
2025-01-26 17:34                   ` Marth64
2025-01-26 18:07                     ` Marth64
2025-01-26 18:43                       ` Gyan Doshi
2025-01-26 18:51                         ` Marth64
2025-01-26 19:17                     ` Michael Niedermayer
2025-01-26 19:39                       ` Kieran Kunhya via ffmpeg-devel
2025-01-26 20:40                         ` Rémi Denis-Courmont
2025-01-26 20:51                           ` Kieran Kunhya via ffmpeg-devel
2025-01-26 21:20                             ` Kieran Kunhya via ffmpeg-devel
2025-01-26 22:01                             ` Marth64
2025-01-28 18:21                               ` Michael Niedermayer
2025-01-29  6:40                                 ` Zhao Zhili
2025-01-29 12:39                                   ` Nicolas George
2025-01-29 15:16                                     ` Niklas Haas
2025-01-29 16:12                                       ` compn
2025-01-29 16:22                                         ` Vittorio Giovara
2025-01-29 17:02                                         ` Soft Works
2025-01-29 17:41                                           ` Marth64
2025-01-29 18:26                                             ` Marth64
2025-01-29 19:36                                               ` Kieran Kunhya via ffmpeg-devel
2025-01-29 20:20                                                 ` Marth64
2025-01-29 20:54                                                   ` Nicolas George
2025-01-29 21:08                                                     ` Marth64
2025-01-29 21:45                                                       ` Nicolas George
2025-01-30  6:12                                                         ` Vittorio Giovara
2025-01-30  8:02                                                           ` Nicolas George
2025-01-30  9:45                                                             ` Vittorio Giovara
2025-01-31  0:03                                                               ` Soft Works
2025-01-31  0:14                                                                 ` Vittorio Giovara
2025-02-01 13:50                                                 ` Michael Niedermayer
2025-01-29 20:04                                         ` Ronald S. Bultje
2025-01-29 21:27                                         ` Niklas Haas
2025-01-29 21:39                                           ` Nicolas George
2025-02-01 14:15                                           ` Michael Niedermayer
2025-01-29 20:51                                       ` Nicolas George
2025-01-29 21:21                                         ` Niklas Haas
2025-01-29 21:36                                           ` Nicolas George
2025-01-30  6:08                                             ` Vittorio Giovara
2025-01-29 23:26                                           ` Soft Works
2025-01-30  6:35                                             ` Vittorio Giovara
2025-01-30 23:21                                               ` Soft Works
2025-01-31  0:14                                                 ` Vittorio Giovara [this message]
2025-01-31  1:07                                                   ` Soft Works
2025-01-30  9:50                                           ` Vittorio Giovara
2025-02-01 14:46                                           ` Michael Niedermayer
2025-02-01 14:48                                             ` Kieran Kunhya via ffmpeg-devel
2025-02-01 15:03                                               ` Michael Niedermayer
2025-02-01 16:10                                                 ` Kieran Kunhya via ffmpeg-devel
2025-02-01 15:11                                             ` James Almer
     [not found]                                               ` <dffa122a-f13a-4e95-8210-9053a6832e6a@e-blokos.com>
2025-02-01 16:03                                                 ` James Almer
2025-02-01 20:18                                               ` Nicolas George
2025-02-01 13:44                                       ` Michael Niedermayer
2025-02-01 20:20                                         ` Nicolas George
2025-02-01 21:00                                           ` Soft Works
2025-01-29  9:45                                 ` Vittorio Giovara
2025-01-29 10:32                                   ` Soft Works
2025-01-29 10:51                                     ` Vittorio Giovara
2025-01-29 11:52                                       ` Soft Works
2025-01-29 14:38                                         ` Vittorio Giovara
2025-01-29 15:24                                           ` Soft Works
2025-01-29 16:24                                             ` Vittorio Giovara
2025-01-29 16:44                                               ` Soft Works
2025-01-30  8:02                                         ` Tobias Rapp
2025-01-29 16:58                                     ` Marth64
2025-01-29 17:06                                       ` Soft Works
2025-01-29 17:14                                         ` Marth64
2025-01-29 17:22                                           ` Soft Works
2025-01-29 17:38                                             ` Vittorio Giovara
2025-01-29 18:13                                             ` Soft Works
2025-01-29 18:23                                               ` Marth64
2025-01-29 17:15                                       ` Soft Works
2025-01-26 21:24                         ` Michael Niedermayer
2025-01-26 21:41                           ` Kieran Kunhya via ffmpeg-devel
2025-01-27  9:03                           ` Vittorio Giovara
2025-01-20 17:44     ` Soft Works
2025-01-20 18:14       ` Gyan Doshi
2025-01-20 21:04         ` Nicolas George
2025-01-21  0:41         ` Michael Niedermayer
2025-01-21  6:52           ` Soft Works
2025-01-25 18:04             ` Michael Niedermayer
2025-01-24 20:01         ` Rémi Denis-Courmont
2025-01-20 17:59     ` Nicolas George
2025-01-20 18:18       ` Marth64
2025-01-20 18:46         ` Soft Works
2025-01-20 20:57         ` Nicolas George
2025-01-20 21:08           ` Marth64
2025-01-20 22:20             ` Marth64
2025-01-20 18:23       ` Marth64
2025-01-20 20:50         ` Nicolas George
2025-01-20 21:00           ` Soft Works
2025-01-21  0:55             ` Michael Niedermayer
2025-01-21  4:29               ` Marth64
2025-01-22 20:51               ` Nicolas George
2025-01-22 22:00                 ` Soft Works

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=CABLWnS_g38EMr+bRsERVB8awS7o7e-pSdhb6w23qQzBXMNrotw@mail.gmail.com \
    --to=vittorio.giovara@gmail.com \
    --cc=ffmpeg-devel@ffmpeg.org \
    /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