Jump to: navigation, search

Difference between revisions of "Architecture Council/Meetings/September 12 2013"

(New page: {| cellspacing="0" cellpadding="4" border="1" |- | Meeting Title: | '''Architecture Council Monthly Meeting''' |- | Date & Time: | Thursday August 8, 2013 at [http://www.timeandd...)
 
 
(4 intermediate revisions by 2 users not shown)
Line 29: Line 29:
 
|-
 
|-
 
| '''BIRT:'''  
 
| '''BIRT:'''  
| Wenfeng Li
+
| <strike>Wenfeng Li</strike>
| Wenbin He
+
| <strike>Wenbin He</strike>
 
|-
 
|-
 
| '''DTP:'''  
 
| '''DTP:'''  
Line 37: Line 37:
 
|-
 
|-
 
| '''Eclipse:'''  
 
| '''Eclipse:'''  
| Mike Wilson
+
| <strike>Mike Wilson</strike>
| John Arthorne<br>Boris Bokowski
+
| John Arthorne<br><strike>Boris Bokowski</strike>
 
|-
 
|-
 
| '''Modeling:'''  
 
| '''Modeling:'''  
| Ed Merks
+
| <strike>Ed Merks</strike>
| Cédric Brun<br>Sven Efftinge<br>Eike Stepper
+
| <strike>Cédric Brun</strike><br><strike>Sven Efftinge</strike><br>Eike Stepper
 
|-
 
|-
 
| '''Mylyn:'''  
 
| '''Mylyn:'''  
 
| Steffen Pingel
 
| Steffen Pingel
| Mik Kersten
+
| <strike>Mik Kersten</strike>
 
|-
 
|-
 
| '''RT:'''  
 
| '''RT:'''  
| Christian Campo
+
| <strike>Christian Campo</strike>
| Tom Watson<br>Doug Clarke<br>Ian Bull
+
| <strike>Tom Watson</strike><br><strike>Doug Clarke</strike><br>Ian Bull
 
|-
 
|-
 
| '''SOA:'''  
 
| '''SOA:'''  
| Adrian Mos
+
| <strike>Adrian Mos</strike>
| Marc Dutoo<br>Sebastien Gandon
+
| <strike>Marc Dutoo</strike>
 
|-
 
|-
 
| '''Technology:'''  
 
| '''Technology:'''  
| Gunnar Wagenknecht
+
| <strike>Gunnar Wagenknecht</strike>
 
| Wayne Beaton
 
| Wayne Beaton
 
|-
 
|-
 
| '''Tools:'''  
 
| '''Tools:'''  
| Doug Schaefer  
+
| <strike>Doug Schaefer</strike>
 
| <br>
 
| <br>
 
|-
 
|-
 
| '''WTP:'''  
 
| '''WTP:'''  
 
| Chuck Bridgham
 
| Chuck Bridgham
| Dave Carver<br>Neil Hauge
+
| <strike>Dave Carver</strike><br>Neil Hauge
 
|}
 
|}
  
 
===All Attendees===
 
===All Attendees===
  
* '''Signed-Up:''' Wayne Beaton, Ian Bull, Neil Hauge, Achim Loerke, Ed Merks, Martin O, Andrew Overholt, Brian Payton, Eike Stepper, Krum Tsvetkov, David Williams
+
* '''Signed-Up:''' John Arthorne, Wayne Beaton, Chuck Bridgham, Ian Bull, Linda Chan, Neil Hauge, Jonas Helming, Maximilian Kögel, Martin O, Brian Payton, Steffen Pingel, Michael Scharf, Eike Stepper, Krum Tsvetkov
* '''Regrets:''' John Arthorne (vacation), Benjamin Cabé, Christian Campo, Markus Knauer, Adrian Mos, Doug Schaefer, Gunnar Wagenknecht
+
* '''Regrets:''' Christian Campo, Markus Knauer, Achim Loerke, Doug Schaefer, Tom Watson
* '''No-Show:''' Chris Aniszczyk, Boris Bokowski, Nick Boldt, Chuck Bridgham, Cédric Brun, Dave Carver, Linda Chan, Doug Clarke, Sebastien Gandon, Kenn Hussey, Mik Kersten, Mike Milinkovich, Kim Moir, Steffen Pingel, Mary Ruddy, Michael Scharf, Tom Schindl, Tom Watson, Mike Wilson
+
* '''No-Show:''' Chris Aniszczyk, Boris Bokowski, Nick Boldt, Cédric Brun, Benjamin Cabé, Dave Carver, Doug Clarke, Kenn Hussey, Mik Kersten, Ed Merks, Mike Milinkovich, Kim Moir, Adrian Mos, Andrew Overholt, Mary Ruddy, Tom Schindl, Gunnar Wagenknecht, David Williams, Mike Wilson
  
 
== Agenda / Notes  ==
 
== Agenda / Notes  ==
 
* '''Feel free to edit, but <font color="red">not during the call!</font>'''
 
  
 
=== Review of Last Meeting  ===
 
=== Review of Last Meeting  ===
Line 85: Line 83:
  
 
=== New Topics ===
 
=== New Topics ===
 +
 +
* Welcome '''Maximilian Kögel''' Modeling, EMF committer, EMF Store Lead, EMF Client Platform Lead,
 +
* Welcome '''Jonas Helming''': Modeling, e4 committer,
 +
 +
==== Dev Process Update ====
 +
* John: '''Dev Process Update'''
 +
** Wayne: Bugs are all there for review, please weigh in on the bugs
 +
** [https://bugs.eclipse.org/bugs/buglist.cgi?list_id=6515986&short_desc=%5BEDP%5D&query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&short_desc_type=allwordssubstr EDP Bugzilla Records]
 +
** John: Wanted to simplify review docs etc but these are not in the Dev Process itself
 +
** Wayne: The implementation is far more flexible than the process ... can respond to specific feedback
 +
*** Example: Release Review Requirements had listed 12-15 items, but these were meant only as guideline
 +
*** Changes are OK as long as in the spirit - been trying to soften things over time
 +
** Want to make ''New & Noteworthy'' more useful and thus more prominent
 +
* Wayne wants a final draft for review by end Sept. - won't get to the board before 2014
 +
 +
==== Minimum BREE ====
 +
* Neil: '''BREE best practices regarding bundle dependencies'''
 +
** If bundle X BREE is 1.6 and bundle Y depends on bundle X, can bundle Y BREE be 1.4? In theory yes (and in practice sometimes this flexibility would be desirable), but it would also seem that this would be confusing and problematic in many cases to bundle Y clients? 
 +
** http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg09733.html
 +
** http://wiki.eclipse.org/Execution_Environments
 +
** Case by case decision by bundle developer?
 +
** Martin: Not practical to be forced updating my BREE when dependencies change, must be self-contained
 +
** John: Reusable module should minimize its own dependencies to maximize its own re-use (avoid making transitive dependencies explicit)
 +
** Ian: Also related to versioning discussion (avoid transitive need for updating)
 +
** Martin: Maybe only tooling is missing that analyzes the tree of dependencies and computes an "effective BREE" which may be different than the "design BREE" ?
 +
*** John: The OSGi resolver already has the ability to do that computation ... the difference is, right now it computes the "current requirement" but the new ask would be computing the "minimum requirement"
 +
*** Ian: Another question is "I want this system, can you resolve it on a 1.4 system"
 +
** Background was the question whether any claim to support 1.5 has been obsoleted with OSGi requiring 1.6 now
 +
** John: It's reasonable for a project to set a "minimum starting point" ... what should a project start with when doing a new plugin
 +
*** Could require Minimum-1.1 but that's not practical any more ... starting with 1.5 or 1.6 makes more sense these days
 +
*** Ian: eRCP was terminated a while ago, does anybody still run on J2ME ?
 +
** Martin: Maybe this is really about making recommendation / guidance for projects to go "beyond their own"
 +
*** Neil: New code at 1.6 ; not going to change old code that's been fine at 1.4
 +
 +
* From [[Execution Environments]]: The "smallest possible" is probably not good advice any more ... these days, "smallest practical" or "smallest tested" might be more appropriate
 +
** There is static analysis available to validate API compatibility ... but subtle changes might break at runtime
 +
** To some extent, testing in EE's is the responsibility of the consumers / product builders .. we can help them by not artificially breaking API
 +
** Better state the "version tested" separately from "lowest API"
 +
** Perhaps "lowest practical" is a good
 +
** Eike: implementing SPI interfaces against the BREE (JDBC connection interface had a major version jump in a minor version update)
 +
*** Neil: had a similar issue on Dali
 +
 +
* '''RESOLUTION:'''
 +
** Bundles should minimize their dependencies to maximize re-use : No artificial unnecessary increase of BREE
 +
** Bundles can't practically react to changes in their dependencies : No increase of BREE due to dependencies
 +
** We don't want unnecessary impediments for bundle developers - recommend "lowest practical" BREE as a compromise between producer and consumer (as of today, a 1.6 BREE probably makes most sense)
 +
 +
 +
==== Misc ====
 +
 +
* Martin: [[E4/Scripting]] initiative
  
  
=== General Topics ===
+
* Martin: '''AC to make more Architecture ?''' - ide-dev
 +
** We are not "process only" we can have technical discussions and give technical advice
 +
** just practically, we need people to sign up for it
 +
** In many cases, technical discussions will end up as a workgroup or mailing list, but can be initiated by AC
 +
** Please do continue bringing up technical topics !!
  
* '''Eclipse Infrastructure''' - git, Gerrit, Maven, Hudson, Bugzilla, ...
 
  
 
* '''Updates from the Board or the EMO'''
 
* '''Updates from the Board or the EMO'''
 +
** Been quiet over the summer
  
 
== Action Items  ==
 
== Action Items  ==

Latest revision as of 12:07, 12 September 2013

Meeting Title: Architecture Council Monthly Meeting
Date & Time: Thursday August 8, 2013 at 1500 UTC / 0800 SFO / 1100 Ottawa / 1600 London / 1700 Berlin attention DST change
Html.gifHTML | Ical.gifiCal
Dial-in: Let's use the Foundation's Asterisk setup for this call:
  • North America (toll free) 1-866-569-4992
  • Germany (local call anywhere in Germany) 49-692-2224-6059
  • France (local call anywhere in France) 33-17-070-8535
  • Switzerland, Spain, Sweden, others - see Asterisk/Numbers

Participant conference extension: 701 then enter pin: 51968

  • SIP clients can call 701@asterisk.eclipse.org, then enter pin 51968.

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 Wenbin He
DTP: Brian Payton Linda Chan
Eclipse: Mike Wilson John Arthorne
Boris Bokowski
Modeling: Ed Merks Cédric Brun
Sven Efftinge
Eike Stepper
Mylyn: Steffen Pingel Mik Kersten
RT: Christian Campo Tom Watson
Doug Clarke
Ian Bull
SOA: Adrian Mos Marc Dutoo
Technology: Gunnar Wagenknecht Wayne Beaton
Tools: Doug Schaefer
WTP: Chuck Bridgham Dave Carver
Neil Hauge

All Attendees

  • Signed-Up: John Arthorne, Wayne Beaton, Chuck Bridgham, Ian Bull, Linda Chan, Neil Hauge, Jonas Helming, Maximilian Kögel, Martin O, Brian Payton, Steffen Pingel, Michael Scharf, Eike Stepper, Krum Tsvetkov
  • Regrets: Christian Campo, Markus Knauer, Achim Loerke, Doug Schaefer, Tom Watson
  • No-Show: Chris Aniszczyk, Boris Bokowski, Nick Boldt, Cédric Brun, Benjamin Cabé, Dave Carver, Doug Clarke, Kenn Hussey, Mik Kersten, Ed Merks, Mike Milinkovich, Kim Moir, Adrian Mos, Andrew Overholt, Mary Ruddy, Tom Schindl, Gunnar Wagenknecht, David Williams, Mike Wilson

Agenda / Notes

Review of Last Meeting

New Topics

  • Welcome Maximilian Kögel Modeling, EMF committer, EMF Store Lead, EMF Client Platform Lead,
  • Welcome Jonas Helming: Modeling, e4 committer,

Dev Process Update

  • John: Dev Process Update
    • Wayne: Bugs are all there for review, please weigh in on the bugs
    • EDP Bugzilla Records
    • John: Wanted to simplify review docs etc but these are not in the Dev Process itself
    • Wayne: The implementation is far more flexible than the process ... can respond to specific feedback
      • Example: Release Review Requirements had listed 12-15 items, but these were meant only as guideline
      • Changes are OK as long as in the spirit - been trying to soften things over time
    • Want to make New & Noteworthy more useful and thus more prominent
  • Wayne wants a final draft for review by end Sept. - won't get to the board before 2014

Minimum BREE

  • Neil: BREE best practices regarding bundle dependencies
    • If bundle X BREE is 1.6 and bundle Y depends on bundle X, can bundle Y BREE be 1.4? In theory yes (and in practice sometimes this flexibility would be desirable), but it would also seem that this would be confusing and problematic in many cases to bundle Y clients?
    • http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg09733.html
    • http://wiki.eclipse.org/Execution_Environments
    • Case by case decision by bundle developer?
    • Martin: Not practical to be forced updating my BREE when dependencies change, must be self-contained
    • John: Reusable module should minimize its own dependencies to maximize its own re-use (avoid making transitive dependencies explicit)
    • Ian: Also related to versioning discussion (avoid transitive need for updating)
    • Martin: Maybe only tooling is missing that analyzes the tree of dependencies and computes an "effective BREE" which may be different than the "design BREE" ?
      • John: The OSGi resolver already has the ability to do that computation ... the difference is, right now it computes the "current requirement" but the new ask would be computing the "minimum requirement"
      • Ian: Another question is "I want this system, can you resolve it on a 1.4 system"
    • Background was the question whether any claim to support 1.5 has been obsoleted with OSGi requiring 1.6 now
    • John: It's reasonable for a project to set a "minimum starting point" ... what should a project start with when doing a new plugin
      • Could require Minimum-1.1 but that's not practical any more ... starting with 1.5 or 1.6 makes more sense these days
      • Ian: eRCP was terminated a while ago, does anybody still run on J2ME ?
    • Martin: Maybe this is really about making recommendation / guidance for projects to go "beyond their own"
      • Neil: New code at 1.6 ; not going to change old code that's been fine at 1.4
  • From Execution Environments: The "smallest possible" is probably not good advice any more ... these days, "smallest practical" or "smallest tested" might be more appropriate
    • There is static analysis available to validate API compatibility ... but subtle changes might break at runtime
    • To some extent, testing in EE's is the responsibility of the consumers / product builders .. we can help them by not artificially breaking API
    • Better state the "version tested" separately from "lowest API"
    • Perhaps "lowest practical" is a good
    • Eike: implementing SPI interfaces against the BREE (JDBC connection interface had a major version jump in a minor version update)
      • Neil: had a similar issue on Dali
  • RESOLUTION:
    • Bundles should minimize their dependencies to maximize re-use : No artificial unnecessary increase of BREE
    • Bundles can't practically react to changes in their dependencies : No increase of BREE due to dependencies
    • We don't want unnecessary impediments for bundle developers - recommend "lowest practical" BREE as a compromise between producer and consumer (as of today, a 1.6 BREE probably makes most sense)


Misc


  • Martin: AC to make more Architecture ? - ide-dev
    • We are not "process only" we can have technical discussions and give technical advice
    • just practically, we need people to sign up for it
    • In many cases, technical discussions will end up as a workgroup or mailing list, but can be initiated by AC
    • Please do continue bringing up technical topics !!


  • Updates from the Board or the EMO
    • Been quiet over the summer

Action Items

  • Cleaned up old action items, see Architecture Council/Meetings/February 10 2011 for old stuff
  • (old) Tim write up an initial wiki page with information for people to standardize on the tracing API
  • (old) Martin revise the AC Wiki to make it easier to find the New Member Process. More links on homepage. More usage of categories.
  • (old) Martin bug 315210 Make the AC mailing list open / moderated

Next Meeting