That's about all I have to say about that. Eclipse is what you make of it. If you want change, get in, get your hands dirty, and make change happen. I've been able to do that over my years at Eclipse. We have a pretty decent C/C++ IDE thanks to the hard work of the community. We've been able to work with the platform team to push a number of changes down into the platform, debug especially, and now with the flexible resources, and more to come.
It is a lot of work, but then no one gets a free pass. If you're passionate about helping with Eclipse's success, you can make it happen, if you have the desire to work at it and work with our great community. If you are just going to complain about things from the sidelines, you shouldn't expect much sympathy. And that's all I have to say about that.
Eclipse rules, that is for sure. CDT rules as well, and I look forward to the day when you can do cross-language debugging over the JNI barrier. However, the threshold for contributing to Eclipse/CDT is far too high when it comes to smaller, janitorial, tasks.
ReplyDeleteFact is, if I see something bad in the code (warnings, sloppyness, ugly code, whatever), there are simply too many steps to go through for me to feel that it is worth the time to fix things. Lowering that threshold would certainly make it easier for newcomers to get into CDT-development.
Jesper, if Git was available, would you find it easier to contribute? What are your major stumbling blocks in contributing patches?
ReplyDeleteGreat point Chris. We need a high octane solution that makes it easier for both the contributor and the committer that has to apply them. I'm really hoping git can do that.
ReplyDeleteBTW, once Helios is out the door, I'll work with the CDT gang to get onto git. Assuming egit is good enough at that point, that is. Or failing that, git gui does the trick.