News:

Latest versions:
Server plugin: 0.5.1
MVP dongle: 0.5.2
Raspberry Pi client: 0.5.2
Windows client: 0.5.2-1

Main Menu

DEVELOPING FOR VOMP

Started by Chris, March 17, 2007, 17:09:55

Previous topic - Next topic

Chris

Issues to consider when developing for vomp...

I think it's great that people are working on things for vomp, but I need to do something about these monolithic patches containing several different additions or changes turning up that are near impossible to integrate into the codebase. So...

1. I am swamped with patches for vomp. It is safe to assume that if you create a patch for vomp it will not be included in cvs any time soon.

2. Smaller patches that do a very specific change are good - especially with an explanation.

3. Anything that runs straight on top of the current code is more likely to get a good reception - e.g. a new V* view class that does something but doesn't change anything else in the code.

4. Patches that change code in the base classes (e.g. surface, box, view, timers - the low level stuff) are likely to get a bad reception. To include these I have to read them very carefully to find out what they do. My time is limited as is everyone's, and frankly I would rather be working on my list of things to do for vomp rather than attempting to understand everyone else's. (Currently I spend most of my vomp time reading patches rather than coding things I want to code). If you need things changing in the base classes maybe it would be better to seperate them from your main code and submit bug reports or feature requests...

5. Patches that include patches from other people are bad. I probably already have that other patch on my to-do list, and having another patch file with that code included makes things really tricky. Especially if you don't even mention it is there.

6. I am trying to work through the patches in chronological order. This means that earlier patches will be easier to go through, but later patches won't because the codebase might have changed too much before I get to them.

Now I don't mean to put people off coding for vomp, but I would still like to be able to code for vomp myself which means I have to understand the code and keep it on track.

I realise it's going to be more difficult to code for vomp like this, but what I have to do with two monolithic conflicting patches isn't difficult, it's impossible...

Chris

P.S. If you're not bothered about mods you make going into cvs, and you don't mind repatching every now and again when I break things for you, then I don't mind at all people making mods. Hey, this is all released under the GPL after all. If there were lots of these I would even make something for the main vomp web site to host them all.