I love Code::Blocks

[jvadillo]

I really really love codeblocks. I use it for quite complex projects and I feel that this environment has saved my life and my work several times.

I started more than 12 years ago using DevCPP, and sometime around 5 years ago I jumped to CB and I really felt the improvement for better.

I am a pure C programmer, and I develop firmware for embedded systems, but many times I have to do projects involving a Windows machine, and this is the BEST solution for both worlds. And it is definetly the best solution for programming C under Windows. I simply don't like the over-bloated Visual Studio.

I would like to contribute somehow to improve it. I am so thankful...

I have donated some money in the past, but I would like to do something more.

Please tell us what can we do more to improve this already incredible and ultra-powerful tool . I would really like to get more people involved in this project, to have more frequent updates, to solve some bugs...

[tigerbeard]

I am sure the devs love to get feedback like that.

I guess you had a look into the ticket system on sourceforge. I am sure the post from Andrew from last year is still valid. It was kind of made for your question:  https://forums.codeblocks.org/index.php/topic,24549.msg167582.html#msg167582

[AndrewCot]

The work turned out to be a big waste of time like allot of the work I have done as very little has made it into the C::B trunk.

[MortenMacFly]

The work turned out to be a big waste of time like allot of the work I have done as very little has made it into the C::B trunk.

...for example?

[AndrewCot]

One example of many:
https://forums.codeblocks.org/index.php/topic,24603.0.html

[MortenMacFly]

One example of many:
https://forums.codeblocks.org/index.php/topic,24603.0.html

Oh dear... its not forgotten. The installer will be taken care of once there is a new release prepared. As I said before: please be more patient.

Also, don't forget that we always focus on stability. Just mindlessly applying tons of patches will not work. Therefore, careful testing is required. So you can help with that one quite well: Write test-cases and provide proof that patches you submit will not cause any harm under all conditions. That is what causes most delays. I, for example, have quite a bunch of patches applied for month before even considering applying it to SVN. If you are in a total hurry, you can contact me for specific patches via PM.

[AndrewCot]

So you are saying that I have to work under different rules to other devs who supply patches in the SF ticket system or apply changes directly to the SVN tree? I have seen very scarce (by this I mean I cannot remember seeing any) SF ticket info by people for "Write test-cases and provide proof that patches you submit will not cause any harm". Is this a new requirement as there are no test harnesses to use to write test cases, with the exception of the CC that I have come accross?

I also see a allot of changes being applied to the SF SVN trunk that are peer reviewed and have no links to any tickets or forum posts. This makes the changes very hard or impossible to see if they are to do with a stability issue.
There have also been a number of SF SVN truck changes that have had to have changes applied within a day to fix them due to the lack of peer reviews and lack of testing.

I test my changes as best I can and also when changing complex or code that may break break code use it for an extended period of time before submitting a patch. As you are aware due to the complexities of the code base it is hard, unless you know all of the code inside out to test every code path that may be affected.
As for sending a PM I did for the installer and it got me where?

As for test cases, if this is a requirement then make it a requirement for every SVN change.

[MortenMacFly]

So you are saying that I have to work under different rules to other devs who supply patches in the SF ticket system or apply changes directly to the SVN tree?

No. All should work under the same conditions.
But of course we trust people more that have contributed over years.

And there is also a difference between fixing bugs and implementing new features. Fixing bugs is probably more relaxed as you can prove easily the bug is actually fixed. Implementing new features should actually require a discussion beforehand whether or not such a feature is desired. A lot of patches "to make things easier" caused actually the opposite.

So, I don't want you to stop, but it is no help to pup tons of patches and then abandon these after a while because nobody takes care immediately. Instead, try to push / move forward what you believe is important.

[AndrewCot]

If other devs want info or help or have feedback or comments or updates on any of my patches I will help, but I will not push patches or chase things up where the other party (if there is another party) has gone AWAL or has stopped responding or no one is willing to look at the patch.

[MortenMacFly]

If other devs want info or help or have feedback or comments or updates on any of my patches I will help, but I will not push patches or chase things up where the other party (if there is another party) has gone AWAL or has stopped responding or no one is willing to look at the patch.

As you "nagged me" (just as I suggested to do) I gave you a few comments on open tickets assigned to me.
Keep it that way. :-)