[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[news.eclipse.technology.kepler] Re: Kepler and Buckminster

Thomas, your posting is well thought out, and you make a good point
about the establishment of a common model. However, I think that the
model of the component world (nice phrase :) is only part of the
story.

Kepler is certainly about community metadata, but it should also
be about integrating with the tool frontends to present the
community model to, well, the community. So in that way Kepler
has a lot to explore either in greenfield development and in
integration with projects like Mylyn and BIRT. Buckminster isn't
so much about that.

I also think that Kepler needs to be given the space to engage
with the Eclipse ecosystem as a community in its own right. The
initial committers and contributors need to get into our wider
community and prove themselves as able developers and community
managers, learn The Eclipse Way, and bring their knowledge to
the table. I think this is vitally important - Buckminster is
mature in the sense that it has gone through releases and is
familiar with Eclipse processes. These guys need to learn that,
and they need to learn it themselves (with some nudging from
mentors of course ;) -- merging with Buckminster at the outset
will not help that, as I think that it will detract from the
pride and pressure that comes with being a project at the
outset.

So to summarize: the component model creation part of Kepler
complements the Buckminster component model, but there are other
parts of Kepler that need attention too. It's my opinion that
Kepler should start as a project, set out it's stall, and as
a priority action item, develop a plan for interaction and
integration with the Buckminster project.

 cheers
  --oh

-- 
Oisin Hurley at IONA
http://blogs.iona.com/ohurley/