Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Architecture Council/Meetings/June 11 2009
| Meeting Title: | Architecture Council Monthly Meeting |
| Date & Time: | Thursday June 11, 2009 at 1515 UTC / 0815 SFO / 1115 Ottawa / 1615 London / 1715 Berlin HTML |  iCal
|
| Dial-in: | (+1) 613.287.8000 (Ottawa and international) or 866.362.7064 (toll-free North America) passcode 464440# |
Contents
Attendees
- Use the Doodle Attendance Tracking Poll to confirm attendance or send regrets for this meeting. See this message for how to use it. 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: | |
Gary Xue |
| DTP: | |
Linda Chan |
| DSDP: | Doug Gaff (lurking) | Martin Oberhuber |
| Eclipse: | |
Mike Wilson |
| Modeling: | |
Cédric Brun |
| RT: | |
Tom Watson |
| STP: | |
|
| Technology: | |
Wayne Beaton |
| Tools: | Doug Schaefer | |
| TPTP: | Eugene Chan | |
| WTP: | Tim deBoer | Dave Carver |
- Signed-up: John Arthorne, Boris Bokowski, Mik Kersten, David Williams, Darin Wright
- Regrets: Chris Aniszczyk, Sven Efftinge, Oisin Hurley, Markus Knauer, Bernd Kolb, Andrew Overholt
- No-Show:
Agenda / Notes
- Feel free to edit, but not during the call!
Review of Last Meeting
- Architecture Council/Meetings/May 14 2009
-
Dave to add hyperlinks to Architecture Council/Bugzilla Best Practices - Mik to send E-Mail with "how to use bug reporting wizard" to ac mailing list
- Still open items moved to #Action Items
New Topics
- AC Chair for next year
- Follow-up on Architecture Council/Bugzilla Best Practices - how to move on?
- Dave Carver willing to deploy for XSLT; Wayne: Examples Project
- Wayne proposes communicating to the Community that this is happening
- Use a "committers should know" item; small note on committers; blog about the item
- Wayne thinks it's good enough. Dave Carver to blog it. Wayne note to committers (after Dave's Blog)
- McQ: bug 261544 API Deprecation, bug 279539 2 year lead time for Galileo
- Architecture Council/Meetings/API Deprecation 20080119 follow-up
- What problem does the 2-year-lead-time request solve?
- Large products built by IBM literally take 2 years to consume Eclipse
- Between projects at Eclipse.org, the problem is seen as well
- Feel more responsibility that people can respond to an upcoming change
- Much of this discussion driven by e4 work
- Consumers need to decide between hopping onto the major or staying with the older version.
- Martin: Platform vs CDT are different in terms of "how well crafted" the API is
- Need to have a good model of how the Community is affected by any change... CDT major revs were possible because they were in areas not much consumed by the Community.
- Mik: Projects to opt-in into the Platform model? -- Explicitly declare what policies a project is using, then consumers can decide whether they want to use a certain project or not. Other project may follow the WTP model for instance
- Boris: In order to be a mature Eclipse.org project, they must state what their API policy is. AC to recommend projects not invent too many different API policies.
- McQ: What's important about the release train - working together. Projects in the release train who are not leaves must feel the responsibility!
- CDT case: some projects may have to start declaring what their "real API" is
- Platform people found out that any change, even the smallest, has potential to break consumers... there must be intention to help people consume changes.
- Martin: Much discussion at the moment is about fear of change, stability etc. Turning the question around, what can we do to enable projects be more agile, set up communication channels that help people adopt changes
- JohnA: Projects can decide themselves
- Wayne: Deprecation Policy adds value to projects... market this as something that is good for projects in their own interest
- DougS: The AC cannot force guidelines, but showcase a golden trail
- Wayne: A tool like "who's using what" would be extremely valuable ... tell Eclipse Platform what APIs / methods are being used -- Wayne interested in exploring that (with Darin Wright) ... board members could ask this from the foundation
- Martin: Looks like Platform project needs to step up doing it...
- Dave Carver: Create a Wiki page drafting some possible Deprecation policies as blueprints to adopt
- Doug S: CDT is not at a different level, it's the mindset of the
- Martin: Make it a must-do for next year's release train to have "some" Deprecation Policy.
- Dave Williams: When we start actually removing things, we need to bump the major version. This will have a ripple effect due to the version ranges in require-bundle statements ... clients must react even if they do not use the bundle in question! With a 2-year lead time, consumers could extend their version range (up the tolerance in advance of the change). In order to increase tolerance in advance, consumers will need to know all the upcoming changes. We will need good tooling to support this...
- Martin - import-package rather than require-bundle might be another work around the ripple effect of removed API
- Tom - doing that would require us to come up now with versioning rules for packages etc.
- McQ - Platform team will create the policy anyways. Others to decide whether to follow or not.
- Martin would encourage projects come to the AC when they want to define a policy -- something like a peer review
- As multiple policies are created, have the AC host / review them.
- Dave C AC should look at other Agile Principles can be employed (in addition to the Bugzilla practices)
Old items
- See also Architecture Council/Open Issues for overflow items that were not discussed
- PMC Representation for Tools, WTP?
- Mike on the AC?
- News from the EMO and Councils ?
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) Mik to create initial "architectural walkthrough" material for Mylyn -- 1 wiki page not too large, send link to the mailing list
- (old) Tools and Tech PMC's to encourage incubating grandfathered projects find a mentor
- (old) Cedric, Tom talk to their PMCs about making AC representation official (can be 2 backup reps)
- (old) Martin to add Eclipsecon meeting notes onto the wiki
- Dave Carver to blog about bugzilla best practices
- Wayne to E-mail e.o-committers after that