[FFmpeg-devel] [RFC] What to do with 15k euro from STF?

[martin schitter]

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