Architecture Council/Meetings/September 12 2013
< Architecture Council | Meetings
Revision as of 10:58, 12 September 2013 by Martin.oberhuber.windriver.com
|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.
|BIRT:||Wenfeng Li||Wenbin He|
|DTP:||Brian Payton||Linda Chan|
|Eclipse:||Mike Wilson|| John Arthorne|
|Modeling:||Ed Merks|| Cédric Brun|
|Mylyn:||Steffen Pingel||Mik Kersten|
|RT:||Christian Campo|| Tom Watson|
|SOA:||Adrian Mos||Marc Dutoo|
|Technology:||Gunnar Wagenknecht||Wayne Beaton|
|Tools:||Doug Schaefer|| |
|WTP:||Chuck Bridgham|| Dave Carver|
- Eike Stepper, Krum Tsvetkov, Jonas Helming, Maximilian Kögel, Martin O, Ian Bull, Chuck Bridgham, Brian Payton, Steffen Pingel, Linda Chan, Wayne Beaton, John Arthorne, Michael Scharf, Neil Hauge
Agenda / Notes
- Feel free to edit, but not during the call!
Review of Last Meeting
- 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 !!
- Eclipse Infrastructure - git, Gerrit, Maven, Hudson, Bugzilla, ...
- 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