| RE: [cdt-dev] CDT 3.0 Closing |
|
To provide a contrary story, we at TI have always found that we can never take Eclipse or CDT “as-is”. We hate doing it, and we’re actively trying to help out so that this delta hopefully shrinks to nothing, but I don’t know if this will ever truly happen since we rather push the envelope and use CDT as a building block and not just a total solution in and of itself.
There will always be some bug discovered by our internal QA that some project manager says we must fix for our product release, or some feature that our customers say they must have, etc., and it’s very difficult to just wait for the next CDT release for what you need and pitch your own product schedule out the window.
___________________________________________
Chris Recoskie Software Designer IDE Frameworks Group Texas Instruments, Toronto
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Lott, Jeremiah
David Daoust: > include just taking the CDT unchanged, or they may include scheduling a snapshot + fixes + testing. Either > way, when we are sloppy on our
dates, we negatively affect others. Alain Magloire: > etc … will usually take a snapshot/release and do there own Q/A before incorporating the open source > project. Eclipse, CDT are no exceptions.
Just a quick note on our part. I don't know what others do, but it has become our preference to ship CDT (and Eclipse) with no additional patches. This ensures maximum compatibility between our product and plugins from other vendors. This has generally worked pretty well because both CDT and Eclipse follow a release cycle that is more like a corporate setting. Releases are (compared to other open source projects) infrequent and undergo QA by the community before being declare a "release". Dates are set and we can plan a release, knowing that the actual release date will be pretty close. If major defects are found, the community reacts to quickly make a new bugfix release. We obviously do our own QA, but we do somewhat expect that before CDT was declared "released" that it underwent a decent QA process, which has held pretty true. So I guess we do treat CDT and Eclipse as exceptions to other open source projects.
Separately to specifically address the issue at hand. For us I think priority would be 1. production quality, 2. on-time release, 3. features. So I would prefer that minor annoyances or issues with workarounds, as well as unimplemented features, would be pushed off to ensure a more effective QA cycle. Of course I'm not a committer, so I guess that's my $.01 :).
Jeremiah |