search

rust-gamedev / wg

Coordination repository of the Game Development Working Group
514 stars 10 forks source link

Making a case for merging the rust-gamedev and rustgd orgs #6

Closed erlend-sh closed 5 years ago

erlend-sh commented 5 years ago

In response @AlexEne who wrote the following:

The vision I’m proposing for this wg is a bit different and not focused on individual libraries, but with the focus on solving systemic issues game developers face.

For this reason, I think it’s fine to have two separate ones, for this purpose, the rust-gamedev for handling any workgroup related things like: organizing it, website & newsletter and so on and the other github organization for all the libs.

While I agree with your reasoning for keeping the two orgs separate, folding rustgd into the WG effort would give it what it most sorely need: purpose.

As I understand it, right now it exists by and large in a similar capacity as rust-lang-nursery. Which is a perfectly fine function to serve, but it could be doing a lot more with a little bit of top-down direction. For starters we could label all currently rustgd hosted projects with the same Active, Incubating, Retired convention as Apache. With a liberal interpretation of Active, rustgd currently holds projects of all 3 statuses.

In the bigger picture rustgd is ultimately about lowering the bus factor of libraries that the ecosystem doesn’t want to lose. cgmath for example has hummed along just fine with this approach.

Dealing with the responsibility of what it means to be the holder of such libraries is a problem that a WG effort is better equipped to solve, by means of a rudimentary governing structure to more effectively distribute responsibility.

AlexEne commented 5 years ago

I basically have a few concerns on this subject:

  1. I am afraid of making an semi-exclusive club of game development libraries with unclear entry criteria. What are the conditions to get a library under this group? What about libraries that are not part of rust-gd but still useful for game development? Who decides that? It would preferable to not make part of this wg a list of approved libraries as I firmly believe we need the diversity in this space and people shouldn't to feel left out if their gamedev-related library is not on some list or part of a group.

  2. The way I see it, if a library is useful, it will grow organically. To this point, some of the things in rustgd are confusing and with unclear purpose. You mention it's a collection of libraries that the ecosystem doesn't want to lose, but rustgd has a fork of rlua from kyren/rlua, that's about 200 commits behind her original library. That is, rustgd has the library with a commit from Dec. 2017, whereas the original had the last commit in 4 January 2019.
    More than this, for some reason it has diverged from the original with the last 4 commits. I also do not find a PR (even a declined one) for the original repo with those changes, but I may have missed it.
    If anything, these things are hurting more than helping the ecosystem. It also kind of proves that if something is useful it will organically grow anyway. It doesn't help anyone keeping under this wg a fork of a library that we never update, just update to keep up with the author(s), or ever worse fork, diverge it and do not attempt to merge our changes back. It also distracts potential contributors as they might not realize that it's just a fork and they should actually open an issue / pr to in the official repository.

That is not to say that we cannot start some libraries here as part of this group if the need would surface.

In the end, the issue you describe about the bus factor is an interesting one, and it is quite wide spread in open source as there are various degrees of libraries out there with various degrees of participation, not just in the gamedev space. Probably there might be a different group teased out here to deal with this bus factor but this is not really a gamedev specific issue.

erlend-sh commented 5 years ago

Fair enough. While I don’t think we’re entirely on the same page about what we’re really discussing here, it’s probably best not to dwell on this tangential issue so early in the setup process. Will close for now.