[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 at 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