Marvin Scholz <epira...@gmail.com> 于2025年7月14日周一 06:22写道： > > F (see below for my reasoning) F. looks reasonable > > While I would be fine with either outcome, and had helped extensively for the > GitLab migration of VLC and at that time was quite convinced its the best > solution > out there, my opinion on this has changed, and also Gitea or now its fork > Forgejo > changed quite a bit and also some things on GitLabs side I got increasingly > frustrated > with. > > My main issue with GitLab is the enterprise edition. While I understand the > need for them > to have some sensible business model, I fundamentally disagree with some of > their allegedly > business features, just to name a few that I very much disagree with: > > - Scoped labels (https://docs.gitlab.com/user/project/labels/#scoped-labels) > - Configurable issue boards > (https://docs.gitlab.com/user/project/issue_board/) > - Custom fields in issues > (https://docs.gitlab.com/user/work_items/custom_fields/) > > Also, while I don't necessary disagree with this being a more enterprise-ish > feature, merge trains are incredibly useful for big open source projects > for merging multiple changes efficiently: > > - Merge trains (https://docs.gitlab.com/ci/pipelines/merge_trains/) > > Once a feature is in the enterprise edition it is really hard to get it moved > into > the community edition (Free tier) and also obviously means that no open source > contributor could build such a feature and submit it upstream for the > community > edition. > > Also GitLabs codebase is very hard to approach as a new contributor, making it > quite hard to quickly add a missing feature or fix an annoying issue. There > are > also somewhat trivial features not implemented for a very long time, just to > name > one example: > > - Multiple artifacts for a CI job > (https://gitlab.com/gitlab-org/gitlab/-/issues/18744#note_2603279227) > > Also for this feature they consider it being an "advanced" one and therefore > to be > an enterprise edition feature: > https://gitlab.com/gitlab-org/gitlab/-/issues/18744#note_899915876 > > Of course this doesn't mean Forgejo is perfect but I am personally more > hopeful for its > future than I am for GitLab. So I think it would be at least worth a try to > go that route. > Note also that it doesn't mean anything is set in stone, we could change > again if it turns > out Forgejo doesn't work well for us… > > Sorry for the long email, have a nice start of the week everyone! > > Regards, > Marvin Scholz > _______________________________________________ > 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". _______________________________________________ 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".
