Hi Doug,
Doug Schaefer wrote:
The point is
to raise the quality
perception of Eclipse in the marketplace, i.e., beat NetBeans (and for
my
community, be as good as Visual Studio). Nothing changes to the train
and its
current operation. This is more an addition for those projects who want
and
need to work at addressing these issues.
I understand this point. But that's not the only purpose/strategic
goal for EF projects (to beat NetBeans/Visual Studio). Other projects
have other needs...like further distribution/popularization,
emerging/new technical areas for tooling, enabling RCP apps, etc. I
don't think these are inherently any less important to the community as
a whole (e.g. committer community, user community, etc).
The process
for managing these products
needs to be open just like everything else in Eclipse.
I agree.
But
depending on what we’re
trying to achieve strategically, some components would end up not
making the
cut, just like in the “real” world (been there, done that, i.e.
been cut, its just part of doing business).
But the last I checked, EF wasn't a business. So who decides who
doesn't 'make the cut'?
Scott
|
