Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "Architecture Council/Meetings/July 9 2009"

(→‎Attendees)
Line 16: Line 16:
 
{|border=1 cellspacing=0 cellpadding=1
 
{|border=1 cellspacing=0 cellpadding=1
 
| '''BIRT:'''
 
| '''BIRT:'''
−
| Wenfeng Li
+
| <strike>Wenfeng Li</strike>
−
| Gary Xue
+
| <strike>Gary Xue</strike>
 
|-
 
|-
 
| '''DTP:'''
 
| '''DTP:'''
−
| Brian Fitzpatrick
+
| <strike>Brian Fitzpatrick</strike>
 
| Linda Chan
 
| Linda Chan
 
|-
 
|-
 
| '''DSDP:'''
 
| '''DSDP:'''
−
| Doug Gaff
+
| <strike>Doug Gaff</strike>
 
| Martin Oberhuber
 
| Martin Oberhuber
 
|-
 
|-
 
| '''Eclipse:'''
 
| '''Eclipse:'''
−
| Philippe Mulet
+
| <strike>Philippe Mulet</strike>
 
| Mike Wilson
 
| Mike Wilson
 
|-
 
|-
 
| '''Modeling:'''
 
| '''Modeling:'''
−
| Richard Gronback
+
| <strike>Richard Gronback</strike>
−
| Ed Merks<br/>Cédric Brun
+
| Ed Merks<br/><strike>Cédric Brun</strike>
 
|-
 
|-
 
| '''RT:'''
 
| '''RT:'''
−
| Jeff McAffer
+
| <strike>Jeff McAffer</strike>
−
| Jochen Krause<br/>Tom Watson
+
| <strike>Jochen Krause</strike><br/><strike>Tom Watson</strike>
 
|-
 
|-
 
| '''STP:'''
 
| '''STP:'''
−
| Oisin Hurley
+
| <strike>Oisin Hurley</strike>
−
| Antoine Toulme
+
| <strike>Antoine Toulme</strike>
 
|-
 
|-
 
| '''Technology:'''
 
| '''Technology:'''
−
| Gunnar Wagenknecht
+
| <strike>Gunnar Wagenknecht</strike>
−
| Wayne Beaton
+
| <strike>Wayne Beaton</strike>
 
|-
 
|-
 
| '''Tools:'''
 
| '''Tools:'''
Line 53: Line 53:
 
| '''TPTP:'''
 
| '''TPTP:'''
 
| Eugene Chan
 
| Eugene Chan
−
| Oliver Cole<br/>Joanna Kubasta
+
| <strike>Oliver Cole</strike><br/><strike>Joanna Kubasta</strike>
 
|-
 
|-
 
| '''WTP:'''
 
| '''WTP:'''
−
| Tim deBoer
+
| <strike>Tim deBoer</strike>
 
| Dave Carver
 
| Dave Carver
 
|}
 
|}
  
−
* '''Signed-up:'''  
+
* '''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:''' Mik Kersten (traveling), David Williams (conflict)
+
* '''Regrets:''' Doug Gaff (conflict), Oisin Hurley, Mik Kersten (traveling), Andrew Overholt (travelling), Mary Ruddy (travelling), Mark Vandenbrink, David Williams (conflict)
−
* '''No-Show:'''  
+
* '''No-Show:'''
  
 
<!--
 
<!--
Line 79: Line 79:
 
=== New Topics ===
 
=== New Topics ===
  
 +
==== Release Naming ====
 
* '''[http://dev.eclipse.org/mhonarc/lists/eclipse.org-architecture-council/msg00961.html Release Naming]'''
 
* '''[http://dev.eclipse.org/mhonarc/lists/eclipse.org-architecture-council/msg00961.html 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 ====
 +
 
* '''[[Architecture Council/Open Issues|AC Bugzilla]]''' backlog
 
* '''[[Architecture Council/Open Issues|AC Bugzilla]]''' backlog
−
* '''Follow-up on [[Architecture Council/Bugzilla Best Practices]] - how to move on?'''
+
** 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)
 
* '''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 ===
 
=== Old items ===

Revision as of 12:10, 9 July 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

Retrieved from "https://wiki.eclipse.org/index.php?title=Architecture_Council/Meetings/July_9_2009&oldid=162965"

Back to the top