January 24, 2007, Burlingame, California
|Anurag Gupta, Intel, TPTP|
|Bjorn Freeman-Benson, Eclipse|
|John Graham, Sybase, DTP|
|Rich Gronback, Borland|
|Kevin Haaland, IBM, Platform|
|Yossi Leon, Zend|
|Wenfeng Li, Actuate, BIRT|
|Ed Merks, IBM, Modeling|
|Michael Scharf, DSDP, Wind River|
|Jess ?, BEA|
|David Williams, IBM|
|Oisin Hurley, IONA, STP|
|Scott Lewis, ECF|
|Brian Carroll, ALF, Serena|
|Patt Huff, IBM|
|Valentina Popescu, TPTP, Intel|
|Don Ebright, STP, Compuware|
Major point of discussion was that the cross-project-issues-dev mailing list is actually working so how is the Ask the Architecture Council different? How will a developer know to Ask the Architecture Council instead of using the cross-project list? ... After some discussion, it was concluded this is a collection development issue: find the relevant architecture discussions and answers across mailing lists, wiki, blogs, design docs, etc. and then collecting them (aggregating them) onto a single wiki page. The council would also like to see a "Digg" like system for Eclipse items (web pages, etc).
ACTION: [Oisin H] Create the initial wiki page and nag/motivate people to contribute to it.
Major point of discussion is that unless this is automatically maintained, it will go out of date so rapidly as to be useless. It has to be automatic and of value to the producer in order to be self-sustaining. Another point of discussion was that if consumer project A wants to reuse a component of producer project B but in a different packaging than producer currently supports, then the consumer is asking for the producer project to do work for consumer's (but not the producer's) benefit.
The council held a vote and a overwhelming major felt that the catalog was
not a good idea.
A second vote on whether it is valuable to have a standard way to publish component information to the website resulted in Oisin volunteering to take the discussion to the mailing list.
ACTION: [Oisin H] Continue this discussion on the mailing list.
Ed Merks wrote up a wiki page with a few notes, he is also putting together an EclipseCon presentation. The Council agreed that this is one of the roles on the Architecture Council: to take our aggregated knowledge of this kind of issue and mentor the project teams about their options and decision making. We are not telling them what to do - merely explaining the options.
Discussion of the process for gathering these top ten architectural problems. David and Yossi have each added an item, but nobody else has. Overall, we want to avoid this being a "complain to the Platform team" forum. David brought up the point (and it was agreed) that in any big project it is important for the senior people to state what the big problems are so that developers can keep them in mind as build systems. The idea is that this is about focus rather than being bugzilla-like complaints because in the end only contributing resources (actually, really only contributing people) gets things changed in an open source project.
ACTION: [Michael S] Add his two items to the wiki page
ACTION: [Bjorn FB] Standing agenda item for calls to discuss the top architectural problems
The basic question is "is it worth meeting face to face once a quarter"? (There was a question about whether the Bylaws require these meetings, but upon re-checking the Bylaws, we could not find a requirement.) Brian explained that the OMG's architecture council is very effective at guiding new proposed projects to create a coherent architecture - this basically matches the architecture council's new role as mentors.
There was unanimous agreement that having the Council meet for trivial tasks (block structure diagrams) was a complete waste of time and nobody does the work anyway - there's just no benefit in it. There was also consensus that we should continue to have monthly phone calls and a once-a-year face-to-face meeting at EclipseCon.
ACTION: [Bjorn FB] Cancel the F2F at EclipseCon
ACTION: [Bjorn FB] Standing agenda item: review recent project proposals
Be it resolved, then, that the Architecture Council has evolved into a council of senior developers who help guide (mentor) the architectural consistency of Eclipse, consult by phone with each other and meet face-to-face only when specific technical issues arise. These face-to-face meetings will be workshop style and may not involve any Architecture Council members because other developers from the projects may be more useful (e.g., the build workshop).
Notes taken and posted by Bjorn Freeman-Benson
Back to the top