Architecture Council/Meetings/May 14 2009
< Architecture Council | Meetings
|Meeting Title:||Architecture Council Monthly Meeting|
|Date & Time:|| Thursday May 14, 2009 at 1500 UTC / 0800 SFO / 1100 Ottawa / 1600 London / 1700 Berlin|
HTML | iCal
|Dial-in:|| (+1) 613.287.8000 (Ottawa and international) or|
866.362.7064 (toll-free North America)
- 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.
|DSDP:||Doug Gaff||Martin Oberhuber|
|STP:||Oisin Hurley|| |
- Signed-up: John Arthorne, Boris Bokowski, Cedric Brun, Dave Carver, Sven Efftinge, Brian Fitzpatrick, Doug Gaff, Neil Hauge, Oisin Hurley, Mik Kersten, Markus Knauer, Martin Oberhuber, Andrew Overholt, Mary Ruddy, Dave Williams, Mike Wilson, Darin Wright
- Regrets: Wayne Beaton, John Graham, Wenfeng Li, Ed Merks, Doug Schaefer, Tom Schindl, Karsten Schmidt, Gunnar Wagenknecht, Tom Watson
Agenda / Notes
- Feel free to edit, but not during the call!
Review of Last Meeting
- Architecture Council/Meetings/April 9 2009
- (old) Martin to follow up with the m2eclipse and IAM projects regarding duplication
- Talked at Eclipsecon.
- (old) Cedric, Tom talk to their PMCs about making AC representation official (can be 2 backup reps)
- Martin to add Eclipsecon meeting notes onto the wiki
- Martin to create Architecture Council/Bugzilla Best Practices
- Dave to add hyperlinks to that page
- Mik to send E-Mail with "how to use bug reporting wizard" to ac mailing list
- Linda to send E-Mail with screenshots of portal to define Wiki Navbar to the ac mailing list
- Still open items moved to #Action Items
- Good-bye to Bjorn - Props and THANKS for all his work!
- AC Chair for next year
- Follow-up on Architecture Council/Bugzilla Best Practices
- Platform-UI not used "assigned-to-inbox" in order to send a clear signal; keep inbox clean; ASSIGNED should mean "assigned to a real person".
- Dave C will update page with some actual queries
- Mik offers customizations in Mylyn (add buttons), file bug against Mylyn with CC to AC - configurable - Boris to CC on the bug once exists
- In Platform UI, committers own "subcomponents" identified by  in summary field
- Dave C already uses Mylyn to manage XSL Tools, there is not much to do! - will add instructions on the Wiki.
- Boris recently changed Wiki homepage, created new "Best Practices" category
- Encourage everyone to put that category tag on their own Wiki pages: Just look at any existing source from a page in that Category, will see the right tag at the end of the Wiki page
- Gunnar: bug 249745 Repo best practices blocking bug 257706 host a git repo
- Doug G: Around EclipseCon, created a whole series of bugs blocking the bug 257706 git one -- decouple the "best practices"
- More VCS meeting notes linked off the Architecture Council main page somewhere
- Martin thinks that bug 249745 could just be kept open as an open-ended discussion channel... McQ agrees
- Jeff, McQ: bug 261544 API Deprecation
- Architecture Council/Meetings/API Deprecation 20080119 follow-up
- There are 3 separate pieces to deprecation:
- 1. Want to flag particular public API as "should not use any more"
- 2. Describe alternative new way
- 3. Indicate somewhere that this is not just idle talk but will have consequences
- 1 and 2 come out of the current @deprecated tag... what's currently unclear is the consequences, "when will it be removed"
- What should the new tag look like?
- Darin's comment: there's two different kinds of users... "number" for tooling + more information for end users
- Martin: unique ID in order to keep the information open-ended and extendable?
- McQ: We want a tool that's sending warning / errors
- Yes, but end-users get more from open-ended tooling indexed by unique ID... so the machine-readable part is the more important one
- DaveC: Human readable part is important as well and close to the source (or it wouldn't be read). Perhaps have the human-readable part in a separate tag?
- McQ thought that there would be controversy around the suggestion that ALL Eclipse projects should have a 2-year time before removing deprecated stuff?
- DaveC: Depends on project maturity
- But it's part of what Eclipse is... and why there should be
- JohnA: What this Policy really means is: Deprecating + waiting 2 years is the ONLY way of breaking API
- Martin: Gee that opens my eyes!
- McQ: How are we negotiating with Consumers? - For the Release Train, we have measures: Cannot get stuff into the Release Train unless the Policy is followed.
- DaveC: This is controversial... and may hinder innovation
- McQ: Yes.. and this means we need to explore what it means to be on the Release Train
- Time Horizon: We should be able to make a statement how we are going to treat the next release train really soon!
- AI Everyone Follow up on the bug
- Dave C AC should look at other Agile Principles can be employed (in addition to the Bugzilla practices)
- Eclipse Platform Process may not work best for all processes
- Martin: Where are conflicts with the Eclipse Development Process?
- Dave: Newer, smaller projects would like to go at a different pace... Eclipse Process is not fast/agile enough to fit their needs
- Dave to file bug
- 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 ?
- (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