michaelni changed the topic of #ffmpeg-devel to: Welcome to the FFmpeg development channel | Questions about using FFmpeg or developing with libav* libs should be asked in #ffmpeg | This channel is publicly logged | FFmpeg 7.1.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
<cone-086>
ffmpeg Clément Péron master:8a9cbf99a5c7: libavformat/rtpdec: Fix RTP timestamp wraparound in Producer Reference Time
_whitelogger has joined #ffmpeg-devel
socrates1298 has joined #ffmpeg-devel
System_Error has quit [Ping timeout: 244 seconds]
kurosu has quit [Quit: Connection closed for inactivity]
System_Error has joined #ffmpeg-devel
System_Error has quit [Ping timeout: 244 seconds]
System_Error has joined #ffmpeg-devel
beastd has quit [Ping timeout: 272 seconds]
beastd has joined #ffmpeg-devel
cone-086 has quit [Quit: transmission timeout]
jamrial has quit []
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 252 seconds]
<fflogger>
[newticket] gnattu: Ticket #11630 ([avcodec] Regression: hevcdec with videotoolbox hwaccel aborts on broken frames after commit 79afc45c03abfb7f1d9dc2cc758ec162bfade1a0) created https://trac.ffmpeg.org/ticket/11630
mkver has quit [Ping timeout: 265 seconds]
_whitelogger has joined #ffmpeg-devel
socrates1298 has quit [Remote host closed the connection]
HarshK23 has joined #ffmpeg-devel
Everything has joined #ffmpeg-devel
rvalue- has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 268 seconds]
rvalue- is now known as rvalue
Xe_ has joined #ffmpeg-devel
Xe has quit [Ping timeout: 244 seconds]
kasper93 has quit [Ping timeout: 252 seconds]
devinheitmueller has quit [Ping timeout: 252 seconds]
TheVibeCoder has joined #ffmpeg-devel
kepstin has quit [Remote host closed the connection]
<electrona>
hey is this the right place to ask noobie doubts?
<ramiro>
haasn: I'm looking at the swscale6_split_planes branch. I believe you plan on squashing the commits, but I thought I'd let you know that a few commits break stuff and then get fixed later: 3bb4280d breaks compilation, fixed in ad80787f. 6be177e9 breaks yuvj444p to gray, fixed in ea18d284.
<ramiro>
haasn: fbbdb548 introduces an issue with argb to rgb444be (I believe it's the dithering issue we discussed already), so for now I didn't cherry-pick it.
electrona has quit [Quit: Leaving]
jamrial has joined #ffmpeg-devel
<ramiro>
haasn: 0cef1444 introduced issues with many conversions for me (I believe it's my fault, due to the way I initialize vector registers). the first issue I looked at is rgb24 to yuva444p, where the optimized list is read/clear/write, but I think the read could be omitted.
<haasn>
Aye, it’s still WIP
<haasn>
Recommend not pulling from it yet except into a test branch
<BBB>
michaelni: re: your email, I prefer to focus on video. I'm ok with others doing rtp review instead of me
BradleyS has quit [Remote host closed the connection]
BradleyS_ has joined #ffmpeg-devel
BradleyS_ is now known as BradleyS
<ramiro>
haasn: also extremely tiny nit: in ops_optimizer.c, the second line of the comment "Prefer to clear as late as possible, [...]" is unaligned :P
mkver has joined #ffmpeg-devel
<haasn>
Boo
<haasn>
Zed sucks at aligning comments
<haasn>
Sadly all other editors suck even more
<Lynne>
haasn: what layout is compatible with host image ops?
<Lynne>
other than general?
<Lynne>
oh wow, nevermind
termos has quit [Ping timeout: 260 seconds]
kurosu has quit [Quit: Connection closed for inactivity]
BradleyS has quit [Read error: Connection reset by peer]
jamrial has quit [Read error: Connection reset by peer]
jamrial has joined #ffmpeg-devel
BradleyS_ has joined #ffmpeg-devel
BradleyS_ is now known as BradleyS
socrates1298 has joined #ffmpeg-devel
socrates1298 has quit [Client Quit]
^Neo_ has joined #ffmpeg-devel
TheVibeCoder has joined #ffmpeg-devel
<Lynne>
haasn: btw unified layouts extension was released
<Lynne>
act surprised such a thing exists
<kierank>
ban TheVibeCoder, he runs competing project
cone-925 has quit [*.net *.split]
^Neo has quit [*.net *.split]
wellsakus has quit [*.net *.split]
derpydoo has joined #ffmpeg-devel
derpydoo has quit [Quit: derpydoo]
minimal has joined #ffmpeg-devel
leo60228 has joined #ffmpeg-devel
vriska has quit [Ping timeout: 252 seconds]
<haasn>
Lynne: the driver reports in
mkver has quit [Ping timeout: 265 seconds]
termos has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
___nick___ has joined #ffmpeg-devel
minimal has quit [Remote host closed the connection]
minimal has joined #ffmpeg-devel
HarshK23 has quit [Quit: Connection closed for inactivity]
<beastd>
kierank: Why do you want to ban TheVibeCoder? Competing project members are very welcome in our channel!
<rcombs>
> Somebody who cannot hack before breakfast a tool to connect a mailing-list with their workflow has no business reviewing patches on the devel mailing-list of an elite Libre Software project.
<rcombs>
lol
<kierank>
beastd: ok
<rcombs>
counterpoint: why the hell would I care enough to spend the time on doing that when I could simply do anything, literally anything else
<beastd>
rcombs,kierank: don't assume i have already read all my emails. first time attending my computer today
<rcombs>
> The demands of the monopolistic mail operators evolve too frequently to follow. If you have suggestions to enhance the configuration, please share them.
<rcombs>
fwiw this is just "don't send messages that claim to be from a given address, but aren't actually signed by the published keys for that address"; it's a very basic anti-spam/anti-forgery system that exists on independent mail servers as well as major ones
<rcombs>
as expected my message on ga@ resulted in several replies from mailer daemons that refused to process the message because they flagged it as a forgery
<beastd>
rcombs: i heard your mail from yesterday. mailman and MTAs is not my area of expertise, but I hope it can be fixed (somewhat) easily.
<rcombs>
servers that errored include at least intel.com, myais.com.cn, and pars.ee
<rcombs>
previously I've also seen failures at siteground.com, box.mail.dx9s.net, mailspamprotection.com, and mail.overt.org
<rcombs>
the issue is that the listserv generates emails with a sender field of <original sender's email address>, carrying the original message's headers (including the signature field)
<rcombs>
receiving mail servers interpret this as a claim that the message was sent by <original sender>
<beastd>
ok i think i understand. thanks for your detailed report! need to do sth completely different, but i will definitely look into it
<rcombs>
but the message sender doesn't match the published list of IP addresses for the sending domain, and the message body doesn't match the signature in the headers (apparently the listserv modifies it some way?)
<beastd>
if anyone (BtbN or michaelni) beat me to it, that's would be good as well
<rcombs>
I happen to have my domain set up with instructions for receiving mail servers to notify me when they receive forged messages claiming to be from me
<rcombs>
but most people don't, so most failed deliveries as a result of this kind of misconfiguration go unnoticed
<BtbN>
I did already look into it, and I do not see an immediate solution to that issue
<BtbN>
it's just an alias in /etc/aliases
<BtbN>
and postfix is apparently too dumb to handle it
<beastd>
that probably explains it a bit. not sure there is much processing done if it's not an ml
<beastd>
that was kind of easier in the olden days. email delivery was much more liberal and mostly anything would go - on the bad side misuse was probably a lot easier as well (that's still a problem today, but in different ways)
<rcombs>
this also comes up for ffmpeg-devel@ and such
<BtbN>
that's a different issue
<BtbN>
the ML at least sets the right from-address
<rcombs>
not as far as I can tell? the from field is still the original sender's address in the ML messages I have laying around here
<BtbN>
There is a different from the from and envelope-from
<rcombs>
the DKIM signature is on the message-from
<BtbN>
Yeah, but the problem with the ga address is that the ffmpeg.org mail server is sending a message with an envelope-from that's not ffmpeg.org
TheVibeCoder has quit [Quit: Client closed]
TheVibeCoder has joined #ffmpeg-devel
___nick___ has joined #ffmpeg-devel
<BtbN>
While on the ML, it's that mailman tampers with the message content, breaking the dkim signature
___nick___ has quit [Client Quit]
<rcombs>
yup
<rcombs>
so ga@ fails SPF and ffmpeg-devel@ fails DKIM
___nick___ has joined #ffmpeg-devel
<rcombs>
for ga@, the solution is theoretically to just not spoof MAIL FROM, but I don't know enough about the tooling to know if that's straightforwardly possible
<rcombs>
for ffmpeg-devel@, there are two possible solutions; either set the From field to something at a domain controlled by the list server itself (and optionally insert a reply-to with the original sender's address), or create a new message from the list that contains the original message (unmodified) as a message/rfc822 MIME part
<BtbN>
I can tell Postfix to rewrite the envelope-from
<BtbN>
but not selectively
<BtbN>
so that'd absolutely break the ML
<BtbN>
The solution to the problem would be a mailman 3 upgrade, which is much smarter at handling that stuff
<BtbN>
(And then making all the current aliases just private lists)
<beastd>
Annoyingly big change to fix 2 small'ish problems.
<beastd>
OTOH if it's the only known and non-breaking way to get there, we should switch away from mailman2 anyway. The sooner the better.
<rcombs>
this is all kinda orthogonal to the base issue of "legacy patches-on-mailing-lists workflows are a pain in the ass and discourage people from contributing, 'elite Libre Software project' or not"
<rcombs>
but if it gets fixed then at least I'll be more inclined to send non-patch messages on there
<rcombs>
I'm still really amused that nobody has actually suggested specific tooling for this stuff
<rcombs>
george just went "you should be able to build your own tools from scratch" and like. what?
<rcombs>
why would I want to do that
<michaelni>
the /etc/aliases should work mostly ok if you have valid DKIM
<BtbN>
michaelni: the slew of bounces for every mail to ga@ says otherwise
<michaelni>
rcombs mail says: dmarc=fail reason="No valid SPF, No valid DKIM" header.from=rcombs.me (policy=quarantine);
<michaelni>
softworkz says for example: dkim=pass header.d=hotmail.com header.s=selector1 header.b=sP30s5Q+; dmarc=pass (policy=none) header.from=hotmail.com; spf=pass (spool.mail.gandi.net: domain of softworkz-at-hotmail.com@ffmpeg.org designates 79.124.17.100 as permitted sender) smtp.mailfrom=softworkz-at-hotmail.com@ffmpeg.org; arc=pass ("microsoft.com:s=arcselector10001:i=1")
<rcombs>
at least one of the failure reports I got (from vidala.pars.ee) said DKIM passed but SPF failed
<BtbN>
I've turned on dmarc_moderation_action=wrap_message now for ffmpeg-devel
<BtbN>
I've found that as well, but I don't understand what it does
TheVibeCoder has quit [Quit: Client closed]
TheVibeCoder has joined #ffmpeg-devel
<rcombs>
meanwhile something just came up elsewhere and, question: is there any reason why accurate_rnd and full_chroma_int aren't on by default in swscale these days
<TheVibeCoder>
swscale is in process of full rewrite
<michaelni>
BtbN, added rcombs.me to sender_canonical that should fix it for rcombs
<BtbN>
well, I'm also getting a couple bounces
<BtbN>
but my SPF is set to permissive
<beastd>
rcombs: michaelni gave a hint on how to achieve things with mutt. doesn't make sense for someone to switch MUAs just for the goal of contributing to ffmpeg.
<rcombs>
I'll send a patch to change the sws flag defaults, and that can serve as a test to see if I get any bounces with the new ffmpeg-devel config
<beastd>
rcombs: also i believe the direction of everybody should come up with their on breed of solution doesn't at all scale as well as providing easily accesible contribution interfaces like with a forge
<rcombs>
yeah agreed obviously
<beastd>
so as i hope i could articulate in my reply i agree with your stand on this
<rcombs>
the ML workflow is a huge barrier to entry for new contributors
<rcombs>
it's not something people are familiar with anymore
<rcombs>
I've only ever interacted with 3 projects that still do things this way (ffmpeg, musl, and linux)
<rcombs>
a lot of things that used to use MLs have moved on to forges (eg fontconfig, freetype, most of the freedesktop stuff)
<beastd>
yes. times have changed quite a lot. and mailing lists don't really have read-made way to interact with them with out of the box apps. most MUAs don't help at all (or even the other way around)
<rcombs>
review is also much more complex with them, and browsing historical patchsets (and the comment history for a given patch) is quite a chore
<rcombs>
a lot of it assumes you've been subscribed to the list since the dawn of time, since the web archive is very limited
<rcombs>
patchwork helps a little but it can only do so much
<beastd>
yea there are lots of hurdles. many not inherent to MLs but to widely used implementations
<rcombs>
> I'll review something if CC'd, but there's so much excess traffic on the ML I don't care about, can't care about, or am not qualified to review.
<rcombs>
this is also a big issue for infrequent contributors
<michaelni>
theres a CC tag for the MAINTAINER file. So you can get a CC on anything you are interrested in
<michaelni>
the archieves have downloadable mbox files to get history into your MUA, seems they are split per month though
<beastd>
but having a forge and an ML should be fine and is my preferred way
<beastd>
i would envision it this way: general discussions and reminders of new and active PRs should happen on the ML. Big PRs and iterations should happen in the forge. the forge should also notify maintainers and previous contributors (if possible) about new PRs in their area. and interactions with CI.
<beastd>
michaelni: yes it is possible, *BUT* in our case cumbersome because of the split per month. also pipermail is flawed in multiple ways (i remember some "From" in mails confused it and such things, also attached patches often need download to be viewed); the per month break ups mostly destroy discussions spanning one or more months.
<rcombs>
which doesn't even necessarily mean to be "conversations that last months"; it can just be "conversations that start on the 30th and go on for a few days"
<rcombs>
I'm really not aware of any *advantages* that an ML-based workflow has over a forge-based one
<jamrial>
rcombs: your email has an .eml attached
<rcombs>
sounds like that's how your client is rendering the new dmarc_moderation_action=wrap_message behavior
<beastd>
rcombs: yes i wrote "spanning" because of that. it can easily happen for 2 mails in close succesion as you just pointed out
<rcombs>
mmhm
<rcombs>
(I sent the email using git send-email as usual)
<jamrial>
and then headers as if it was a whole standalone email
<rcombs>
so it's set as inline, not nominally an attachment
<jamrial>
guess thunderbird does not like it
jamrial has quit []
jamrial has joined #ffmpeg-devel
<rcombs>
heh, seemingly this is handled in thunderbird for android but not for desktop? bizarre
<beastd>
rcombs: ml has advantage in its distributed and low tech nature and in its possibilities to organize bigger discussions
<beastd>
This also was true for contributions, but since quite a few years forges have advanced enough to be better there, especially with many iterations of a big patch set
<jamrial>
rcombs: i'm on the yearly release stable channel
<jamrial>
maybe the android version uses the monthly stable codebase
<beastd>
rcombs,jamrial: thunderbird for android is quite a different code base (somehow shared with K9 mail) if i'm not mistaken
<rcombs>
beastd: I can see that making sense for discussion of higher-level stuff, but not so much for reviewing an actual patchset
<rcombs>
and yeah the android version is a whole separate java codebase
<beastd>
rcombs: exactly. and that's the direction i want to go. discussions on the ml and code review and iteration in the forge.
<rcombs>
I'd just been googling to see if anybody had run into this before, and saw that there was an issue thread for the android version, which was fixed a couple years ago
<rcombs>
but the desktop codebase doesn't seem to have any corresponding handling
<rcombs>
uh. that page says everything passed though
<rcombs>
I'm looking through the ga@ thread and seeing a bunch of discussion of, like, people being unsure whether or not a patch still had unresolved review comments, and that's something modern forge software is *excellent* at tracking
<jamrial>
oh ffs, the whip protocol/demuxer was added and minor version wasn't bumped
<michaelni>
we need a fate test that checks if we added any new demuxers without bump since origin/master
<michaelni>
and also one that checks author fields for this--at--that@ffmpeg.org addresses
TheVibeCoder has quit [Quit: Client closed]
<jamrial>
all these checks can be done by CI in forgejo/gitlab
<jamrial>
which will not depend on reviewers having ot catch them
cone-951 has joined #ffmpeg-devel
<cone-951>
ffmpeg James Almer master:117343c0ba0e: avcodec/ac3_parser: handle more header bits in ff_ac3_parse_header()
<cone-951>
ffmpeg James Almer master:efbcd312060a: avcodec/ac3_parser: use a padded buffer in av_ac3_parse_header()
<beastd>
michaelni,jamrial: sounds good. doing them in CI is not an excuse for not doing them in FATE or similar. but of course it's good to have the CI use the same stuff that can be used locally to avoid mistakes.
<beastd>
rcombs: that is for sure. it's only half of the problem, because modern way to handle stale PRs and issues is mostly to just automatically close them. still better then nothing and still more accessible and easily deployable than everyone doing book keeping in there mails.
<jamrial>
CI is run automatically and unconditionally on all PRs, and it's the perfect place to check for things like this (tabs in diff, bogus author emails, etc), by running a script like patcheck
<beastd>
jamrial: yes. my only additional point was. it should be in patchek or similar first and in CI second
<rcombs>
I'm a little confused, the FATE runners *are* a CI
<jamrial>
yes, post push :p
<rcombs>
they're just not well-integrated with merges right now
<rcombs>
some of them also run on patchsets sent to the list
<rcombs>
or at least they did at some point
<kasper93>
all this require manual intervention / checking of the status, which beats the purpose of automation / CI which suppose to reduce the burden on the developers
<beastd>
maybe, it's a bit a terminology problem. if you mean CI is having automated test suite then FATE is CI. if you include the build servers, triggers, runners and reporting. FATE is not a (complete) CI
<rcombs>
sent an email to ga@, we'll see if I get bounces
<beastd>
my point is if you run stuff in CI it should also be possible for everyone to run it locally (for some things with extra effort like fate-samples, additional packages not needed for build only etc)
<beastd>
CI should only make it well defined, and clean and e.g. more exhaustive and more platforms and also inform in case of CI failures and provide overviews and logs
<rcombs>
a couple comparisons: at libass, we have CI jobs that github runs automatically on pushes to PR branches, and the status is clearly indicated on the PR page by where the merge button is, but there's nothing technically stopping a maintainer from merging a PR with failing tests (we just… don't do that)
<rcombs>
imo that's fine for small projects without that many people working on them
<beastd>
totally agree with that
<rcombs>
for bigger projects it starts to get trickier
<rcombs>
at Discord, we have the same kind of CI-on-PR-branches stuff, but triggering a merge on a PR doesn't actually merge it immediately; instead, it puts it in a "merge queue"
<beastd>
yeah, that's cool. especially for corporate settings.
<kasper93>
I think noone disagree with that, scripts to run checks should be commited in repo. But having automated CI pipeline which would be last check before merge would catch some obvious errors
<rcombs>
the merge queue service rebases branches against main, runs the CI tests, and merges them *if* the tests pass; otherwise the branch is rejected, the developer notified, and it advances to the next branch in the queue
<beastd>
kasper93: i think we are not all on the same page here. i have seen it more than once, that CI was implemented in a way that all devs were just pushing and waiting for the CI to say no because they couldn't reproduce most of it on their machines. i also agree with you and rcombs (and others) that CI is helpful
<rcombs>
if something absolutely must merge immediately (because it's fixing a critical bug that needs to get resolved immediately, or the CI fails due to a problem with the test suite but there's no actual problem with the code and the code is time-sensitive), the developer can "break glass", which merges the PR immediately
<rcombs>
and break-glass merges are audited after-the-fact
<beastd>
that's interesting and i think sensible. have also seen similar flows described by other company projects.
<rcombs>
BtbN: got a bounce on the ga@ mail from vidala.pars.ee; looks to be the same issue as last time
<beastd>
for ffmpeg i would think maintainers should be able to merge (even with failed CI), but the rule should be not to and it should notification should be sent (e.g. to the mailing list)
<rcombs>
no bounces on the ffmpeg-devel@ mail, though apparently it causes some display issues in Thunderbird
<rcombs>
beastd: yeah, that sounds reasonable to me
<rcombs>
bypassing CI is for emergencies (and to deal with issues with the CI itself)
<beastd>
the rule for ffmpeg has been since pretty much the beginning that if you are a committer and push stuff, you are responsible. you also get to fix or revert stuff when it turns out broken
<beastd>
i don't want to see that fully replaced by "but the CI said yes"
<kasper93>
of course implementation of CI and policies around it can vary. It's meant to help
<beastd>
and of course we should be actionable in case of CI insufficiences (like you pointed out already)
<BtbN>
I think at this point, the only one strictly against a modern workflow is Nicolas? We should really just cast a vote. "Forgejo, Gitlab, Videolan-Gitlab, Any of the above, Keep using ML, I don't care" would be my immediate idea how to run it
<BtbN>
Not sure if we should throw Gitea into the mix as well? it IS still actively developed and all
<rcombs>
as long as we use something ranked-choice-based, I don't think the any-of-the-above should be necessary
<rcombs>
people could just rank all the forges together above the ML
<rcombs>
and I think we have election tooling that supports ranked-choice?
<BtbN>
ah, right.
<BtbN>
Yeah, it's quite a complex voting system
<rcombs>
also I feel like it's worth tossing in "just use github" as an option
<BtbN>
Though you do have to pick a favourite
<BtbN>
Yeah, Github should be in the mix
<BtbN>
I honestly don't care. Though at the moment I'd rank Videolan-Gitlab below our ML unfortunately
<BtbN>
given all the issues with it
<BtbN>
Getting an account there is rather troublesome
<BtbN>
and it's slow af
<rcombs>
I'm poking at it and performance seems… well maybe a little worse than github, but entirely decent atm?
<rcombs>
I think last time I looked I concluded it's probably hosted somewhere with poor peering to some users, and that's why they see bad perf
<kierank>
23:36:36 <• BtbN> I honestly don't care. Though at the moment I'd rank Videolan-Gitlab below our ML unfortunately
<kierank>
Incredible
<kierank>
We have a garbage forjego on some crappy server
<kierank>
Vs a properly hosted Videolan gitlab
<BtbN>
Can you just stop? It's just ridiculous at this point.
<kierank>
That other projects of comparable size
<kierank>
Use
<rcombs>
I also have an account on the videolan gitlab; no idea how I signed up though, and maybe it's gotten harder since then
<kierank>
A ton of people couldn't even sign up on forejgo
<rcombs>
I didn't have any trouble with that either
<BtbN>
They have completely locked it down due to bot waves
<BtbN>
the only way to get an account is via manual admin intervention
<rcombs>
ah, that sucks
<BtbN>
and there's people hitting #videolan every day, asking for an unlock, and it usually goes unanswered
<rcombs>
this is one advantage of public hosted services like github (or gitlab.com, etc)
<rcombs>
spam handling for account signup is pretty much handled for you
<BtbN>
So far Forgejo has been on "Sign up yourself" mode since months now, without a single bot account. The anti-speam measures there are unusual enough so far.
<kierank>
BtbN: just put me on ignore like you said you would
<BtbN>
The exact same procedure could be implemented for any other software
<kierank>
Loool
<rcombs>
BtbN: how much of that is just because there aren't many inbound links to it from elsewhere online, though
<kierank>
Some dumb anime thing
<BtbN>
Yeah, only time will tell
<rcombs>
oh is it anubis
<BtbN>
no, it's the same thing that's in front of trac
<BtbN>
and works there too, despite how dead simple and trivial to bypass it is
<rcombs>
kierank: I don't really get why you're so upset about anubis
<kierank>
I'm upset about the jank way sysadmin is done (by design)
<kierank>
Whereas we could use videolan
<rcombs>
like, yeah, it has a logo
<kierank>
Some people can't even join
<kierank>
On HN they are complaining they can't get past it
<BtbN>
You still have completely failed to explain what is supposed to be jank, and what is supposed to be so horrible about Hetzner vs. the Franch hoster Videolan uses.
<kierank>
Sometimes it takes 20 seconds
<kierank>
Videolan has a proper datacentre with access requirements and sysadmind
<kierank>
There's a difference
<BtbN>
Videolan is just using some French Cloud-Hoster. What?
<kierank>
Lol
<rcombs>
do we know anyone specific who's had issues and been able to report the problem in detail?
<kierank>
Videolan isn't run like a high school project
<rcombs>
it's kinda hard to tell what's going on if all we've got is HN comments
<BtbN>
And I fail to see how that is any better/worse than Hetzner
<kierank>
Loool
<kierank>
Incredible
<BtbN>
Explain then, or I will continue to not take you serious
<kierank>
Videolan has an actual cage in a datacentre
<kierank>
With access controls
<kierank>
It's not just some crappy cheap vps
<rcombs>
why is that a good thing
<kierank>
They bought the server themselves, it's extremely powerful
<kierank>
Because they have actual auditing of their hosting
<BtbN>
Well, not powerful enoug for Gitlab it seems
<kierank>
Not the crap we have here where nobody wants to admit who owns avcodec.org
<kierank>
And infrastructure is deliberately opaque
<rcombs>
BtbN: have we established whether the perf problems you're seeing on gitlab are due to server performance or network issues?
<kierank>
And the reason several devs quit (Anton in particular)
<kierank>
He just loves this jank forjego Esperanto crap
<BtbN>
rcombs: it's just a general Gitlab/Ruby problem. It's sadly just not slow
<BtbN>
*not fast
<kierank>
And weird anime proof of work
<kierank>
Anubis isn't slow of course
<kepstin>
in my experience, the extra cost of getting a dedicated rack is usually not worth it, and owning your own hardware means you have to deal with capital expenditures and depreciation; you'll often have systems which maybe were once powerful but are now old.
<rcombs>
^
<BtbN>
Getting a dedicated rack is also actively harmful, since now only one or maybe two select people can do infra work
<kierank>
That's the case already
<BtbN>
while if it's all a hosting solution, multiple people can get admin access and do everything
<kierank>
It's not transparent who has access
<kierank>
Forjego already took code.ffmpeg.org without a vote
<kierank>
Implying it's official infrastructure
<rcombs>
like, I'm trying to understand what actual problem dedicated hardware would solve for ffmpeg (or solves for videolan)
<kierank>
Never would have happened in videolan
<BtbN>
It's not advertised anywhere, and purely a test instance
<kierank>
We're comparing against a €20 VPS here
<kierank>
Which Btbn is proudly using
<rcombs>
and?
<kierank>
Because videolan has complex CI
<rcombs>
does being more expensive make it automatically more suitable for every use-case
<BtbN>
You realize I'm paying that out of pocket at the moment, purely as a test to get familiar with the software?
<kierank>
You're not the only one paying for ffmpeg resources out of pocket
<BtbN>
And why would I buy a vastly more expensive hosting solution, when this much power is enough?
<kierank>
Because it obviously isn't for any non trivial CI
<kierank>
But it's there to produce a false impression of your pet forejgo
<kierank>
That you had to put some anime thing in front of because it's so good
<rcombs>
calling it "some anime thing" doesn't make your case more credible
<kierank>
Ffmpeg is a serious project that's part of critical infrastructure
<kierank>
It really does, it makes us look amateur
<BtbN>
Plenty of other projects think otherwise
<kierank>
You expect this project to be taken seriously with a hosting system that needs Esperanto lessons to pronounce
<BtbN>
It's sucks to have to use solutions like that, but the alternative is melting servers to to access flood.
<kierank>
And waiting 30 seconds for some anime thing to load
<rcombs>
lore.kernel.org is also behind anubis
<kierank>
Beyond a joke, truly
<kierank>
code.videolan.org is not, it has advanced CI
<BtbN>
And it's slow af
<BtbN>
great
<kierank>
It's marginally slower than a lightly used forejo
<kierank>
It's fake, nobody uses forejgo
<kierank>
When it gets loaded it will be slow
<kierank>
Doing a simple git diff on big repos at work grounds it to a halt
<BtbN>
At the moment it's actually quite fast tbf
<rcombs>
heck, UNESCO has stuff behind anubis
<kepstin>
anubis or similar anti-ai-scraping tech is generally a useful way to reduce hosting costs, let alone the benefit of blocking your stuff from getting included into ai models.
<kierank>
Not when people complain it doesn't let them in
<kierank>
Or takes 30 seconds to load
<BtbN>
The later was long fixed
<BtbN>
And I have only heard of one person who couldn't get in, which was also fixed by an Anubis update a few days later
<kierank>
Literally there is a working system dav1d uses, VLC uses.
<rcombs>
it's not really credible to argue that anubis isn't used by serious projects
<kepstin>
(an amusing thing is that the anubis defaults let through some text-based browsers like lynx without a challenge)
<kierank>
But no, we have to homebrew some junk that will inevitably fork soon
<BtbN>
Vote for Gitlab then, is that so hard?
<kierank>
rcombs: kernel doesn't use the dumb anime thing
<rcombs>
it's the same software, just with the logo swapped out
<kierank>
And?
<rcombs>
who cares about the logo?
<BtbN>
kepstin: Anubis lets through anything without "Mozilla" in the UA
<kierank>
The kernel is grown up to realise major infrastructure can't be behind an anime character
<kierank>
We are not
<rcombs>
I mean if you really care then swap out the logo ¯\_(ツ)_/¯
<rcombs>
I just don't care
<BtbN>
Pay to swap out the logo, mind you
<BtbN>
Getting rid of anime is the paywall of Anubis
<kepstin>
kierank: kernel pays to change the logo, it's still the same software. feel free to fork and build it yourself or chip in some cash to the dev if you don't like it?
<kierank>
It's a smart move, I'll give you yhat
<rcombs>
BtbN: it's MIT-licensed
<kierank>
This project has the funds to do hosting propely
<kierank>
People donate to help run the projecy
<BtbN>
rcombs: yeah, but I don't care enough to maintain a fork just to change the logo
<kierank>
But instead it's used to by gaming PCs
<kierank>
The way this project is run is just beyond
<kierank>
But it's by design of course
<kierank>
that's why Anton left
<kierank>
That's why Derek left
<kierank>
It's amazing how librempeg makes this project look well run
<kierank>
I would have bet otherwise
<kierank>
But here we are
<rcombs>
am I the only one who thinks that the CI infrastructure's hosting isn't the most important thing about ffmpeg
<kierank>
It's code+ci
<rcombs>
like. this is a media library and toolset, right
<kierank>
And yes it's important because of supply chain integrity
<kierank>
Which we have none of now
<BtbN>
Again, I don't bloody care what solution we in the end set up. I just want to get going with _something_ finally
<rcombs>
same really
<BtbN>
So we need to vote on it
<rcombs>
I just don't get being so upset about what feels ultimately very secondary
<kierank>
CI matters
<kierank>
Tons of commits go in that break fate
<rcombs>
(and also specifically being so militantly in favor of the most expensive available solutions)
<BtbN>
literally ANY solution we might end up going with supports CI
<kierank>
We can merge stuff quicker
<kierank>
With a button
<kierank>
Even automatically with LGTM
<rcombs>
yeah, that's a problem that needs solving, but the solution doesn't need to involve "rent a cage in a DC"
<kierank>
Gitlab CI is much more sophisticated
<kierank>
I'm saying we use Videolan
<kierank>
Who have already done this
<BtbN>
Gitlab and Forgejo/Gitea CI are relatively similar
<BtbN>
If Videolan Gitlab remains this locked down, I'm strictly against using it
<BtbN>
It's a major deterrent for any possible contributor if they first have to hunt for an account for days
<rcombs>
yeah that's my main concern with it
<rcombs>
what issues do people have with the "just use github" route btw
<kierank>
As opposed to Anubis which doesn't lock anyone down
<BtbN>
It's Microsoft
<rcombs>
seems path-of-least-resistance to me
<kierank>
Except all the people complaining last week on HN
<kierank>
Sorry this week even
<rcombs>
kierank: again is that an identifiable issue that identifiable people actually have
<kierank>
rcombs: with a mirror, I have no issue with GitHub either
<rcombs>
BtbN: and?
<kierank>
rcombs: plane hole meme.jpeg
<BtbN>
Some people hate Microsoft enough to just hard-NAK it
<rcombs>
like, I'm not massively fond of microsoft as a company, sure, but I don't really see what relevance that has to the product on offer
<BtbN>
and I kinda get the argument, that making oneself dependent on the mood of a big US Tech Giant isn't the best thing in the world
<BtbN>
But in the end, I'd be completely fine with just using Github as well
<kepstin>
(i'm curious, maybe i've just missed this discussion, but have the videolan folks said that they're _willing_ to host ffmpeg?)
<beastd>
kierank: it seems not at all usefull to see gitlab@videolan as only option for ffmpeg forge (and more)
<kierank>
Yes
<kierank>
It's the best option for long term community growth
<kierank>
And long term project CI
<BtbN>
not if nobody can sign up there easily
<beastd>
kierank: also i have seen you rants confusing everything with everything starting at forgejo over anubis over trac here more than often enough (and i'm not even here all the time)
<BtbN>
And CI can be implemented for any solution we pick, so that's simply not a concern.
<kierank>
beastd: all the same voices left
<kierank>
Have you noticed recently we had system() in git
<kierank>
WebRTC pushed without review
<kierank>
And insane rants on the ml
<rcombs>
kierank: there's a reply there asking for details, but none are forthcoming; I can't repro locally (also on iOS safari)
<kierank>
Again, plane hole meme.jpeg
<kierank>
It's not a problem for you so therefore it's not a problem
<rcombs>
kierank: not sure how any of those issues relate to which forge software to use
<beastd>
kierank: that is an opinion. i do not see gitlab@videolan as the only best option. i agree it is one option.
<rcombs>
that's not what I'm saying
<BtbN>
Why do you keep shifting to some other unrelated thing all the time?
<rcombs>
I'm saying that if this is still a problem, it'll require more information to diagnose
<BtbN>
Again, I have increasing difficulty to take anything you say seriously.
<kierank>
beastd: I never said that it's the only option
<rcombs>
if I *was* able to repro it then we wouldn't need more information from the reporting user
<rcombs>
but I can't, so more information is needed
<kierank>
But it's obviously an issue
<kierank>
Because several people are complaining
<kierank>
And there's a selection bias because they never even get in
<kierank>
And so you never hear about it
<rcombs>
I see 3 comments to that effect, and none have any more detail
<beastd>
kierank: "system" push and what followed unfortunate and i also object to it. but it was also reverted quickly. and we need to keep watching
<kierank>
Exactly, they couldn't get in and moved on
<BtbN>
the one linked even sounds more like a general network or server issue, not anubis related
<BtbN>
but details are missing
<kierank>
Incredible
<beastd>
kierank: whip push is also unfortunate in a different way. and it should be mentioned to steven liu.
<rcombs>
yeah you could have the same situation with any software
<kierank>
beastd: in the last few months (because of a loss of Anton), the quality of this project has fallen
<beastd>
kierank: and also what BtbN said, you are jumping topics frequently and it's all not related
<kierank>
And I don't want Hosting/CI to go that way
<kierank>
Huh
<kierank>
It's that simple
<rcombs>
if someone's not willing to provide details about the issue, it's gonna be hard to diagnose ¯\_(ツ)_/¯
<beastd>
no, i do not see this in connection to anton leaving
<kierank>
100% is, reasonable voices are drowned out by the loudest
<kierank>
We have multiple daily softworkz rants now
<rcombs>
anyway, kierank, do you have any suggestions for how to address the issues with videolan gitlab (most notably lack of public user account signup)
<beastd>
don't agree. also lot's people see it differently @ "100% is, reasonable voices are drowned out by the loudest"
<kierank>
Also plane meme
<beastd>
kierank: regarding softworkz i also dislike a lot of their recent moves.
<rcombs>
to be clear, I'm all for using it as long as that's resolved
<kierank>
j-b: ping
<rcombs>
kierank: if you're just gonna say plane meme in response to everything, I could say that about the videolan gitlab signup situation, or about the friction of using a mailing list
<kierank>
I agree about the ML
<rcombs>
all of the options have tradeoffs; what matters is what we can do to mitigate them
<kierank>
There were people who learnt assembly from my classes and then sent patches and got fed up of ML and left
<kierank>
The solution obviously is to move to some dumb Esperanto named forge
<rcombs>
yup, ML is the main reason I don't contribute more
<rcombs>
why does the origin of the name matter :|
<kierank>
With an anime character blocking signup
<kierank>
You could say the same about ML
<kierank>
We all use email
<kierank>
We should all run our own mailservers like Nicolas says
<beastd>
lots of our problems are because of recent infighting and because of our lack of maintainers. and that is all somehow connected in same more and many less direct ways
<rcombs>
like, as far as I can tell, the actual credible complaints about forgejo are that (1) it's less mature than gitlab, and (2) there isn't a readily-available host available for it (videolan)
<beastd>
kierank: regarding forge with esperanto name that is completely off topic (and strawman or whatever the clever guys call it). we would host forgjo and stlyle it in ffmpeg (and people not caring about the origins wouldn't even notice its name)
<kierank>
It's noy
<kierank>
Not
<kierank>
We should use something that contributors are used to
<kierank>
Not some thing you need someone to tell you how to pronounce
<BtbN>
Forgejo closely mimicks github, which almost everyone is used to
<BtbN>
The name of the tool is completely irrelevant to that
<kierank>
It's not
<beastd>
yes, forgejo feel *A LOT* like github
<rcombs>
(2) is kinda mitigated a bit by the videolan signup situation, and free hosting is available from eg Codeberg
<fflogger>
[editedticket] Balling: Ticket #979 ([swscale] Abnormal colorspace conversion of BGR -> YUV comparing the RGB variant) updated https://trac.ffmpeg.org/ticket/979#comment:27
<kierank>
People are not gonna sign up to some weirdly named thing
<BtbN>
People won't even see the name when they do
<BtbN>
unless they scroll to the very bottom
<kierank>
it's on the homepage
<rcombs>
of the test instance, sure
<BtbN>
Cause I put it into the instance name
<rcombs>
I don't really understand why you're so focused on tooling branding
<beastd>
rcombs: i don't hitnk 2 is a problem. BtbN do we have a problem to host forgejo on our infrastructure? if yes what much more would we need short of runners for ci?
<kierank>
Because we lack new contributors
<kierank>
I have personally tried to get some and they have all got fed up
<rcombs>
I don't think any of the branding issues are meaningful barriers to new contributors
<BtbN>
beastd: what do you mean?
<rcombs>
the ML flow definitely is though
<kierank>
And creating arcane tooling isn't gonna help
<BtbN>
The plan is to specifically NOT host Forgejo/Gitlab/... on the current servers. For the sake of eliminating them as single point of failure for all our infra.
<rcombs>
all of the forge options are immediately dramatically better on that front than the ML
<kierank>
An anime character and some randomly named forge is going to scare people off
<rcombs>
the most familiar option is github
<beastd>
BtbN: i talk about this comment from rcombs point 2: [01:19:16] <rcombs> like, as far as I can tell, the actual credible complaints about forgejo are that (1) it's less mature than gitlab, and (2) there isn't a readily-available host available for it (videolan)
<rcombs>
as far as I can tell, gitlab and forgejo are pretty similar on that front
<rcombs>
i.e. slightly less familiar than github, but similar enough to feel pretty normal
<kierank>
Forgejo is the third fork of gogs, then gitea
<BtbN>
I'm pretty confident that Forgejo has enough traction to not just die at some point
<kierank>
Lol
<kierank>
Gitlab/hub have orders of magnitude more traction
<kierank>
This is a long term project, we need proper infrastructure
<beastd>
kierank: it has lot's of the things other people have requested for ffmpeg
<rcombs>
gitlab is definitely more mature
<BtbN>
Gitlab also has regular critical security issues
<BtbN>
almost like clockwork recently
<kepstin>
fwiw, note that the gnome folks have no significant concerns regarding the anubis mascot driving off possible contributors on https://gitlab.gnome.org/
<beastd>
kierank: gitlan is opencore. it's quite in the area of redis and the likes. i don't like that at all.
<rcombs>
BtbN: well, how much of that is due to more attention
<beastd>
*gitlab
<BtbN>
Only time will tell
<rcombs>
Fedora is also on forgejo now
<kierank>
No
<BtbN>
but looking at the last two issues that got fixes, both of them were cause "Ruby be confusing"
<rcombs>
so it's not like it's a non-player in major projects
<kierank>
Fedora has announced it's going to move
<kierank>
That's kot the same thing
<rcombs>
fair
<rcombs>
but you see my point
<BtbN>
Yeah, more people will be looking at it
<BtbN>
but Forgejo/Gitea is also much much smaller, so less attack surface
<rcombs>
mm
<kierank>
beastd: the one issue about GitHub is potential US sanctions
<BtbN>
Gitlab is frankly quite bloated
<kierank>
Forgejo is basically a toy
<kierank>
Built on intellectual purity
<kierank>
And fighting forks
<kepstin>
yeah, there's a certain amount of overhead for designing software to run at the scale of gitlab.com which can make it overkill and complex on smaller deployments.
<kierank>
We have elements of that complexity
<kierank>
And we should take advantage of that
<BtbN>
It also just has a lot of features we won't ever need that complexify it
uau_ has joined #ffmpeg-devel
<kepstin>
the elements of that complexity are in the deployment side to make it scale when hosted on server clusters, which isn't appropriate here
<BtbN>
I haven't yet found anything Gitlab can do that we'd benefit from that Forgejo doesn't have as well
uau is now known as Guest5973
uau_ is now known as uau
<kierank>
Just compare the videolan CI with forgejo
<kierank>
Forgejo is primitive
<BtbN>
I did, looks quite similar to me
<rcombs>
please elaborate
<BtbN>
What can Gitlab do that Forgejo can't?
<kierank>
Look yourself at dav1d and what they do
<rcombs>
or, like, link particular pages that show features you expect not to be available
Guest5973 has quit [Ping timeout: 248 seconds]
<beastd>
everything can fail that is not argument against trying. even ffmpeg could have failed easily. also there would be no linux kernel etc if people would have said there are enough OSs and Codecs no need to re-implement/compete them in Open Source software
<kierank>
Gitlab has already been done by a bigger project, VLC
<kierank>
Forgejo has no comparable big projecy
<kierank>
It'll be the same mistake as picking trac
<kierank>
Which is effectively dead
<another|>
I think Fedora is going to switch to it
<beastd>
kierank: AFAICT dav1d is fine, but I do not see how we could not do fine with forgejo? also FFmpeg has regular testing since Mike hacked up FATE long before dav1d was there (and I think also before VLC had CI).
<kierank>
That's not CI
<kierank>
Fate is not CI
<beastd>
It's also a non-argument to say everything related multimedia should be under videolan umbrella. it's an opinion that one can have, but not an argument.
<rcombs>
anyway I don't really have strong opinions on this; it seems like there are reasonable pros and cons (basically the tradeoff is heavier-but-well-established vs lighter-but-less-mature)
<kierank>
CI is every patch is tested
<beastd>
CI is a fuzzy word. I myself said a few hours ago FATE is not CI.
<rcombs>
I just don't like seeing all the hyperbole
<kierank>
I don't like the forgejo cultism because reasonable voices have left
<rcombs>
I don't really see any evidence of forgejo "cultism" here?
<rcombs>
like, all the pro-forgejo stuff has just been "it's a reasonable option that's lighter-weight and would probably perform better on a given host"
<beastd>
Having FATE test run by lot's of clients regularly (some did even on every commit) and aggregating the results in the fate server is a lot like CI. it just not per commit / push CI before inclusion
<kierank>
It's not every commit
<kierank>
It's every submitted patch
<beastd>
it depends on how you do it
<kierank>
So that people can be sure their stuff doesn't break on platforms they can't test
<kierank>
Literally fate breaks avoidably every week
<kierank>
Fate can still do edge cases
<beastd>
and having this is (not necessarily per commit) is wanted by almost everyone in the project
<kierank>
But CI can catch issues
<rcombs>
I think we all agree that we want a test suite to run on PRs
<beastd>
kierank: FATE is good and "proper" CI is also.
<beastd>
but there are many flavours
<kierank>
Huuh
<kierank>
00:35:49 <rcombs> I think we all agree that we want a test suite to run on PRs
<beastd>
i don't think we want per commit
<kierank>
Like it's 2025
<kierank>
We want test suite on every PR
<rcombs>
I haven't seen anyone argue against that
<beastd>
i also think we won't run all target platforms on all pushes to topic branches
<kierank>
This is orthogonal to fate
<another|>
kierank: To be clear: videolan does not run CI on every patch. It's on every MR ususally
<beastd>
or MR/PR whatever
<rcombs>
beastd: pre-merge at least, though
<kepstin>
fwiw, linux kernel has had similar issues with their "ci" feedback not properly getting taken into account before code is merged, also associated with their use of ML patch submission and the expectation that code is pushed directly into git :/ (the "linux-next" stuff where they try to merge and test code before it gets merged for real is their workaround)
<kierank>
another|: ok
<rcombs>
there also might be a bit of confusion here between "fate" (as in, the post-merge runs at fate.ffmpeg.org) and "fate" (as in, the checks you get by running make fate)
<beastd>
rcombs: pre merge and probably selected common and very uncommon known to break a lot targest (all we cover with fate will pretty sure be too much)
<rcombs>
the latter makes sense to automatically run pre-merge, I think
<kierank>
But I don't think fate operators will want random code running on their machines
<kierank>
So fate will remain for actual git pushes
<beastd>
kierank: i didn't imply this, but in general that is true
<kepstin>
yeah, running _full_ fate, especially if you want to get a good cross section of architectures/operating systems, is probably far too slow/expensive for every MR
<rcombs>
beastd: if it's running post-merge anyway, is it really any worse to run it pre-merge instead?
<BtbN>
Nah, it's absolutely possible if enough people contribute machines
<kierank>
rcombs: obvious security issue
<kepstin>
most forges (including forgejo) include protection against running ci on merge requests by new users, usually by requiring manual approval
<beastd>
in particular i think we could achieve it on fate clients where the owners run them explicitly isolatet, but it needs a bit more thinking
<kierank>
I can do a MR to mine bitcoin
<rcombs>
by "pre-merge" I mean "after a maintainer has triggered a merge, but before it actually merges to trunk"
<rcombs>
or on a PR after being approved for CI by a maintainer
<beastd>
BtbN,rcombs: I think having all of FATE run (and it is run by volunteers as of today) I mean on all currently provided platforms is too much on a PR basis. if you can prove me wrong and it doesn't take to long etc i would not be unhappy
<BtbN>
ALL of fate is too much, yeah
<kierank>
It's clearly a security risk
<BtbN>
and the way the fate network works is based on trust of what gets pushed
<BtbN>
So it's not suitable for CI
<beastd>
kierank: running fate clients is also clearly a security risk
<BtbN>
but setting up a bunch of CI runners for every arch to then run fate on is absolutely possible
<kierank>
Yes but it's based on trust that patches are reviewed
<kierank>
And access to git push is controlled
<kierank>
(none of which are doing well right now tbh)
<kepstin>
yes, but one that is in common in all ci system linked to forges, and generally mitigated by mechanisms to prevent ci usage on the forge side and sandboxing/isolation on the ci runner side.
<beastd>
sure, but it is a risk
<kierank>
kepstin: yes and videolan has this already
<rcombs>
speaking of running fate on patches pre-merge, my sws patch just failed a fate-run-on-push
<cone-951>
ffmpeg Leo Izen master:5fea5e3e11d6: configure: rename POSIX ioctl check
<beastd>
why do think it could not be a controlled security risk when we have clients running fate tests in proper isolation?
<kepstin>
kierank: yes, it's a general thing that all multi-user forges implement.
<rcombs>
(or, well, fate-run-on-ML-patch-send)
<kepstin>
well, all the ones being considered
<kierank>
Let's hope forgejo does it securely
<beastd>
let's hope gitlab does it securely
<BtbN>
Well, a bitcoin miner could still be run, that's kinda unavoidable
<BtbN>
but if someone hits approve on that, that's their fault
<BtbN>
And the worst it does is lock up CI until the job times out
<kepstin>
i don't know how the videolan runners are set up, since i don't have enough access, but the most secure option available in gitlab is to have it use a virtual machine system to spin up a new temporary vm for each ci run, either on cloud hosting or there's a few options for self-hosted clusters
<Traneptora>
that's usually how it works right
<rcombs>
yeah github does something along those lines
<beastd>
BtbN: think even miner could be avoided (or at least the damage limited)
<Traneptora>
they typically spin up a new VM for every job. at leasat on github
<BtbN>
Gitlab/Forgejo by default just spin up a new container per job
<BtbN>
cause it's faster
<Traneptora>
a new sandboxed environment should still be fine for our purposes, right?
<BtbN>
Which is decently isolated still, but not as good as full VM
<kepstin>
yes, most non-gitlab.com deployments of gitlab do end up using docker runners as an in-between option that's easier to host but not as secure.
<kierank>
"Forgejo Actions is still in an experimental stage"
<BtbN>
Which just means that it's not feature complete and can have breaking changes
<kepstin>
looks like forgejo actions are container-based only currently, they don't have a vm runner system atm.
<BtbN>
not that it doesn't work
<kierank>
Lol
<kierank>
The mental gymnastics to defend the beloved forgejo
<rcombs>
I mean, "major features are currently flagged experimental and are subject to breaking changes" is a legitimate concern
<BtbN>
You're the only one I see doing mental gymnastics here to keep finding new things to hate
<beastd>
could also use other ci systems like woodpecker or buildbot. tho i think going with forgjo action ist just as fine
<kierank>
Having something compatible with GitHub actions helps new developers
<BtbN>
Yeah, using woodpecker was the default on Codeberg until recently
<beastd>
and attacking forgejo and everyone in favor everytime is not helping anyone
<beastd>
and also forgejo actions are to big extent compatible to github actions
<kepstin>
for something in a commercial product, github actions are annoyingly unstable. they keep deprecating and breaking old action versions so you have to ensure your project's ci config is constantly being updated.
<kierank>
So actually it's woodpecker, not forgejo actions...
<BtbN>
hm?
<kierank>
00:48:23 <rcombs> I mean, "major features are currently flagged experimental and are subject to breaking changes" is a legitimate concern
<BtbN>
Forgejo Actions are their own thing, based on github actions
<BtbN>
got nothing to do with woodpecker.
<beastd>
on codeberg it is woodpecker. i think some run even forgejo actions somehow but not sure how well that is supported on codeberg.
<kierank>
So actually we have to use something else for CI
<BtbN>
Codeberg can also run Forgejo Actions now
<beastd>
no. we can use sth else but we don't have to
<kierank>
Gitlab has the advantage of being built in
<kierank>
Forgejo actions are experimental
<compn>
kierank, i thought you were against videolan hosting anything before? when i suggested it at vdd ?
<BtbN>
They're experimental cause they're not done, so the scripts might need adjustments
<kierank>
So we can now finally conclude that Forgejo is less mature than Gitlab
<beastd>
forgejo actions is also built-in (and yes they are still experimental)
<compn>
nice to see you come around i guess
<BtbN>
Not cause they're broken or defunct
<BtbN>
they work fine already
<kierank>
Glad it only took several hours for this to come out
<BtbN>
You can sign into the current test instance, and test the already working CI
<BtbN>
That's Forgejo Actions
<kierank>
"Forgejo Actions related work led to an undocumented default that broke workflows relying on it. This may have been fixed for backward compatibility, but Forgejo Actions is still in an experimental stage, so supporting undocumented behaviors wouldn’t be sustainable. "
<rcombs>
kierank: I mean, I don't think anyone argued that it wasn't at any point
<beastd>
no one debated that forgejo actions are not officiall "stable". they are still quite usable and integrated
<kepstin>
kierank: that was understood to be a given from the start? from what I can see, the remaining open questions are about weighing that vs. the additional complexity and costs of hosting gitlab, vs the management issues of someone else hosting gitlab
<rcombs>
just that it's a tradeoff that could be weighed against others
<kierank>
Yes but this is something that needs bearing in mind
<kierank>
Vs GitHub/lan
<kierank>
Lab
<rcombs>
I do think github is still the easiest option lol
<kierank>
I agree but it's not gonna fly with some people
<kierank>
I think that was one, reason forgejo was created, because gitea is being developed on GitHub
<kierank>
In the end we have an existential crisis of lack of developers
<kepstin>
i suspect that next to github actions (knowledge of which is partially reusable of forgejo), people who might be able to help contribute setting up ci are most likely to be familiar with gitlab's ci.
<kierank>
And the way to get new developers is as streamlined a process as possible.
<kepstin>
(personally, i do like using gitlab ci, i've used it in several projects, and find github actions kinda frustrating)
<BtbN>
it's not just partially reusable. Forgejo/Gitea literally use the Github Actions parser
<BtbN>
so it's the same
<BtbN>
just some variables are named differently
<beastd>
easiest short term? probably. best? i don't think so. not completely opposed here either. but just ms recent work in regards to "AI" and US government etc. makes me more wary..
<kierank>
Problem is with our project infrastructure (deliberately) held together with string, forgejo is what we deseve
<kierank>
And what the leadership will force
<BtbN>
No idea what is supposedly held together by a string
<kierank>
And when forgejo dies as it will it's game over
<kierank>
Who owns avcodec.org?
<BtbN>
what we have right now is quite solid, server wise.
<kierank>
Hohohohohoh
<beastd>
kierank: why should it be game over?
<kierank>
Man, April fools day has come early
<BtbN>
We "only" need to desperately update to Mailman 3, which will be disruptive.
<kierank>
Who owns avcodec.org
<kierank>
Who owns ns1.avcodec.org
<kierank>
Who controls this stuff
<rcombs>
if we one day have to migrate to a different solution, that'll be unfortunate, but not world-ending
<BtbN>
We already listed you who runs the nameservers...
<BtbN>
but you somehow keep forgetting
<kepstin>
yeah, it's not the structure of forgejo actions that i'm worried about, but more that familiarity with the specific "actions" used in ci (many of which are provided by github themselves) isn't necessarily transferrable.
<beastd>
kierank: if github or gitlab dies or changes tos or whatever? then it's game over. i don't see the argument
<kierank>
Forgejo is the third fork
<kierank>
We still use gitea at work
<BtbN>
And?
<kepstin>
it's a git repo and ci. you can move it and rework the ci if need be.
<kierank>
Because it's not clear which one to move to
<BtbN>
Migration from one fork to the next was always hassle free
<kierank>
It's not backwards compatible
<kierank>
You commit and that's it
<beastd>
being a fork is not the definition of being a problem. there being no gitlab forks could be seen as the bigger problem