Architecture Council/Meetings/September 12 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 | iCal
|Dial-in:|| Let's use the Foundation's Asterisk setup for this call:
Participant conference extension: 701 then enter pin: 51968
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.
|DTP:||Brian Payton||Linda Chan|
|| John Arthorne|
|Mylyn:||Steffen Pingel|| |
|WTP:||Chuck Bridgham|| |
- 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
- Architecture Council/Meetings/August 8 2013
- Still open items moved to #Action_Items
- 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
- 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?
- 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
- 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)
- Martin: E4/Scripting initiative
- 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
- 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