Anyone can review a pull request, but only the Owners and Members (of the jMonkeyEngine’s GitHub organization) can merge a PR. There are 32 of us: People · jMonkeyEngine · GitHub but most of those are inactive.
Reviewing PRs is the bottleneck. Due to human nature, shared responsibilities tend to suffer neglect. Sometimes it helps to ask a specific person. Sometimes I merge my own PRs without any outside review.
We need a project manager. The glue to hold the team together. Nobody replaced @erlend_sh when he left for discourse. It would be nice to have someone to keep things going and have vision for its future. It’s just as important as any other area.
Like the slack core channel is virtually dead now, and it’s nobodys fault. Those that are active are doing their bit, but i feel if there were someone keeping the candle alight things might be more focused.
And regarding PRs - the commit action seems to be something people abuse a lot from what I see. I don’t expect to change everybody but a commit action shouldn’t be a blanket move. It should be commited on every action. This commit does this. This commit does that. Not one massive commit with a simple “does this” description. That way individual commits can be accepted and others rejected or scrutinized. Far more commits will be merged that way.
I’m hesitant to push through the VertexBuffer change myself just because I don’t have the ability to test it, never needed the particular functionality, etc… I was hoping someone else who “had a dog in that fight” could look at it and comment.
…else we end up just going back and forth because apparently the last buffer object changes weren’t right and just pushed through anyway.
This particular change (changes to VertexBuffer) seem like that would need a little more scrutiny than a glance by me and pushing a button. It would be really nice if some other folks could try out the changes and make sure that at least they don’t break normal operations.
I am currently using master because there is no release with Java 11. Once a release with Java 11 comes out I will be using it. I use alpha 1 on some of my recent Java 8 based projects that are in development.
In my opinion we have enough commits and bug fixes since alpha1 that indicates a new alpha 2 release.
A shorter release cycle for alpha releases will be good in my opinion.
I guess this might also help new bugs to be detected, tested and reported sooner (specially for the new animation system).
i were looking at JME github changes, indeed, there are some nice commits.
most required for myself one seems to be AmbientLight for PBR.
Anyway there are still some issues ofc, that can be fixed for later releases. Generally IMO new animation system issues should be high priority. (if there is someone who know Nehon new system idea best)
you said there is issue on github for one of this issues(gltf github), but what about other 2. i dont say it need to be fixed now(because it take a time, and anyway half of it work with some tricks), but i think this should be visible on github as issue if its not. I thought to create, but im unsure if there is something already created and related to this issues.
im happy with JME, currently just wait for “AmbientLight for PBR”, the only dilemma i had was to use Minie or wait @sgold to move its features into JME basecode. because its fantastic work he done there.
About PR, i agree with @jayfella, but i also feel there are not many of community devs who have time to do this, so should somehow make it easier.
i never used it myself, just at work we had something similar(but i dont think it was Travis) and it was working magically, but there were no issues like this.
how it work anyway? you just provide github repo on some Travis account? or github have some integration with it?(so maybe there is button like “resend to Travis”). deleting tag seems like odd solution
We were using Amazon tools for tickets and everything else, its great, but need to pay probably much.
I think there’s some integration at both ends. GitHub’s website knows when continuous integration is running on Travis or AppVeyor. Travis accepts my GitHub credentials and detects commits and pull requests made at GitHub.
I have my own Travis account, which I can use to trigger builds. Someone else set up builds to occur automatically; probably it was one of the project owners — I don’t know who. I’m not an owner of the jMonkeyEngine project. I believe the only control I have over automated builds is by commiting edits to the .travis.yml in the repo.
I don’t think we’re seeing queue delay, because in that case I’d be able to see the queued job(s) when I log into Travis. Also, GitHub would show an amber-colored disc in the commit history.