Community generated patches

[BradB]

OK, this is my first post here - so I have no cred
I've been reading the forums, and in particular this thread caught my eye - http://irrlicht.sourceforge.net/phpBB2/ ... sc&start=0

I must admit that when I first came here & read that there was no CVS, I was a little, well I don't know what I thought - just that it was unusual for an open source project. I actually think that Niko is doing the right thing, he is dedicated enough that a single developer is better than 100 part time helpers.

However, the fog thread above also illustrated that the community wants to contribute & wants features before any "official" point releases.

My proposal is thus:
The Irrlicht engine obtains a community space, either on this site in its own area. In this central place people can post their code modifications, I personally would like the mods in "patch" format, so I can patch my tree - though I don't know if there is a patch program for Win32.
Anyhow, patches would need to be submitted against a particular code version, and commented - ie the fog patch in the link above could have details like.

Code: Select all

Description : Adds fog to OpenGL and DX interfaces
Base Code : 0.4.0, 0.4.2
Known Conflicts : None
Download : fog-0.4.0.patch.gz

Anyone who wants fog in their engine now just runs (under Linux at least) something like "gunzip -cd fog-0.4.0.patch.gz | patch", and their Irrlicht 0.4.0 code base will now have fog enabled.
If Niko likes a particular patch, he can just push it into his current dev tree (and tell people that that patch is accepted, and not required for the next release). Of course, all submissions would need to turn copyright over to Niko & the Irrlicht license.
Also, there needs to be a cavet that all patches are completely unsupported & they may need a special forum area.

So what do people think? I think this will have twin benefits
1) People can stop reimplementing what has already been done (like the fog)
2) The community can contribute in a more effective way, without distrupting Niko's chosen style of development.

Cheers
Brad

[Robomaniac]

Great idea, i hadn't thought of that, but it'll be great. I know the problem w/ the fog, as i have three or four versions of it that i tried. This will keep all the different patches organized while not eliminating Niko's cvs thoughts.

Great Idea Again, hope it gets implemented

[niko]

Hm, very nice idea. I think there exists a windows version of the patch command too, right?
Some months ago, someone had another idea: Maintaining his own Irrlicht engine version, with all patches included. Would be a nice solution too, because lots of Irrlicht users don't want to mess up with the source code and simply want to use the binary version.

[Guest]

I just found some info here http://drupal.org/book/view/324 for windows diff & patching.
I think this would be a good first step toward having multiple unofficial Irrlicht binaries.
So, who has patches to get this rolling? Fog someone?

Brad

[keless]

Just so the rest of you know, I've worked with Brad, so I can lend him my credibility.

[Robomaniac]

I've got fog and the DirectX for DevC++ patch, and i was working on an edit box before Niko beat me to it. So, i can put that one up, but since the fog is going to be integrated in the next version, i don't know how helpful it would be

-- The Robomaniac

[buhatkj]

while everybody knows there are thousands(maybe hundreds of thousands) of contributors to linux, maybe what they dont know, is that NOTHING gets into the kernel without linus's personal approval. this idea sounds similar! it's been workin great for linux, i bet it can work for irrlicht. maybe eve-corp can host it for us? this is clearly an irrlicht related prject...and then maybe niko could put a link to it someplace prominent here. i have some little patches i would like to contribute too, like my improved irrlicht timer class.

[tstuefe]

Hi,

this addresses a topic which has been a sore spot for me with Irrlicht too. But your approach requires a lot of work:

For every new official irrlicht release, patch programmers would have to go through all their patches and check whether they are still valid for the new release. Potentially they might have to maintain multiple versions, to support different base releases.

Then there is the problem of patches which contradict each other - after a while, you end up with tons of patches, which work or don't work together - probably not even the patch creators know this, because they don't test all patch combinations. I've seen this with the Torque game engine, they do the same thing. A base release which gets updated pretty seldom, and tons of patches from game programmers which need a faster update cycle. Collecting all the patches and integrating them and making sure they work together is pain.

Plus, the patches from the people go not through the same testing Niko does.

I always thought Linux works differently: the HEAD version is maintained by Linus, but in contrast to Niko he _does_ take other people changes. Older releases are handed of to some other lead maintainer. The advantage of this approach is (compared to a simple "everyone posts his patch into some database"): You always have a stable branch or stable branches, where all patches are well incorporated, are ensured to work together and are tested together.

Of course, a patch database would still be a big improvement to the current situation, where people's patches maybe get posted to the forum, if at all...

[BradB]

Tstuefe - I agree that there will be problems with my patch database idea, but with a few guides that people want to follow it should be OK.

Basically
1) It's unofficial, so use patches at your own risk, people will have to live with conflicts
2) Any majorly cool patches that conflict - well, I'm sure someone will fix that & submit an uber patch combining the functionality
3) Patch submitters only need to patch against the versions they want to, I'd expect most patches to only track the last stable version.
4) If Niko accepts a patch (or implements the functionality of that patch) he'll need to mark that clearly in the changelog, perhaps have a "Redundant Patches from Last Version" section

I think that Irrlicht is moving fast enough that there won't be an unweildy patch database, and at least now Niko has a central place to draw patches from.

Right - now someone has to step up with the webspace to host this. Perhaps even a wiki page where people can just post descriptions & links to patches? If the wiki + links (ie patches actually hosted elsewhere) idea works, I can set one up.

Cheers
Brad

[keless]

I think I have an idea of a comprimise:

Whoever is the administrator of the patch database should be in control of it-- they would:
1) accept patch submissions
2) evaluate whether the proposed patch is a) neccesary, b) efficiently coded, and c) does not conflict with other patches
3) work with patch submitters to keep their patches from conflicting, and to try to keep everyone leaving IrrLicht with the same API style

PROS:
* users of the 'alpha library' would not have to worry about conflicting patches, because they would be weeded out before they reached the library
* all of the patches would be quality assured, and they would adhere to the API-style of IrrLicht which we have all come to love
* Niko would only have to worry about one tree to merge with his own
* users would only have to worry about one tree-- the latest alpha library version

CONS:
* requires someone to dedicate themselves to the alpha library (which would take away time from their own personal projects)
* for users to get the latest and greatest patches, they have to wait for them to be merged into the alpha library (this will still be many times faster than waiting for the next official IrrLicht version, however)

[buhatkj]

niko does pay attention to our features requests and change submissions, but he carefully reviews, tests, and adapts them to his API style before making them a part of irrlicht. he has credited many people for contriduting code to irrlicht which he adapted and added to a following version. like the curved surfaces and tga loader stuff.

i agree it is important to note that these patches must be clearly known to be under the irrlicht license(ie. use at your own risk, and there is ABSOLUTELY no liability or guarantee) so use at your own risk.

i think this can work. what we need is somebody who is willing to volunteer to do it, and provide the webspace. perhaps even a small team like 2-3 people who could review patches and post them. i would happily be one of those people(doubt i'd have time to do it ALONE tho) and somebody to provide several hundred megs of webspace to host this sucker on.

maybe we could even register it with SF as the "irrlicht patch project".

all patches should be made against a known version of irrlicht, and which version the patch is for, any other patches it conflicts with, and any other patches it depends on should be clearly noted

the same sort of thing commonly happens with .rpm archives in linux, their dependencies are well-known and documented before they are posted/released. the author of the patch should try to include any details to this effect, and also possibly a basic set of installation instructions for their patch (such as the nice instructions that madinitaly includes with his MD3 loader), just a text files with the basic step to ge tthe files where they need to be and compile the engine is sufficient.

if people aren't comfortable recompiling the engine they prolly should either use one of perhaps a few pre-made patched engine binaries (we could take requests on pre-compiled versions to offer, not everybody has the same needs) or just stick to the latest official version of irrlicht.

this is all talk tho, if enough people second this, and give it their blessing then somebody has gotta run with it. i think there is a cadre of really dedicated irrlicht users who would like to see this happen. i certainly wanna see it happen, and be a part of it if i can.

also we would need niko's blessing for this i think, to make sure we aren't gonna get in his way or anything with this.

-ted

[niko]

maybe we could even register it with SF as the "irrlicht patch project".

Also a nice idea. Would be cool, would take a lot of admin work away from me. And I rather like to code then to update homepages. Some time ago somebody wanted to do something similar, but as most projects do, it stopped before they even had a homepage: http://irrlichtx.sourceforge.net/

also we would need niko's blessing for this i think, to make sure we aren't gonna get in his way or anything with this.

No problem with me, do what you like. If it wouldn't be ok for me that people can do with Irrlicht what they want, I would have chosen another license for Irrlicht.

[buhatkj]

welp to try and prevent that happening again, the vital part is to get more than one guy running it. any volunteers? if there is 3+ people interested in participating in this then i think it's worthwhile
-ted

[Robomaniac]

I could help a bit, but nothing too much. I can work on the webpage or something, and manage a few patches, but i don't have th time to test everything. But i'll gladly help if needed.

[saigumi]

Well, even better.

I submitted a request for "Irrlicht Patches" on sourceforge with the same license as Irrlicht. The page I have includes heavy disclaimers that it isn't supported by Niko, Not to mail Niko about problems with the 3rd party code, and if they do, I release insane, mutated deer on them.

Being one of the 3 people in the world who knows how to set up all the private/public keys to submit files to CVS, it will have a CVS directory.