Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Seeking new maintainers for gl-rs #524

Open
brendanzab opened this issue Jun 29, 2020 · 18 comments
Open

Seeking new maintainers for gl-rs #524

brendanzab opened this issue Jun 29, 2020 · 18 comments

Comments

@brendanzab
Copy link
Owner

brendanzab commented Jun 29, 2020

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
Copy link

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
Copy link
Owner Author

brendanzab commented Jun 29, 2020

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

@AlexEne
Copy link

AlexEne commented Jun 29, 2020

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
Copy link
Owner Author

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
Copy link

AlexEne commented Jun 30, 2020

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

@MarijnS95
Copy link

@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
Copy link

ids1024 commented Jan 10, 2024

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
Copy link

MarijnS95 commented Jan 10, 2024

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
Copy link

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

@MarijnS95
Copy link

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
Copy link

ids1024 commented Jan 10, 2024

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
Copy link

MarijnS95 commented Jan 10, 2024

@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
Copy link

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
Copy link

ids1024 commented Jan 10, 2024

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
Copy link

@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
Copy link

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

@kchibisov
Copy link

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

@MarijnS95
Copy link

Ping again @brendanzab, is there anything we can get going here?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants