Like most teams that build C/C++ tools on top of Eclipse & CDT we have been building Carbide with the latest platform release and a somewhat forked version of CDT. This made sense as most of our releases have shipped in the winter or spring, long after the last major Eclipse release. But with the next major release of Carbide due after Helios we’ve jumped on the opportunity to align more closely on Eclipse 3.6 and CDT 7.0. How closely? Well, we’ve just started creating our Carbide builds with 3.6M5 and the CDT 7.0 sources straight out of the eclipse.org CVS repository.
We hesitated to do this in the past because it means we effectively have the entire CDT team contributing to Carbide in real time: any one of the committers can break our build or introduce bugs. But we’re more confident now and our experience with the CDT community has been very good: people rarely break the build and the quality and review of contributions has been excellent.
And since we sync up with the latest platform and CDT eventually anyway is makes more sense to discover any issues at the moment when the work is developed and contributed, not months later. Now both our internal test team and the Carbide beta group can give the new platform and CDT stuff a workout before it’s released. This also lets us get rid of our internal copy of CDT we would occasionally sync with the public one. Trying to keep it updated was a pain and it created a temping way for us to make changes that weren’t really ready to go back into the community.
Wednesday, February 24, 2010
Friday, February 5, 2010
CDT-EDC and Openness
While our team here at Nokia has been developing the Eclipse Debugger for C/C++ (EDC) as a component of the CDT project we wanted to do it in the open as much as possible. But we still had quite a bit of initial work to do before the community would be able to evaluate what we were doing. Now that the initial contribution is in CDT we're going to start working on changing our habits to bring more openness and transparency to the effort:
We're going to start moving our discussions about EDC to the cdt-dev mailing list. This may seem simple but we also don't want to bore the CDT community with issues related to Carbide, Symbian, on-device debugging etc. so we'll need to be a little selective.
New issues with EDC will be logged in the Eclipse bugzilla instead of our Carbide bugzilla. We'll need to be a little selective here too and probably won't log every minor issue, but anything that merits any sort of discussion will be public.
Currently our team has two committers on the CDT project, Warren Paul and myself. I've been syncing the EDC sources in CDT with our internal copy. This has done wonders for my committer stats, it looks like I wrote all of the EDC code, but has masked the contributions of our team members. So we're going to start nominating additional people as CDT committers, starting with the ones who already have a track record of contributions to other components in addition to their work on EDC.
We're going to start moving our discussions about EDC to the cdt-dev mailing list. This may seem simple but we also don't want to bore the CDT community with issues related to Carbide, Symbian, on-device debugging etc. so we'll need to be a little selective.
New issues with EDC will be logged in the Eclipse bugzilla instead of our Carbide bugzilla. We'll need to be a little selective here too and probably won't log every minor issue, but anything that merits any sort of discussion will be public.
Currently our team has two committers on the CDT project, Warren Paul and myself. I've been syncing the EDC sources in CDT with our internal copy. This has done wonders for my committer stats, it looks like I wrote all of the EDC code, but has masked the contributions of our team members. So we're going to start nominating additional people as CDT committers, starting with the ones who already have a track record of contributions to other components in addition to their work on EDC.
Subscribe to:
Posts (Atom)
