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

[Neal Gompa]

On Sun, Sep 24, 2023 at 6:09 AM Michael Niedermayer
<michael at niedermayer.cc> wrote:
>
> 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:
> >
> > 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
>

At the risk of directing flames at myself, might I suggest maybe an
ffmpeg Pagure deployment?

Pagure (https://pagure.io/pagure) is a lightweight and extensible Git
forge written in Python that has a few notable properties:

* All project data is stored as Git repos (tickets, pull request
metadata, docs sites, etc.)
** This means project backups, instance migrations, and restores are
relatively easy
* Pagure project maintainers can do bulk work offline and push
whenever because of the above
** Pag-Off is an example tool: https://pagure.io/pag-off
* Pagure supports a concept called "remote pull requests" where Pagure
can be pointed to an arbitrary git branch on another git server to
create a pull request
* Pagure is packaged in a number of Linux distributions (offhand:
Fedora, RHEL/CentOS, openSUSE, Mageia, Debian, Ubuntu, and Arch AUR)
* Jenkins and Zuul CI integration exists for Pagure, and the API can
be used to support others

A long time ago, Fedora wrote a tool for importing stuff from Trac
into Pagure: https://pagure.io/pagure-importer

There's work going on right now for an upcoming 6.0 release, but the
latest 5.x release is available in at least Fedora, RHEL/CentOS, and
openSUSE.

There are a few instances out in the wild already:

* Reference: https://pagure.io
* Fedora: https://src.fedoraproject.org
* openSUSE: https://code.opensuse.org
* CentOS: https://git.centos.org
* Midipix: https://dev.midipix.org

(Full disclosure, I'm a contributor to Pagure.)



--
真実はいつも一つ！/ Always, there's only one truth!