Ideas about a gtksourceview-data repository

Current state/problems

• The *.lang files are present in the main GtkSourceView git repository.

• Central maintenance problem: once a *.lang file is accepted upstream, the original author usually disappears and we (the GtkSourceView maintainers) need to deal with bug reports, patches, etc for languages that we know nothing about.

Solution 1 - lots of small git repos

• Decouple *.lang files from the main GtkSourceView repository, by creating a repository named for example gtksourceview-data.

• gtksourceview-data could also contain style schemes.

• The data files in gtksourceview-data would be installed for GtkSourceView 3, 4, 5, … as long as the XML formats are compatible.

• When the XML format evolves, keep old *.lang file for old GtkSourceView versions, and install new *.lang files that take advantage of the new features only for the last GtkSourceView version.

• Maintenance decentralization: instead of having all the *.lang files in the same repo with only a few maintainers, have roughly one git repo per *.lang file, with ideally the original author maintaining his/her repo. In some cases it would make sense to group several related *.lang files in the same repo, but in the majority of cases I think it's better to have one repo per *.lang file.

• Do a new gtksourceview-data tarball regularly (e.g. every month). When generating the tarball, the *.lang files would be downloaded from the upstream repos (gtksourceview-data would contain a list with URLs to download). By providing one central tarball, it's easier to package in Linux distributions and containers.

• When generating a new tarball of gtksourceview-data, if there is a 404 error for a certain *.lang file, copy that *.lang from the previous tarball.

• For each *.lang file repo, there needs to be a public bug tracker, so if a maintainer no longer replies, we can see that there is no activity, and someone can fork the repo and we update the URL in the central list contained in gtksourceview-data. There needs to be no activity from the maintainer during a certain minimum duration, e.g. 3 months or 6 months.

• To create a lot of small repos on GitHub or GitLab, a script can be written, using for example git-spindle.

Solution 2 - like the Linux kernel

See this article: Why Github can't host the Linux Kernel Community. The solution here would be to function similarly to the Linux kernel, with a MAINTAINERS file and sending patches by e-mails.

Solution 3 - GitLab?

GtkSourceView has moved to the GNOME GitLab instance. Maybe with GitLab we can find a better solution.