Hi Michael, On Sun, Sep 24, 2023 at 11:09 AM Michael Niedermayer <mich...@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 _______________________________________________ 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".
