Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: for the plan.

Jump to: navigation, search

Architecture Council/Meetings/June 12 2014

Meeting Title: Architecture Council Monthly Meeting
Date & Time: Thursday June 12, 2014 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, 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
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 Neil Hauge

All Attendees

  • In attendance:
    • Wayne Beaton, Marcel Bruch, Ian Bull, Jonas Helming, Maximilian Kögel, Martin O, Steffen Pingel, Denis Roy, Doug Schaefer, Eike Stepper, Krum Tsvetkov, Tom Watson
  • Regrets: Christian Campo, Neil Hauge, Markus Knauer, Adrian Mos, Gunnar Wagenknecht
  • No-Show: Chris Aniszczyk, John Arthorne, Nick Boldt, Chuck Bridgham, Cédric Brun, Benjamin Cabé, Dave Carver, Linda Chan, Doug Clarke, Kenn Hussey, Mik Kersten, Bernd Kolb, Achim Lörke, Ed Merks, Mike Milinkovich, Kim Moir, Brian Payton, Michael Scharf

Agenda / Notes

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

Review of Last Meeting

New Topics

  • LTS naming convention (Wayne)
    • LTS working group: How to identify artifacts that are produced by the LTS forges ? (for support scenarios)
      • Eg Open Source "Eclipse Project X" receives a bug report, but maintainer of "project x" has never heard about that version
    • Idea: Use JAR signing - have LTS forge use its own certificate (available for LTS members to use when bundles come from a "collaboration forge")
      • Plus, special kind of "qualifier" to indicate LTS (dashes/underscores could confuse some tooling; monotonic increase of version)
      • Plus, build ID (from the About Dialog)
      • Ideally, want something in the build infrastructure that doesn't count on an LTS committer making the right change
        • Ian: Could also just put verification into the build ("fail if qualifier doesn't end with -lts")
    • Ian: Need restrictions on what version digits may be increased by LTS (Martin: 3rd digit only)
    • Martin: "how obvious" does it need to be that the bundle comes from LTS (eg what about "Provider: Eclipse LTS") ?
      • Wayne: Concern was that this requires changing the source
    • EPL: Derivative work must be "made available" (typically/hopefully as patches back upstream)
    • Likely looking at a corner case here, since "lts customes" will come to their lts provider first. Bundle version number is most important.

Marcel: Update on Logging

  • GSOC is making good progress. Apache Commons, Log4J, and SLF4J are loggged to a EclipseLog appender. Configuration is done via logback.xml which is loaded from an expanded plugin folder. More details probably on the next meeting.

New AC Member Candidates

  • One from Ian
  • One from Doug/Andrew
  • One from Wayne

Simrel Cycle

  • Wayne: Much confusion with many projects; need to do a full evaluation and bring to the next meeting ... need to do better job on mentoring
  • Committer Hangouts looking good (with help from Richard Burcher)
  • EDP: "Releases" designed to be "major events", but for RT projects (Orion, Vertex) they want to release more often
    • AI Wayne - Bug will follow

Usage of Non-Singleton like Guava

  • bug 437107 Policy for shared non-singleton libraries such as Guava
    • Marcel: Commented on the bug, enforcing everyone use one particular version of Guava doesn't make sense
      • Adding "uses" constraints and import statements to "help" the runtime resolve properly is all we can do
        • As specified in OSGi, and there's also a button in the IDE to add "uses" directives
      • Recommend doing a "compatibility test toolkit" to ensure missing "uses" etc are discovered
      • It's in the interest of consumers to have tested for compatibility and feed feedback into providers
    • Eike changed Guava requirements for CDO (boradened it a bit), submitter confirmed that this solved the problem
    • Wayne: But we have a PC Simrel requirement that one version of each 3rd party lib must be used (to reduce footprint etc) ... isn't that enough ?
      • Marcel: Sometimes can't enforce exactly the same ... because eg newer guava introduced an 1.6 BREE but some projects required an 1.4 BREE

Oomph Update

  • Doug played with it ... it does more than traditional installers --> defer to a separate discussion
  • Might consider a special download link on the downloads page (because it's an alternative to downloading ZIP's)
    • Mike M. would appreciate this, but would require good backing from the AC, PC and EPP
    • AI All Review info on mailing list and comment there


  • Krum signed up for 2 projects as 2nd mentors but never got any requests ... is this normal ?
    • Wayne: For most of us, "mentoring" is just "answering questions"
    • Locationtech may need some more pro-active help, they come from a very different community

General Topics

  • Eclipse Infrastructure - git, Gerrit, Maven, Hudson, Bugzilla, ...
    • CDT HIPP instance had some hickups this week (seemed like ran out of RAM)
    • Denis: 10 HIPP's shared per server, 8 Gig for each ... did not notice anything out of the ordinary
    • Denis: Projects can restart their HIPP in case of anything really problematic
    • Denis: One problem is that lots of projects set up their git triggers to "every minute" that can cause quite some load on the git servers
      • (probably 60 sec is the default!) Suggest polling every 5 minutes instead
      • Doug: Would be great if Gerrit jobs could "trigger on push" rather than polling
      • AI Thanh send out an E-Mail to projects
  • Updates from the Board or the EMO

Action Items

  • No new 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

Back to the top