| RE: [technology-pmc] Nexus project |
|
I agree. But I claim that neither Nexus nor
the I sense that I am not communicating effectively
on this. Let me try to explain. I am not trying to address the inherent
overhead in doing software development in team environment or even for that
matter overhead that’s unique to Eclipse (such as IP process). My primary
concern is with startup overhead. Remember that my core goal with all of this is
to make it easier for projects to collaborate on shared code. As such, I am
comparing the cost for a committer on an existing project to add a new plugin
to that project vs. creating a new Eclipse project to hold that plugin (because
it’s functionality that would be useful to others). In both of those
cases, the running overhead is the same. It’s the startup overhead that
discourages this kind of code sharing from taking place. I disagree. Larger projects (such as E4)
clearly have a much larger startup overhead than tiny projects. Could you elaborate? Why would a project
such as E4 have much larger startup overhead than a tiny project? As far as I
can tell, all of the startup tasks are largely the same regardless of project
size. A build system that builds two dozen plugins is not all that different
from one that builds two plugins. There might be marginally more overhead for a
large project, but it certainly doesn’t scale with project size. I think that it would be mistake to say
"if nobody in the larger Architecture Council wants to be a You know, I never understood the desire
for having mentors in the first place. Perhaps back when you could create a
top-level project from scratch it made a certain amount of sense. At this
point, I would argue that it is the job of the PMC of the project that accepts
a project proposal to mentor the project. This is especially true for the
Technology Project which has incubation as the primary goal. Regarding constraining projects, I cannot
even begin to comprehend why this would be a benefit to the community. The last
thing we want to do is to turn Eclipse into a private club where only people
who think in the same way are admitted. Just because no one on the Architecture
Council is interested in a particular project proposal (or has any time left
for mentoring) does not imply that the project proposal is not viable. As long
as we are good about shutting down failed projects, I do not believe we should
be putting in place artificial barriers to admission. My claim is that project success *includes*
finding a location for the project. Thus a project that cannot find a home is
not successful. I realize that's sort of a circular argument, but my point is
that Eclipse is more than just a CVS repository: one key goal for Eclipse is
that there are communities around each project. If a project cannot find a
community then it should go somewhere else. I agree that every successful project
requires an active community, but community and finding an appropriate location
is not the same thing. Let’s take a real example to ground this
discussion. As I mentioned in one of my other e-mails, there is talks in
progress for WTP and DTP to collaborate on two separate pieces of shared
infrastructure. These projects can incubate at the Technology Project, but then
what? These projects would be consumed by two large projects at Eclipse and
backed by very large communities, yet it is not obvious where these projects
can live after graduation. |