[FFmpeg-devel] Re: [POLL] [VOTE] code.ffmpeg.org vs. ML

[Timo Rothenpieler via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>]

[-- Attachment #1.1: Type: text/plain, Size: 4214 bytes --]

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 tested
>> Forgejo. 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-leave@ffmpeg.org


[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4742 bytes --]

[-- Attachment #2: Type: text/plain, Size: 163 bytes --]

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org