@airbaggins kindly agreed to help us get more friendly with GitHub. There is a WIP mirror repository being set up here:
Please note:
This mirror is not official yet, and we might still make changes. Don't make yourself reliant on it.
Don't make any pull requests to this repository, they will be ignored.
We'd like to eventually move to Git/GitHub as our main repository, making SVN/GoogleCode the read-only mirror, but this will not be the case for some time still.
Get your GitHub accounts in working order
We’re currently working on committer attribution. You can help make sure we get your commit address right by reading the following help article and updating your account accordingly:
Special notice to committers
If you are currently added as a “Committer” to jMonkeyEngine on GoogleCode, post here with your GitHub username and I will add you to the corresponding “Committers” team on GitHub. As long as GitHub serves as a mirror this group will not serve any functional purpose; it’s merely for organizational purposes.
We could make some cleaning in the branches though…jme2 ones are not really needed anymore…or are they?
I mean we could have only migrated jme3 branches and keep the google code repo for history.
You also have to migrate all the issues from the google tracker.
I know I already said it, but I won’t give up that easily.
I’m really sad we’re leaving google code. I don’t really see the point in migrating to github, except obviously for git, but git is also available on google code.
The code browsing is like the worst on the internet. File diff is diff patch style which is IMO barely readable…
I know you think it will be beneficial for the community, but I fail to see how.
I’m one of the people that are using the most this repo, and this is just gonna hinder my everyday work. At least for a time, I’ll end up getting used to the damn thing, but really…what’s the point?
imho, the big benefit of github is the nice workflow of merge requests. Contributors can more easily publicise their changes and it encourages healthy, public debate before their changes are merged into the official project.
@airbaggins said:
imho, the big benefit of github is the nice workflow of merge requests. Contributors can more easily publicise their changes and it encourages healthy, public debate before their changes are merged into the official project.
Yeah ok, but that's what we mostly do here....isn't it?
I mean, some changes go straight to the repo because they are made by core members...but very often they've been thoroughly discussed in the core chat.
Other changes, usually made by contributors with commit access, are posted on the forum and waiting for approbation...
I don't know...for me it's trying to add features we don't really need by replacing some we do by poor counterparts.
Ok. Well you can always leave it as a mirror of SVN for now and see what the uptake is like.
Speaking personally, I have contributed to a few open source projects on github, but none on Google code. I find the github website a lot more pleasant in general to use. The way it encourages you to fork and put in pull requests is quite compelling. It conveys a feeling of empowerment to potentially good developers who might be put off by the process required by the bureaucracy of a project before they can start contributing. The emphasis is: “Go! Create! We will deal with the admin later.”
I guess the main feature missing that you have on Google code but not on github is the expandable tree browser. I rarely actually use those on websites anyway as they’re never going to be as good as searching in an IDE.
GitHub fixed the vulnerability in less than an hour and temporarily suspended Homakov's account pending an investigation into his actions. His account was later reinstated after the GitHub team determined that his intentions were not malicious.
“In parallel to the attack investigation we initiated a full audit of the GitHub codebase to ensure that no other instances of this vulnerability were present,” Preston-Werner said. “This audit is still ongoing, and I am going to personally ensure that we have a strategy going forward to prevent this type of vulnerability from happening again.”
Wait why am I sitting on this thread with advocacy posts… :?:
@airbaggins said:
Ok. Well you can always leave it as a mirror of SVN for now and see what the uptake is like.
Speaking personally, I have contributed to a few open source projects on github, but none on Google code. I find the github website a lot more pleasant in general to use. The way it encourages you to fork and put in pull requests is quite compelling. It conveys a feeling of empowerment to potentially good developers who might be put off by the process required by the bureaucracy of a project before they can start contributing. The emphasis is: “Go! Create! We will deal with the admin later.”
I guess the main feature missing that you have on Google code but not on github is the expandable tree browser. I rarely actually use those on websites anyway as they’re never going to be as good as searching in an IDE.
Yeah I guess you’re right.
Once again, I’m not against GIT, but, more the Github ui and facilities. Yeah the tree browser is one of the feature that I like, but the diff compare is also a lot better on google code.
Anyway, I’ll try github of course, maybe i’ll fall in love with the feature you describe…you never know.
Btw as a side note, since the discussiona bout github, was a simple git server over http and a gerrit source review taken into consideration? Since it would probably do exactly what is necessary, without adding any more stuff.
re: Github, I’m not going to check a bunch of different sites for patches. So if patches still don’t get posted here to the forums then someone else will have to review them. Not that I do it that often but still. I like having the submissions and discussions all right here. So I’m with Nehon, git or not-git discussions aside, I don’t see the point of github other than having JME’s name on github.
@airbaggins hehe, yeah that’s not what’s gonna make me change my mind but heh, can be handy.
EDIT : I don’t want to belittle your work though @airbaggins, that’s really not against you. From what I read in the chat you’ve been a great help for this.
I honestly don’t see the point really. Unless GitHub offers something invaluable that we’ve been wanting for a long while or would greatly help, I don’t see what good it could bring, except to have the name there.
I feel to switch to a different solution (in any circumstance) one would need either something highly sought-after and a significant improvement. Switching just for the hell of switching? I’m not for that.
Consider this an evaluation of GitHub. This wasn’t meant to be a debate. This thread was intended for existing (and newly registered) GitHub users to get their account properly connected with their pre-existing user in our commit history. That’s it.
My bad for saying “We’d like to eventually move to Git/GitHub”, Nevermind that. We’ll get back to arguing about the usefulness of GitHub if this mirror actually picks up steam.
@Empire Phoenix said:
Btw as a side note, since the discussiona bout github, was a simple git server over http and a gerrit source review taken into consideration? Since it would probably do exactly what is necessary, without adding any more stuff.
There is also gitlab, which is kind of cool. There are a few issues about self-hosting this though…
Bandwidth: A full clone of the repository is 657MB. Removing the jME2 branches will help, but the payload will still be measured in the hundreds of MB's. Capacity going towards this is that which is being taken away from serving web pages.
CPU Cycles: When you do a clone operation (as well as a fetch or pull), the payload is compressed on the server. This takes real CPU power to drive, so - as with bandwidth - capacity going towards serving source code is being taken away from serving web pages.
Administration: Many folks already have GitHub accounts and making a new one requires zero intervention on our part. Our involvement is essentially "Grant or Revoke access".
Discovery: There are over 4.6 million repositories on GitHub and nearly 3 million users. This is where people interested in open-source are hanging out.
And ofc the german is afraid to lose control over the engine Like when people create maven repos based on pulls of engine builds that have been changed and don’t even pull the SDK and then come here to complain it doesn’t work etc… maven, osgi, all kinds of these distro formats are planned to come directly from us after release. So I think I can speak for the whole core developer group that we don’t want to make this a way to distribute or spread the coding work. So, no worries anyone, you just should have an account if you want to appear on github as a jme contributor
@normen said:
And ofc the german is afraid to lose control over the engine ;) Like when people create maven repos based on pulls of engine builds that have been changed and don't even pull the SDK and then come here to complain it doesn't work etc.. maven, osgi, all kinds of these distro formats are planned to come directly from us after release.
I think part of what’s fueling this is that while we may be waiting to call jME3 a release, there are plenty of people out there relying on jME and already integrating it into their workflows. To this end, there should be a community driven (and centralized) effort to make the official code available in the expected channels.
That is to say… downloadable via version control (git, svn, whatever), JAR bundles, and popular dependency management tool(s). Considering how popular Maven is in the open-source community, why do we not reach out to one of the folks generating builds and start doing this under our own namespace?
I know, bigger picture than this thread, but at least part of the discussed move to git is a general thirst for access on behalf of users.
@sbook said:
I think part of what's fueling this is that while we may be waiting to call jME3 a release, there are plenty of people out there relying on jME and already integrating it into their workflows. To this end, there should be a community driven (and centralized) effort to make the official code available in the expected channels.
That is to say… downloadable via version control (git, svn, whatever), JAR bundles, and popular dependency management tool(s). Considering how popular Maven is in the open-source community, why do we not reach out to one of the folks generating builds and start doing this under our own namespace?
I know, bigger picture than this thread, but at least part of the discussed move to git is a general thirst for access on behalf of users.
I’m sorry but I doubt real professionals who just need some 3D scenegraph for their business app have any issue integrating jME without any maven or github no matter where its from and in the end will most probably use their own way to integrate it into their build system anyway.
And what good came to jME from wild code EVER? In more than 10 years? Darkstars collada importer? ^^
