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

[Michael Niedermayer]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20230924/20667328/attachment.sig>