[wtp-pmc] Preliminary EMO Architecture Council Report

[David M Williams <david_williams@xxxxxxxxxx>]

Fellow PMC Members,

These are some quick notes of Council
meetings I attended last week ... just to keep WTP PMC up to date ... there
is a lot that is not well captured in brief notes, was not finalized, and
will be on-going efforts to update meeting minutes, documents, development
process, gain board review, etc. but thought I'd jot down what I could.

[And, thanks to Tim and Bjorn for quick
"sanity check" of initial draft of these notes.]

Much time spent on discussing what appropriate proposal-to-project path
was. In general, current approach of "accepting nearly all proposals"
is seen as being (nearly) over. Will (likely) add requirement that new
proposals must, at their own initiative, have a "sponsor" (Architecture
Group suggested two sponsors from Arch. Council members (which includes,
via proxy, all PMCs and strategic members), but final change to process
may be slightly "lighter"). This would help ensure new proposals
"land" in the right project. 

Also much discussion on whether or not "all new projects should be
incubated". This was to both be helpful to new projects, and to avoid
any new projects from going astray and not maintaining correct Eclipse
procedures or quality.  In general, that was considered good idea,
but details of what was expected of "parent project" and when
to exit incubation were not as clear and will (likely) be decided in follow-up
calls. (The main action here was to write down a few specific proposed
processes and vote or come to consensus on which written version was best).

The "plenary session" with architecture and requirements council
was informative. There was general feeling that specific "requirements"
from Eclipse members were not being tracked well (even though tracked at
"themes and priorities" level). SAP representative, Georg Lenz
had some interesting "editing requirements" he discussed ...
a few of which we begin to address in SSE (though, not necessarily yet
in final API level that he is asking for). These requirements might also
inform (long term) LDT work?  [Georg also talked to Tim Wagner about
possibility of SAP contributor to WTP, I think for J2EE project level work].

Mine and Tim's brief demo went well ... it convinced one Eclipse member
who was not familiar with WTP to install M4 on the spot!  :) 

There was general discussion of "project overlap" and general
agreement that no project should (initially) declare API that is not in
the scope of their charter or for which there is potential overlap with
other projects (as we are doing with "extensible navigator",
"tabbed property sheet", and "internet monitor" --
it was general considered ok that 'internal.provisional' be used for these
cases (but still should be spec'd as any other non-provisional API) ....
"internal.provisional" in these cases is declaring it may move
next release, or even if not moved, at least gives time for full planning
cycle to occur before being finalized. [There was still some dissent that
projects should never do any work that's not in their charter, but I think
with was based on misunderstanding how easily there can be grey areas].
Along these lines -- Harm did ask us to better coordinate our Cactus work
with Dominique Gulbaud in TPTP (in France).  In general it was deemed
desirable to do as much "peer-to-peer" coordination as possible
and not feel Architecture council needs to review or get involved in routine
matters. Unfortunately, not enough time to drill down much on widely overlapping
requirements, such as "multiple source language support". 

Other uses of "internal.provisional" were less clear. I got the
impression some believed there should be no such thing, but was hard to
pin down Eclipse members on reasons ... some simply "wanted API",
and they could not trade off, in such a short meeting, if better to defer
release until API, or have well spec'd provisional API. Some also believed
"provisional" would be used as "an easy out" and water-down
Eclipse API quality. There was a general desire to have "provisional
API" mean "well specified API that might change in future, which
would have implied support at least in point releases, migration documentation,
etc", which departs from our WTP intended use of 'provisional' as
meaning "internal, but might become API in future (given feedback,
demand, better specified, meets quality standards, etc)".  There
will be follow-up meetings and calls to discuss (but no immediate action
required on our part .... except I would recommend to look closer at  our
"provisional APIs" and better assess how many are more provisional
than API. 

There was too much discussion to get to consensus on detailed level of
exact naming, documentation, etc (some, such as WindRiver rep. (Michael
Scharff)), initially agreed that naming 'provisional', then later renaming,
would cause undesired churn, but with discussion from others he then agreed
it depended on the "degree of provisional" ... if really "experimental",
then a rename would be a good thing, but if "provisional-really-close-to-API"
then would be seen as unnecessary churn. I suspect we in WTP complicate
the issue by having several reasons or several categories for what we often
call the same thing ('provisional'). Guess we need more names!  :(
 <just kidding!> but probably do need clearer statements/definitions
of what means what.  There will be follow-up meetings and calls to
come up with acceptable WTP and Eclipse guidelines. 

In general, I think perception was that we in WTP have a good end-user
product [and, we didn't even get to details such as end-user documentation!],
but less clear on how Eclipse members could build 'value add' products
on it (currently, that is, with many provisional APIs, lots of changes
milestone-to-milestone, us using our own internal classes across components,
etc.).  

My personal view is that there is a
certain sense that defining "Eclipse Quality" (and defining what
it means to be "part of Eclipse") is a moving, increasingly high
target that everyone in Eclipse is struggling to clarify (the Councils
and Board, add-on-providers, as well as us Projects)  -- no one wants
a "no rules" approach as in some open source communities, nor
a "one product" approach either, but finding the right balance,
how to specify and gauge achievement and success is an ongoing effort (and
probably will be for some time, in my humble opinion). I suspect we in
WTP are viewed as a good proving ground due to our supreme development
and management skills :)

Lastly, Portland lived up to its reputation
.... it rained every day  :)

Feel free to ask if any specific questions. 

David 

P.S. If I may add two of Tim's
notes from EMO planning meeting.
·
        All projects
are required to submit quarterly update reports; we haven’t been doing
this. Bjorn is going to update the template and remind us.
·
        WTP is
part of the “super bundle” that the councils would like to see release
on a single day next summer. (That is, WTP 2.0 and Platform 3.2 are supposed
to GA on the same date, along with all of WTP’s prereq’s.)    [DW's
addition: while a ways off to effect planning, its my understanding this
isn't just WTP releasing faster, but may change prereq's "end-game"
to have a slightly more extended period of shutdown]