Converting plugins to 64 bit - reward discussion

[ghisler(Author)]

I agree that some plugins are much more complex than others, e.g. 7zip, DarkCrypt and also SynWrite. However, I haven't found a fair system so far when I should offer a higher reward and when not. The current system is better for plugin writers with multiple small plugins than for those with just one or two large plugins. Any suggestions for a more fair system?

[Alextp]

U can give each plug the "complexity value". By manually reviewing. E.g 1..3. So when u look @ hpg_ed, u give it value of 1, when look @ Shelldetails u give it value of 2, and SynWrite/XBaseView - value of 3. Then u give value*$100

[tbeu]

Question is if complexity value depends on plugin complexity or porting complexity of plugin to x64. They may be not on the same level for some plugins.

[Flint]

tbeu
Sometimes porting to x64 can be the motive to improve a plugin beyond just adding a new architecture. So it's hard to estimate which part of changes was necessary and which optional. Especially when adapting plugin sources to new IDE.

[Alextp]

Tbeu
Complexity of porting, but it 's maybe bound to complexity of source(number of forms, commands, etc)

[Hacker]

[mod]Thread split from SynWrite (Syn2).

Hacker (Moderator)[/mod]

[tbeu]

Complexity of porting, but it 's maybe bound to complexity of source(number of forms, commands, etc)

But you never know complexity of porting unless you are finished. E.g. CatalogMaker.wcx64 compiled pretty fine but had some inappropriate compiler options which lead to access violations which hardly could be explained by debugging. Thus first it looked like any easy recompilation job but turned out to be tedious trial and error investigation. I doubt that you can tell if porting complexity is of level 1, 2 or 3 if source is not available.