On Sun, Sep 24, 2023 at 6:09 AM Michael Niedermayer <mich...@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! _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
