On 11.11.24 08:11, Diederick C. Niehorster wrote:
I have no personal experience with gitlab, but it:

I'm a long term GitLab user. I use it for most of my work on self-hosted instances but also on gitlab.com.

In the past it was a really impressive alternative to github, which provided useful features long before similar tools became available on github (e.g. the CI/CD capabilities), but I'm not sure, how we should think today about GitLabs future?

I'm really surprised, that they still exist as an independent company offering this self-hostable free open core compromise, but the whole project became very business oriented over time. Their actual backing by Google investments and infrastructure also doesn't build a really convincing alternative to the github-microsoft monoculture.

Unfortunately there is simply nothing more acceptable available until now.

('forgejo' could a more lightweight and easier maintainable option for small private projects, but I wouldn't see it as an equal competitor, and 'radicle', which is in many ways a rather interesting innovative decentralized project utilizing a much more sympathetic non-web-tech base, is still far away from a more user-friendly alternative for the masses)

1) allows creating merge requests by email:
https://docs.gitlab.com/ee/user/project/merge_requests/ creating_merge_requests.html#by-sending-an-email

That's an interesting point!

If you see this kind of services just as a solution to make Git repos available in web-browsers and enabling the contribution of "patches" by another transport mechanism, this could be trough, but the real workflow significantly differs in both cases.

The git history of Patches here on this mailinglist are usually rewritten whenever one of the reviewers requests some change, but the typical workflow in github/gitlab doesn't use or even forbids this kind of changes in uploaded code resp. forced pushes. It's enforcing a strict incremental timeline of changes.

That's why contributions and the related communication process looks very different in both environments in practice.

There are pros and cons for both kinds of workflow and don't want to advocate one or the other, it's just important to point out this much more complex side effects and foreseeable consequences of such a workflow change.

See there are also tools for managing discussion by email.
2) has a CLI tool that can manage merge requests, but cannot be used
for attaching comments to specific code lines:
https://gitlab.com/gitlab-org/cli/-/issues/1311

Yes -- there very efficient cli-tools and plugins for nearly all common development tools available to support a wide range of habits and user preferences. But often you'll still have to use the webinterface and feel the horrible pain of all this typical slow and bloated web-tech-crap again...

Nevertheless, IMHO it would still be a better solution in comparison to the status quo!

But this estimation isn't so much caused just by the already mentioned elementary Git access features, but to other aspects provided by GitLab:

* much better integration of a more useful issue tracker (automatic cross-links to code and MRs) and therefore much better searchable growing implicit development documentation (which is IMHO one of the really unsatisfying aspects of ffmpeg -- because searching old debates in mailing list archives or in the IRC logs is just unacceptable frustrating!)

* and CI capabilities -- automatic testing of all incoming merge requests, which could eliminate lots of noise here on the list by much more useful machine generated responses resp. quick error reports. This provides much faster improvement circles and helps to focus the human communication on more relevant non-trivial topics.

But I also see the danger, that current participation on this list and the actual review of contributions by many watching eyes will very likely decrease. That's IMHO a very important problematic aspect, because I'm really impressed by the review quality here on this list, although I'm not always sharing the opinions of some maintainers and their attitude to communicate directives.

I don't know, how I should think about this question of self-hosting vs. shared usage of an already existing GitLab instance?

Self-hosting GitLab is definitive no rocket science, but it's nevertheless a responsible challenge, because it's not done with one installation session, but leading to a rather time-consuming continuous update and maintenance obligation.

Using an instance of one of the well established free software players (freedesktop.org, debian, etc.) on their infrastructure, could therefore also make sense for ffmpeg. This could help focus the available man power on more useful development tasks.

Martin
_______________________________________________
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".

Reply via email to