On 9/16/2025 11:12 PM, Balint Marton via ffmpeg-devel wrote:
On Tue, 16 Sep 2025, Michael Niedermayer via ffmpeg-devel wrote:Hi all 2 months ago we voted on testing Forgejo vs Gitlab, we picked and testedForgejo. And as said in that vote, (and surprisingly, i have not forgotten it)heres the "after testing" discussion and vote do we want to keep Forgejo or switch back to the ML workflow (or something else)Forgejo was not bad, but I remember some issues: - When doing individual patch reviews and quoting code the code context gets messed up, maybe it is references the combined diff?
That's a bug in Forgejo, which was introduced in Gitea, when someone tried to fix that exact bug:
https://codeberg.org/forgejo/forgejo/pulls/9264
- Comparing pull request versions does not remove the upstreamed commits from the comparison, so if a new version is newly rebased, I see upstream commits as well in the comparison.
Yeah, that's definitely an issue.I've kinda started to manually work around it by doing separate pushes for rebases and actual changes.
GitHub is also not entirely free from this, though does handle it a bit smoother.
- I am not sure what would be the counterpart of doing a last-chance ping before applying a series in the foregejo system, it was a useful thing in the ML workflow. Maybe some "auto-apply this in 1 day even if there are no approvals" checkbox with mail notificaitons could work, and that would also resolve the issue of self-approval.
That's not an option, but could be emulated with CI to some extend.But generally if someone wants to insta-merge a PR, they can. Given they could just push it manually.
- Bumping versions and final commit polishing is a bit tiresome with foregjo. E.g. it would be nice if I could also edit the commit message, not just the commit title in the web page...
I'm not entirely sure what you're referring to here. Editing commit messages via Web UI? Where do you ever do that?
- Pull requests show up on the mailing list but not force pushes, so people only reading patches via email won't get notifications of new versions.
That's an intentional decision. I could send mails for every single thing that happens in a PR, but I opted not to to not completely flood the ML.
Not sure how many of these are fixable...F. keep Forgejo as primary forge for patch/git workflow M. switch back to the ML for patch/git workflow all GA members can vote, by publically replying here with a "F." / "Forgejo" vs "M." / "ML" End time is in 7 days unless teh community wants to extend that. (Also if results are inconclusive like because a 3rd option emerges then ill restart this with condorcet on vote.ffmpeg.org) * If we keep forgejo we will likely transition our issue tracker tickets into forgejo too, discussing with timo yesterday night indicates that this likely can be done cleaner and neater than at first expected.Forgejo issue tracker is seriously lacking features: - severities - resolutions - issue workflow - votes - custom keywords for components (e.g. mxf, mpegts)Simple tags to emulate all these is a hack, e.g. how can you enforce a single severity or a single resoluton for a resolved issue? Or do ordering by severity or status?So this vote being about ML v.s. forgejo should not cause any decision regarding the issue tracker, that should be another vote if any. Until forgejo catches up, I'd rather keep trac.Regards, Marton* if we switch back to the ML, we still could have subsystem maintainers using their own forge thx -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have often repented speaking, but never of holding my tongue. -- Xenocrates_______________________________________________ ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org To unsubscribe send an email to ffmpeg-devel-le...@ffmpeg.org
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org To unsubscribe send an email to ffmpeg-devel-le...@ffmpeg.org
