[FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[Kyle Swanson]

Hi,

Here are my notes from the VDD meeting. If I missed anything, please feel
free to send corrections.

Thanks,
Kyle


Voting
------

General Assembly:
-   Original 2020 general assembly: <https://0x0.st/HVz-.txt>
-   Proposal: General Assembly is determined twice a year on January 1st,
and July 1st.
-   The criteria for General Assembly inclusion is 20 commits with
authorship in the last 18 months.
-   Current General Assembly will vote on vote.ffmpeg.org to enact the
above proposal, J-B will setup.
-   Admission of the extra members to the GA will be voted on separately
well.

General Assembly, Candidates (J-B will mail a vote):
-   BBB
-   Derek

Technical Committee, Candidates (J-B will mail a vote):
-   JEEB
-   Anton
-   Lynne
-   wbs
-   haasn
-   MN
-   Mark

Community Committee, Candidates (J-B will mail a vote):
-   Dave Rice
-   James
-   J-B
-   Thilo
-   Steven
-   BBB

Gitlab (or something like Gitlab)
---------------------------------

-   Ronald is proposing that we move to Gitlab, or something similar
(gitea).
-   Michael says "i don't like Gitlab"; Ronald says the exact tool is not
important and we can work together to make sure that the new tool suits
other styles of work, such as command line tools.
-   No strong dissent in the room, acceptable to most.
-   This change will need to be voted on by today's General Assembly (J-B
will mail a vote).
-   We need to make sure that "drive by contributions" do not have a high
barrier of entry (i.e. must create a new Gitlab user to submit patches,
issues).
-   We could find a way to accept "off Gitlab" patches, the workflow needs
to be well documented.
-   We need to ensure we have people to do the work, doesn't seem like a
huge issue.
-   J-B recommends against gitea, suggesting that we piggyback on the
videolan Gitlab experience infra.

DNS
---

-   Currently the DNS of ffmpeg.org is managed by Fabrice
-   Michael was asked if he has control over the ffmpeg.org DNS register.
-   Michael says he thinks he has some.
-   Ronald would be curious to know what "some" means.
-   Ronald proposes current project owners should have control over DNS and
trademark.
-   Ronald: Fabrice is not active, DNS and trademark should be in the
control of project members.
-   Michael: "i think fabrice should stay in ultimate control", "he has
always acted in the best interests of the people".
-   Ronald took a poll in the room, most agreed current project developers
should have control of this.
-   This will need a vote, Fabrice will need to be contacted.
-   We would prefer to bring voting results to Fabrice, hopeful that
Fabrice would be amicable to handover.

SDR (software defined radio)
----------------------------

-   Michael says, "just merge it"
-   J-B, "the problem is no one wants it in FFmpeg except you"
-   Ronald, "this should be an external library, like libdav1d", would be
fine if external library.
-   Michael: "it can become a separate library within ffmpeg but it should
be merged first"
-   Paul "burden to maintain it is huge, adding it will fragment
contributions even more"
-   Michael, rational to merge: "there's no API/ABI it needs users first"
-   Ronald asks if Michael wants to bring this to a TC vote?
-   Michael will try to write a mail to ffmpeg-devel on this topic, and
probably ask for a vote.
-   Kieran asks Michael to confirm that SDR will not be merged into 6.1
-   Michael says he will make an alternative 6.1 release
-   On where the fork is published, Michael says "this depends on the
community"
-   Ronald, Kieran, others want to confirm this is not published in a way
that it makes it seem like ffmpeg endorses SDR

Stream Groups
-------------

-   Anton introduces the topic of stream groups, a concept for bundling
many streams with metadata.
-   Many probable use cases: separate alpha, enhancement layers, HEIF,
IAMF, etc.
-   Derek asks about API, Anton suggests an array of structs in avformat.
-   J-B: We need to start this, and see how this goes.
-   decoder/filters would not be aware of stream groups, there may be some
cases where this may be limiting. Derek mentions something about
DolbyVision.
-   Not limited to video, could be used for audio, etc.
-   AVFormat should export stream groups, "everyone agrees"

AVFrame Subtitles
-----------------

-   Lynne cares about this, and hasn't done work on this yet.
-   Lynee suggests she could make time to collaborate with others on this.
-   Anton, others, say it makes sense to do this to avoid special handling
of subtitles, filtering, etc.
-   We should do it, someone needs to take this on.

Sidedata
--------

-   JEEB asks if there is any reason that we use two overlapping
functionality, metadata can reside in either AVPacket and AVFrame.
-   Agreed that it is nice to have, the benefit is small but the work is
large.

MMX, self modifying code
------------------------

-   We should remove it

MPEG-2 Fast
-----------

-   We should remove it

7.0
---

-   If there is to be a new major release (7.0) in January we need to get
started on the work.
-   We need to define/agree on a depreciation and removal timeline. This
needs to be documented.
-   If you want to deprecate things in time, get started on this work ASAP.
_______________________________________________
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".

Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[Matthias Dressel]

Hi,

the date in subject is wrong.
23-09-2023 or in ISO format 2023-09-23

Matthias


On 24.09.23 10:37, Kyle Swanson wrote:
> Hi,
> 
> Here are my notes from the VDD meeting. If I missed anything, please feel
> free to send corrections.
> 
> Thanks,
> Kyle
> 
> 
> Voting
> ------
> 
> General Assembly:
> -   Original 2020 general assembly: <https://0x0.st/HVz-.txt>
> -   Proposal: General Assembly is determined twice a year on January 1st,
> and July 1st.
> -   The criteria for General Assembly inclusion is 20 commits with
> authorship in the last 18 months.
> -   Current General Assembly will vote on vote.ffmpeg.org to enact the
> above proposal, J-B will setup.
> -   Admission of the extra members to the GA will be voted on separately
> well.
> 
> General Assembly, Candidates (J-B will mail a vote):
> -   BBB
> -   Derek
> 
> Technical Committee, Candidates (J-B will mail a vote):
> -   JEEB
> -   Anton
> -   Lynne
> -   wbs
> -   haasn
> -   MN
> -   Mark
> 
> Community Committee, Candidates (J-B will mail a vote):
> -   Dave Rice
> -   James
> -   J-B
> -   Thilo
> -   Steven
> -   BBB
> 
> Gitlab (or something like Gitlab)
> ---------------------------------
> 
> -   Ronald is proposing that we move to Gitlab, or something similar
> (gitea).
> -   Michael says "i don't like Gitlab"; Ronald says the exact tool is not
> important and we can work together to make sure that the new tool suits
> other styles of work, such as command line tools.
> -   No strong dissent in the room, acceptable to most.
> -   This change will need to be voted on by today's General Assembly (J-B
> will mail a vote).
> -   We need to make sure that "drive by contributions" do not have a high
> barrier of entry (i.e. must create a new Gitlab user to submit patches,
> issues).
> -   We could find a way to accept "off Gitlab" patches, the workflow needs
> to be well documented.
> -   We need to ensure we have people to do the work, doesn't seem like a
> huge issue.
> -   J-B recommends against gitea, suggesting that we piggyback on the
> videolan Gitlab experience infra.
> 
> DNS
> ---
> 
> -   Currently the DNS of ffmpeg.org is managed by Fabrice
> -   Michael was asked if he has control over the ffmpeg.org DNS register.
> -   Michael says he thinks he has some.
> -   Ronald would be curious to know what "some" means.
> -   Ronald proposes current project owners should have control over DNS and
> trademark.
> -   Ronald: Fabrice is not active, DNS and trademark should be in the
> control of project members.
> -   Michael: "i think fabrice should stay in ultimate control", "he has
> always acted in the best interests of the people".
> -   Ronald took a poll in the room, most agreed current project developers
> should have control of this.
> -   This will need a vote, Fabrice will need to be contacted.
> -   We would prefer to bring voting results to Fabrice, hopeful that
> Fabrice would be amicable to handover.
> 
> SDR (software defined radio)
> ----------------------------
> 
> -   Michael says, "just merge it"
> -   J-B, "the problem is no one wants it in FFmpeg except you"
> -   Ronald, "this should be an external library, like libdav1d", would be
> fine if external library.
> -   Michael: "it can become a separate library within ffmpeg but it should
> be merged first"
> -   Paul "burden to maintain it is huge, adding it will fragment
> contributions even more"
> -   Michael, rational to merge: "there's no API/ABI it needs users first"
> -   Ronald asks if Michael wants to bring this to a TC vote?
> -   Michael will try to write a mail to ffmpeg-devel on this topic, and
> probably ask for a vote.
> -   Kieran asks Michael to confirm that SDR will not be merged into 6.1
> -   Michael says he will make an alternative 6.1 release
> -   On where the fork is published, Michael says "this depends on the
> community"
> -   Ronald, Kieran, others want to confirm this is not published in a way
> that it makes it seem like ffmpeg endorses SDR
> 
> Stream Groups
> -------------
> 
> -   Anton introduces the topic of stream groups, a concept for bundling
> many streams with metadata.
> -   Many probable use cases: separate alpha, enhancement layers, HEIF,
> IAMF, etc.
> -   Derek asks about API, Anton suggests an array of structs in avformat.
> -   J-B: We need to start this, and see how this goes.
> -   decoder/filters would not be aware of stream groups, there may be some
> cases where this may be limiting. Derek mentions something about
> DolbyVision.
> -   Not limited to video, could be used for audio, etc.
> -   AVFormat should export stream groups, "everyone agrees"
> 
> AVFrame Subtitles
> -----------------
> 
> -   Lynne cares about this, and hasn't done work on this yet.
> -   Lynee suggests she could make time to collaborate with others on this.
> -   Anton, others, say it makes sense to do this to avoid special handling
> of subtitles, filtering, etc.
> -   We should do it, someone needs to take this on.
> 
> Sidedata
> --------
> 
> -   JEEB asks if there is any reason that we use two overlapping
> functionality, metadata can reside in either AVPacket and AVFrame.
> -   Agreed that it is nice to have, the benefit is small but the work is
> large.
> 
> MMX, self modifying code
> ------------------------
> 
> -   We should remove it
> 
> MPEG-2 Fast
> -----------
> 
> -   We should remove it
> 
> 7.0
> ---
> 
> -   If there is to be a new major release (7.0) in January we need to get
> started on the work.
> -   We need to define/agree on a depreciation and removal timeline. This
> needs to be documented.
> -   If you want to deprecate things in time, get started on this work ASAP.
> _______________________________________________
> 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".
_______________________________________________
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".

Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 5402 bytes --]

Hi

Iam a little tired so expect a more tidy mail in a few days but i want to
reply with a few points immedeately as they seem important.


On Sun, Sep 24, 2023 at 09:37:03AM +0100, Kyle Swanson wrote:
> Hi,
> 
> Here are my notes from the VDD meeting. If I missed anything, please feel
> free to send corrections.
> 
> Thanks,
> Kyle
> 
> 
> Voting
> ------
> 
> General Assembly:
> -   Original 2020 general assembly: <https://0x0.st/HVz-.txt>
> -   Proposal: General Assembly is determined twice a year on January 1st,
> and July 1st.
> -   The criteria for General Assembly inclusion is 20 commits with
> authorship in the last 18 months.
> -   Current General Assembly will vote on vote.ffmpeg.org to enact the
> above proposal, J-B will setup.
> -   Admission of the extra members to the GA will be voted on separately
> well.

First this needs to be discusssed, you cant just dump a bunch of
very signifcant project changes and general assembly changes and start voting
on them.

Conveniently this also seems initiated by the people gaining more control over the
project if some of the votes pass. (not accusing anyone here, just noting the
correlation)


> 
> General Assembly, Candidates (J-B will mail a vote):
> -   BBB
> -   Derek

Quite interresting that every single developer who probably isnt going to support
some of the significant changes proposed later disappeared from the Previous
Candidates

I think you should at least post a list of people who would loose vote power
then that can be a start of proposed additional candidates


> 
> Technical Committee, Candidates (J-B will mail a vote):
> -   JEEB
> -   Anton
> -   Lynne
> -   wbs
> -   haasn
> -   MN
> -   Mark
> 

> Community Committee, Candidates (J-B will mail a vote):
> -   Dave Rice
> -   James
> -   J-B
> -   Thilo
> -   Steven
> -   BBB

Iam missing carl on the list


> 
> Gitlab (or something like Gitlab)
> ---------------------------------
> 
> -   Ronald is proposing that we move to Gitlab, or something similar
> (gitea).
> -   Michael says "i don't like Gitlab"; Ronald says the exact tool is not
> important and we can work together to make sure that the new tool suits
> other styles of work, such as command line tools.

> -   No strong dissent in the room, acceptable to most.

strong dissent by me against any move making FFmpeg more dependant on
other projects. (videolan or gitlhub or whatevr)

also IMO major changes cannot be done with just 51% majority, thats not really
normal.

iam not fundamentally against moving to better software (hell, why would i)
but trac and git work fine
and fate well, some fate clients are down since i moved one of my
boxes and forgot to restart them. And of course noone reminded me
(ill look into restarting them after this conference reminded me)
No SW is going to safe you of this sort of issue

Also SW must be easy maintainable, everything i hear of gitlab is saying
the opposit.
It must be possible that when something happens to our servers no matter
if videolan or micosoft or our own. That everything can be recovered
and quickly put back in action without too much server admins cooperation
(they could be sick or arrested or joined the wrong FOSS cult)
plain git allows easy recovery, trac has backups in the hands
of multiple people (these backups are the drop it in a directory and start
it more or less kind IIRC)

again IMO any change to what SW we use needs more discussion than a
"who likes gitlab, who likes gitwhatever" vote


[...]
> DNS
> ---
> 
> -   Currently the DNS of ffmpeg.org is managed by Fabrice
> -   Michael was asked if he has control over the ffmpeg.org DNS register.
> -   Michael says he thinks he has some.
> -   Ronald would be curious to know what "some" means.

We have control over everything we need, like zonefiles and DNS servers
sorry for not replying fuller yesterday but this discussion (as well as others)
came as a total surprise and i was a bit sick and still am.

So iam sorry but i think theres nothing we need from fabrice unless the
goal is to take FFmpeg over from the current community

also id like to note that these surprise agenda points are uncool


[...]
> 
> SDR (software defined radio)
> ----------------------------

I have comments about SDR but SDR really is not important ATM.
also i just like to reiterate I wont do anything that the FFmpeg community
doesnt want (unless maybe on april the first)
There seems a disagreement on what the position of the community is and
yeah if we dont resolve this, i will bring it to a vote but of course
I still have hope that we can reach a consensus on SDR, instead of a 55%
vs 45% kind of thing.
The actual disagreement on SDR is not as big as it may seem ATM i think.


[...]

> MMX, self modifying code
> ------------------------
> 
> -   We should remove it

you should first provide an argument for its removial


> 
> MPEG-2 Fast
> -----------
> 
> -   We should remove it

frankly i am not really against if it causes a problem though as long as it
doesnt it could as well stay.
but again you should write an argument first


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What does censorship reveal? It reveals fear. -- Julian Assange

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[Jean-Baptiste Kempf]

>> General Assembly, Candidates (J-B will mail a vote):
>> -   BBB
>> -   Derek
>
> Quite interresting that every single developer who probably isnt going 
> to support
> some of the significant changes proposed later disappeared from the 
> Previous
> Candidates

What are you talking about? This is just people in the room, who asked to be in the extra bucket, because they don't have the required commit numbers. It does not mean it's the complete list.

>> Community Committee, Candidates (J-B will mail a vote):
>> -   Dave Rice
>> -   James
>> -   J-B
>> -   Thilo
>> -   Steven
>> -   BBB
>
> Iam missing carl on the list

As above.



-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
_______________________________________________
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".

Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[Derek Buitenhuis]

On 9/24/2023 11:13 AM, Jean-Baptiste Kempf wrote:
> What are you talking about? This is just people in the room, who asked to be in the extra bucket, because they don't have the required commit numbers. It does not mean it's the complete list.

I do have the relevant commit numbers, I was informed, FWIW. I was mistaken.

- Derek
_______________________________________________
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".

Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[Ronald S. Bultje]

Hi Michael,

On Sun, Sep 24, 2023 at 11:09 AM Michael Niedermayer <michael@niedermayer.cc>
wrote:

> On Sun, Sep 24, 2023 at 09:37:03AM +0100, Kyle Swanson wrote:
> > Gitlab (or something like Gitlab)
> > ---------------------------------
> >
> > -   Ronald is proposing that we move to Gitlab, or something similar
> > (gitea).
> > -   Michael says "i don't like Gitlab"; Ronald says the exact tool is not
> > important and we can work together to make sure that the new tool suits
> > other styles of work, such as command line tools.
>
> > -   No strong dissent in the room, acceptable to most.
>
> strong dissent by me against any move making FFmpeg more dependant on
> other projects. (videolan or gitlhub or whatevr)
>
> also IMO major changes cannot be done with just 51% majority, thats not
> really
> normal.
>
> iam not fundamentally against moving to better software (hell, why would i)
> but trac and git work fine
> and fate well, some fate clients are down since i moved one of my
> boxes and forgot to restart them. And of course noone reminded me
> (ill look into restarting them after this conference reminded me)
> No SW is going to safe you of this sort of issue
>
> Also SW must be easy maintainable, everything i hear of gitlab is saying
> the opposit.
> It must be possible that when something happens to our servers no matter
> if videolan or micosoft or our own. That everything can be recovered
> and quickly put back in action without too much server admins cooperation
> (they could be sick or arrested or joined the wrong FOSS cult)
> plain git allows easy recovery, trac has backups in the hands
> of multiple people (these backups are the drop it in a directory and start
> it more or less kind IIRC)
>
> again IMO any change to what SW we use needs more discussion than a
> "who likes gitlab, who likes gitwhatever" vote
>

Briefly: don't expect any quick activity here that affects anyone. My goal
here was to see if we (as a GA) can find some kind of consensus to look
into alternatives to our current trac/patchwork/fate/git workflow. That
doesn't mean everything is bad: git is great. I find the "integrated
developer experience" very lacking, though. We use a different system in
dav1d and it is by far superior. (Please voice your +1/-1 here.)

There are many important details to be worked out and kinks to be
resolved.  Michael named some. I agree with most of what Michael says. Own
control is critical, and we should not rely on outside parties. Anton had a
whole bunch also, for example about commandline accessibility of the full
feature set of a developer workflow, including efficient patch review that
does not require a web browser. I agree with that also. I don't mean to
take your workflow away from you.

Ronald
_______________________________________________
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".

Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[Nicolas George]

[-- Attachment #1.1: Type: text/plain, Size: 361 bytes --]

Michael Niedermayer (12023-09-24):
> Also SW must be easy maintainable, everything i hear of gitlab is saying
> the opposit.

I have not read the rest of the message yet, for now I just want to
mention that a non-negligible part of my job in the last year involved
upgrading GitLab after emergency security releases.

Regards,

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 3430 bytes --]

Hi

Ill add a few points to sw/infrastructure point here

On Sun, Sep 24, 2023 at 12:09:38PM +0200, Michael Niedermayer wrote:
[...]
> On Sun, Sep 24, 2023 at 09:37:03AM +0100, Kyle Swanson wrote:
[...]
> > Gitlab (or something like Gitlab)
> > ---------------------------------
> > 
> > -   Ronald is proposing that we move to Gitlab, or something similar
> > (gitea).
> > -   Michael says "i don't like Gitlab"; Ronald says the exact tool is not
> > important and we can work together to make sure that the new tool suits
> > other styles of work, such as command line tools.
> 
> > -   No strong dissent in the room, acceptable to most.
> 
> strong dissent by me against any move making FFmpeg more dependant on
> other projects. (videolan or gitlhub or whatevr)
> 
> also IMO major changes cannot be done with just 51% majority, thats not really
> normal.
> 
> iam not fundamentally against moving to better software (hell, why would i)
> but trac and git work fine
> and fate well, some fate clients are down since i moved one of my
> boxes and forgot to restart them. And of course noone reminded me
> (ill look into restarting them after this conference reminded me)
> No SW is going to safe you of this sort of issue
> 
> Also SW must be easy maintainable, everything i hear of gitlab is saying
> the opposit.
> It must be possible that when something happens to our servers no matter
> if videolan or micosoft or our own. That everything can be recovered
> and quickly put back in action without too much server admins cooperation
> (they could be sick or arrested or joined the wrong FOSS cult)
> plain git allows easy recovery, trac has backups in the hands
> of multiple people (these backups are the drop it in a directory and start
> it more or less kind IIRC)
> 
> again IMO any change to what SW we use needs more discussion than a
> "who likes gitlab, who likes gitwhatever" vote

I think its very important that we do not loose independance and run
our own infrastructure.

That said.

I think we should make a detailed list of what people actually want
closing bugs with git commits ?
creating new tickets with mails ?
controlling the whole infrastructure from the command line ?
...

then with sw/implementation options then
(maybe some of the wanted things can be easily added even to some infrastructure options
 that otherwise lack them)

expected costs (admin time) of each and
expected benefits (developer time saved)

then for a fixed factor of how much admin time is equivalnet to developer time
you can show what would be optimal.
Its like a encoder finding the best encoding with RD

Then make a sanity check to see if the result actually makes sense and is
what people want.

I think even if the funky idea above fails it would lead to a valuable
thought process about the cost and benefit of various things

Then decide who will admin the sw  and then we will setup a new VM on our
server and setup the new infrastructure on the new VM ...

OTOH
Giving up independance, which again i strongly oppose, would need to be a seperate
vote, It cannot be a sideeffect of updating our infrastructure
like some sugar laced cyanide pill

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[Anton Khirnov]

Quoting Michael Niedermayer (2023-09-27 20:03:12)
> > again IMO any change to what SW we use needs more discussion than a
> > "who likes gitlab, who likes gitwhatever" vote
> 
> I think its very important that we do not loose independance and run
> our own infrastructure.
> 
> That said.
> 
> I think we should make a detailed list of what people actually want
> closing bugs with git commits ?
> creating new tickets with mails ?
> controlling the whole infrastructure from the command line ?
> ...
> 
> then with sw/implementation options then
> (maybe some of the wanted things can be easily added even to some infrastructure options
>  that otherwise lack them)
> 
> expected costs (admin time) of each and
> expected benefits (developer time saved)

One highly important potential benefit you're not considering is how
many people fail to become developers because the barrier to entry is
too high or because the project gives off the air of obsolescence.

I do share many of your concerns though, and this should definitely be
considered in detail.

-- 
Anton Khirnov
_______________________________________________
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".

Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[Marton Balint]

On Sun, 24 Sep 2023, Kyle Swanson wrote:

> DNS
> ---
>
> -   Currently the DNS of ffmpeg.org is managed by Fabrice
> -   Michael was asked if he has control over the ffmpeg.org DNS register.
> -   Michael says he thinks he has some.
> -   Ronald would be curious to know what "some" means.
> -   Ronald proposes current project owners should have control over DNS and
> trademark.
> -   Ronald: Fabrice is not active, DNS and trademark should be in the
> control of project members.
> -   Michael: "i think fabrice should stay in ultimate control", "he has
> always acted in the best interests of the people".
> -   Ronald took a poll in the room, most agreed current project developers
> should have control of this.

I think you should define what you are aiming for exactly. Having more 
people control the domain zone, or asking Fabrice to transfer domain 
ownership to someone else or some legal entity.

I doubt anybody has problem with the former, but for the latter, knowing 
history, it will certainly raise eyebrows. IMHO having Fabrice ultimate 
control over the domain ensures that everybody plays nice.

Regards,
Marton
_______________________________________________
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".

Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1659 bytes --]

On Sun, Sep 24, 2023 at 02:36:20PM +0200, Marton Balint wrote:
> 
> 
> On Sun, 24 Sep 2023, Kyle Swanson wrote:
> 
> > DNS
> > ---
> > 
> > -   Currently the DNS of ffmpeg.org is managed by Fabrice
> > -   Michael was asked if he has control over the ffmpeg.org DNS register.
> > -   Michael says he thinks he has some.
> > -   Ronald would be curious to know what "some" means.
> > -   Ronald proposes current project owners should have control over DNS and
> > trademark.
> > -   Ronald: Fabrice is not active, DNS and trademark should be in the
> > control of project members.
> > -   Michael: "i think fabrice should stay in ultimate control", "he has
> > always acted in the best interests of the people".
> > -   Ronald took a poll in the room, most agreed current project developers
> > should have control of this.
> 
> I think you should define what you are aiming for exactly. Having more
> people control the domain zone, [...]

currently all the root admins can update the zone file on the main
DNS server and it will then get pulled to the DNS slaves from there

I guess i have been the one updating it most of the time but the other
admins can too. I also think updates have always been done quickly
And its rare that something needs to be changed in it.
like if between https://fatebeta.ffmpeg.org/ and http://coverage.ffmpeg.org/
you want to setup a fategamma.ffmpeg.org ...

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[Ronald S. Bultje]

Hi,

On Sun, Sep 24, 2023 at 1:40 PM Marton Balint <cus@passwd.hu> wrote:

> On Sun, 24 Sep 2023, Kyle Swanson wrote:
> > DNS
> > ---
> >
> > -   Currently the DNS of ffmpeg.org is managed by Fabrice
> > -   Michael was asked if he has control over the ffmpeg.org DNS
> register.
> > -   Michael says he thinks he has some.
> > -   Ronald would be curious to know what "some" means.
> > -   Ronald proposes current project owners should have control over DNS
> and
> > trademark.
> > -   Ronald: Fabrice is not active, DNS and trademark should be in the
> > control of project members.
> > -   Michael: "i think fabrice should stay in ultimate control", "he has
> > always acted in the best interests of the people".
> > -   Ronald took a poll in the room, most agreed current project
> developers
> > should have control of this.
>
> I think you should define what you are aiming for exactly. Having more
> people control the domain zone, or asking Fabrice to transfer domain
> ownership to someone else or some legal entity.
>
> I doubt anybody has problem with the former, but for the latter, knowing
> history, it will certainly raise eyebrows. IMHO having Fabrice ultimate
> control over the domain ensures that everybody plays nice.
>

I disagree.

Fabrice has theoretical veto power over anything this community does
because he can change the IP ffmpeg.org points to. That is not right. He is
not a participant anymore. I understand he conceived of the project and its
name, but he is no longer part of the developer community in this project.
Most participants (basically everyone) agreed with this.

I don't mean to threaten and I don't mean to own rights to anything myself.
If you don't like me asking to be part of the GA even though I don't meet
the commit count threshold, you can express that by denying me membership
in the "other people" vote that will be up at some point in the near
future. I will respect this process regardless of outcome.

I believe the GA should have sole control and ownership over the domain and
trademark. I suggested to kindly ask Fabrice to transfer ownership and/or
legal control permanently to a non-profit controlled by and composed of
only our GA. I believe this can be amicably worked out.  If you believe
Fabrice should continue to have *some* (although not *sole*) say over
FFmpeg and ffmpeg.org, then we could propose for him to be a GA member,
too. I think that makes a lot of sense - he historically has a ton more
work in FFmpeg than me.

Ronald
_______________________________________________
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".

Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 3967 bytes --]

On Sun, Sep 24, 2023 at 04:10:00PM +0100, Ronald S. Bultje wrote:
> Hi,
> 
> On Sun, Sep 24, 2023 at 1:40 PM Marton Balint <cus@passwd.hu> wrote:
> 
> > On Sun, 24 Sep 2023, Kyle Swanson wrote:
> > > DNS
> > > ---
> > >
> > > -   Currently the DNS of ffmpeg.org is managed by Fabrice
> > > -   Michael was asked if he has control over the ffmpeg.org DNS
> > register.
> > > -   Michael says he thinks he has some.
> > > -   Ronald would be curious to know what "some" means.
> > > -   Ronald proposes current project owners should have control over DNS
> > and
> > > trademark.
> > > -   Ronald: Fabrice is not active, DNS and trademark should be in the
> > > control of project members.
> > > -   Michael: "i think fabrice should stay in ultimate control", "he has
> > > always acted in the best interests of the people".
> > > -   Ronald took a poll in the room, most agreed current project
> > developers
> > > should have control of this.
> >
> > I think you should define what you are aiming for exactly. Having more
> > people control the domain zone, or asking Fabrice to transfer domain
> > ownership to someone else or some legal entity.
> >
> > I doubt anybody has problem with the former, but for the latter, knowing
> > history, it will certainly raise eyebrows. IMHO having Fabrice ultimate
> > control over the domain ensures that everybody plays nice.
> >
> 
> I disagree.
> 
> Fabrice has theoretical veto power over anything this community does
> because he can change the IP ffmpeg.org points to. That is not right. He is
> not a participant anymore. I understand he conceived of the project and its
> name, but he is no longer part of the developer community in this project.
> Most participants (basically everyone) agreed with this.
> 
> I don't mean to threaten and I don't mean to own rights to anything myself.
> If you don't like me asking to be part of the GA even though I don't meet
> the commit count threshold, you can express that by denying me membership
> in the "other people" vote that will be up at some point in the near
> future. I will respect this process regardless of outcome.
> 

> I believe the GA should have sole control and ownership over the domain and
> trademark. I suggested to kindly ask Fabrice to transfer ownership and/or
> legal control permanently to a non-profit controlled by and composed of
> only our GA. I believe this can be amicably worked out.  If you believe
> Fabrice should continue to have *some* (although not *sole*) say over
> FFmpeg and ffmpeg.org, then we could propose for him to be a GA member,
> too. I think that makes a lot of sense - he historically has a ton more
> work in FFmpeg than me.

I disagree
* Who is and is not a member of the GA is in flux, there can be disputes
  even on GA membership.
* You cannot have something owned by a group like that. There needs to be
  an individual like a treassurer who has the actual key.
  So you again trust one person, this is not different from what it is
  now.

Also democracies can make really bad decissions. Which iam sure you have
never seen occur ;)

And last but not least, this is attackable even unintentionally
you just need for a single moment a majority in the GA that is
bad. This is not hard to reach, a group can easily pose as enough
active developers to achieve 51% and if the domain then really is
legally controlled by the GA. yeah goodby domain
this is not a scenario possible with fabrice having theretical veto
power.
So Yes, i strongly favor fabrice keeping this veto power.

And sure i can probably word above mail more convincingly if i go
over it 3 times and send it tomorrow but i belive you understand
my point even with it just roughly worded

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[Cosmin Stejerean via ffmpeg-devel]

> On Sep 24, 2023, at 5:45 PM, Michael Niedermayer <michael@niedermayer.cc> wrote:
> 
> On Sun, Sep 24, 2023 at 04:10:00PM +0100, Ronald S. Bultje wrote:
>> 
>> 
>> I believe the GA should have sole control and ownership over the domain and
>> trademark. I suggested to kindly ask Fabrice to transfer ownership and/or
>> legal control permanently to a non-profit controlled by and composed of
>> only our GA. I believe this can be amicably worked out.  If you believe
>> Fabrice should continue to have *some* (although not *sole*) say over
>> FFmpeg and ffmpeg.org, then we could propose for him to be a GA member,
>> too. I think that makes a lot of sense - he historically has a ton more
>> work in FFmpeg than me.
> 
> I disagree
> * Who is and is not a member of the GA is in flux, there can be disputes
>  even on GA membership.
> * You cannot have something owned by a group like that. There needs to be
>  an individual like a treassurer who has the actual key.
>  So you again trust one person, this is not different from what it is
>  now.
> 
> Also democracies can make really bad decissions. Which iam sure you have
> never seen occur ;)
> 
> And last but not least, this is attackable even unintentionally
> you just need for a single moment a majority in the GA that is
> bad. This is not hard to reach, a group can easily pose as enough
> active developers to achieve 51% and if the domain then really is
> legally controlled by the GA. yeah goodby domain
> this is not a scenario possible with fabrice having theretical veto
> power.
> So Yes, i strongly favor fabrice keeping this veto power.

These are legitimate concerns that exist in every member driven non-profit. There are common tools though to deal with this. I'm not proposing anything specific for ffmpeg, I don't get a vote here, but I'm just going to list some suggestions:

- a board, elected by the GA with staggered board seats such that 1/N come up for a vote every year
- rules around how or when something can be put to a vote by the GA
- bylaws requiring a supermajority of the vote such as 2/3 or 3/4 for certain decisions that shouldn't be left to simple majority
- new members of the GA needing to be voted in by existing members in addition to requiring certain criteria for eligibility such as number of commits 

Perhaps some of these things have been considered in the past.  The more important point is that these are common concerns with common tools to deal with them. I don't believe concerns about a name takeover should require an ad-hoc governance model when more common and arguably more equitable governance models exist. 

- Cosmin
_______________________________________________
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".

Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[Ronald S. Bultje]

Hi Michael,

On Sun, Sep 24, 2023 at 6:45 PM Michael Niedermayer <michael@niedermayer.cc>
wrote:

> I disagree
> * Who is and is not a member of the GA is in flux, there can be disputes
>   even on GA membership.
> * You cannot have something owned by a group like that. There needs to be
>   an individual like a treassurer who has the actual key.
>   So you again trust one person, this is not different from what it is
>   now.
>
> Also democracies can make really bad decissions. Which iam sure you have
> never seen occur ;)
>
> And last but not least, this is attackable even unintentionally
> you just need for a single moment a majority in the GA that is
> bad. This is not hard to reach, a group can easily pose as enough
> active developers to achieve 51% and if the domain then really is
> legally controlled by the GA. yeah goodby domain
> this is not a scenario possible with fabrice having theretical veto
> power.
> So Yes, i strongly favor fabrice keeping this veto power.
>

Yes, these are good points / concerns, and I share most of this. (I think
it's important to state this explicitly.) So, the question is: do you think
we can find a middle ground here where you and I (and other GA members,
obviously) might agree on what legal entity could be the holder of this
"certificate of ownership"? And do you think it would make sense that in
practice, one person elected by (for example) the TC or GA actually
practically "has" that key, in the role of executing the "will of the
assembly" (similar to treasurer, indeed)? I think we're essentially trying
to define a democratic governance model here. Or do you explicitly think
that Fabrice owning it is the only good way forward? (More like a
benevolent king model.)

And sure i can probably word above mail more convincingly if i go
> over it 3 times and send it tomorrow but i belive you understand
> my point even with it just roughly worded
>

<signal> Thumbs-up-emoji.</signal>

Ronald
_______________________________________________
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".

Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 4387 bytes --]

On Tue, Sep 26, 2023 at 03:21:49PM +0200, Ronald S. Bultje wrote:
> Hi Michael,
> 
> On Sun, Sep 24, 2023 at 6:45 PM Michael Niedermayer <michael@niedermayer.cc>
> wrote:
> 
> > I disagree
> > * Who is and is not a member of the GA is in flux, there can be disputes
> >   even on GA membership.
> > * You cannot have something owned by a group like that. There needs to be
> >   an individual like a treassurer who has the actual key.
> >   So you again trust one person, this is not different from what it is
> >   now.
> >
> > Also democracies can make really bad decissions. Which iam sure you have
> > never seen occur ;)
> >
> > And last but not least, this is attackable even unintentionally
> > you just need for a single moment a majority in the GA that is
> > bad. This is not hard to reach, a group can easily pose as enough
> > active developers to achieve 51% and if the domain then really is
> > legally controlled by the GA. yeah goodby domain
> > this is not a scenario possible with fabrice having theretical veto
> > power.
> > So Yes, i strongly favor fabrice keeping this veto power.
> >
> 
> Yes, these are good points / concerns, and I share most of this. (I think
> it's important to state this explicitly.)

you say you agree, but then you continue talking in disagreement


> So, the question is: do you think
> we can find a middle ground here where you and I (and other GA members,
> obviously) might agree on what legal entity could be the holder of this
> "certificate of ownership"? And do you think it would make sense that in
> practice, one person elected by (for example) the TC or GA actually
> practically "has" that key, in the role of executing the "will of the
> assembly" (similar to treasurer, indeed)? I think we're essentially trying
> to define a democratic governance model here. Or do you explicitly think
> that Fabrice owning it is the only good way forward? (More like a
> benevolent king model.)

What we have currently is not a king making decissions.
What we have currently is the founder having a final (very difficult to use)
veto power to prevent something catastrophic

Also
What we have currently is not some random entity being in control of the
zonefile.
What we have is the zonefile on our server. Where our admins make changes
to it as our developers ask for. We did not had a dispute but if we had one
the TC and GA would decide what happens with the zonefile.

I think polling the developers if they want this power is not asking
the right question, because they have as much power already, as possible.

I think its better to keep fabrice as the one who has this final veto power
We have no dispute but if we imagine we had one.

I trust fabrice to act in the best interrests of the community. That is to
enact the democratic choice.

I do not trust a complex government structure to act in the best interrests
of the community and act within what the majority wants or whats best for the
majority.

Complex governance structures fail in complex ways, legal structures need
people willing to go to court even if not doing so would be better for them
in every form.

We see corruption and abuse of power in almost every government around the
world. I do not think we should move to such a system and expect different.

Also setting up such a legal entity and governance structure around the
domain will cost money and time, there are setup costs, there are yearly
costs. Also the people in the structure will want to be paid, maybe
you find a person doing it for free today but eventually teh set of
candidates who want to manage access to the "domain keys" for free
will be down to increasingly corrupt people. It may even be someone
like a bot net admin if you are unlucky enough.
And if you actually elected such a person as "treassurer" once your
not getting the domain back not with all your legal structurers in place

So again, fabrice is IMO the choice that is safe, simple and proofen

Fabrice has nothing to gain from (ab)using this power. Everyone
else who wants to guard  the final veto power for free probably has
something to gain from it.

Thanks

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[Vittorio Giovara]

On Wed, Sep 27, 2023 at 6:01 AM Michael Niedermayer <michael@niedermayer.cc>
wrote:

> What we have currently is not a king making decissions.
> What we have currently is the founder having a final (very difficult to
> use)
> veto power to prevent something catastrophic
>

This is basically saying that you don't trust the community to make the
best decisions for itself, or that the community is not mature enough to
stand on its own to support the project. While I'm aware of the long and
sometimes difficult history of this group, I'd say the situation changed
for the better over the last few years with more structure and process, and
it'd be ok to try and rely on the active people who make this project
possible rather than a distant disinterested founder, in my opinion.
-- 
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".

Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[Nicolas George]

[-- Attachment #1.1: Type: text/plain, Size: 969 bytes --]

Vittorio Giovara (12023-09-27):
> This is basically saying that you don't trust the community to make the
> best decisions for itself, or that the community is not mature enough to
> stand on its own to support the project.

You are twisting the words to make it sound bad, but it is roughly what
I am saying, and I suspect also what Michael is saying.

More precisely, I now strongly believe that democracy is a terrible way
to run a project like FFmpeg.

As the project grows, democracy gives an increasing weight to people who
came late to contribute to the project in specialized ways (maintaining
code for a specific arch) for external reasons.

It perverts the spirit of the project by shifting towards more stability
and stagnation and away from fun and creativity.

Let us go back to a single leader who is here to have fun and will
foster an environment where other hackers can have fun and create
something good.

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[Vittorio Giovara]

On Tue, Oct 3, 2023 at 2:50 PM Nicolas George <george@nsup.org> wrote:

> Vittorio Giovara (12023-09-27):
> > This is basically saying that you don't trust the community to make the
> > best decisions for itself, or that the community is not mature enough to
> > stand on its own to support the project.
>
> You are twisting the words to make it sound bad, but it is roughly what
> I am saying, and I suspect also what Michael is saying.
>

YOU LITERALLY DO THIS TO EVERYONE WHO RESPONDS TO YOU

You do not intend to win an argument with reason, you mean to tire the
opposing side by tirelessly draining the energy of the counterparty with
essay long replies,
In other words, you're filibustering any reasonable change and improvement
in this community, it's a net negative help!

I am not willing to play your game, and I don't think this community should
either! You claim democracy is a bad model for ffmpeg stewardship, but it's
the only thing that is keeping certain members in the community, and
letting this kind of abuse happen at every discussion. Just please be
better and just stop sending overly long emails with skewed rehashing of
the past or with wrong interpretations of the concept of community,
democracy, and software maintenance.
-- 
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".

Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[Kieran Kunhya via ffmpeg-devel]

On Tue, Oct 3, 2023 at 7:50 PM Nicolas George <george@nsup.org> wrote:
> More precisely, I now strongly believe that democracy is a terrible way
> to run a project like FFmpeg.

Why are you part of a community project if you don't believe the
community is capable of running a project?
Why not start your own project like TempleOS where you can do what you want?

Kieran


Kieran
_______________________________________________
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".

Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1094 bytes --]

Hi Kieran

i didnt really want to get drawn into this discussion but there is one
point i have to make

On Tue, Oct 03, 2023 at 08:29:23PM +0100, Kieran Kunhya via ffmpeg-devel wrote:
> On Tue, Oct 3, 2023 at 7:50 PM Nicolas George <george@nsup.org> wrote:
> > More precisely, I now strongly believe that democracy is a terrible way
> > to run a project like FFmpeg.
> 
> Why are you part of a community project if you don't believe the
> community is capable of running a project?

Questioning why some developer is part of FFmpeg is IMHO a violation of
the Code of Conduct. No matter how it is worded


> Why not start your own project like TempleOS where you can do what you want?

are you suggesting that we all move to a system where every developer has her/his
own fork and they get merged ?
Iam sure this was not meant to be directed at a single developer only

Thanks

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[Anton Khirnov]

Quoting Michael Niedermayer (2023-10-04 16:23:12)
> Hi Kieran
> 
> i didnt really want to get drawn into this discussion but there is one
> point i have to make
> 
> On Tue, Oct 03, 2023 at 08:29:23PM +0100, Kieran Kunhya via ffmpeg-devel wrote:
> > On Tue, Oct 3, 2023 at 7:50 PM Nicolas George <george@nsup.org> wrote:
> > > More precisely, I now strongly believe that democracy is a terrible way
> > > to run a project like FFmpeg.
> > 
> > Why are you part of a community project if you don't believe the
> > community is capable of running a project?
> 
> Questioning why some developer is part of FFmpeg is IMHO a violation of
> the Code of Conduct. No matter how it is worded

The development community has agreed on the following fundamental rules
some years ago:
> The FFmpeg project is organized through a community working on global consensus.
> [...]
> The General Assembly is sovereign and legitimate for all its decisions regarding the FFmpeg project.

It is IMO perfectly reasonable to wonder why does someone who does not
agree with the basic rules participate in the project.

-- 
Anton Khirnov
_______________________________________________
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".

Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[Nicolas George]

Anton Khirnov (12023-10-04):
> It is IMO perfectly reasonable to wonder why does someone who does not
> agree with the basic rules participate in the project.

Or you could have given the issue just two more seconds of thought and
realized that FFmpeg is a software project rather than a Nomic game, and
therefore where the code goes matters more than how it is decided.

So yes, it was definitely an ad-hominem attach, an attempt to smear me.
But I do not care, I do not weaponize the formal rules of politeness, I
leave that to my detractors, some seem to make a habit of it; I only
observe with amusement that their arguments are becoming weaker and more
desperate.

-- 
  Nicolas George
_______________________________________________
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".

Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[Vittorio Giovara]

On Thu, Oct 5, 2023 at 8:55 AM Nicolas George <george@nsup.org> wrote:

> Anton Khirnov (12023-10-04):
> > It is IMO perfectly reasonable to wonder why does someone who does not
> > agree with the basic rules participate in the project.
>
> Or you could have given the issue just two more seconds of thought and
> realized that FFmpeg is a software project rather than a Nomic game, and
> therefore where the code goes matters more than how it is decided.


Code never matters more than people. It's people who make the community and
it's the community who writes the code or who decides what belongs to the
project -- never a single individual.

There is a lot of content on the web that exemplifies that in professional
environments:
-
https://hackernoon.com/thoughts-on-software-development-heroes-5ec656c2e31a
How To Prevent Coding "Heroes" From Destroying The Team
-
https://leaddev.com/culture-engagement-motivation/eliminating-hero-culture-software-engineering-teams
Eliminating hero culture in software engineering teams
-
https://medium.com/@LuiscaGuerrero/the-myth-of-the-hero-developer-70870e76c00b
The myth of the Hero developer

I am as puzzled as you are why we let this kind of abuse happen in this
community, so claiming a CoC violation for a legitimate question seems a
bit ridiculous in my opinion.
Just my 2 cents
-- 
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".

Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2670 bytes --]

Hi Vittorio

On Thu, Oct 05, 2023 at 01:32:11PM -0400, Vittorio Giovara wrote:
> On Thu, Oct 5, 2023 at 8:55 AM Nicolas George <george@nsup.org> wrote:
> 
> > Anton Khirnov (12023-10-04):
> > > It is IMO perfectly reasonable to wonder why does someone who does not
> > > agree with the basic rules participate in the project.
> >
> > Or you could have given the issue just two more seconds of thought and
> > realized that FFmpeg is a software project rather than a Nomic game, and
> > therefore where the code goes matters more than how it is decided.
> 
> 
> Code never matters more than people. It's people who make the community and
> it's the community who writes the code or who decides what belongs to the
> project -- never a single individual.
> 
> There is a lot of content on the web that exemplifies that in professional
> environments:
> -
> https://hackernoon.com/thoughts-on-software-development-heroes-5ec656c2e31a
> How To Prevent Coding "Heroes" From Destroying The Team
> -
> https://leaddev.com/culture-engagement-motivation/eliminating-hero-culture-software-engineering-teams
> Eliminating hero culture in software engineering teams
> -
> https://medium.com/@LuiscaGuerrero/the-myth-of-the-hero-developer-70870e76c00b
> The myth of the Hero developer
> 
> I am as puzzled as you are why we let this kind of abuse happen in this
> community, so claiming a CoC violation for a legitimate question seems a
> bit ridiculous in my opinion.

If people in a team start asking each other "why are you part of the team"
no matter in what form or in what context or under what argumentation.
Thats not a good thing.
A well working team doesnt do that except maybe as a joke
If that is technically a CoC violation is really not the point.

I could elaboarte more here, I mean lets assume someone has an actual
reason or contradiction to his membership in the project.

Maybe ones employer doesnt allow it, or some other arbitraray reason
The question "why are you here if X" surely is legitimate from a logic
point of view but it none the less is a question that has no place to
be asked. logic legitimacy != moral legitimacy
as in "Ohh i know skynet doesnt allow you to work on FFmpeg, why are you here?"
Thats not a question thats in the interrest of the FFmpeg team.
or another example, "Ohh you just said you hate multimedia, why do you continue
to work on FFmpeg?"
So I stand by my oppinion that such questions are inappropriate.

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[Rémi Denis-Courmont]

Le torstaina 5. lokakuuta 2023, 21.33.16 EEST Michael Niedermayer a écrit :
> Hi Vittorio
> 
> On Thu, Oct 05, 2023 at 01:32:11PM -0400, Vittorio Giovara wrote:
> > On Thu, Oct 5, 2023 at 8:55 AM Nicolas George <george@nsup.org> wrote:
> > > Anton Khirnov (12023-10-04):
> > > > It is IMO perfectly reasonable to wonder why does someone who does not
> > > > agree with the basic rules participate in the project.
> > > 
> > > Or you could have given the issue just two more seconds of thought and
> > > realized that FFmpeg is a software project rather than a Nomic game, and
> > > therefore where the code goes matters more than how it is decided.
> > 
> > Code never matters more than people. It's people who make the community
> > and
> > it's the community who writes the code or who decides what belongs to the
> > project -- never a single individual.
> > 
> > There is a lot of content on the web that exemplifies that in professional
> > environments:
> > -
> > https://hackernoon.com/thoughts-on-software-development-heroes-5ec656c2e31
> > a
> > How To Prevent Coding "Heroes" From Destroying The Team
> > -
> > https://leaddev.com/culture-engagement-motivation/eliminating-hero-culture
> > -software-engineering-teams Eliminating hero culture in software
> > engineering teams
> > -
> > https://medium.com/@LuiscaGuerrero/the-myth-of-the-hero-developer-70870e76
> > c00b The myth of the Hero developer
> > 
> > I am as puzzled as you are why we let this kind of abuse happen in this
> > community, so claiming a CoC violation for a legitimate question seems a
> > bit ridiculous in my opinion.
> 
> If people in a team start asking each other "why are you part of the team"
> no matter in what form or in what context or under what argumentation.

He has made no secret that he does not _want_ to be in the same team. A few 
months ago, he told several people here to (and I quote) "go fork 
[themselves]". It hardly gets more explicitly than that, does it not? It is 
also much more offensive than Kieran's question. Surely, you have noticed that 
it reads very much like a major insult.

In a way, I suppose that I get your point: *you* do want everybody in the same 
team. And he ostensibly wants to be in your "team". But that is not 
transitive: he does not want Anton, Kieran, Vittorio, Tomas, and a whole lot 
more in that hypothetical team, or at least not on the terms that Anton 
refereed to as the "fundamental rules" from some years ago.

If you do not agree with Nicolas on this point, then admonishing Kieran and 
Vittorio about alleged CoC violations is not conducive to resolving your 
disagreement, nor is preaching to them about an united FFmpeg team.

I understand that you do not like this situation. Nobody does. But you are 
addressing the wrong people, and ultimately adding fuel to the fire, even if 
you do not mean to.

-- 
Rémi Denis-Courmont
http://www.remlab.net/



_______________________________________________
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".

Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[Nicolas George]

[-- Attachment #1.1: Type: text/plain, Size: 295 bytes --]

Rémi Denis-Courmont (12023-10-05):
> He has made no secret that he does not _want_ to be in the same team. A few 
> months ago, he told several people here to (and I quote) "go fork 
> [themselves]".

Honesty would have involved quoting the “if” before that.

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[Nicolas George]

[-- Attachment #1.1: Type: text/plain, Size: 215 bytes --]

Vittorio Giovara (12023-10-05):
> There is a lot of content on the web that exemplifies that in professional
> environments:

Well, good thing FFmpeg is not a professional environment.

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[Rémi Denis-Courmont]

Le keskiviikkona 4. lokakuuta 2023, 17.23.12 EEST Michael Niedermayer a écrit 
:
> > Why are you part of a community project if you don't believe the
> > community is capable of running a project?
>
> Questioning why some developer is part of FFmpeg is IMHO a violation of
> the Code of Conduct. No matter how it is worded

Kieran was asking a very valid *question*. NG has been vocally adamant (to put 
it mildly) about turning FFmpeg into (or back into) a place for fun 
experimentation and innovation, without the burden of reverse dependencies, 
down-stream packagers, users, and contributors with business interests.

In the past year, I have not noticed anybody else support those directions. 
Your own (in)actions have been in direct contradiction with his stated views, 
for instance:
- You keep making tons of "boring" fixes from OSS fuzz findings and other 
sources (I am thankful for your continued efforts on the first point, by the 
way; this is not meant as negative criticism).
- You are listed as a prominent member of FFlabs (and you have not denounced 
that in any way).

Admittedly, Kieran's question could be taken as loaded, but TBH the question 
seems valid, and calling it a violation of the CoC is too much of a stretch 
for me.

> > Why not start your own project like TempleOS where you can do what you
> > want?
> are you suggesting that we all move to a system where every developer has
> her/his own fork and they get merged ?

He is suggesting that if one person *appears* to be alone in wanting to take 
(or take back) FFmpeg in the given directions that they advocate, they should 
consider starting their own project or fork.

-- 
Rémi Denis-Courmont
http://www.remlab.net/



_______________________________________________
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".

Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[Rémi Denis-Courmont]

Le tiistaina 3. lokakuuta 2023, 21.50.25 EEST Nicolas George a écrit :
> More precisely, I now strongly believe that democracy is a terrible way
> to run a project like FFmpeg.
> 
> As the project grows, democracy gives an increasing weight to people who
> came late to contribute to the project in specialized ways (maintaining
> code for a specific arch) for external reasons.

That sure is a suspiciously specific examplary case.

For the record, this particular issue was not raised or defended by me, 
whether in person or on list. And if you meant the LoongArch people, they were 
not even at the meeting (and they are most likely on holiday at this time).

Also neither they nor I are members of the GA (at least I am not), so we have 
literally zero weight in the meritrocratic democracy. I did however spot a lot 
of support for this motion from members of the GA who did *not "come late to 
contribute to the project in specialized ways (maintaining code for a specific 
arch) for external reasons".

With that noted, I shall be cowardly today and leave it to them to defend 
their point.

-- 
レミ・デニ-クールモン
http://www.remlab.net/



_______________________________________________
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".

Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[Leo Izen]

On 10/3/23 14:50, Nicolas George wrote:
> As the project grows, democracy gives an increasing weight to people who 
> came late to contribute to the project in specialized ways

I have more than 20 commits in the last year, although my contributions 
are almost entirely to one specific module that I maintain.

This feels like a personal attack, especially considering that I haven't 
made any attempt to vote on or influence the outcome of any these decisions.

If you didn't intend to include people like me in this declaration, you 
should have been more specific.

- Leo Izen (Traneptora)
_______________________________________________
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".

Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[Anton Khirnov]

Quoting Michael Niedermayer (2023-09-24 18:45:37)
> > I believe the GA should have sole control and ownership over the domain and
> > trademark. I suggested to kindly ask Fabrice to transfer ownership and/or
> > legal control permanently to a non-profit controlled by and composed of
> > only our GA. I believe this can be amicably worked out.  If you believe
> > Fabrice should continue to have *some* (although not *sole*) say over
> > FFmpeg and ffmpeg.org, then we could propose for him to be a GA member,
> > too. I think that makes a lot of sense - he historically has a ton more
> > work in FFmpeg than me.
> 
> I disagree
> * Who is and is not a member of the GA is in flux, there can be disputes
>   even on GA membership.
> * You cannot have something owned by a group like that. There needs to be
>   an individual like a treassurer who has the actual key.
>   So you again trust one person, this is not different from what it is
>   now.
>
> Also democracies can make really bad decissions. Which iam sure you have
> never seen occur ;)

So can individuals. Would you rather live in a democracy or an
autocracy?

Fabrice has not been a part of this project for the majority of its
existence (he has <10 commits after 2003). What makes you think he is
more qualified to judge what's good for the project than its actual
developers.

-- 
Anton Khirnov
_______________________________________________
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".

Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[Anton Khirnov]

Quoting Kyle Swanson (2023-09-24 10:37:03)
> Hi,
> 
> Here are my notes from the VDD meeting. If I missed anything, please feel
> free to send corrections.

Thank you very much for the notes, they are very helpful.

-- 
Anton Khirnov
_______________________________________________
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".

Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[Tomas Härdin]

sön 2023-09-24 klockan 09:37 +0100 skrev Kyle Swanson:
> Gitlab (or something like Gitlab)
> ---------------------------------
> -   J-B recommends against gitea, suggesting that we piggyback on the
> videolan Gitlab experience infra.

As someone who's tried to maintain a Gitlab instance I can also
recommend letting someone else do that. It might also be worthwhile
finding something that isn't as huge of a mess as Gitlab is, but I'm
not sure what's out there that's less of a pain.

> 
> DNS
> ---
> -   Michael: "i think fabrice should stay in ultimate control", "he
> has
> always acted in the best interests of the people".

A bus factor of 1 will sooner or later cause problems. At the very
least there needs to be some kind of plan in place to hand the domain
over if Fabrice disappears for one reason or another, lest it fall into
the hands of domain squatters.

/Tomas
_______________________________________________
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".

Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[Nicolas George]

Kyle Swanson (12023-09-24):
> AVFrame Subtitles
> -----------------
> 
> -   Lynne cares about this, and hasn't done work on this yet.
> -   Lynee suggests she could make time to collaborate with others on this.
> -   Anton, others, say it makes sense to do this to avoid special handling
> of subtitles, filtering, etc.
> -   We should do it, someone needs to take this on.

Hi.

I have quite a few thoughts on how to do that and pitfalls to avoid
while designing this. I will send them shortly. (Please remind me if I
am late.)

Regards,

-- 
  Nicolas George
_______________________________________________
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".

Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[Nicolas George]

[-- Attachment #1.1: Type: text/plain, Size: 3738 bytes --]

Kyle Swanson (12023-09-24):
> DNS
> ---
> 
> -   Currently the DNS of ffmpeg.org is managed by Fabrice
> -   Michael was asked if he has control over the ffmpeg.org DNS register.
> -   Michael says he thinks he has some.
> -   Ronald would be curious to know what "some" means.
> -   Ronald proposes current project owners should have control over DNS and
> trademark.
> -   Ronald: Fabrice is not active, DNS and trademark should be in the
> control of project members.
> -   Michael: "i think fabrice should stay in ultimate control", "he has
> always acted in the best interests of the people".
> -   Ronald took a poll in the room, most agreed current project developers
> should have control of this.
> -   This will need a vote, Fabrice will need to be contacted.
> -   We would prefer to bring voting results to Fabrice, hopeful that
> Fabrice would be amicable to handover.

Hi.

For an impartial arbiter, NOT being involved in the project, not being
part of the current drama, is a significant plus.

But first, we must ask what we want: do we want an impartial arbiter,
somebody who is trusted to have the best interest of a certain
conception of the project in mind and who can step in in case of a
failure of project democracy? Or do we not want that, just direct
control over the DNS by the admins.

Impartial and benevolent arbiters are hard to come by. We are lucky that
we have somebody who can be considered impartial and benevolent by
definition. I think we would be mad not to rejoice of it.

It is worth remembering that, IIRC, if Fabrice was not the ultimate
arbiter for the name FFmpeg, then the fork from >10 years ago would not
have been a fork, it would have been a successful coup. And then, since
the same causes lead to the same results, it would have progressively
died like it did, just more slowly, because having the recognized name
does override removing features that users enjoy.

Since we are FFmpeg, not avconv, we are happy that the coup was thwarted
by Fabrice's authority. We should look with a lot of suspicion any
attempt to weaken this last line of defence. By the way, I think it is
worth re-reading the mail announcing the coup:
http://ffmpeg.org/pipermail/ffmpeg-devel/2011-January/106403.html
There is a name that sticks out with regard to the present discussion.


Another point. Fabrice chose to give us the code, he chose not to give
us the name but only to lend it. That is his choice. Both the code and
the name belong to him, to do as he will. As members of the Libre
Software movement, we should rejoice he gave the code. But the name is
something different entirely: code is about skill, names are about
emotions.

Even if he has not contributed for more than a decade, Fabrice still has
the reputation for being the author of FFmpeg and FFmpeg still has the
reputation for being one of Fabrice's projects, and unless I am
mistaken, the first F still means Fabrice.

So if Fabrice were to believe that what the projects would be becoming
reflects poorly on him, hurts his reputation, he is entirely within his
rights, moral and legal, to refuse to be associated with it any longer.
“Sorry guys, you've turned my code to shit, I'm taking the name back.”

(It also matches somewhat the way French copyright law: patrimonial can
be ceded, but moral rights cannot.)

So, if the General Assembly were to decide to try to get control over
the trademark and DNS, it would be entirely within its rights, but I
believe both the good of the project and Fabrice's own interest would
suggest he should refuse. And I firmly reserve the right to make that
point to him, privately.

Regards,

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".