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