In an effort to become a better player in the open source community, jMonkeyEngine is tweaking it's contribution policies. Our goal is to make it easier for community members to contribute to the jME code base while maintaining the level of quality jME is known for.
The key change is that anyone who requests write access to the 2.0 code repository will be approved. However, they will be on a probationary period where this access will be revoked if any issues arise. This system will make allow users to get bug fixes and new features in place without having to rely on a Developer.
This system will work in the following way:
A user will request write access to the repository (they will then be given the Contributor title).
The user will post on the forum any changes they wish to contribute back to the code base.
If after 1 day there are no disagreements of the change, the user can then submit the change into the repository.
If any item is contributed that is contested by another user or developer, that user will immediately lose write access while the contribution is investigated. If it is deemed to not be worth losing contributor title over, it will be granted again.
This system requires self governing of the community, but the community is one of jME's strongest attributes. I believe that this will prevent stagnation of the code base and give the community a chance to help build the best engine in Java.
This system will be tweaked over the coming months as issues arise.
If you are interested in becoming a Contributor email info@jmonkeyengine.com with your desire.
Why not just use a scheme were people submit patches - and when they have sent enough (ie. it becomes a nuisance to apply them all the time) they get write access?
As for the squabbling I have no solution - never seen that issue arise.
Submitted patches is basically what is happening now, but then becomes a bottle neck as a developer becomes free to apply it. Most developers no longer have the time to devote as they once did.
I think one day may be too little time to have a look at proposed contributions for most. But then again, at least one developer will look at the proposed patches before applying them - so in theory everything should be ok.
I'd still feel beeter with a longer probationary period, maybe three days or four.
Oh and there should be a special forum for the patches, so everybody intersted in the patch process can monitor that forum and see what's going on without missing a patch.
I agree about the specialized forum, users can discuss and/or disapprove certain patches this way more easily. Through user feedback, lacking patches can be improved in quality to be accepted into the jME codebase.
I don't think I said any time for the probationary period.
Sorry, I was quite mistakable refering to the probationary period for the patches, not the users!
This:
mojomonk said:
3. If after 1 day there are no disagreements of the change, the user can then submit the change into the repository.
is what needs work IMHO. It may very well be possible that after 24 hours nobody had enough time to even look at a bigger patch, let alone apply it locally and take it for a test drive.
Let's face it, by being easy to use as it is jME attracts some of inexperienced programmers who sometimes overestimate their skills and experience. I can for sure remember myself, but also others, suggesting some rather stupid or unfinished ideas over the time I've been here.
The thought of such users applying patches nobody else ever had a look at scares me.
Or maybe I am just being too pessimistic about this - what does everybody else think?
I think its a good idea to give more users write access. Most of what has been said sounds good to me. However I am also a bit apprehensive about giving write access to anyone who requests it… Perhaps just give write access to some more senior community members who would accept the responsibility of applying patches? Everything else said about people posting on a special forum and an overview etc could still stay…
What if a disgrunted member of the community offers a patch where he just improves some comments in the jme source. Patch gets approved. But then when the creator applies the patch, he also adds a small (x / 3 * 3) code somewhere in one of the same files. This would be very hard to spot… just the performance would take a hit as the call is executed 100K times per second or something. Not only would it be necessary to double-check if correct files have been changed but also if correct lines have been changed. Basically what I say is that it would be a sabotage nightmare (not to mention accidents of similar nature could creep in).
There are all kinds of people in the world. While me and you might never do anything like this, some people do have big egos and lash out. While I am sure our Xith3d bretheren are all just nice and honorable as we are… there still is a competition for the title of the best java 3d engine… I know I am paranoid… but as the saying goes… am I paranoid enough?
However I am also a bit apprehensive about giving write access to anyone who requests it... Perhaps just give write access to some more senior community members who would accept the responsibility of applying patches? Everything else said about people posting on a special forum and an overview etc could still stay...
+1
Also branches should be added to SVN , shouldn't they? To have a period of testing of the patches and a stable trunk/branch. Write access should be for the dev branch only obviously.
Also branches should be added to SVN , shouldn't they? To have a period of testing of the patches and a stable trunk/branch. Write access should be for the dev branch only obviously.
I am not so sure about this one.. From my experience branching complicates things and unless there is a real need for it, should not be done... Doing a new branch for every patch would just get messy... we want a system that makes contributing easier.. not harder...
What if a disgrunted member of the community offers a patch where he just improves some comments in the jme source. Patch gets approved. But then when the creator applies the patch, he also adds a small (x / 3 * 3) code somewhere in one of the same files. This would be very hard to spot.. just the performance would take a hit as the call is executed 100K times per second or something. Not only would it be necessary to double-check if correct files have been changed but also if correct lines have been changed. Basically what I say is that it would be a sabotage nightmare (not to mention accidents of similar nature could creep in).
This is where community support is important. Everyone that is interested should be getting SVN update e-mails and looking at the diffs they provide. If enough people look at the diffs of contributions, then these sorts of things would be caught.
I don't mind only allowing contribution access to more senior members... but how is that defined? Then we just get back to where we started, with our policy for accepting new Developers, etc.
hevee - I can see 24 hours being too short. Perhaps, 48. I don't want to drag it out too long though and make it stagnate.
I actually agree with the initial 24-hours since that is dedicated to a question being raised, not approval being completed. If a question is raised about the validity of the patch within the 24-hour period and has not been properly addressed then the patch should be held off on until there is agreement. The problem with taking longer than 24-hours is that it will make patches potentially drag by for simple ones that are needed for developers to move forward and I think 24-hours is plenty of time for a patch submitted to get some sort of feedback.
This is where community support is important. Everyone that is interested should be getting SVN update e-mails and looking at the diffs they provide. If enough people look at the diffs of contributions, then these sorts of things would be caught.
I understand what you are saying and agree that the community itself should be taking more responsibility. I just think that the number of people who completely understand what is going on in the internals of jME and the relationship between its different parts is very small. Hoping on them catching this sort of stuff is a bit like hoping the current set-up is good enough and does not need to change.
I don't mind only allowing contribution access to more senior members... but how is that defined? Then we just get back to where we started, with our policy for accepting new Developers, etc.
Actually I do not know what the current policy is. During my 1 year stay here I do not think anything has changed in regard to developers? In any case the person who does the commits does not have to be a developer as such. Anyone has the skill of taking patches from the forum and applying them to the SVN. Having the forum as the source of the patches though, guarantees that we know what is going into the code. Everyone can still make patches and post them. Just some 2-4 more active member commit them after community review.
I think the most important change for contribution policies is the introduction of this 'Patches' forum (Perhaps using the neglected Tasks forum for this?). Keeping it in good order, one thread per patch, only patch related topics allowed etc will be an enormous progress. Applying patches from such an organized list should be a breeze. All this is nicely supported by the recently introduced board moderators policy change.
I just think that the number of people who completely understand what is going on in the internals of jME and the relationship between its different parts is very small. Hoping on them catching this sort of stuff is a bit like hoping the current set-up is good enough and does not need to change.
I do share your concerns about the repository being in jeopardy of malicious, obfuscated changes. However, it seems that with this system all that is needed is a "Hey! This looks slightly fishy, can we hold off until it is investigated!"
My only problem with this is that it seems like there'd have to be an attempt to define who is going to be doing these reviews. I'm all for stopping fishy changes, but what about legitimate contributions that stall forever and get lost beneath piles of posts (as occasionally happens with forum posts)? Before you get the wrong idea: I'm not saying it's a bad thing to do, just suggesting that modifications may be needed for the forum in order to accommodate this. Maybe some flag to say "This contribution under review", which pushes it to the top of the pile like a Sticky post.
Since there will probably not be dozens of patches per day (now even a week I presume)… All it would take to keep the related forum organized (sticking/unsticking of topics) is an active board moderator. And some discipline from the contributors themselves concerning the way they make and name their threads.
Only devs should have write access to the trunk. A new branch should be created for all contributors to work on (a single branch, not one per patch). This branch could then periodically (once a week?) be merged back into the trunk after it has been thoroughly tested.
If some one proposes a massive change or feature update (for example, changing how textures are handled) they get their own branch to work on and are responsible for keeping it up to date from the trunk until the time comes to merge it back.
This means everyone using jME would have a stable trunk they could be using and even if a really malevolent contributor manages to mangle the branch beyond repair we only lose at most a weeks worth of patches.
Contributors can get promoted to devs once they have proven themselves.
As for the Contribution Depot forum thing I'd suggest people use the Google code issue tracker and just post a link to the created issue in the Contribution Depot forum. Any real points made about the patch should be made in the issue log making it easier to track in the future (minor questions, comments could be made in the forum thread). One of the major reasons for doing this is traceability and more importantly so people can actually check in their work using some sort of defect number. Because in my experience most SVN check in messages are pretty useless. This also makes it easy to revert all changes related to a particular issue if they are spread over multiple check ins.
