Bjorn,
Comments below.
Bjorn Freeman-Benson wrote:
Ed
Merks wrote:
shouldn't we just fix that problem rather
than create some new group, which is likely to suffer the same problems
as the current group?"
An excellent point. My claim is that the new group will be composed of
people who are interested in, and have the time to, do the job of
one-to-one project mentoring (answering questions, discussing problems,
explaining how they solved the same problem, etc) rather than a group
of people with a vaguely defined architecture mission.
I agree that it might well be very useful to have folks to act as
specialized mentors. The Eclipse processes are quite complex and are
changing, i.e., improving, all the time. So much of the mentoring will
be about helping understand those processes. I all too often need such
help myself...
It is entirely possible that the new mission will also be ineffective
or that the new, larger, more diverse, group of people will also be
ineffective. I prefer to remain optimistic that the mentoring role will
advance Eclipse's goals better than the architecture role has.
Yes, I'm generally an optimist so as long as we learn from past
mistakes, we won't be doomed to repeat them.
And not to point any fingers, but I suspect
that to a large extent the tools and the technology PMCs can't cope
with the volume of traffic within those domains, so perhaps the focus
should be more on such specific problems.
Another good point. However there are many new projects that are
starting outside the Tools and Technology projects, all of whom could
use mentoring. In fact, one might even argue that starting projects in
other top-level projects is detrimental to the long-term success of
Eclipse because all of the mentoring of those new projects comes from
the "group-think" of that one PMC - wouldn't it better to have at least
two different views of Eclipse, perhaps three different views of
Eclipse, to guide the 'open source social development' of a new
project?
Yes, only multiple perspectives can give you an overall sense of the
diversity of perspectives.
Also, ask yourself this question: how many of
the people important to driving Eclipse's architecture are typically
present at the architecture council to help make it effective and to
make it fully an architecture council, i.e., with a focus on the design
part of your architect definition, rather than mostly with a focus on
the supervisory part?
A third good point. Are the architecture council members really the
right people to attend from each project? I cannot answer that - the
projects will have to answer for themselves.
Certainly the folks I've met so far are highly intelligent and very (I
might even say, amazingly) cooperative, which is why I want to be sure
to deflect criticisms of the group. That being said, at the last
meeting, there was effectively no deep technical representation for the
platform itself, so that really doesn't help so much...
I've only been to two meetings (the first
being more effective than the second, in my opinion),
Ed, could you explain how the June 28th meeting was effective?
http://www.eclipse.org/org/councils/20060628ACMinutes.php
I had a feeling you'd bring up the fact that we've not yet begun our
5.0 porting wiki. But you did it so gently. ;-) This is kind of my
point about having the best of intentions not necessarily producing
results. To air my dirty linen in public, my tiny little development
team is currently still tied up with the second edition of the EMF book
work---you know how it goes, whenever you ask, it will be done in just
three short weeks---so I've been prototyping the 5.0 work in isolation
(and publicizing the results via attachments to 79768).
But I have not forgotten my promise...
As I recall, we talked about the JVM 1.4/1.5 issue and concluded that
everyone should just do what they should already be doing: making sure
their run-time dependency is explicit. There was also an action item
for various members to write up a wiki page and update their plans:
neither of which happened (or at least I don't recall them being
announced on the mailing list, a wiki search reveals nothing
http://wiki.eclipse.org/index.php/Special:Search?search=JVM&go=Go
and a random sampling of project plans has some JVM information:
NO> http://www.eclipse.org/webtools/ > "Release Plan 2.0"
NO> http://www.eclipse.org/datatools/ > "Development" > "DTP
1.0 Project Plan"
YES>
http://www.eclipse.org/birt/phoenix/project/project_plan_R2_2_0.php
NO> http://wiki.eclipse.org/index.php/GMF_Project_Plan
We also talked about a common build infrastructure. There was a lack of
follow through from the AC members on their lists of problems and
prides. In spite of that, the Foundation held a releng workshop in the
fall and a common build structure is slowly evolving from that.
I thought that was itself an excellent result and we are definitely
willing to contribute our precious resource toward this effort.
Maybe I'm being too demanding, but I don't see a lack of follow through
by the AC members as a sign of effectiveness.
I guess I would say that the meeting itself seemed effective to me (it
was my first one) because we really talked in depth about some of the
architectural issues that I personally was most concerned about. I
think that helped create a better understanding of the issues we all
will face. But perhaps I set my effectiveness bar too low. ;-) I
certainly wouldn't suggest you should be less demanding since, to a
very great extent, it's your personal drive that keeps things from
degrading to the point of totally unacceptable...
- Bjorn
|