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

[Michael Niedermayer]

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
-------------- 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/20230927/cf547288/attachment.sig>