[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] CDT 3.0 Closing
|
Title: Message
David Daoust:
> There is a
wider community that takes our published dates and makes plans around them.
These plans may
> 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:
> This may sound
harsher then intended, but companies shipping major piece of code, GCC, GDB,
Mozilla
> 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
