Seeking new maintainers for gl-rs

[brendanzab]

I currently don't have the mental bandwidth to maintain this library! Most of my current work is in programming languages, and it's a bit of a context switch to jump back to gl-rs, and so I end up procrastinating on looking at pull requests or issues! This is not a good position for such a critical library to be in, even given the current shift to newer APIs like Vulkan. I'm really sorry if this has affected you if you are reading this!

Going forward I'd like to see if I can find a better home for gl-rs. It was started a long time ago (8 years ago in fact!), and could probably do with some TLC. Please let me know if you'd be up for helping out with this, or have any ideas for where to migrate this repository! The help would be most appreciated! A plan for crate stewardship was mentioned in rust-gamedev/wg#42, but I haven't got around to following up until now.

[Lokathor]

The gamedev-wg is still interested in being a home for this repository, but others should have a chance to speak up with ideas before any big moves happen.

[brendanzab]

Thanks for the quick comment, yeah I thought it best I post here and get the discussion started (again).

[AlexEne]

Do you have some outstanding issues/plans that you'd think are a bit more high-priority to be done? It does seem like a light workload if we split it with the WG members, at only 17 issues (I didn't read them so maybe there's years of work in there :D )

[brendanzab]

Good question. I'm guessing something like:

• Review and merge outstanding PRs
• Switch to Github actions
• Check if the webgl binding generator is still needed (I think folks are using something else these days?), and if not deprecate it
• Update any dependencies, and ensure that we are still using the ones recommended in the community
• Review versioning strategy and repository structure - at the moment all crates are versioned independently in a monorepo, which is painful for a maintainer to manage

@Lokathor also attempted to do a cleanup in #507, but ran up against some frustrations with the test suite.

[AlexEne]

I'm fine with the gamedev-wg move if it's needed.

[MarijnS95]

@brendanzab is this offer still open? I won't be able to dedicate much maintenance effort but lots of high-value crates are still using the gl and gl-generator crates, including glutin. We could use a bindings update such as the one submitted in #546 for example, and could clear out some outstanding issues/PRs.

[ids1024]

Probably most users of gl/gl-generator are using glutin. It could make sense to maintain under the rust-windowing alongside glutin, although it isn't specifically windowing related.

Gfx-rs is also a relevant organization (that I'm not a part of) but wgpu seems to use gl-generator only indirectly by depending on glutin.

[MarijnS95]

The only other popular crates in my search for GL on crates.io are glow and khronos-egl, the latter also uses gl (EDIT: only in dev-dependencies for a GL example) but hand-writes its EGL bindings instead of using the bindings generator here. Perhaps some of the workload could be shared there.

[Lokathor]

Last I was aware, glow does not use the gl crate, but instead bundles the output of my own generator crate phosphorus

[MarijnS95]

Fwiw I was referring to popular crates that provide GL bindings, not necessarily through crates provided by this repository. To make a case for rather maintaining what everyone is currently still using, before too many new forks/crates are spawned to slowly diverge the ecosystem.

phosphorus was mentioned to me some time ago, anything that can be done to bring the ecosystem forward as a whole here?

[ids1024]

Would phosphorus work for EGL/WGL/GLX like gl_generator? I guess if they're all just C functions and the same xml format?

If it can handle all of these, perhaps glutin could make use it.

[MarijnS95]

@ids1024 I'm quite sure it doesn't, looking at the files in the repository and what was mentioned in rust-windowing/glutin#1653 (comment). Hence my suggestion/request that there might be something to win by unifying. Especially with regards to ecosystem divergence again (i.e. if most crates are using gl-generator, can the improvements from phosphorus be translated to gl-generator?).

[Lokathor]

It could probably be updated to work on more stuff.

Currently it's used literally just by me and groves (the glow lead), so it doesn't do anything else because no one asked. However, I suspect it's probably pretty trivial to add EGL support.

[ids1024]

Yeah, probably not too hard to add.

There's also https://github.com/Dav1dde/glad, which added Rust support. And seems to be a pretty popular GL generator for C at the moment. It's written in Python though.

[MarijnS95]

@Lokathor what would be the advantage of phosphorus over gl-generator? Assuming we can figure out maintainership (proposed by the author themselves in this specific issue) and update the bindings source, I'd rather stick to what is currently being used and known to work (perhaps with some incremental improvements) than switch to something completely new.

[MarijnS95]

Any updates on transitioning ownership to a larger organization with a bigger bus-factor?

[kchibisov]

As alternative you can move it to rust-windowing, which hosts glutin/raw-window-handle and has plenty of maintainers.