Jump to: navigation, search

Architecture Council/Meetings/July 9 2009

Meeting Title: Architecture Council Monthly Meeting
Date & Time: Thursday July 9, 2009 at 1500 UTC / 0800 SFO / 1100 Ottawa / 1600 London / 1700 Berlin
Html.gifHTML | Ical.gifiCal
Dial-in: (+1) 613.287.8000 (Ottawa and international) or
866.362.7064 (toll-free North America)
passcode 464440#

Attendees

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 Fitzpatrick Linda Chan
DSDP: Doug Gaff Martin Oberhuber
Eclipse: Philippe Mulet Mike Wilson
Modeling: Richard Gronback Ed Merks
Cédric Brun
RT: Jeff McAffer Jochen Krause
Tom Watson
STP: Oisin Hurley Antoine Toulme
Technology: Gunnar Wagenknecht Wayne Beaton
Tools: Doug Schaefer
TPTP: Eugene Chan Oliver Cole
Joanna Kubasta
WTP: Tim deBoer Dave Carver
  • Signed-up: Chris Aniszczyk, Dave Carver, Eugene Chan, Linda Chan, Adrian Colyer, Sven Efftinge, Neil Hauge, Bernd Kolb, Ed Merks, Martin Oberhuber, Doug Schaefer, Mike Wilson
  • Regrets: Doug Gaff (conflict), Oisin Hurley, Mik Kersten (traveling), Andrew Overholt (travelling), Mary Ruddy (travelling), Mark Vandenbrink, David Williams (conflict)
  • No-Show:


Agenda / Notes

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

Review of Last Meeting

New Topics

Release Naming

  • Release Naming
  • Martin: This is just another incarnation of the "cross-project consistency vs. project individualism"
  • Dave C: Alphabetical naming is more a marketing aspect... not in bundles or features, just on website etc
  • Ed: Where do the names show up (only on web pages etc) e.g. "The Galileo Version of EMF" ... some bundles could even remain unchanged between releases
    • Putting release name into the qualifier is problematic
  • What are the problems we are trying to solve?
    • Chris: Ensure that version numbers are always technical numbers (bundle, feature level)
      • Ed: That's a lot of work for EMF
      • Chris: It's easier than most people think
      • Agree: Promote using API tooling on bundle and feature level
      • AI Chris put together a quick howto, to promote things
      • Martin: most important thing to understand about technical versions is that it's always only about the deltas
  • Sven: Add a common place for putting in the marketing version number (release level)
    • People get stuff from multiple places and want to know whether they are on the latest
    • Users only care about marketing number (in the about dialog) and never care about technical numbers
      • Martin: Make technical numbers less prominent in the about dialog; use the "Build ID" for the marketing number - advantage of build ID (in about.ini) is that it can be changed by a simple re-build without changing any code, and it is prominent in the about dialog
      • DougS: This is a good idea
      • Never mix marketing version(s) with technical version(s)
    • Sven: What about a new Manifest Entry (e.g. "Code Name") in the Bundles
      • We have to educate people how to put the marketing version number in, and Manifest Editor is more logical than the build ID in about.ini
      • Ed: changing code just for changing the version is painful
    • Would we allow bumping the major at the release level even without API breakage?
    • E.g. AspectJ: Adding new language features is a major new functionality even if API is not changed
    • Agree that marketing number (release version) is at the project's discretion
  • Chris: How to talk to people about releases
    • Talk about train names: e.g. "Release n.n for Eclipse Ganymede"
    • What to do about multiple releases in one train cycle?
    • What to do with multiple Platform Streams in 1 year? -- McQ: Platform will make a decision which Stream (3.6 or 4.0 will show up in the train) -- so the train is an interesting distinguisher! - don't solve tomorrow's problems today
    • Could be multiple train names e.g. "AJDT version n.n for Eclipse Ganymede and Helios"
      • Most people know the platform version numbers better than the train code names
    • McQ: Picking up e4 or not will likely be a very organic process...
  • AI Martin create bugzilla bug for continuing the discussion

Maven

  • Ed: Maven stuff for EMF, Maven Repositories for the Platform etc?
    • Bernd: Big discussion at SAP...
    • Should we have an official Maven Repo at Eclipse?
    • Just a structured file system (at S3 for instance)
    • Just talk to the Maven projects - AI Martin create a bug for the discussion

Others

  • AC Bugzilla backlog
    • Martin will look through the backlog and comment... request everyone else to look through the backlog too
  • Dave C AC should look at other Agile Principles can be employed (in addition to the Bugzilla practices)
    • Defer to a future call, need Wayne on the call
  • Follow-up on Architecture Council/Bugzilla Best Practices - how to move on?

Old items

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

Next Meeting