@normen said:And what good came to jME from wild code *EVER*? In more than 10 years? Darkstars collada importer? ^^
This is an indictment of the status quo rather than a reason to continue it ^^
@sbook said: This is an indictment of the status quo rather than a reason to continue it ^^We just started to get it all together and we already have 3 half-done gui systems again ^^
1 Like
Well what do you expect? It’s opensource so it will branch no matter what we do. Basically there are two options for this:
- One official site with stuff, like currently, will reduce amount of stuff done externally, but improve average quality.
- Allow wild branching and merging, eg like many other opensource things do, this will create many inferior aand crippeld branches, but a the fittest survives system, eg if there is finally by someone done a good gui library that meets most usecases, the others will start to degrade and vanish after time.
(btw i have a also a own gui, since nifty is just to limited for some usecases with solution2 there is a good chance, that more people start to help each other instead of everyone doing a own branch)
Generally i would say both are ok, but should be done consequently.
What I miss for 1 currently is clear guidelines what needs to be done to contribute code/moduls in terms of coding style, formating, dokumentation, and other considerations. I would greatly love it if we would have some kind of official approval workflow. To often it happens that some aptches and code parts just die in the contribute thread when they fall of the site without ever being really evaluated.
@Empire Phoenix said: Generally i would say both are ok, but should be done consequently. What I miss for 1 currently is clear guidelines what needs to be done to contribute code/moduls in terms of coding style, formating, dokumentation, and other considerations. I would greatly love it if we would have some kind of official approval workflow. To often it happens that some aptches and code parts just die in the contribute thread when they fall of the site without ever being really evaluated.I also like being consistent and concise (the german "konsequent" has no equivalent in english, just like "fair" has none in german ;))
We do have an official workflow for contributions, check out the Introduction menu on top. Doing a development description for each subsystem is kind of hard and I think the general descriptions on how the subsystems are supposed to be used should give developers enough insight on how new features should look? But if you have concise ideas on what can improve how, hit us!
Don’t misinterpret the fact that not everything in the contrib depot goes to core as “ignoring” though, its actually QC 
If it doesn’t fit in yet we won’t add it and a lot of that code needs some more work or additional extensions of the engine.
Finally, jME2 tried 2) already, lets try 1) now. Properly, “konsequent”. 
Here’s mine FAIW.
Doesn’t konsequent mean consistent?
Here’s mine, but I’ve somehow received emails from GitHub with some commits mentioning my name, maybe it’s already working?
@normen
This might be, but often a small not with a short description why not would be much more useful than no response at all.
Oh, also
@Empire Phoenix said: @normen This might be, but often a small not with a short description why not would be much more useful than no response at all.Why not what? This thread is about that there is a way to access via github now :?
Edit: Ah, if you mean the comments on why things won’t go in? I guess mostly thats being done but it seldom works like that. A “short note” to the dev mostly results in him trying to go at the arguments one by one which results in a long discussion and in the worst case the guy leaving… That its about what I just said (how it actually fits the engine and is useful to others) is being ignored. Its not like the code is gone, its right there in the contrib repo to be used. But if each of these threads is 10 pages long with various back and forths about what is good or not about it few will actually trust it, use it or develop it further I guess.
We are moving to GitHub. @Kaelthas @pspeed and @zathras do you have GitHub accounts?
Also, if anyone wanna take a crack at the GoogleCode Issues to GitHub Issues migration script, please get in touch.
http://beets.radbox.org/blog/github-issues.html
https://github.com/daniele-athome/google-code-issues-migrator
Yay.
The issue migration scripts looks pretty straightforward… i test it against a repository and report back
//One thing: as the descriptions says every collaborator gets an email on any migrated issue, so it might be better setting up the whole stuff before you add a lot of people 