[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse.org-planning-council] RE: [cross-project-issues-dev] Galileo Must-do's
|
Hi Richard,
Richard Gronback wrote:
Hi Martin,
Many of the things we’re requiring are just good Eclipse citizenship
items that all projects should be striving for anyway. Globalization
effort is not only about larger companies or commercial adopters. At
least 2 of the 3 communities that all Eclipse projects are supposed to
support require this for worldwide consumption. I see these as Eclipse
entry requirements, not only as train requirements. See non-code
aspects listed on the Release Review checklist:
http://wiki.eclipse.org/Development_Resources/HOWTO/Release_Reviews
I can imagine a larger company contributing to a smaller project to
get it up to snuff if they are consumers of the project and require it
for a commercial product, for example. But, I doubt you’ll find a
willingness to contribute for the sake of getting projects on the
release train. Instead, we’ll likely just see smaller projects falling
off the train, or the respective project leads growing their project
team to meet the requirements, and in the process, improving the
overall quality/success of their proje
Rich I feel compelled to respond to some apparent assumptions.
First assumption: the stricter rules being proposed imply greater
quality of all project's output. Although seeming widely believed in
EF...I don't think this is the case for all projects. For example,
having a required new and noteworthy (which for my project we've/ECF
have adopted happily)...for a project like the platform and others,
obviously yes. But for EMF (e.g.), I personally would rather see Ed
spend his time on the newsgroup or mailing list answering questions
directly with users, or working on his book than writing a new and
noteworthy or a dozen plan.xmls. What I'm trying to say is that the
*means* to ensure quality (and success for that matter) are based upon a
number of things...e.g. how many resources are available, what's the
size of the community around the project, what stage of development it's
in, what organization is around to help with that community, etc.
There's a judgment about what's important for the project and community.
One size doesn't fit all projects/communities.
Second assumption: these rules have anything to do with project success.
Although it's easy to point to the platform and say 'they were
successful, so all projects that do things exactly like the platform
will be successful too'...I don't think that's actually the case.
Third assumption: losing small projects [from the train] isn't a
significant problem. I think this *is* a big problem, as the small
projects are (IMHO) the engine of innovation for Eclipse/Eclipse
Foundation. And as much as I would like it to be so, for small companies
(and independents) it's not as easy to find contributors...especially
from outside the company that leads the project (see our old friend
project diversity).
And also: "I can imagine a larger company contributing to a smaller
project to get it up to snuff if they are consumers of the project and
require it for a commercial product, for example"...I also can imagine
it, but regrettably I haven't seen it happen yet.
Scott
