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.
The process for managing these products
needs to be open just like everything else in Eclipse. 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).
From: eclipse.org-planning-council-bounces@xxxxxxxxxxx
[mailto:eclipse.org-planning-council-bounces@xxxxxxxxxxx] On Behalf Of Scott Lewis
Sent: Friday, November 02, 2007
1:47 PM
To: eclipse.org-planning-council
Subject: Re:
[eclipse.org-planning-council] A suggested topic for PlanningCouncil Discussion
Doug Schaefer wrote:
Yes. Allow any project to release along with the train as far
as scheduling and the monster update site go. But create a second tier of
product quality components that would be released as part of the EPP packages.
I don't believe this is a good idea. Why? Because all it does is
move the problem of selection/exclusion to another body (the EPP
project). Currently the EPP selection criteria are (IMHO) pretty
closed. That is, up to this point, the EPP project team members and/or EF
select the contents of the packages (the individual projects) with whatever
criteria they have chosen. There's a discussion on the epp project
newsgroup about the future EPP selection criteria here:
http://www.eclipse.org/newsportal/article.php?id=101&group=eclipse.technology.packaging#101
(It's thread entitled 'Policies for EPP' started by Ian)
I guess I see having two tiers (an EF set of 'products' and then a set of
'projects') as inherently a non-level playing field...to re-use Doug's
observation.
Scott