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.
Yes, when possible, surgical commits are better.
…it’s not always possible.
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.
Is anyone currently using 3.3.0-alpha1?
AFAIK, these guys use 3.3-alpha1 or master.
@oxplay2 : he is using the new animation system and morphs
@mitm :
@tlf30: he added support for Java 11 and uses new animation system
and myself
In my mind, there’s a big difference between alpha1 and master. If people are using master, that doesn’t indicate any need for an alpha2 release.
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 might be wrong , I am yet a noob in such stuff 
I can only speak for myself, but a (new) release with this fix in would make my life a lot easier 
I use a sporadically updated master for MOSS development but I peg my libraries to full release versions… so for example JMEC was set to use 3.2.2-STABLE or something I think.
So for me it depends.
@oxplay2 : he is using the new animation system and morphs
im using 3.3.0-alpha1 from org.jmonkeyengine - Maven - Bintray (as i remember)
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)
@Ali_RS is there some ticket(github issue) made for this 2 additional issues i mentioned in:
https://hub.jmonkeyengine.org/t/solved-import-fbx/41456/28
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.
Thanks for all the responses. I’ll cut an alpha2 release ASAP.
I have no opinion on PR 1087.
I pushed a tag to the repo, but Travis ignored it—didn’t even run the continuous integration checks. I’m unclear what the issue is. I’ll delete the tag and try again.
again Travis dont like you 
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.
The documentation is at https://docs.travis-ci.com/
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.
So its not like Travis is connected to JME repo, but to your account / JME repo ?
i thought Travis have his own credentials for repo, or even dont need, because repo is public.
its your own Travis account?
edit: as i see in doc, it have a lot of options even AWS s3
also isnt this about some Travis queue delay?(even AWS tools that runned tests i remember had a delay)
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.
looking at
i see a lot options that might break auto-building. Might be good try different settings.