Skip to main content
Jump to: navigation, search

Architecture Council/Meetings/September 9 2010

Meeting Title: Architecture Council Monthly Meeting
Date & Time: Thursday September 9, 2010 at 1500 UTC / 0800 SFO / 1100 Ottawa / 1600 London / 1700 Berlin attention DST change
Html.gifHTML | Ical.gifiCal
Dial-in: NEW Canada 1-877-727-8553 toll free / 1-416-840-9801 caller paid
NEW U.S. 1-866-394-4146 toll free / 1-480-629-1624 caller paid
NEW passcode 428029063


All AC Members are invited.

  • PMC Reps please confirm attendance or list your delegate below. Every PMC is required to name a primary and backup delegate, and to ensure that one delegate attends the meeting.
BIRT: Wenfeng Li Gary Xue
DTP: Brian Payton Linda Chan
DSDP: Martin Oberhuber TBD (DSDP-PMC)
Eclipse: Mike Wilson John Arthorne
Boris Bokowski
Modeling: Ed Merks Cédric Brun
Sven Efftinge
RT: Jeff McAffer Tom Watson
STP: Antoine Toulme Oisin Hurley
Technology: Gunnar Wagenknecht Wayne Beaton
Tools: Doug Schaefer
TPTP: Jonathan West
WTP: Tim deBoer Dave Carver
Neil Hauge
  • Regrets: Oliver Cole (standing conflict), Wenfeng Li (standing conflict), Mik Kersten

Agenda / Notes

  • Feel free to edit, but not during the call!

Review of Last Meeting

  • Architecture Council/Meetings/August 12 2010
  • (old) Tim write up an initial wiki page with information for people to standardize on the tracing API
  • Martin revise the AC Wiki to make it easier to find the New Member Process. More links on homepage. More usage of categories.
  • Martin bug 315210 Make the AC mailing list open / moderated
  • Antoine / Dave C bug 316642 Requirements Wiki for build systems
  • Still open items moved to #Action Items

New Topics

  • Findbugs day / Fixit challenge - Dave C
    • Ed likes the idea... but how configurable is Findbugs to avoid false positives just due to style?
    • Wayne: Producers of FindBugs have been using Eclipse as a test project
    • Resolution follow up in a bug, key will be getting a good config to only show bugs but no stlye issues

  • bug 324125 architecture diagrams - 2006 version - relationship to e4 ?
    • Ed - nice to have, but who's going to produce them?
    • Wayne - core question is, are these valuable? If yes, what is the smallest amount of work possible creating something useful?
    • Jeff - Platform: Technical details like OSGi bundles etc are well covered... but what is the relationship between projects on top of the Platform ? What can be used together?
      • From a Consumer point of view, always hard to find out how eg the Modeling projects work together
      • Eg relationship RAP - EMF - Eclipselink ... how to put something together with Persistence + Web
    • Martin - looks like interaction between projects would just be documenting what evolved ad-hoc
    • Jeff - having no deliberate architecture sounds like failure of the AC in the past
    • Michael - opposite is also true, avoiding dependencies
    • How to sell this ... who is the target audience? Value to committers / adopters seems small
    • Wayne: A PDE component can draw a dependency graph .. but what is the value?
      • Jeff: RCP came about by having the community ask for removing dependencies
  • Diagrams are a vehicle, not a means to an end.
    • Looking at current architecture, it appears too "stacked"
  • Wayne has a newer diagram for the Platform in a presentation somewhere ... rectifying the diagrams is not too much work
    • Martin: Rectifying current diagrams + collecting statements might be helpful .. on a Wiki page
    • To keep that from getting stale, would need to make it a recurring agenda item
  • Ed: Dependency issues are likely best driven by Community ("what they want").
    • Some dependencies are really annoying, but well-known and unlikely to change (eg EMF -> Resources, making it unusable in RCP)
  • Truth is, we have ad-hoc dependencies, but it's unlikely to change
    • Cleanup only happens with sufficient pressure / value to consumers.
    • If we cannot effect change, we can just document things
  • AI Wayne create an "Eclipse Platform Architecture" Wiki page with a diagram he already has as slideware. Continue discussion from there

  • Helios API Usage report
    • How much of an issue is it (related to e4)?
    • Handling of provisional API ? E.g. o.e.debug.internal.ui.viewers.model.provisional.IChildrenCountUpdate
    • promote usage of x-friends / startup extension (as per zx mail)
    • Darin thinks that client of API should request producer of API to be a friend (and allow producer to say yes or no)
    • Jeff: non-API usage is really a bug... but allow consumers to request being a friend
      • Value of promoting friend-usage is diagram cleanup / reducing noise
      • In order to promote the effort, could create some statistics of showing the biggest offenders
    • Jeff would like no internal references in the release train ... exemption when a request exists asking for new API
      • If we really think there should be no non-API use, we should walk the walk and enforce it
      • We can promote the idea, but control resides with the PC
    • Current report is user-based ... Darin wants a consumer-based report in Indigo bug 322571 on the PDE/Plan/3.7

  • Build systems requirements - Antoine, Dave C
  • News from the Board, EMO and Councils

e4 - current state of affairs

  • PC / Release Train Relationship to Eclipse 4.0

Items for next meeting

Regular briefing on the status of e4.

Old Topics

We need to reduce our bug backlog, by actually coming to a common resolution on some. Here are the most recent ones:

  • DaveC would like to discuss New Committer Guidelines; Scrum / Agile techniques
  • bug 285074 - Dave Carver - Hudsonbuilder and write access to the cvs / svn repo
  • bug 288393 - Denis - Bugzilla Best Practices

Action Items

  • (old) Martin to follow up on Architecture Diagrams idea
  • (old) Michael to flesh out the Patterns idea and remind the EAC -- started Architecture Council/Top Ten Recommendations#Design Patterns, backed by EclipseCon tutorial proposals
    • While these show how well-known GoF patterns are applied in Eclipse, Michael's idea was more to find and describe new patterns which are specific to Eclipse
  • (old) Michael to draft an E-Mail about the "plugin granularity" idea, searching for people to lead the effort
  • (old) Tools and Tech PMC's to encourage incubating grandfathered projects find a mentor; mentorless projects due to AC members quitting or falling dormant
  • (old) Martin to add Eclipsecon meeting notes onto the wiki
  • (old) Mik to create initial "architectural walkthrough" material for Mylyn -- 1 wiki page not too large, send link to the mailing list
  • (old) Dave C work with Wayne on a "handbook" for project criteria for becoming a committer (referencing committer guidelines)
  • (old) Dave C come up with a document how to save build resources
  • (old) Dave C to try bugzilla UNCONFIRMED state
  • (old) Wayne to ask Sonatype about Nexus test installation
  • (old) Wayne to try doing a 3.6m2 API Report on Helios m2
  • (old) Martin to file bug for asking Mik hyperlink Wikitext / crowdsourcing Docs handbook on the Architecture Council/Top Ten Project Development Practices page
  • (old) Tom S Athena Common Builder Cookbook
  • (old) Tim write up an initial wiki page with information for people to standardize on the tracing API
  • Martin revise the AC Wiki to make it easier to find the New Member Process. More links on homepage. More usage of categories.
  • Martin bug 315210 Make the AC mailing list open / moderated
  • Antoine / Dave C bug 316642 Requirements Wiki for build systems

Next Meeting

Back to the top