Patch submission guidelines?

[3DModelerMan]

Are there any guidelines published for submitting patches? There are a lot of patches on the forum that haven't been added into the engine (like Devsh's tesselation) because in some way they were incompatible with the engine itself, or the testing process, or the coding style, or other similar things. It would be nice if somewhere on the wiki (and have a link to it on the Sourceforge and main pages) there was a guide for getting your patch accepted. That way we might get new features sooner, and they would be more stable.

[hendu]

The FAQ does. IMHO it's fairly clear and easy to follow, but you should also consider that not all patches are meant for inclusion by their authors.

[ACE247]

Maybe we can have some wiki page that details all the patches, and why they are not included, etc what needs fixing.

[CuteAlien]

I guess most of it is pretty much common sense:
- make as little changes as possible, which means only one change per patch and if your patch depends on other changes then make extra patches for the other changes (maybe the most common problem)
- test it! (no really - just do it, even for the single line that can't break anything - it still will have a bug)
- post your test-code
- add some short example if it's a complete new feature
- use the same coding style as used already in Irrlicht
- post it on the patchtracker
- post about it on the forum and explain what it does

Also very trivial patches (the typical 1-2 line patch) can just be posted in the forum and if they come with explanation or even a testcase they are usually added quick.

If you really want a patch to get in and it doesn't for a long time you can always ask about it or remind us again. If I remember the correct thread - the patch of Devsh got feedback from Hybrid including the reasoning why it couldn't be included like that.

Also, well, sometimes we simply don't manage to add patches for a while - for time or other reasons (I've been pretty much failing adding something now for 3 months for personal reasons, but I'll be back).

edit: Also you can certainly always put more info on the Wiki - that's the cool thing about the Wiki :-)

[3DModelerMan]

Yeah. I think I'm going to write a few articles on there soon (if I can find the time that is). Thanks for the feedback. Also, what about patches (like Devsh's) that propose adding a feature? Should the features be kind of small? If a feature can be implemented such that old code is still compatible (making use of default values when adding parameters to functions) does that help?

[hybrid]

There's no real limit on the size of changes, whether bug fixes or feature additions. But of course, larger changes require more testing and much more focus on getting everything clean and very good integrated into the existing API and functionality. Of course, adding new features and keeping all previous parameters and so in use is good. But there's no reason to make a new feature integrate in a strange way, just to avoid some necessary change to the API. If we have concerns about the way the method is integrated in the patch, we will say so and ask for fixes or suggest better ways on our own.

[CuteAlien]

Yeah, it's not size, but avoiding adding more stuff than necessary for a single patch. One feature per patch - that is the important part. Splitting up patches as much as possible makes them easier to read them and often also easier to decide on applying them or not. For example you might want to add new API functions - putting a setter and getter together for one variable in one patch is fine, but adding a second API function which you just wanted to add as well in the same class but affects an independent variable should rather go in an own patch.
Lets use another (more concrete) example - you want multiselection in the file-open dialog, but for that you need multiselection first in the listbox as that is used in the file-open dialog. This means you have (at least) 2 patches - one for the listbox and then one for the file-open dialog depending on the first one. And maybe you even wait with writing the second patch and just mention in your first for what it could be used as well (for this specific case I have for example already 2 patches which I won't apply without changes).

[3DModelerMan]

http://www.irrlicht3d.org/wiki/index.ph ... Guidelines